JUL
1
2009

A QtWebKit KPart is no answer for a KDE browser

Disclaimer: I have no desire to re-ignite KHTML vs WebKit arguments. Rather, the purpose of this blog post is to hopefully enlighten a technical question.

Over the last few months I've heard many KDE developers in various forums bemoan the lack of a working and stable WebKit KPart. The motivation behind this complaint seems to be that KDE folk want a WebKit browser option for KDE. Thus the naive solution is to just get the WebKit KDE KPart in shape. Given this motivation... the solution is wrong IMO.

I can speak from some experience here. I've been working on QtWebKit for quite awhile and have also worked - in the past - on the WebKit KPart plus Konqueror integration that Simon started. For a time, it was building and running just fine. You could install it and change a configuration file and Konqueror would render using QtWebKit. However, the integration was *far* from complete. Plumbing the sources of Konqueror I learned a nasty secret: Konqueror is highly KHTML API specific. Konqueror has deep integration with KHTML that goes far above and beyond the KPart API. Creating a QtWebKit KPart is woefully insufficient for the purpose of providing anything more than a basic HTML viewer.

A simple HTML viewer is no where close to a fully modern desktop browser.

This all makes sense if you stop to think about the history of Konqueror. Konqueror is a generic desktop shell. It is designed to allow basic viewing of various documents in various formats. Of course, it has become much, much, more than that. And the key to this growth of features is Konqueror's steady adoption of API's above and beyond the generic KPart API.

Which brings me to my point: if parts of the KDE community truly want a modern browser based on QtWebKit they'd best be looking at solutions beyond Konqueror. Otherwise you are left with two hacky solutions: make a QtWebKit KPart that is API compatible with KHTMLPart OR migrate Konqueror source to make it less dependent on KHTMLPart. The former is not going to be fun as the KHTMLPart API is not refined or polished and highly KHTML specific. The latter can only be accomplished with a lot of work set aside for refactoring or through nasty '#ifdef KHTML callThisWay() #else callThatWay();'

Both of these solutions are sub-optimal in my opinion.

Comments

just port web-shortcuts feature to arora, and integrate it with kwallet, and I will apt-get remove konqueror


By shaforostoff at Wed, 07/01/2009 - 22:26

If you set arora as your default browser, you can do Alt+F2 and use web-shortcut from there, it will open arora with the correct web-shortcut. Works with me on firefox.


By patcito at Thu, 07/02/2009 - 02:35

rekonq is like arora (also based on the QtDemoBrowser) and intends to be integrated nicely into the K Desktop.

I think Arora should just stay a Qt-only browser and the two projects should exchange code wherever it makes sense.


By maestro_alubia at Fri, 07/03/2009 - 13:37

Very interesting take on things, thanks for it. It's good to hear that the Webkit KPart isn't ready just because people can't be bothered to write it.

With your experience what do you see as the solution for web browsing in KDE?


By Mike Arthur at Wed, 07/01/2009 - 22:27

I use Arora. It is already based on WebKit and has one of the cleanest code bases you'll find in all of KDE land. It was originally spun out of the demo program by Benjamin Meyer while he was working at Trolltech. He now works with me and has continued to improve it. Add some KDE integration and I think it is a great solution for web browsing on the KDE desktop.


By Adam Treat at Wed, 07/01/2009 - 22:36

rekonq is like arora (also based on the QtDemoBrowser) and intends to be integrated nicely into the K Desktop.

I think Arora should just stay a Qt-only browser and the two projects should exchange code where it makes sense.


By maestro_alubia at Fri, 07/03/2009 - 13:36

That means it will have to be either Firefox KDE integration or Arora or Rekonq that solve the problem. Most users had reached that conclusion already, but this post adds yet another basis to that claim.

Thanks for clarifying that.


By tobami at Thu, 07/02/2009 - 07:28