Interview With KDE’s Konqueror Team

Today we are hosting an exclusive interview with the Konqueror team, KDE’s integrated filemanager, image/document viewer and web browser. Dirk Mueller, Waldo Bastian, Carsten Pfeiffer and Simon Hausmann are answering questions regarding the future of Konqueror, its portability and the integration with QT3.1. What are the plans for full CSS2 and maybe for IE-specific tags and Properties support?

Dirk Mueller: We have assembled a small table that shows which CSS2 visual properties we do support in principle. As our internal rendering model is fully compatible with the one outlined by the CSS2 specs (unlike for example IE and some other browsers), there are no principal problems in adding support for the missing properties, except that they all have a certain impact on performance and memory consumption. While we’re improving the internal architecture, support for those properties will be a lost easier to add than it is right now. We will add support for extensions where it is necessary for realworld-WWW compliance, as we did already in the past (i.e. those properties that influence the scrollbar colors or the autocomplete=off for the FORM tag among of a huge amount of JavaScript-related extensions). If those extensions are incompatible with the relevant specs (DOM1-3, HTML4, CSS2), they are however only available in the non-strict parsing mode that is chosen when we detect that the page doesn’t comply with the specs (i.e. the DOCTYPE is nonstrict or missing). Our error recovery is in all cases compatible to IE, which is the major reason for being able to handle so many real world webpages (almost) in the way the author intended them.

2. Konqueror now features support for the Netscape plugin architecture. Are there plans for a native architecture?

Dirk Mueller: Konqueror is build around KParts, which is the native component based architecture used by KDE and KHTML, the actual browsing engine. So in fact support for the Netscape 4.x plugin architecture is only for compatibility, we have and always had a native architecture already. I hope that at some point we will be happy to drop the Motif-dependencies the Netscape 4.x plugins require and be able to provide something that is less resource-hungry and more stable.

Waldo Bastian: Konqueror has been using KParts for everything from the start. As a matter of fact, khtml is a KPart itself. We have KParts available for postscript, pdf and numerous other formats. KDE’s office suite, KOffice, is also based on KParts, so all KOffice documents can be embedded in Konqueror as well.

3. Are there plans for a full featured download manager? What users should be waiting for the future?

Dirk Mueller: It is possible to do that as a third party “plugin” already. We’ve had one in CVS but I’m not informed about its status or alternatives.

Carsten Pfeiffer: There are some download managers available for KDE, one of them is KMago. You can simply drag a link onto it and it will manage downloading, resuming, queuing etc. for you. Maybe some better integration would be helpful.

KDE v3.0, which will be based on Qt 3.0, will be able to solve the existing font problems and add support for even more non-european scripts. Note while KHTML had a fully working Bidi implementation right from the beginning already and we support i.e. logical Hebrew for some time already, we will now be able to extend this support for all applications of the desktop with only small overhead.

As usual, we will continue to improve and bugfix KHTML as well as all other parts of the desktop.

4. When browsing the net it is quite important to have the fonts that the webmasters inteded you to use. But no original-looking Verdana, Tahoma, Trebuchet or Arial True Type Fonts are being distributed with Unix which makes the whole experience not so pleasant some times. Are there any steps towards solving the problem?

Dirk Mueller: Qt/KHTML has support for the X Freetype extension (Xft), which allows antialiased font rendering of truetype fonts with acceptable performance. So if you install the freely available webfonts from the Microsoft webpage (and
some distributions can do that for you), you will get results with Konqueror that look 99% like IE under Windows. The only reason why they’re not included by default is that they’re not allowed to be distributed in any way, although they are free to use for home users. We also spent significant logic in providing an almost-nice surf experience using the standard bitmap oriented fonts that are usually available on Unix platforms. However, this has principal limitations. Situation will become a lot better with Qt3’s fontsets.

Carsten Pfeiffer: Many distributions ship a script “fetchmsttfonts”, which downloads and installs Microsoft’s webfonts. I don’t know of any efforts for creating free replacements of those fonts.

5. It is my understanding that Konqueror can be used in PDAs when compiled with the QT/Embedded option. So, are there products out there that feature a mini Konqueror?

Dirk Mueller: Yes, I know of quite a few products that make use of Konqueror/Embedded and as I’m directly involved in one of those projects I can say its performing surprisingly nice in such an environment. I have no idea about all the usages of KHTL because they usually don’t tell us ;-).

