User-Centred: Stop Continual Web Failure

KDE needs as an entire project to support a Web browser that everyone can use in 2009. That's the simple message behind this blog entry and my talk at LinuxTag on Saturday.

If you need any more motivation to go out there and make that happen, read on.

I have to admit that as a KDE user for the past ten years and a developer for 8 years, I'm writing this blog on Firefox right now. What do 95% of desktop users actually do after they log in? They consume content. That means they use Firefox, use Firefox, use Firefox, use Firefox, and while they are at it they may listen to music using Amarok. Unless you are reading this in lynx, you know what users are doing - webmail, social networking, youtube, microblogging, editing online documents, uploading to their photo collection, using intranets.

Anything else they do using a fat local app is pretty much incidental nowadays - using at best, what we used to call 'utilities' to patch their system or change the volume level.

If a desktop or an operating system doesn't have a well integrated web experience, users have no reason to stick around.

Details. KDE always has been network-transparent environment. Our apps can just as easily pull content from a web server as load it from the hard disk or save it back to an FTP site. But Firefox has a completely separate network layer. Passwords, cookies, sessions are all separate and insulated from KDE and have to be managed separately if you want to use KDE apps, which is hassle.

File associations are managed in most Firefox versions by GVFS now, which means that if you have any g* apps installed, they will be Firefox's first pick to open links to movies, PDFs, and music files you click. If you are a curious user who installed the whole distro DVD, if every time you view a PDF in KDE, Evince shows up, why bother logging into KDE?

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? KDE should have a single Bookmarks app letting users see where they currently are in all their content - Web stuff, documents, podcasts, videos, even Konsole sessions.

And many other smaller integration points break. Try 'Set as Background Image' for example. Firefox saves downloaded files in one directory. Chances are it isn't part of the fancy Places list in the KDE file dialog - another wasted opportunity.

I have nothing but respect for the KHTML developers. They do an amazing job with very few resources, creating fast, efficient code. But although KHTML is 'pretty good' that is just not sufficient for real world users. I tried a selection of modern sites with trunk on Saturday and the majority of them had rendering or ajax errors that provoke a WTF reaction among anyone not very close to the KDE project. The blame for this is almost certainly with the site developers, but a reality check says that they will never test for KHTML and never fix it.

So I suggest, as strongly as I can, that KDE gets behind a widely used web engine that works, puts it in Konqueror, integrates Rekonq, and makes it all work as well with the rest of KDE as Konq+KHTML did. I don't think this even changes anything for the KHTML developers - the same tiny subset of KDE users will continue to choose to use Konq+KHTML, but the majority will be able to have a web experience that strengthens KDE, rather than weakening it.

By not having an integrated browser that anyone uses, KDE is on the same path to irrelevance that Microsoft started when they ignored the World Wide Web in the mid 90s. Apple gets it, Microsoft now gets it, GNOME gets it. Yet KDE continues to look away from this unsightly hole in its portfolio.


I strongly agree. The current user experience (for the non-kde-devs people) is really unpleasant.

I tried to defend the KHTML choice for *years* with my friends but it's not possible anymore:
some of them use Firefox (heavy and zero-integrated), some of them moved to GNOME.

Failing to handle this problem now will weaken KDE and allow others to say "the only desktop environment with a broken browser".
Admitting that we have a problem is the first step towards a solution, thanks Will !!

By Enrico Ros at Tue, 06/30/2009 - 12:57

Hi Bille,

