Interview: KDE League Chairman Andreas Pour

Frank writes "Here's a good interview with KDE League chairman Andreas Pour. He talks about the K desktop environment (KDE) 2.1, that will be Hitting the streets on Monday, February 26. He reveals info about some significant advantages over the old 1.0 platform, including a full-fledged browser and the upcoming KOffice suite of business applications."

Comments

Shell Plugin Rocks!

[KurtP]

I love the new shell plugin idea. Konqueror has been top-notch stuff, and adding the ability to conveniently execute shell programs and capture them to a terminal just rocks.

I've been using the embedded terminal feature to do this in KDE 2, and having a way to do it without needing to pop open a shell in advance is just nifty. I bit of configuration lets me set up development directories that are extremely convenient to use.

I've been hearing this fiction that KDE is not for serious Unix users, but this is just bull IMHO. Konqueror is easily the most productive programming environment I've ever worked with.

Alternative to merging

[be-fan]

There is obviously a lot of talk here about merging KDE and GNOME. That is not a good idea. There is also a lot of talk to keeping things like it is. Also, not a good idea. The only real way to solve this issue is create a standard desktop API that KDE or GNOME backends can plug in to. I've already espoused the idea dozens of times, and if you want details, look at my back-posts, especially the recent Art of UNIX Programming Thread. If there was an ABI that apps had to follow, then we could open the desktop environment to competition in quality, stability, etc, while still having a consistant desktop, and without fragmenting the application base.

Why should they?

[Carnage4Life]

Consider your history. Why are there now two desktop environments for Linux? Well, we have reached this state because of liscensing issues. The Gnome project formed purely because people were unhappy with the KDE qt liscense.

