|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Wednesday, 23 August 2000||Author: Monty Manley|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
The GNOME Ascendant
Why did IBM, HP, and SUN settle on GNOME as a "go-forward" GUI/toolkit technology? Many KDE developers felt slighted and angry over the decision, and it will no doubt continue to be hotly debated. But it's important for everyone in the OSS community to understand why this decision was made (always bearing in mind the quotation above).
KDE is dependant upon the QT toolkit, which is owned by Troll Tech of Norway. While Troll Tech has proven itself to be a fair and upstanding member of the community, the fact remains that QT is owned exclusively by Troll. Troll has the ultimate say over which features are implemented in QT and when they are implemented. Further, QT's licensing is still a thorn in the side of many; it is only "free" if used to write "free" software, otherwise payment is required. The GNOME project was initiated specifically to address the closed licensing of QT.
For this reason, it is completely understandable why commercial houses like IBM, HP, and SUN would be hesitant to adopt the technology. Why pay licensing fees to Troll when GTK/GNOME has no licensing fees at all? And since GTK/GNOME is GPL'd, and thus open to community development, the playing field for all companies is leveled: IBM cannot add proprietary code to GNOME to get a leg up on SUN, for example.
KDE boosters hotly deny that Troll's licensing of QT conflicts with the tenets of open-source software, but I find this reasoning rather specious. The fact is that QT is Troll's main (indeed, their *only*) source of income, and this means they have a vested interest in keeping control over the code. GTK/GNOME, on the other hand, is owned by no one (or by everyone) and consequently is unencumbered in this sense.
QT is written in C++, as is KDE. This has proven to be both a blessing and a curse -- QT has an elegant object model and has proven to be highly productive for programmers, but it is also extremely difficult to write bindings in other languages such as Perl and Python (although such bindings do exist for QT). This is because certain features of C++ -- like multiple-inheritance and copy constructors -- cannot be duplicated in other languages. Further, C++ libraries often do not interact well with non-C++ clients -- in essence this means that QT/KDE is pretty much a C++ party.
GTK/GNOME is written in straight C. While this requires a pseudo-object-orientation (or POO, as I call it) approach in terms of the API, it has the dramatic benefit of allowing virtually any language to be bound to it: C++, Perl, Python, Dylan, you name it. And since C is a "lowest-common-denominator" language, libraries written in C tend to have fewer linking problems than C++-based libraries.
Lastly (although this is a minor point these days) C tends to produce smaller and faster binaries than C++.
Component-based programming is based on the idea that re-use can be achieved at the binary level, and be completely language- and platform-independent. In the Windows world, COM is the standards-bearer; in the Unix world, CORBA carries the flag. The benefits of component-based programming are many, and it is beyond the scope of this essay to enumerate them; but it is a critical factor in settling on a toolkit for writing applications.
The KDE developers experimented with CORBA (KOM) early in the project, but eventually discarded it due to speed problems and the complexity of the code. Instead they settled on a "home-grown" solution called KParts. Conceptually KParts is similar to Microsoft's COM, but it has some significant limitations which are delineated below:
Now, none of these things means that KParts is a bad technology. It was designed to be a lightweight component model for KDE, and it fulfills that role admirably. And there is nothing to stop a KDE developer from using a CORBA ORB (like Mico or ORBit). But it presents certain problems: for example, one cannot simply drag a document from (say) KMail and drop it into a GNOME word-processor and expect it to work. Different component technologies means that KDE apps and GNOME apps will be "deaf" to each other.
The modern computing environment is becoming increasingly stratified and dispersed: PDA's, cell phones, pagers, and laptops routinely "enter" and "exit" networks. A distributed component architecture makes writing applications, which must live in such networks much easier. GNOME's component framework (Bonobo) simplifies and standardizes the writing of components, and since these objects speak CORBA, this means a Bonobo component could "talk" to another CORBA component running on a Windows machine elsewhere on the network.
It's worth noting that had the KDE group gone with CORBA components, it would have been possible to write components that would work in both GNOME and KDE. This would have given developers a very powerful way to write common code for both environments. KDE developers insist that they did not "abandon CORBA", but this is largely a matter of semantics; CORBA is there if the developer wishes to expend the effort, but KParts itself does not support it natively. So I contend that KParts does, in fact, represent an abandonment of CORBA by KDE.
In my view, this point was probably the deciding factor in the selection of GNOME over KDE. GNOME simply has a more flexible and extensible object model.
Finally, GTK/GNOME simply has a higher profile than KDE at this point in time, which put it on the radar screens of many larger companies. Helix Code packaged up a very slick and stable distribution of GNOME, while Eazel has been showing a very interesting browser/file-manager called Nautilus. By contrast, the KDE guys have been working steadily but comparatively quietly over the past months to get KDE 2.0 out.
Many KDE developers have termed the formation of the GNOME Foundation as a "sellout", but I don't think this is the case. First, the formation of the Foundation changes nothing in regards to the code itself: the same developers are still doing the same things. In fact, this effort will bring many more skilled developers into the fold. But GTK/GNOME is, and will remain, GPL'd -- this protects it from being "hijacked" by any special interest.
The "buzz" may shift to KDE when Borland finally ships its Kylix product (their Pascal-based Delphi clone for Linux); Kylix is built on the QT library and so will integrate natively into KDE.
Not Invented Here
I have heard some KDE developers opine that KDE is being ignored because it is primarily a European effort, while GTK/GNOME is predominately American. There is a certain kind of xenophobia in this assertion that is disturbing: many KDE advocates see this as yet another instance of the "Americanization" of the internet, while GNOME folks like myself see it as simply a technical decision made for technical (and defensible) reasons.
We need to avoid casting aspersions of this kind. It not only smacks of xenophobia, but it clouds technical decisions with overtones of national pride and identity. We all need to be bigger than that.
It is probably apparent that I am a GNOME fan, but I hope I have avoided any of the shrill "GNOME rulez, KDE suX0rz" malarkey that all too often dominates discussions like this. I think GNOME has real technical advantages over KDE that make it more suitable as a "standard", but many KDE users would no doubt (hotly) disagree. The only answer here is the same one we must always look to: you use what works.
Monty Manley is 33 years old and has been programming for more than half his life, on everything from a Vic 20 to an IBM 390 mainframe. He forms part of the hated power elite of white males who hold down programming jobs. He currently lives in Minnesota with his wife, two cats, two rats, and a mole who decided to make a home in his front yard. This article originally appeared at www.osopinion.com and is published under the open content license.