Skip to content

If the Qt WebKit KPart is not answer for a KDE browser, why does it seem to (kind of) work for me?

Saturday, 4 July 2009  |  lubos lunak

This may look like beating a dead horse, but it seems like many people discussing the WebKit issue not only actually don't have much of a relevant technical knowledge, but even fail to simply do a reality check. Because I have tried the WebKit KPart and while I can't say it worked perfectly, it worked. I don't see why I should even myself feed my personal data to Google or what's the point of suddenly needing a webpage for friends, so no GMail of Facebook, but I tried a couple of sites, including YouTube or using two online bank systems to make payments, and I mostly got done what I wanted to get done. Ironically the worst breakages I found were search on or Martin Graesslin's blog, which possibly may be bugs in WebKit itself. Not that I tried that hard to break it, but after all, you can try out WebKit in Konqueror for yourself (openSUSE users can get the WebKit KPart from the KDE:KDE4:Factory:Desktop repository together with the rest of KDE4.3RC1) Change the association in 'keditfiletype text/html' or temporarily in Konqueror's View menu.

Now, I'd like to stress the part about it not being perfect now, not even close. It worked, it was usable, but it had some pretty rough edges. Still, I have to wonder more and more why really it takes so long to get the WebKit KPart ready.

Some opinions on the alternative ways of using WebKit in KDE seem to me to be rather confused too. One doesn't even need to actually try Arora or Rekonq (and I haven't, to be honest) to realize that neither of these is a suitable candidate for a KDE browser, at least now. Arora has no KDE integration whatsoever, nor does it plan to have it from what I understood. It may be a fine browser otherwise, but this completely rules it out as the KDE browser. And Rekonq, or any other Arora fork, first needs to do the KDE integration. That may happen, and this browser may even become the web Dolphin, I just don't think it's less work than having the browser already done and only doing the KDE integration for WebKit. Especially given that KDE integration for WebKit in Rekonq or Konqueror should be basically one and the same thing (code reuse, remember? we are known for it).

As for the blog entry I'm referring to in the title, there possibly may be parts in Konqueror that are written with KHTML in mind, if nothing else because until WebKit KPart there was only KHTMLPart, but it is definitely not the design. If we could switch the file browsing KPart in Konqueror to the one from Dolphin, why should it be a big problem to use another HTML rendering KPart? And while I have digged a bit in Konqueror and WebKit KPart sources, I consider myself to be no Konqueror, KHTML or WebKit expert, so let me just point you to what David Faure says about it.

Really, we have written a lot of good code and invested a lot of time into it. We shouldn't just randomly dump it because everybody and their grandmother think it is a good idea. If we do so, it should be because there are technical reasons. This really reminds me a lot of the KWin vs Compiz problem we had before KDE 4.0. Does somebody still think these days that we should have dumped what we had working for the new kid on the block? If you do, I suggest to do a reality check there too.

Oh, and this blog entry would be 100% written using Konqueror+WebKit, if it managed to post it (ok, so this is ironically the worst breakage I found, life is funny like that). I said it wasn't perfect, there is still work needed. I just still haven't found a good reason why this would be a bad decision or even not reasonably doable.