posted by Eugenia Loli on Mon 25th Feb 2002 17:32 UTC
IconDavid Faure is a well known developer in the KDE & Linux community. His work can be found in KFM, Konqueror source code and he recently also picked up KOffice's KWord development. David is also one of the people who have commited in bug squashing under KDE, especially after he got hired by Mandrake Software. Read more for our interview with David regarding Konqueror, KDE object prelinking, Gnome and much more.

1. KDE 3 comes out soon. What is the best new advancement/feature found in KDE 3 in your opinion?

David Faure: I think the most important improvement in KDE3 is the greatly improved Javascript and DHTML support in Konqueror. I'm not only saying this because I took part in the work on Javascript, but also because this was said to be the most important drawback of Konqueror in KDE 2 by many users. The IMAP support in KMail comes to mind too, as an important new feature, for those using IMAP. KDE 3 is not a big architectural change (such as KDE 2.0 was), it is simply a continuation in the work on all applications, adding the features that the user requested, as well as improving speed and stability.

2. Are the KDE people going to do something for the C++ loader problem in Linux, which results on slow KDE loading times? Is the object prelinked method 'safe', or work is being done to the loader itself, to add the needed functionality?

David Faure: You said it all ;)
The linker has indeed been identified as a cause for slowdown when starting C++ applications. Work is being done in that area, though not by the KDE developers themselves. The objprelink method does not appear to be stable enough to work around this problem, it is known to be the reason for crashes in the Javascript engine and in KMail. I'm not aware of the details, but it seems objprelink is rather a "hack", i.e. a quick change that doesn't address the whole issue. On the other hand, rumours have it that the gcc/ld developers are working on prelinking, which is something different, cleaner, faster, and stable.

3. Some people call you the "KDE Bug Crasher". Windows enjoy the presense of some very advanced development tools, like the new VS.NET debugger or Purify/Quantify by Rational. How the Linux developers are coping when they are in need to debug big projects like KDE or Gnome or Star Office? What tools do you use and how they compare to the Windows equivelant?

David Faure: Those calling me that never told me :) Let's talk about the development tools then. In addition to the obvious compiler, debugger and text editor, Linux comes with pretty decent development tools such as XEmacs, vim, and kdevelop. On the subject of XEmacs, the KDE developers have been developing some macros (lisp code) that help developing C++ with it, this is available in kdesdk/scripts. For advanced debugging such as memory leaks, kmtrace (in kdesdk) seems to do a good job too. What was missing for a long time was a memory debugger, to detect use of uninitialized or deleted memory etc., such as Purify provides. This is now available thanks to Julian Seward, who developed a GPL tool call valgrind.

Although still under development, this tool allows to find many non-obvious bugs in the code. But for the most common types of bugs (wrong code paths etc.) kdDebug() (the equivalent of printf or cout) and gdb do the job quite well ;)

4. What do you think about .NET the Framework? Have you had a look to this new API yet? What are your thoughts of dotGNU and Ximian's Mono?

David Faure: From what I've seen - I admit I haven't looked very much into the API though -, .NET is basically Microsoft's reinvention of Java, with the possibility for any object-oriented language to be compiled into C# bytecode, which isn't possible with Java itself. I'm quite fond of Java, and C# seems to be the same kind of language, but speed has always been a problem with Java. It can be either interpreted or compiled just in time, but none of those beat compiled code. However I realize that's primarily a problem in browsers, native applications written in either of those could be "pre-compiled" to native code, I suppose. But the idea of cross-platform applications written in any programming language is indeed appealing, and goes the right way in the long term. I'm just not too fond of using a Microsoft solution for that, as "open" as they claim it to be. For that reason, DotGNU looks much better to me than implementing Microsoft's .NET, if I understand DotGNU correctly.

Anyway, KDE's stand on the question is that "when we'll be at a point where we need to add support for .NET or DotGNU, we will, not before". So this might come when there are many .NET applications out there, primarily developed for Windows, and people will want to run those under Linux/Unix, with KDE/Qt widgets. The compiler and interpreter are independent from the desktop or toolkit anyway, so there is no need for developing KDE-specific versions of those. Personnally, I'd rather concentrate on providing the applications people need under Linux, such as a word processor (I work on KWord, part of KOffice). However, others seem more interested in this, and for instance a CLI disassembler has just been started by a KDE/Qt developer (see kdenonbeta/kcli in CVS).

Despite previous claims, Gnome is apparently in need for an object-oriented language, much more adapted to develop graphical applications, and this is probably why they are jumping to .NET much before KDE. For us and our users, C++ does the job just fine, I don't see us throwing that away just yet.

5. The two major browsers under Linux are Konqueror and Mozilla these days. However, both are not so responsive, many times they feel sluggish. What do you think about a KDE application that only uses the KHTML KPart (like Kurt Skauen did when ported it to his AtheOS) to achieve the same goals and speed as Galeon does for Mozilla?

