16

About a Blog from Aaron Seigo: http://aseigo.blogspot.com/2010/01/key-quest-webkit.html

I think, that he is right for most of it, but i don't believe, that a change from KHTML to WebKit is good for KDE.

My first thought ever is and was: why can the KDE project rely on an external project as an foundation (used everywhere in KDE). The next thing was about arts ... hmmh what have been done ... lets thought about it ...

I'm no KDE-Developer and so i won't assume to tell the developers in which direction it goes, but:
i am a developer and i see it everywhere: for a quick solution it is most often used to make a workaround than to find the real problem and when this will happen more often in WebKit and it will run to an dead end ...

A solution could be the library "KDE WebKit" as an interface like phonon ... the user could switch between WebKit or KHTML and the KHTML-developers have the challenge to implement it (what's missing).

I don't like it, if some very enthusiastic developers are thrown out. Only some few numbers from http://khtml-konqueror.blogspot.com/
2008 -> 102 commits
2009 -> 355 commits
2010 -> 43 commits and it's only January
i don't know, if this are the right numbers, only taken it from that site

Conclusion: my brainstorm idea is, make an interface for the HTML-usage in KDE and let the user select between KHTML or WebKit. There could be all other solutions ... and if it will be the Gecko-engine ... but don't don't believe that WebKit is the only one ... (selection, when KHTML have a solution for all Plasma-problems ...)

Thank you everybody for reading this (i hope its readable) and please vote for it.

I think that your idea is similar to this idea:
brainstorm.php#idea38873
But I'm not sure if it's duplicate...
Check the other idea and report if it's what you want or not.

This is only a part of what i mean.

Until now, it seems, that Plasma relys on QtWebKit and thats very WebKit-centric. If you want to use KHTML only you have to use WebKit because Plasma uses it ...

My idea is, that there will exist an library for common html-engine functions that are used in KDE SC and are written in an KDE interface lib (interface like class). One of the (until now the only) implementations is in QtWebKit but there could be any other (and possible better) solution.

The big advantage for KDE is (not for now, but maybe in a few years), that, if WebKit fails and there is a better solution (could also be KHTML), KDE SC can work in implementing the interface for an other engine ...

I know this idea is not visible for the user, but i think this is exact thats why phonon is written (see Arts) and this is just the right time for this idea, because most programs (i think, don't know) are just using KHTML and Plasma is using QtWebKit but there are great efforts are to take it down to one ... and i don't thing WebKit should be the only one ...

An as a bonus: the KHTML-developers are not thrown out an could deliver a better solution ... maybe, i hope so ...

I do not understand why people vote against this idea.
It would also be good for WebKit. Why? It would be easier to use WebKit in applications like KMail or KHelpCenter and it would be possible to use the KHTML-plugins in WebKit and future WebKit-plugins could be used for KHTML.
The development of a common interface would be a good job for KDEWebKit and KHTML.
+1

+1 as well.

I don't think KHTML should be removed or made redundant by Webkit: I just think that the goals of the KHTML team should be revised.
In the past, the goals seemed to be to make a lightweight, powerful, fast and standards-compliant HTML/JS rendering engine. This goal has been a huge success called Webkit, and lots of people seem to agree that it is one of the best rendering engines available.

I think the KHTML team could change its goal to be more centric with the rest of KDE: to bring the web closer to the desktop, and to integrate it more seamlessly. That is why I want to work on KHTML in the future, because that's the goal I am tempted towards and I know quite a few cool things that could be implemented in KHTML which might be harder with Webkit, simply because we control the code.

I had a similar idea that I wished to propose. That KHTML would be used as WebKit wrapper. Just that here's WebKit the main engine and not KHTML. But idea is the same.
+1

I agree with the idea - smthing should be to webkit, gecko and others like phonon is to pulse, oss, alsa etc... Something like a wrapper...
And the big holy war will be finished for KDE
+1