Web Diplomacy

So the cold war between KHTML and WebKit heated up a little again, this time the enemy isn't Apple, but former KHTML developers, and KDE personas. I will spare you the links, since it is all too embarrassing.

As someone with a leg in both camps, I will try and explain what is the real issues are and suggest a road map for peace.

Since summer 2006 there have been active attempts to remerge KHTML and WebKit, or simply switching to WebKit. It started because Apple had started a process of opening up WebKit and creating a real open source community. In the beginning the effort was driven by George Staikos who started the Unity project. We discussed several solutions and requirements for KDE, and even wrote a list of demands for Apple. The list ended up a little too bureaucratic, and was rejected by Apple, but George kept going and tried to create a workable solution for both KDE and Apple, but at some point he gave up. During 2007 the Qt-version of WebKit keeps improving as Trolltech turned up their involvement, and at aKademy 2007 in June, Lars Knoll announced Trolltechs plans of including WebKitQt in Qt 4.4. We had a few meetings, discussing all kinds of solutions, but reaching no conclusion. After aKademy the discussions stopped, and no progress is made, until suddenly Troy published some of the discussion. This created a problem, since it was now "official" that KHTML will switch to WebKit, but we still had no idea how to solve the practical issues. Several months later a few KHTML developers responds with the FAQ that started the latest debacle.

So what are the practical issues, why haven't we agreed on what to do?

In the perfect world of helpfull magic fairies, we would dump KHTML and port all improvements from KHTML over into WebKit, but as all the trouble surrounding KDE 4.0 has shown so perfectly, the development model of "dumping stuff, replacing it with a good idea and let the magic fairies do the rest" has serious real world issues.

We would like several things:

  • Binary compatibility: Practically impossible, but if we fix the KDE applications to just use the kpart interface we should be safe.
  • Feature compatibility: Hard, requires porting many improvements, and Apple are reluctant in accepting patches.
  • No bug regressions: Practically impossible. There are too many changes on both sides, and going through 5 years worth of patches is not anyones idea of fun. On the other hand, bug-for-bug compatibility with Safari might be worth more than having few bugs.
  • No speed regression: Hard, requires porting many improvements, and the WebKit has a very different understanding.

These are just the KHTML work, then there is the surrounding work:

  • Making WebKitQt work in a KPart (partly done), integrating it with KDE image viewers, integrating it with KDE settings, integrating it with KDE plugins, integrating it with KDE applications.
  • Syncing releases or branching. If we have to commit a patch to WebKit, wait for WebKit to release with the next version of OS X, and wait for Trolltech to release that with the next version of Qt, we are in for some very long and unsatisfying turn-around times.

What happens if we don't solve these issues?
Remember the key phrase in aseigo and zrusin's blogs? "Let the market decide".

Well KHTML is actually not in a bad shape, we have excellent standards support, unbeatable performance and pretty good support of most MSIE- and Firefox-extensions used on the web. We only miss a few features like contentEditable and native-SVG, but the sites that use these are still very limited. Most of all, the few sites that fail in Konqueror fails because they don't recognize us.

Unfortunately this is enough for several KDE distributions to default to Firefox instead of Konqueror. With a 3rd party WebKit KPart available, these distros will likely replace Firefox with Konqueror+WebKit, but what will the rest do? I don't know, but the risk of losing a well-integrated web-component and much work is too big.

What do we do?
Well, right now the answer is simple. We are busting our ass to make KDE 4.0 the best KDE release ever, and since KHTML is all we've got, we are making it the best we can.

What do we do after KDE 4.0?
We have two options: Keep improving KHTML, or try and make WebKitQt good enough to replace it.

Improving KHTML is actually not that hard. WebKit has both SVG and contentEditable, and we are so experienced in both trees, that merging is a fun one week project. Still we are going lack hype.

At least trying to work with Apple is certainly a good idea. I've been submitting patches to Apple since November 2006. The first patch was finally merged in just a few weeks ago. Most patches was rejected over white-space. I thought it was a bit silly to send a 200-line patch back to me just to force me to change one line from "Element *node;" to "Element* node;", so for a long time I let the patches sit with Apple to see if they actually wanted contributors or just free employees. However after aKademy, I gave in and started resubmitted my patches closely following their KDE-like, except anal coding-style. Things are moving, but at a pace no one can be satisfied with.

