Time Series Prediction Approaches

Time Series Journal

Subscribe to Time Series Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Time Series Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Time Series Journal Authors: Jason Bloomberg, Progress Blog, SmartBear Blog, APM Blog, Jnan Dash

Article

Enterprise Open Source Magazine: GNOME vs. KDE Revisited

While I prefer Qt & KDE, I criticize GTK & GNOME in hopes these environments will improve

This story originally appeared in LinuxWorld print edition in May 2003.

My comments in last week's column about KDE and Qt being superior to GNOME and GTK generated fewer gripes and flames than I expected. That's a good thing, because there's no reason for the comparison to be contentious. While I prefer Qt and KDE, I criticize GTK and GNOME hoping these environments will improve.

This week and next I will list my main concerns and complaints about GTK and GNOME. Jeff Waugh, a GTK/GNOME developer, agreed to review my columns and point out where he thinks I'm right, wrong, what is being addressed in future versions, what isn't, and why. If you contribute to or program with GTK, GNOME, Qt, and KDE, please send me your thoughts. I will select interesting opinions, condense them, and add my own reactions in a follow-up column. I understand that these aren't the only desktops, widget toolkits, and programming languages out there, but I would appreciate it if you'd confine your comments to GTK, GNOME, Qt, KDE, C and C++, otherwise I'll have far too much material for any follow-up. We can always address other tools and languages later.

Before I begin with my criticism, let me assure you I understand there are several different philosophies of application development. Some people prefer GTK not because it is the better tool kit, but because the approach makes more sense to them, because GTK is more granular than Qt, prefer C to C++, or another reason. I cannot address all of these factors, but I will try to take them into account wherever they matter. There are also legitimate licensing issues that will lead someone to prefer GTK to Qt, but I do not intend to address those, either.

Granularity

Those of you who like to micromanage every detail in an application are likely to prefer GNOME to KDE. I do not argue you're wrong for taking that approach. Nevertheless, I argue GNOME is wrong for failing to provide the coarse granularity one finds with KDE. There's no reason why GNOME has to eliminate its granular approach to fill in the gaps I'm talking about.

Take one of the complaints I voiced about Evolution's tool bars last week as an example. I'm used to right-clicking on a tool bar (or at least select an option from a menu) to get to a dialog where I can customize the tool bar. I cannot do that with Evolution or just about any other GNOME application, but I can with most KDE applications.

Before I delve into this matter, please understand that my point is not about tool bars, it is about the general differences in approach or perhaps differences in maturity between GNOME and KDE. The tool bar is simply an example to illustrate the point.

GNOME folks acknowledge that this feature is desirable. Here's a quote from the GNOME 2.0 Human Interface Guidelines (CVS draft):

"Allow users to configure toolbars to contain their own selection of commands, in whatever order they choose. If you do this, you should also provide an option to return the toolbars to their default configuration."

The KDE libraries include a class called KEditToolbar that makes it easy to add this capability to your applications. If you adhere to certain KDE standards, this class even makes it a breeze to manage the saved settings. That's one reason why most of the KDE applications I use not only offer the ability to customize the toolbar, the method for doing so is the same for all these applications.

But in spite of the fact that the GNOME guidelines suggest developers should allow users to configure toolbars, I couldn't find any similar API or class within GNOME or GTK that provides features similar to KEditToolbar. You may say that you prefer to micromanage tool bars with your own code, but KEditToolbar doesn't prevent you from doing that. You can code at the low-level in both KDE and GNOME, but the high-level option is not available within GNOME or GTK. You have to find a tool bar editing widget somewhere else, or micromanage the tool bar code yourself (at least as far as I can tell, based on searching the online documentation of the various APIs).

It is important to understand that my preference for the KDE approach is not just an issue of convenience for programmers. When you implement a human interface guideline through a standard class (or set of APIs) instead of just leaving everything up to the developer, you improve the chances that all applications based on these guidelines will have a consistent look and feel. Admittedly, sometimes you won't want a look and feel that is consistent with all other GNOME or KDE applications. That's the exception, however, and a high-level class or API doesn't prevent you from micromanaging the details if you want to.

Someone is sure to cry "bloat" at this point. In the case of something like KEditToolbar, it is only bloat for the user who never intends to customize a tool bar for any applications. Indeed, one could argue that the GNOME guidelines encourage people to implement this feature, therefore many people will do so. However, if you leave it up to individual programmers to implement these features, each application has its own separate code for managing tool bars. The fact that they're not sharing code is more likely to lead to bloat than a shared widget like KEditToolbar.

API Overload

Another problem I have with GNOME and GTK is that they are not really just GNOME and GTK. GNOME is difficult to pin down, since it may split into different directions in the near future. The catalyst here is Mono, the subset of the Microsoft .NET framework that Ximian is producing. I hope that will not lead to a split at all, but just another layer of development options.

