OCT
26
2007

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.

Comments

when do i get a khtml that can paint to a QGraphicsItem?

and really, i think you paint far too rosy a picture as to the difference between webkit and kthml from a development effort and technology perspective.


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

Doesn't Qt4.4 support showing widgets as QGraphicsItems?

And how do you get a QtWebkit that uses standard KDE dialogs, icons, context menus, KIO (including network settings such as proxies, etc.), KSSL key management policies, KCookieJar, KParts + KJava + nspluginviewer + plugin scriptability, etc, etc, etc.?

P.S. The Qt canvas support in current webkit SVN sucks, and lacks lots of basic operations.


By Maksim Orlovich at Sat, 10/27/2007 - 03:20

I don't think most Distro's make Firefox rather than Konqueror the default because they think Gecko is waay superior to KHTML. It's more like "People know Firefox" and, most importantly - and that's unfortunately the thing that's also holding me back from using Konqueror full-time - Firefox has tons of extensions that do very useful things. Konqueror does not. That doesn't mean that Konqueror is useless - I love it, it's fast and very well integrated into KDE - it just lacks features which are very easily obtained for Firefox. Kind of sad, really.


By jstanzel at Sat, 10/27/2007 - 14:27

I'm going to have to agree. The reason people use Firefox over Konqueror is because of the extensions. I know Konqueror can do extensions too; the problem is, I asked about Konqueror extensions, and no one could give me any links and/or info about how they're supposed to work. OTOH, there are many, many tutorials for creating Firefox extensions around.


By dark phoenix at Wed, 12/12/2007 - 03:44

First of all I must admit I'm just a user ( and big fan ) of KDE. I haven't got a very good idea about the internals and how things work. I do plan on finding out more and maybe getting involved but for now I'm just a user as I said.
What I don't understand and maybe someone could explain this is why we can't have both KHTL and WebKit in KDE and maybe even in Konqueror.
From a user's point of view I must say that as much as I love KDE and KDE apps Konqueror is pretty much useless to me. I'm sorry to say this , I respect the people that work for it and being a junior programmer myself I understand it's hard work. However when you have a browser that doesn't really work in real life situations what's it good for then ? I can't use Konqueror because this page doesn't work and then that page doesn't work and then that's broken and .... Also no Firefox extensions isn't very nice and the search could be an embedded one ... . But the main thing is that sites don't work , it's hard getting some to work even in Firefox but for Konqueror many are broken. So then I end up opening up Firefox which doesn't really integrate well in KDE but I have no choice , it's a better browser at rendering web pages and that's what a browser does after all. I know Konqueror is supposed to support the standards well and this and that but ... :(
From my point of view the move to WebKit is a must , unless maybe you prefer Gecko ? KHTML just can't make it , it will never be mainstream IMO, not anytime soon anyway. So at the end of the day do you want to have a cool project and be proud of how cool KHTML is and how nicely it integrates with KDE or do you want something users can actually use and not have to open up Firefox in KDE ?
Can't KDE deal whith both rendering engines for a while , at least until WebKit is better integrated ? Can't Krusader use 2 rendering engines ? Sure , it's not a very elegant solution maybe but still .... Also about binary compatibility , I don't think it's such a big deal , the API remaining the same could be but still ... After all we're in Linux , we do have the source code for things and we can modify , recompile , right ?
From what I know Nokia uses WebKit for their phone browsers and if they can do that with WebKit then I think it's not impossible to integrate it into KDE , is it ? And why does it have to be in sync with the Apple WebKit ? KDE could always use just the base of it and extend it to its own requirements , right ?
Sorry not being more concise and my lack of technical knowledge. I'm not trying to offend anyone and I know many people know better than me. I also respect the work done by the KHTML developers and I respect them. I'm only sorry I can't really use their work for my needs.


By mcirsta at Sat, 10/27/2007 - 21:51

Pages