Trying to work with Trolltech is another good option. Trolltech is running a Git branch of webkit that they sync and submit from regularly. Git has the distinct advantage of making it easy to merge individual patches between different branches. Where a branch in subversion would likely end up as a fork, a Git branch is more likely to just stay a branch. Trolltech is trying something completely new with Qt 4.4, it will contain both Phonon and WebKit, both projects developed outside of Trolltech. Phonon is primarily developed in kdelibs, and WebKit at Apple. Finding a solution where Trolltech could provide a branch of webkit that KDE could use and sync with our release, might make sense.


Disagree on one technical matter:

1) Binary compatibility for KHTML is non-negotiable (for KJS? /sigh/)
2) It's also very much doable. The DOM APIs
are all pimpl'd, KHTMLPart has a d-pointer, etc.
3) You can not "fix" applications to just use the KPart interface. They rely on the DOM, as well as the security APIs.

And I'd say porting testregression would have to be the first step regardless. Then you go from there.

And, well, Qt != KDE, so whatever half-integrated stuff TT ships will not do. I also don't see much of a point of working with their git, since the renderer is the more interesting part; the platform bindings should be pretty stable (and we need different ones, anyway).

By Maksim Orlovich at Fri, 10/26/2007 - 14:52

So, in other words, it's going to be a choice between WebKit and KHTML? Well, WebKit sure beats Firefox (which I have to use now to know things work) so if there's going to be a WebKit browser, I'm gonna use that. Looking forward to a good KDE browser which works fine with Youtube, Gmail etc :D

By superstoned at Fri, 10/26/2007 - 17:57

1) Binary compatibility for KHTML is non-negotiable (for KJS? /sigh/)

I don't really see why this shouldn't be possible. KHTML could be left as-is, and QtWebKit-using software can be brought on later.

2) It's also very much doable. The DOM APIs are all pimpl'd, KHTMLPart has a d-pointer, etc.

Why bother when you can get Qt to do the work? After all, that is why KDE uses Qt.

3) You can not "fix" applications to just use the KPart interface. They rely on the DOM, as well as the security APIs.

Then you can just leave that as-is and have the QtWebKit parts come in later.

And, well, Qt != KDE, so whatever half-integrated stuff TT ships will not do.

KDE has always leaned on and extended upon the work of Qt. It's mostly why KDE has as good an infrastructure and applications as it has. I fail to see why that should be different in this case. You could even probably cherry pick what works well in QtWebKit and expand upon it.

Others have said that the market will decide. I'll be blunter. The most widely used engine will be that which can render and display the vast majority of web sites without anyone having to close bug reports telling people to whine to web developers to change. Hint: Odds are, it isn't going to be KHTML.

By segedunum at Fri, 10/26/2007 - 21:56

KDE apps should not use QtWebKit, just like they should not use QFileDialog, or any of the other of zillion things in Qt that do not integrate properly. KDE apps are written with KDE libraries, not with Qt only.

By Maksim Orlovich at Fri, 10/26/2007 - 23:47

.. there are many Qt classes which we simply build upon. in fact, that's much probably common than writing our own from scratch these days. in the same pattern, there will be a KPart for QtWebKit.

By Aaron J. Seigo at Sat, 10/27/2007 - 03:08

> force me to change one line from "Element *node;" to "Element* node;"

I actually kind of wish KDE would include rules like that in its coding guidelines. When I started writing KDE code I remember looking specifically for guidance on this topic and finding none.

By vladc at Fri, 10/26/2007 - 17:57

The reason is that it doesn't matter. Both are equally readable and clear, so making a rule or enforcing such a rule, is a complete and utter waste of time. If reading something like that confuses you, you shouldn't be reading code in the first place.

By Allan Sandfeld at Fri, 10/26/2007 - 19:51

There is an another thing, though: when I am accepting a patch from someone and it doesn't match the coding style in some minor way, I just adjust it myself. No reason to bug a contributor over trivialities.

Worse, I think this sort of nitpicking distracts from the real purpose of the review process.

By Maksim Orlovich at Fri, 10/26/2007 - 21:51

Both are valid. I prefer to have the former rather than the latter though (I can't imagine Apple's reasoning), and sometimes you will see space on both sides of the *.

By segedunum at Fri, 10/26/2007 - 20:57

If we ever want a good WYSIWYG style editor in Quanta, we need to access the DOM tree directly. So - from our POV - the KHTML API should be public and BC across minor KDE releases (at least after 4.0, as we won't release Quanta with KDE 4.0). But as I stated on a kde-core-devel thread, I'm all for BC across whole 4.x cycle for libraries that are in kdelibs.

By amantia at Fri, 10/26/2007 - 20:41