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

List:       kfm-devel
Subject:    Re: Konqueror Interview
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-08-31 20:03:11
[Download RAW message or body]

Let me answer some questions.

On Thursday 30 August 2001 11:15 pm, Eugenia Loli-Queru wrote:
> Ok guys, here are the questions, please someone gather the answers from the
> right people and send them back to me (with the name of the person who
> answered each question) by email (I am going to unsubscribe from the list
> after sending this email, so please reply to me by email from then on). The
> interview would be great, if possible, to go live next week between Monday
> and Wednesday which are the high traffic days (Thursday to Sunday our web
> traffic is lower). OSNews receives more than 8,000 page hits/day (not plain
> hits, but page hits :).
>
> 1. What are the plans for full CSS2 and maybe for IE-specific tags and
> Properties support?
> 2. Konqueror now features support for the Netscape plugin architecture. Are
> there plans for a native architecture?

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.

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

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.

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

Cheers,
Waldo
-- 
KDE 2.2: We deliver.

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