I think you are right. KDE needs a good browser. But I am not sure if it is really the KHTML vs. Webkit problem which makes Konqueror not the favourite browser for many people. I like Konqi. It is a very powerful and very integrated browser. At the same time Konqui lacks a lot of usability (e.g. the menupoint "windows" with menupoints duplicated or belonging somewhere else, confusion between "View(Ansicht in German) and "Settings" and just missing functions in the context menu.

But the main thing what it lacks from my point of view is a vision. I believe there is more too "KDE needs a good" browser and it is just more then having a good KDE integrated browser. A vision should attract developers, then people using it, providing feedback thus motivating developers. Then in the end, I believe it wont mater what the favourite rendering engine is, even thought I also believe webkit is the future.

I started a thread on KDE brainstorm with some ideas of mine:

By markw at Tue, 06/30/2009 - 13:45

I fully agree with you. I will for sure check the brainstorm thread you started.

By tobami at Tue, 06/30/2009 - 14:03

You brought up a very important subject.

The problem is konqueror developers (and I don't mean khtml) and fans don't see it. Read the blog response from Stefan Majewsky. While constructive, he doesn't really get it. He says "Okay, I’m not using funky bling-bling Ajax sites that much". That is sad, he is thinking about himself as a use case and about the past of the web, not about the whole freaking world!. Have you seen what people use nowadays?. Exactly, funky bling-bling Ajax sites. So khtml is NOT an option. And it probably won't ever be. Because the day those sites work flawlessly, the next trend will in motion. And khtml won't display it correctly.

Because the webkitpart seems to get nowhere, because khtml developers will continue with their project, and because konqueror has a lot of issues apart from rendering, I think we shouldn't be expecting that konqueror gets its act together. The fact that they don't even acknowledge they have a problem precludes the possibility of it being solved. The focus should now be on getting Arora and Rekonq(somebody change the name for heaven's sake!) in good shape.

So with this blog post you have highlighted the importance of the matter and I really hope (other) KDE developers understand that. The next blog post could be about those other browser projects, where the future of KDE lies.

By tobami at Tue, 06/30/2009 - 14:00

The focus should now be on getting Arora and Rekonq(somebody change the name for heaven's sake!) in good shape.

Yeah. Nothing matches reinventing the wheel for years again.

By Lubos Lunak at Tue, 06/30/2009 - 20:52

Lubos, I think you are being unfair. I clearly outlined the reasons the normal aproach (fixing the existing up) doesn't work in this case.

Redesigning konq's interface for optimal, uncluttered web browsing and getting the KWebkitPart ready isn't happening because developers don't acknowledge the problem/cater to a different audience.

Arora and Rekonq ARE happening.

As simple as that.

By tobami at Wed, 07/01/2009 - 07:06

I think you first need to show a proof that there is somebody stopping others from getting Konqueror+Webkit integration done. Stefan Majewsky is not a Konqueror developers as far as I can tell.

Arora and Rekonq ARE happening.

Yes, and that is the problem. Konqueror already HAS happened. I don't see how anybody can seriously propose the default KDE browser to be 'Arora is a simple cross platform web browser whose feature list includes things like "History" and "Bookmarks".' or 'Anyway, rekonq is far from perfect. It needs a lot of love.. ' v0.1.0.

By Lubos Lunak at Wed, 07/01/2009 - 12:04

I never said somebody was stopping others from completing the webkitpart. I just said that for some reason it wasn't happening.
Adam's post sheds some light on the real problem:

As for the rest of your answer:
"I don't see how anybody can seriously propose the default KDE browser to ..."

I never said that, nor I think anybody can reasonably say so. That doesn't prevent me from saying they are the future. Whether they'll be ready as KDE's default browser in a couple of months or in a whole year is another matter I think no one touched in this conversation.

Have a nice day.

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

I have the deepest respect for the KHTML developers, and I know very well that without their work Webkit would not have been possible. But now that Webkit is integrated within Qt, why bother having another very close implementation in addition within KDE? I have just tried the Webkit kpart, and it performs pretty well on many pages that were broken with KHTML.

I have to admit, I am one of these KDE/Firefox users, although I hate the lack of integration between the two. But in terms of compatibility and usability, the gap has just become bigger and bigger between Firefox and Konqueror, even though one must acknowledge the foundations of the latter are saner. Ah, I so wish my web browsing experience could be integrated within KDE...

By gnurou at Tue, 06/30/2009 - 14:17

I totally agree that firefox has a quite horrible UI: the lack of KDE integration is painfull. So I use konqi as my main browser since it is the best integrated browser. And I have to say: personally I quite like khtml. It works well for all the site I frequently visit. It's always a pain if you encounter a site that doesn't work with konqi, as happens every once in a while, but at least for me, this happens not often enough to use firefox as main browser.
Of course you should never have to switch browser, and since webkit is supposed to be so much better supported by websites, I tried the webkitkde in konqui, I tried arora, and I tried rekonq. Result: the first site I tried which I visit frequently is broken in webkit (http://tweakers.net, note the sidebar when having the browser at ~1024px width). The second site I tried (google maps) performs horrible, while in khtml performance is quite good. Also, I understood that QtWebkit doesn't export the DOM yet. So while at some point (in hopefully the near future) webkit would be a good choice as a replacement for KHTML, and I would be fine with that, I don't think that moment is now.

By pinda at Tue, 06/30/2009 - 14:58