(LinuxWorld) -- This will hopefully be the last in my series on GNOME vs. KDE (see "RELATED STORIES" section below for a link to each installment), at least until GNOME 2 is finalized and I've had a chance to play with it. This week I'm going to speculate on a possible scenario where KDE could make a miraculous comeback in terms of mainstream applications.
Before I begin, I'd like to respond to some of the terrific e-mail I've received. It seems appropriate, given this week's topic, that I begin with a correction. Contrary to what I'd assumed in my column last week, neither StarOffice nor OpenOffice use GTK. Both suites do connect to the Accessibility Tool Kit in GNOME 2, and Sun has endorsed GNOME as a desktop, but you'll have to scratch them off the list of top applications that are written using GTK. I sit corrected.
That pretty much obliterates my lone example of a company that chose GTK over Qt in case they wanted to sell their applications. I stand (or sit) by my assertion, however, that the "free beer" aspect of GTK makes it more attractive than Qt to many (but not all) programmers and companies.
Another reader pointed out that GTK is not really less expensive than Qt in the long haul because you still have to deal with support issues. It is true that support costs could change the way the bottom lines balance between GTK and Qt, but I'm not convinced this will draw as many people to Qt as it should. Decision makers are notoriously short-sighted. In addition, it isn't the cost of Qt alone that makes it less attractive, but the fact that you have to decide whether or not you want to pay for it before you write your first line of code. That's an easy decision for companies, a less easy decision for shareware developers and a very difficult decision for someone who has a great idea for a commercial application and wants to develop it on his or her own time.
A picture is worth 1,000 lines of code
If you've been using KDE over the past few years, you'll have noticed something remarkable about most KDE applications. They are suddenly endowed with many of the same new features, all at once. For example, they have a new file dialog that looks like this:
One of the nicest features of this file dialog is the ability to define shortcuts to frequently used directories. I find this indispensable in everyday tasks. Better still, you can set custom shortcuts that will appear in the file dialog for every application and set other custom shortcuts for individual applications. This satisfies one of the most primal needs of power users: the ability to make the program behave exactly how you want it to behave.
By the way, I don't want to give the impression that the KDE folks were the innovative force behind these dialogs if they weren't. It's been ages since I've used Windows to do any work, but I noticed that the file dialog for Office 2000 is nearly the same (though it lacked some of the features of the KDE file dialog). Perhaps Windows caught up with Office XP, or perhaps it was KDE that did the catching up. Regardless, even if this was one of those rare occurrences of Microsoft innovation rather than KDE innovation, it's hard to deny that this file dialog is far more convenient and useful than the GTK equivalent, which looks like this:
Another nice feature that most KDE applications now share is the ability to customize the toolbar for your application. You can right-click on any toolbar to set the toolbar to display combinations of icons and text, and change the size of the toolbar. You can also add and remove functions. The dialog for this looks like the following:
There are no GTK or GNOME equivalents, and I don't see any equivalents planned for GNOME 2 or GTK 2.
Oops... I did it again
Most of you will have figured out by now where I'm going with this. Put simply, the KDE class libraries and examples are a brilliant testimony to reusable objects done right. Features such as the sophisticated file dialog and toolbar functions are obviously a part of the standard KDE class library, which is why most KDE applications now include them. If you upgrade the file dialog, all applications that use it get upgraded automatically.
This is nothing new in software, although I haven't seen it done as broadly and consistently in Windows or any other desktop as in KDE. The important point is that the classes that provide these capabilities -- and other features I haven't mentioned -- are ridiculously easy to use. In contrast, I imagine it would be possible to mimic the features of the KDE file dialog in GTK, although it would probably be annoying to build the drag-and-drop capabilities into the dialog. But I can't imagine why I would want to such a thing. Why spend the energy reinventing these things when all of these features are just a few lines of code away if you write your application for KDE?
KParts, the component facility in KDE, also seems much easier to use than GNOME's bonobo (although I'm still a fan of CORBA, upon which GNOME's bonobo and Gnorba are based).
Here's the ironic twist to this imbalance in simplicity of components and classes: KDE applications such as Konqueror (the multi-purpose and configurable Web- and file-browser) and KOffice may have all these capabilities that are lacking in GTK and GNOME applications, but the KDE applications are brain-dead in ways that are more important than toolbars or file dialogs to many end users.
For example, almost every modern Web-browser on Linux these days lets you view multiple pages within tabbed windows. Mozilla, Galeon and Opera all do it. Konqueror doesn't. Almost every modern word processor on Linux these days highlights misspelled words as you type. KWord doesn't.
The KOffice applications are troublesome in other respects, too. They don't import foreign document formats as well as their GTK counterparts. KSpread is often nightmarishly slow for me. These capabilities will override the convenience of a file dialog.
Parts of the whole
Then why do I suggest that KDE applications could come up from behind and whomp on GTK applications? Because KDE, in my not-so-humble opinion, has better tools for creating the pieces that are missing in KDE applications. Why it has taken so long for the developers of the KDE applications to fill in the gaps? It's beyond me. However, KDE developers have demonstrated that they know how to fill in the gaps, that they intend to do so and that they have the ability to do so in a way that makes these and other features easily available to all applications.
That's the key. Assuming KDE developers provide the missing classes and components in the way I am expecting them to, it's only a matter of time before KDE applications surpass GTK applications in terms of usability and features. More important, these building blocks could lead to an explosion of equally useful and appealing applications.
There is one possible catch: KDE developers have always been talented in terms of desktop functionality, but until recently they haven't shown an equal understanding of usability at the application level. The file dialog and toolbar features are a step in the right direction, but will they keep going in that direction?
In short, assuming they do stay on the right path and the object-oriented and component-based natures of KDE are as convenient as I've claimed, KDE applications could overtake GTK and GNOME applications very quickly. If, as many GTK proponents say, "It's the applications, stupid," then a big jump in functionality for KDE applications could convince companies like Sun to switch alliances and come out in support of KDE over GNOME for their standard desktop.
It's a long shot. A very long shot. But it's a possibility I thought I'd share. What do you think?
Subscribe to Open Source Magazine Email News Alerts
Subscribe via RSS