Simon Hausmann: There are several companies currently either already using or evaluating the use of of konqueror/embedded. To my knowledge there is no released comercial product out yet though. On the other side the free software community on the Compaq iPAQ PDA is very active. With a robust and constantly developed base distribution which includes an apt-get like, advanced packaging system it is very easy to get software for an iPAQ, that includes a nice graphical environment with PIM apps like Trolltech’s Qt Palmtop (http://qpe.sf.net/ – released under the terms of the GPL) as well as a binary package for konqueror/embedded. Konqueror/Embedded is not limited to Qt/Embedded though. People already built it for X-Windows with Qt/X11 on the iPAQ for example.

6. A month ago, the AtheOS developer ported Konqueror (or to be more specific, the KHTML part) to his operating system. Do you welcome such ports, even if they are not resembling exactly the way Konqueror looks under KDE?

Dirk Mueller: Yes of course, it shows just nicely how reusable our code and framework is, and that can’t be a disadvantage (see also question 5). In case of the AtheOS port it was an extraordinary pleasant experience to see this port coming along. I’ve exchanged some emails with Kurt Skauen to assist him in doing the port, and I think we both benefited from it. I’ve learned about the problems of our code with such a heavily multithreaded environment and I hope we can address them in the near future for even more portability to different platforms.

Waldo Bastian: Yes, we welcome such re-use. KDE is by design very modular, the idea behind that is that it should be easy to take high-level components and mix them together. One of the major success factors of UNIX is the fact that there is
a large set of small, simple & dedicated command-line tools that can be combined together with e.g. pipes to handle very complex tasks. With KDE we try to build on this successfull formula at a much higher level by providing dedicated high-level components that can be combined together in new ways. KDE was build with re-use in mind and at the moment we see developers taking advantage of that in an amazing rate, both within KDE itself as well as outside KDE, like in the case of AtheOS.

7. I have to be a bit strict at this point and say that Konqueror takes 4-5 seconds to load in my dual 533 PC (and it is already object prelinked) and sometimes it even feels rather slow at places. Under AtheOS, where only the KHTML part is in place, the browser, just flies. Are there any Galeon-like, stripped down version of KHTML under development?

Dirk Mueller: The application konqueror itself is just a “hosting environment” for the installed parts. So your startup time depends on a lot of factors, including:

– the amount of installed plugins that want to be executed at startup
– wether or not you start it from inside KDE
– wether or not you use a lot of Xft-fonts

We’re trying to overcome the architectual problems in the future, but biggest parts of them are unfortunately outside of our scope, like the shared library linking problems. However I know that there is some work going on in the binutils/glibc to be able to address these problems, i.e. the development of a real library prelinker. I personally hope that future versions of gcc will also provide a better implementation of virtual functions (with position independend virtual method tables) or add less overhead for exceptions.

Waldo Bastian: No, the goal is to make Konqueror as fast as Galeon, and preferably even faster, without stripping it down. Any stripping down would have to happen in Konqueror (which provides the user-interface) because KHTML only provides the rendering engine, there is little that can be stripped from the rendering engine without sacrifying standards compliance. (KHTML is comparable to Gecko, which is the rendering engine that is used by both Mozilla and Galeon)

We expect to see some more improvements from prelinking in a next generation Linux distributions. The current “object prelinking” manages to reduce the link-time of applications with 30% to 50%. The developers of the GNU linker are hard at work to get rid of the remaining 50% to 70% as well using a more advanced form of prelinking. This will effectively remove the linking overhead completely. Of course the 4-5 seconds that you mentioned are not all caused by the linker, so we will have to take a critical look at our own code as well to see where we can improve things.

Another reason for the AtheOS port being faster is that this environment provides a significantly faster graphics interface. Its a pity that i.e. we still have to scale and adjust the images in software, while almost all other platforms provide hardware acceleration for several years already.

8. JFS and XFS filesystems will soon enter their source code to the Linux kernel and become mainstream in the linux userland. Both filesystems support meta-data (multiple-stream attributes) which can be very useful to the everyday usage of the OS (like in under BeOS). Is the file manager part of Konqueror have plans to incorporate support for such file attributes?

Dirk Mueller: I’m not the right person to answer this, though I’m pretty sure we will add support for those extended metadata in time. Unfortunately such things are rather linux-centric and not very portable.

Waldo Bastian: I don’t think that “support” will be a problem, the interesting question is whether we will be able to make use of it in a meaningfull way. So let me answer that:

The lack of support for generic meta-data in the filesystem is a major drawback at the moment for a desktop environment like KDE. Unfortunately, even with JFS and XFS available, we will still not be able to rely on the availability of it since there are so many filesystems still in use that do not support it. So from a practical point of view little will change since we will still need to come up with a backup-solution in case the filesystem doesn’t support it. I would like to see that happen, but there are no plans for it as of yet.