WebKit

I'm glad to see discussion about web content in KDE, spurred on by Will Stephenson's posting on the matter. A couple years back I attempted to get QtWebkit and KHTML working together and failed utterly and miserably. Shame on me. Today's situation, which Will outlines, is a result of keeping the status quo since then.

Many others have weighed in on the matter since, and it seems there are huge numbers of comments on each of these blog entries. I haven't read the comments as I don't have time to do so today (I have a couple hours to close out some bugs I want to kill and then I have to dash out to the outskirts of the city for a farewell dinner) and I'm not sure I even want to open that Pandora's box, to be honest.

For those who are discussing it, here are some thoughts that rattle about in my head, in point form, that others may find useful in the discussion:

• This has nothing to do with Konqueror beyond "we'd like to use Konqueror, so we need a suitable rendering engine for it". The discussion is really about web rendering stacks.


• That we need to have this discussion says nothing negative about the KHTML developers, their efforts or those who use KHTML. The people working on KHTML enjoy doing so, have their reasons for doing so and do great work. They can and should work on KHTML for as long as they enjoy doing so.


• The discussion should remain centered on what application developers need and what our users require so as to make decisions that serve those ends properly.


• There are two contexts for web content: web browser (e.g. Konqueror) and application usage (we use web content in Plasma, throughout Kontact, in application intro screens, in some control panels, in educational apps, in ... a lot of places). These two contexts may not have the same answers. There is C++ API currently missing in QtWebKit that make it not a great option for some applications (though it seems Qt 4.6 is addressing a lot of this issue), but which is pretty well irrelevant to its use in Konqueror as a web browser. There are vice versa examples as well. So keep in mind that there is not, at least not right now, a "one size fits all" solution availalble to us and the discussion ought to reflect that. We need to pick the right answers given the specific questions.


• The reality is that some applications are already using WebKit, so this isn't particularly revolutionary.


• Equally real is that KHTML will be with us at least until KDE 5 and there will be users of KTHML for quite a while yet no matter what happens.


• QtWebKit is not perfect. It's moving forward nicely in Qt 4.6, but to be perfectly blunt: I am disappointed with its progress to date. I had hoped it would be much farther along than it is now. I see all kinds of cool demos for it, but it's mostly for embedded application and usage. We aren't testing it enough on the desktop and we aren't creating enough pressure to move it forward in those directions. Those responsible for QtWebKit would, imho, be wise to put more human resources on it as well.


• The biggest asset WebKit has going for it is broad usage and broad development by numerous entities. The web has become stupidly complex and is ever evolving; it needs a large developer base to keep up, and this is why WebKit works "better" than KHTML on today's "web 2.0". (As a related aside to the Gtk+ WebKit developers: naming your library libwebkit is not only ballsy it's downright ridiculous, divisive and offensive. It's a shameful decision.)


• Here's the most important point, and thus the one I'll end with: this discussion will not matter one little bit in the least unless people commit to a solution and write code for it. Words are great, but they are just words. It is the effort that turns those words into something that matters. You don't have to ask for permission to work on something, either. Just do it, where "it" in this case is the webkit part in playground/libs/webkitkde.