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

GNOME & KDE docs & themes

Second in a series comparing the background & implementation of GNOME & KDE.

(LinuxWorld) -- Thanks to everyone who responded to the column GNOME and KDE revisited. I got a broad range of responses. One person who hasn't done any development yet for either GNOME or KDE immediately echoed my sentiments about the superior maturity of the documentation for KDE and Qt. Last week, I said I would address the issues of maturity, language, and theme handling regarding GNOME and GTK, so this letter provides me a convenient segue into the first of these topics. Unfortunately, I won't have room this week to get into the issue of language, but I hope my rant about theme handling will tide you over until then.

Before I get started, let me address the general sentiment of many of the letters I've received about last week's column. Most of the e-mails I received ranged from disgruntled readers to outright flames. I'd estimate that half of these letters say I am bashing GNOME and GTK, the other half claim that I am trolling.

I hope most of you will come to understand that it is not my intent to do either. I have several motives for giving a general analysis of GNOME and GTK versus KDE and Qt. Here's what I hope to accomplish by the end of this series.

  • I look forward to your input about what's really important to you, so that I can reflect that here.
  • I would like to give programmers an idea of what they will be getting into if they choose one set over the other.
  • I feel there are many unnecessary weaknesses in GNOME and GTK, and I would like to motivate the maintainers to make it a priority to strengthen these areas.
  • I hope to illustrate why GNOME and GTK is likely to emerge as the leading desktop platform in spite of its immaturity with respect to KDE and Qt, and in spite of my personal preference for KDE and Qt.
  • I will also give you some reasons why the opposite may happen. KDE and Qt applications may surprise everyone and overtake GNOME and GTK applications, a development that could upset the future of GNOME and GTK.

Docudrama

As for the quality of documentation, I will offer my opinion, but I strongly recommend that you judge for yourself which documentation is adequate for your needs. The resources section below contains links to online documentation for GNOME, GTK, some of the libraries upon which GTK depends, some additional toolkits associated with GNOME and GTK, and some additional links to resources such as the increasingly popular C++ layers called gnomemm and gtkmm. It also contains links to various KDE libraries and the documentation for Qt.

If I had to describe the documentation for GNOME/GTK development in three words, I'd say overwhelming, scattered, and incomplete. Add "occasionally excellent" and that should give new developers for GNOME/GTK a good idea of what you're in for.

Sheer numbers

What I find overwhelming is the sheer number of APIs and classes one may have to learn, depending on what kind of application you want to develop. As I pointed out in last week's column, the GNOME/GTK environment encompasses far more toolkits and libraries than just the two names imply. You'll see from the resources section below that I have included links to no less than 26 reference manuals, each for a separate set of library functions or classes. Granted, there is some duplication among these references, since I provided links for the current versions of GNOME/GTK and some links for the next version, 2.0. There are also a few reference manuals for C++ wrappers to the C toolkits, so one could argue there's a degree of duplication there, too. Even if you were to whittle down the list to 13, that's still an enormous amount of information to digest in order to grasp the GNOME/GTK environment. It is by no means a complete list, either, but I tried to shy away from including those libraries one might also use for KDE/Qt applications development, so that fans of GNOME/GTK would not accuse me of artificially inflating one list but not the other.

I also list 15 KDE and Qt documentation resources, with the only duplication being a link for the two latest versions of Qt. So why is 15 so much better than 26 if most of the duplication of links occurs in the list of 26 references? Almost all of the GNOME/GTK references are to low-to-mid-level APIs. Many of the KDE references are to high-level components such as the HTML engine (browser component), the JavaScript engine, a spell checker, MIDI music class, and the universal address book. What you won't find are separate libraries or APIs for low-level functions such as XML file handling, font, and text handling, such as those appearing in the GNOME/GTK list. That sort of thing is built into the KDE and Qt classes. Indeed, Qt 3.0 even includes network-enabled sound support and built-in access to various SQL databases, among other advanced features. This testifies to the unity and maturity of KDE and Qt compared to GNOME/GTK, but that's a topic for a future installment.

It's hard to criticize GNOME/GTK because the documentation is scattered across different locations. GNOME is much more of a melting pot of libraries and toolkits than KDE and Qt. Some developers consider this one of GNOME's greatest strengths, while others find it frustrating. I find it difficult to take either side, since it is more a matter of personal preference than an objective measure of the quality of GNOME versus KDE. Nevertheless, if you are a die-hard C programmer and you prefer to mix and match languages, toolkits, libraries, and whatnot, then you will be more satisfied programming for the GNOME/GTK environment than for KDE/Qt. If you're truly serious about programming in this environment, you won't be put off by the fact that you have to jump from one place to another for your documentation. In fact, if you're smart, you'll download all the documentation you need and set yourself up with convenient bookmarks, anyway.

