Again and again
June 30, 2009
Disclaimer: The content of this blog post expresses only the position of its author, and not the position of anybody else (esp. not the position of any project that the author is involved in). If you do not understand that, stop reading now, please. Thanks.
The discussion about KHTML vs. Webkit does not end, with Will Stephenson proposing to make “a widely used web engine that works” (which means Webkit most probably) the default in Konqueror.
Webkit integration has been discussed throughout the KDE community at least since when Qt 4.4 brought built-in Webkit support in early 2008. Yet nothing has happened. Apparently, nobody really felt the urge to scratch an itch on Konqueror’s Webkit integration (apart from the rudimentary Webkitpart in playground). Okay, there is Rekonq, but I see little added value in shipping a separate browser together with Konqueror. The partial disintegration of Konqueror’s file management into Dolphin is logical, because a file manager needs a whole different interface than a web browser, but I find it pointless to split a web browser off the web browser Konqueror. And not shipping Konqueror with the kdebase package is not an option, either. Konqueror just belongs to KDE as Nautilus belongs to Gnome, or Safari to Mac OS.
So let’s have a more detailed look at what people don’t like about Konqueror. A commenter on Will’s blog agreed to him, saying:
Every time I [try Konqueror] I remember the cool features it has but every time I find myself slipping back to firefox because it is just easier. The web just works.
Curiously, for me, it’s the other way around: Every time I try Firefox I remember the cool features it has but everytime I find myself slipping back to Konqueror because it is just easier. The web just works. Okay, I’m not using funky bling-bling Ajax sites that much, but my WordPress editor works since KDE 4.1. For example: Firefox needs 10 seconds for a cold start (even with all plugins deactivated), while Konqueror is ready for my input when I release the Enter button. And even more curiously, the Flash player Just Works™ in Konqueror, with Firefox not finding it sometimes (although it is correctly installed in /usr/lib/browser-plugins).
Please do not misunderstand this as a rant against Firefox. Firefox has achieved very much for F/OSS in general, and all of my issues with Firefox could have to do with misconfiguration. I just want to fight against the common misconception that Konqueror is a piece of crap. Of course, I do not accuse anyone of having said that, but I feel a general mood of disregard against Konqueror.
I just do not see anything in Konqueror that is broken by design. There are just many areas where Konqueror can certainly improve:
Will means that we should move bookmarks more into the focus of our integration concerns. At least, that is what I read from “Firefox bookmarks are separate and completely ignored by all KDE’s cool semantic technologies like Nepomuk. They could be indexed, sure, but since we’re the integrated Free Desktop environment, why do lists of bookmarks have to be glued to the app they came from?”
This is actually a great idea, and incidentally, KDE developers are working on something like that right now: GSoC student Eduardo Robles Elvira is creating a new Nepomuk-based and Akonadi-powered bookmarking framework for Konqueror (together with a new location bar similar to the Awesomebar). These bookmarks could easily be displayed in a separate application. Also, a discussion is taking place on the kde-devel mailing list on connecting Nepomuk to Gnome’s Zeitgeist, which I expect, sooner or later, to be utilised by Firefox.
- Another interesting question is the integration of scripted extensions in Konqueror. We have working solutions e.g. in Plasma (where applets are basically plugin libraries), but I’m quite sure that the internal APIs of Konqueror would have to be cleaned up beforehand (because it’s much harder to change them when extension writers are already using them).
- Konqueror could use some interface cleanup (e.g. the settings dialog). Also, I think that we took it too far with the KParts. The KParts library is certainly a good technology, but we got just too many of them. The usage of KParts in Konqueror should be limited to those that really handle a specific file or directory or URL. That means, the dolphinpart, khtmlpart and okularpart can stay, while e.g. kjotspart and klinkstatuspart should not be displayed in Konqueror. After all, what is the point in having an application load inside Konqueror instead of in a separate window if it has nothing at all to do with Konqueror? Klinkstatuspart for example does not even do something with the URL I give to it via the address bar, it brings its own URL entry field. Some service menu cleanup is also desirable, there is no point in each and every context menu offering a checkout with KDESVN, even for simple links.
Last but not least, there is the big question of which browser engine to use. I favor KHTML, because we ship it anyway (and because of binary interface compatibilty, we can’t simply remove it in some minor release, i.e. before KDE 5.0), because I personally like its convenience features (such as those “access keys” which you activate through the Ctrl button), and because its rendering currently looks prettier when compared to Webkit. (I don’t know what it is exactly, but the text feels warmer.)
Actually, I’m quite confident that the KHTML team can keep up with web developments, even if they have fallen behind a bit these days. Okay, you’re right that I’m reading tea leaves here. One can never tell what future brings. The only thing I can tell you is that nothing is going to happen until we stop to beat about the bush and start working towards a better solution.