[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Konqueror Interview
From:       Dirk Mueller <mueller () kde ! org>
Date:       2001-09-02 12:25:30
[Download RAW message or body]

On Don, 30 Aug 2001, Eugenia Loli-Queru wrote:

> 1. What are the plans for full CSS2 and maybe for IE-specific tags and
> Properties support?

We have assembled a small table that shows which CSS2 visual properties we 
do support (http://www.konqueror.org/content/khtml_css2.html) 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 <form> 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?

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. 

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

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. 

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?

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. 

> 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?

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 ;-). 

> 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?

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. 

> 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?

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. 

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?

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. 


Dirk

[prev in list] [next in list] [prev in thread] [next in thread]