As far as I can tell without actually writing a GNOME or GTK application, it looks like the vast majority of GNOME and GTK documentation is excellent. When there are examples, the examples seem useful. If you're using the current versions, you're likely to find everything you need.

Bits and pieces of the GTK 2.0 documentation are missing, however. GNOME 2.0 is due out soon, so we should expects missing bits for a while. To be forewarned is to be forearmed, so keep this in mind if you're anxious to get started with the next versions of GNOME/GTK. You'll only run into major problems if you're looking forward to working in C++ with the new toolkits called Gnomemm and Gtkmm. My advice is to keep looking forward. The documentation is so full of holes that it's essentially useless in its present state.

Right now KDE and Qt documentation is preferable to the documentation for GNOME, GTK, and all the associated libraries, but that's partially because KDE 3.0 and Qt 3.0 have been available for a while. Expect the GNOME and GTK documentation to catch up when the next version is ready.

The bottom line on documentation is that it's a wash. I prefer the KDE and Qt documentation by far, but that is at least in part because I prefer C++ to C. Once you start thinking in C++, documentation for C functions just reminds you of all the minutiae of housekeeping chores you worked so hard to get away from when you moved to C++. But I still recall the days when I didn't know C++, so I also know how unappetizing the KDE and Qt documentation might look to someone who is either unfamiliar with C++ or simply doesn't like it. You're going to like what you're going to like. The most important question is whether you can get to the information you need, and in either case, the answer is yes.

Theme

GTK theme handling is a pet peeve of mine, perhaps because it seemed like one of the most exciting features of GTK when it first came out. Back when I first experimented with GTK themes, I thought the whole concept was the cat's meow. GTK themes, along with the theme capabilities of various window managers, left the look and feel of Microsoft Windows in the dark ages. The combination of GTK and Enlightenment or Icewm (the two window managers I used most at the time) also made the best KDE themes as boring as Windows.

Since then KDE and Qt have left GTK and GNOME in the dust with respect to themes and configurability. With years under its belt, you'd think that by now GTK you would be able to do something as simple as customize GTK colors from the GNOME control panel. But you can't. If you want colors other than the default, you'll have to edit some GTK configuration files. I've heard GTK fans say that this is intentional because the default colors make the themes more cohesive and polished.

Hogwash. That may be true of some GTK themes, but many would benefit from the ability to customize the colors. Since you can do it simply by editing a file, why not make the process possible (preferably not only possible but extraordinarily easy) from the GNOME control panel?

Worse, many of the GTK themes get their colors or patterns from graphics files. If you want to change those particular elements of the style, you'll have to fire up GIMP or some other graphics program and put your art talent to work. KDE is not immune to themes that use graphics files with fixed colors and patterns, but you're not nearly as likely to run into that problem in KDE.

Indeed, you can do customize just about everything in your KDE environment from the KDE control panel, including tweaks to custom theme engines. (Heck, you can even configure your Linux kernel from the KDE control center!) When you use a custom theme engine, such as Mosfet's High Performance Liquid (see resources for a link), the customization tools are integrated into the control center. One can only hope that GTK and GNOME will catch up with the next version, but I have yet to see any evidence of this. If any of you know differently, please chime in and I'll recant.

That's enough praise and pans for this week. Next week I'll deal with some of the factors that will affect the future of these toolkits and environments.

More Stories By Nicholas Petreley

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

Comments (2) 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
Monica 04/08/04 12:08:02 PM EDT

I think links on blogs will not be counted anymore by google, just like guestbooks. I've been watching some sites that had hundreds of links from weblogs. Now google displays only a few links to these sites when you seach for backward links. adolescente - adulti - bilder - blasen - blonde - camere - celebritati - chiloti - cur-anal-anus - dezbracate - dragoste - ejaculare - erotice-erotica-erotic - fantasia - femei - fete - fierbinti - filme - foto - fotografii - fotomodel - frumoase - fut_futai_futut - gagici - galerii-galerie-galleria - gay - goale - gratis - gratuit - gratuite - große - grup - imagini - chat - jucarii - kennwort - lenjerie - lesben - masturbation - modell - nue-nues-nuda-nudo-nudi-naakt-nud - pagini - pamela_anderson - pizda-pizde - playboy - poezii - porno - povestiri - poze - pula - romania - sex - sexy_sexi - single - site - stern - titten - vedete - xxx

Bob 03/26/04 01:13:28 PM EST

No kidding. Not too long ago, I could change gtk colors, themes, etc from the Gnome control panel through the sawfish and gtk options, but now all that is gone... I don't want to go mucking about tracking down config files to make simple changes like the color of my scrollbar from purple to gray. What the hell are they thinking. If I wanted to give up all my control I'd install windoze, and if I want to edit a bunch of conf files by hand I may as well just revert to Red Hat 5.1 and uninstall X...