David Faure: The improvements I mentionned in the first paragraph are very related to this. KHTML has been much improved for KDE 3.0, making rendering noticeably faster, and the Javascript engine has been greatly sped up too. I think you are mistaken about Konqueror itself. The fact that it can embed other components than KHTML does not make it slower or more bloated than a separate application using KHTML. All it adds to KHTML is the user interface (menus and toolbars).

On that subject, one area of speed improvement in KDE 3 is that Konqueror's bookmarks are not loaded right away anymore, even when a bookmark toolbar is shown. To come back to the comparison with Galeon and Mozilla: the comparison doesn't stand. Those two are very different, whereas a separate application using KHTML and providing a user interface for it would end up being Konqueror itself! It's all about the same toolkit here, unlike the Galeon vs Mozilla case. Anyway, users should be pleased at the speed and stability improvements brought by KDE 3 - and I expect many more improvements to be done before the final release, since many KDE developers are meeting for a week of heavy bugfixing, in a few days.

6. Have you had a look at Gnome 2? What is your opinion of GTK+ 2 and Gnome 2?

David Faure: I am sorry to say that I haven't had a look at either of those. Users have time to look around and test things. Myself, I have two of the most used KDE applications (Konqueror and KWord) to attend to, and this keeps me quite busy, especially when added to sysadmin work for KDE, helping developers on the mailing-lists and IRC, writing articles about KDE development (see the article I recently wrote about KParts for IBM developerWorks)... Believe it or not, time is always the limiting factor, even for a paid full-time developer.

7. Where do you see KDE in 1-2 years? What new features you would like to see added to the popular desktop environment?

David Faure: To be frank, I'm not really a "visionary". I have recently realized that all the major changes in KDE which I took part in, were all initiated by someone else, I simply joined in and offered my help, usually doing quite an important share of the work. This made me a bit sad, realizing I'm the man-power behind innovation, but not the innovator himself ;)

I guess it's my rather conservative nature ("better keep what we have and improve it than start from scratch and break everything"), although my work on KWord has been an exception to that ;).

Anyway, I hope to see KDE much more widely used, even more user-friendly, and I hope to see many more developers on KOffice - most people don't seem to realize how few developers are behind KOffice :).

In the long run, I'd really like to see many more KDE applications being developed, to cover everyone's needs. We are developing the applications that most people need (mail client, file manager, office suite etc.), but what's preventing many people from switching to Linux is the lack of more specialized applications. For instance, 3D modelling, audio/video editing, advanced scientific apps, accountancy apps... I know that there is some development in most of those areas, but at the moment it doesn't look like Linux provides as many specialized applications as Windows does, nor the same level of functionality. The relation with KDE is that it helps the user if all graphical applications have a consistent look-n-feel - with emphasis on behavior even more than on looks.

8. KOffice has come a long way. What is the roadmap for KWord, which is the specific part you maintain? What new features you would like to implement?

David Faure: The story of KWord development is that after KOffice-1.0, the original author switched to other things and no development happened at all anymore. After 6 months, and seeing the numerous requests from users, I decided to work on KWord, redesigning it around a new text layout engine - developed in Qt by the former KWord author, so experience was built upon, not lost. This work, with the help of a few other developers, has led to KOffice-1.1.1, which most people agree is the first useable version of KWord, stable and providing the most important features. Since then, I've been working on WYSIWYG support, frame z-order, and other developers have been working onimproved table handling and DCOP scriptability. Much work is still to be done, the users have requested many features, and that's basically the roadmap :). Personnally, I plan to look at background spell-checking (underlining mispelled words during typing), page size handling, footnotes, double-underline, and then looking at the buglist again to see what else is missing ;)

9. There is a lot of talk lately, both camps with good arguments as to if Linux will make it on the desktop or not. What do you think? What should be done on Linux to become easily administrated/maintaned by the average JoeUser?

David Faure: I do think that Linux will make it on the desktop. I think it has already made it to some desktops, and will continue to improve, thanks to user-friendly interfaces such as KDE, "konquering" (pun intended) JoeUser's desktop.

My own family is obviously the testing bed for this, I have my own usability labs in the persons of my wife, her sister and my parents.

I think that what is currently missing for non-technical users is better error reporting (e.g. sending errors to log files is not enough - any CUPS developer listening? ;), and more focus on stability everywhere - users should never ever have to face a crash. System administration has finally been made rather accessible, especially thanks to the distributor's tools, but this was also a crucial missing point for long, and it surely still needs improvements. As far as KDE is concerned, the portability on all Unix flavours doesn't always make things easy. For instance I have been working on a "share this directory" feature for Mandrake, as a Konqueror patch, but this hasn't been integrated to KDE itself yet due to the numerous differences between Linux distributions, and between Unix variants.

10. What do you think of MacOSX and the way they have wrapped Unix under a pretty and usable desktop?

David Faure: See the question about Gnome. I haven't had time to have a look, but the idea sounds quite nice. Wrapping Unix in a pretty and useable desktop is exactly what KDE is about, but the main difference is that KDE is free and opensource :)

e p (0)    27 Comment(s)

Technology White Papers

See More