The origin of the projects is no longer important. So if MIT suddenly is given the source code for all the printer drivers in use on their campus, should RMS give up the Free Software Foundation? (click here if that didn't make sense to you)
Why continue to divide out labor on two projects which both hope to achieve the same thing?

Because they plan to do this in completely different ways, also once they are mature the differences willbeself evident.

Imagine how much more polished the Linux desktop environment would be if all effort were focused on just one. Twice as much effort would be expended on it every day.

Anyone who has read Frederick Brooke's Mythical Man Month knows that your statements are a big misconception. Doubling the number of developers on a project does not double the amount of time taken to finish the project because new developers have to be brought up to speed and the layers of communication increase which leads to more errorsoccuring due to miscommunication. Basically there is a certain level of complexity where throwing more developers at a product produces little net gain. KDE and GNOME are at that level of complexity.

KDE is mainly C++, GNOME is mainly C (if you do not realize there is a fundamental difference in these languages then go to comp.lang.c or comp.lang.c++ and state this and see the responses you'll get). GNOME uses all sorts of CORBA stuff while KDE does not. GNOME uses OrBit while the few KDE developers who know CORBA used Mico. Both projects are extremely undocumented and very few, if any, have a complete grasp of the entire system in either case.

Quite frankly,if KDE and GNOME merged the efforts involved in adjusting to the merger would slow down development a lot more than any perceived current lack of developers does. In addition, some functionality that was a part of one or the other system would be lost (because stuff always gets trimmed in a merger).

A better suggestion is for KDE and GNOME to start actively pursing interoperability. Unfortunately this is one place were Open Source may fail. It is unlikely that GNOME interoperability is high on the list of any KDE developer's list of itches he/she wants scratched and vice versa. Thus since they are all simply volunteers they can't be made to do it like would happen in a professional development environment, where a manager can just assign a bunch of coders this task.


Finagle's First Law

A few comments.

[miguel]

It seems that a few conclussions are drawn incorrectly in this interview.

• Usability and toolkits. The fact that the GIMP has not a great user interface, does not mean it is caused by its use of Gtk+. Usability and good user interfaces are long tasks that require usability testing, reuse of good paradigms, and constant improvement. It is not a function of the toolkit as you like to present here.

  For instance, take Gnumeric: the best free spreadsheet available, the one with the most confortable user interface, pleasant to use and only surpased in functionality (but not in usability) by OpenOffice. Guess what? Gnumeric is fully written in Gtk+.

  Evolution is another good example: it has a great user interface, but some bits of usability are still not there, and we are working actively to do user testing to make sure we provide a better interface, but this has nothing to do with the underlying technologies (as you like to convenientnly present in your interview). It has to do with matching the "User view" with the application, rather than forcing the application model into users.

• Bonobo and CORBA: I have repeated this a number of times, but it seems that people are not interested in facts, but more interested in doing marketing "their way".

  OpenParts (KDE's CORBA-based component architecture) failed for a number of things, few of which could be traced to CORBA, I will enumerate the ones i remember, for the sake of completeness:

  • The dependency on MICO: MICO was the biggest and slowest CORBA implementation around the block. GNOME used MICO for a few releases, and before GNOME 1.0, we had written our own thin and fast implementation to circumvent the problems of size and bloat associated with MICO. The KDE team chose to keep using it because MICO was "feature complete".

  • Incorrect programming practices: The C++ CORBA binding implemented by MICO is the one that uses the C++ exception mechanism to report errors during a Remote Procedure Call invocation. This is CORBA's way of telling you "there was an error while talking to the remote server, here is the reason...". The code in OpenParts and in KOffice at the time decided that it would make their code "ugly" if they had to check for exceptions, hence they ignored all exceptions, so code that should have looked like this:

    try {
    corba_object->method (x);
    } catch (...) {
    handle corba errors here;
    }
    Was actually written like this: corba_object->method (x); Of course you get "unreliable" code if you do not handle errors. (btw, notice that most security holes on BugTraq a few years ago were all caused because people did not handle boundary conditions correctly, nor handle errors from Unix system calls correctly.

  • Complex and big interfaces: The "base" interface in KOM had something between 17 to 23 methods, a pretty large interface. The "base" interface in Bonobo, COM, UNO and XPCOM is only three.

• Bonobo and GNOME: Bonobo 1.0 is shipping as part of the upcoming GNOME 1.4 release. And it is the building block used by Nautilus and Evolution. Various applications support Bonobo already and they can integrate directly with Nautilus and Evolution (Indeed, OpenOffice integration with Bonobo is being demoed at every Linux show at the Sun booths where you can see Bonobo/OpenOffice integration being demoed).

Re:State of the GNOME project?

[miguel]

No, the situation is not as you picture it. I think you should have also put links to the various follow-up articles, in which we explain what is going on in GNOME.

The following links might be interesting to read:

1, 2, 3, 4.

Nautilus --which has a large set of developers and a lot of work going towards it-- is really one of the core components of the desktop. I am sorry for Alan if there are not too many hackers working on new IRC clients, or on new color selectors, I think that overall, we are more focused on the problems of users than we were in the past.

Components like Evolution contain some killer features that will help a lot of people transition to Linux, and the kind of work and effort required to develop an application of this size is not trivial. Just supporting every feature correctly for IMAP and broken IMAP servers is a daunting task. Having the best syncronizing tool for PalmPilots and for syncing multiple devices is also an important feature not available anywhere else (not to mention vFolders, quick searches, great user interfaces and more).

Both applications (Nautilus and Evolution) rely on very new technologies that are at the core of GNOME

Also, look at things like the Ximian Setup Tools, which are just a set of GNOME applications (branded by my company, to get some credit for the work we are putting on it) that addresses the major problem of having a user-friendly unified system configuration for Unix (here)

Our work on the Bonobo foundation is unparalleled. Once we started deploying it, many new ideas came out (like Monikers) that have enabled extremely powerful mechanisms to be created.

We sadly do not have white-papers for all of our technologies, but we are working towards documenting them. If you are interested in helping, get in touch with me.

A few things we have recently done and are shipping as part of GNOME 1.4:

• Bonobo 1.0 Ready to ship with GNOME 1.4

• GtkHTML: An HTML editor and rendering engine.

• EBrowser: A Bonobo component to do web browsing

• Gnome Spell: A Bonobo component for doing spelling, suggestions, and dictionary lookups. All available to any application that supports Bonobo.

• Gnome VFS: Access any resources on the network transparently.

There are a lot more technologies comming down for GNOME 2.0, and you can read about some of them at: http://primates.ximian.com/~miguel/gnome-2.0

Other things like Gtk from frame buffers and Pango are developed at the RHAD Labs (http://www.labs.redhat.com) and constitute part of the core technologies in GNOME 2.0

Miguel.

efficency and new ideas

[chompz]

I am often amazed by how quickly kde/gnome development occurs, considering how many developers there are and how many new ideas they implement.

However, if these two projects were merged it would not work. They have many fundamental differences, differences that would nearly require one project to be completely dumped. We all agree that this would not be a good thing.

I am a KDE user, and I am damn proud of it, but many of my friends use gnome, which is thier preference (its too slow for me).

The competition between the two projects has had an effect on each of them, encouraging adoptation of similar ideas, and generation of new ideas, ideas which might not have made it into the source code otherwise.

The competition between kde and gnome is a good thing, even if both groups didn't care about the existence of each other, it is nice to have more than one option.

Those of you calling for a merging of kde and gnome, think about this, what if we merged the linux kernel and a bsd kernel. It probally wouldn't work for a few years. Think about it.