Nevertheless, we can look at GTK to explain what I mean by my heading, "API Overload." GTK consists of GDK, GLib, GObject, Pango, GdkPixbuf, and more. I don't mean to mislead you into thinking you have to learn all these APIs. These libraries are layered such that GTK insulates you from most of the other libraries unless you want to access them directly. What bothers me is that the interdependence of separate layers makes GTK more fragile than it has to be. Fortunately, the fragility doesn't necessarily translate into crashes except when the underlying libraries are undergoing change. As a rule, I don't experience any more crashes with GTK applications than Qt or KDE applications. Nevertheless, be aware these interdependencies exist, and changes to lower layers do introduce the potential that applications will crash, malfunction, or simply not work. Even when my GTK applications work great, I often see error messages indicating problems that are likely the result of changes someone made to one of these libraries.

Flame-proof underwear

That's sufficient analysis to generate enough flameage to keep my bottom warm for at least a week or two, so I'll stop there for now. Next week I hope to address issues of maturity, language, and the GTK approach to themes.

More Stories By Nicholas Petreley

Nicholas Petreley is a computer consultant and author in Asheville, NC.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
LinuxWorld News Desk 11/13/05 10:05:42 PM EST

Enterprise Open Source Magazine: GNOME vs. KDE Revisited. I understand there are several different philosophies of application development. Some people prefer GTK not because it is the better tool kit, but because the approach makes more sense to them, because GTK is more granular than Qt, prefer C to C++, or another reason. I cannot address all of these factors, but I will try to take them into account wherever they matter.

SYS-CON UK News Desk 11/13/05 02:45:20 PM EST

Enterprise Open Source Magazine: GNOME vs. KDE Revisited. I understand there are several different philosophies of application development. Some people prefer GTK not because it is the better tool kit, but because the approach makes more sense to them, because GTK is more granular than Qt, prefer C to C++, or another reason. I cannot address all of these factors, but I will try to take them into account wherever they matter.

Enterprise Open Source Magazine News Desk 11/13/05 02:02:06 PM EST

Enterprise Open Source Magazine: GNOME vs. KDE Revisited. I understand there are several different philosophies of application development. Some people prefer GTK not because it is the better tool kit, but because the approach makes more sense to them, because GTK is more granular than Qt, prefer C to C++, or another reason. I cannot address all of these factors, but I will try to take them into account wherever they matter.

Edward D. Perry PE 03/20/04 01:49:37 AM EST

If you are going to do serious programming, KDE's KDevelop front end to Qt makes a lot of sense, once you get the hang af the signal-slot mechanism. Qt's documentation is mind boggling. If you watch what you are doing, your source code is platform independent, you just need a separate compiler ($$) for each platform.

Mark Dulcey 03/19/04 08:34:45 PM EST

KDE is, in my opinion, the more polished of the two environments. KDE is also easier to write programs for, in large part due to what I consider a mind-bogglingly bad decision on the part of the GNOME and GTK+ teams: doing an object-oriented environment in a non-OO language (C). (Yes, I know there are counter-arguments; let's save that discussion for another time.)

On the other hand, as MG Markum points out, there are licensing differences. GNOME is entirely licensed under the GPL; the GIMP Toolkit (GTK+), used for graphics in GNOME, is licensed under the LGPL. The core of KDE, the Qt graphic toolkit, is under a dual license; it is available under the GPL for use in free software projects, or with commercial licenses from Trolltech for non-free software. (KDE itself is licenced under the GPL.) From the developer's point of view, one difference is that GTK-based software can be used in non-free environments without payment, whereas Qt-based programs cannot without somebody (either user or developer) buying a license from Trolltech.

From the Linux end user's point of view, this has little practical significance. You can install either or both on your Linux system, and use the one you like best. You can run KDE applications from a GNOME desktop, and vice versa, so your choice of environment does not constrain your application choice.

M G Marcum 03/19/04 06:34:00 PM EST

GNOME is the one developed with 100 percent pure open source and free code, KDE isn't. If you want to risk a hugh investment in time and effort in KDE then see it go into a commercial application then go ahead and use it. It's MHO that KDE is the better of the two but I don't like that '$' hanging over my head some day in the future.

Jay 03/18/04 09:32:47 AM EST

Sir,

I'm still just a normal windows user, and intend to shift to linux. .. I've surfed all over, but still i've not come to a conclusion whether i should use gnome or kde as my desktop. The more i try to find out, the more confusing it is for me ...

In simple words, i need to use my machine as a desktop, what is more preferable and easier, Gnome, or KDE.

Thanks

Jay