Pinderkent

Google's relatively new Web browser, Chrome, has generated a lot of interest since its initial release in September of 2008. It has managed to generate this even without native Linux and Mac OS X, although such ports are now in development.

Unfortunately, if this article from OSNews is correct, it appears that the developers at Google have opted to use GTK+ for the UI. The OSNews article does a good job of asking the obvious question: why not just use Qt for the Windows, Linux and Mac OS X versions of Chrome? The article suggests that Google opted not to use Qt, as they want to use native toolkits only, to allow for better integration with the host platform, and to avoid the warts that tend to accompany cross-platform applications.

I think that's a sensible policy. Mac OS X applications do differ in many ways from Windows desktop applications, both of which differ in many ways from X11 desktop applications. While cross-platform applications can be written that run on all three environments, they usually do feel somewhat out of place, and awkward to work with at times. However, it's too bad that Google has opted to consider GTK+ as the "native" toolkit for their Linux port, instead of using Qt, even if they opted to use the native UI functionality of Windows and Mac OS X for those versions.

It's difficult to give quantitative measures when comparing UI toolkits. So we'll need to rely on more qualitative analysis. Thankfully, GTK+ and Qt have both been used as the basis for a large number of popular open source applications that we can analyze.

One such way to qualitatively compare toolkits is in terms of responsiveness. And this is one area where Qt is often much better than GTK+. Qt-based applications often feel noticeably more responsive than similar GTK+-based applications. We can see this when using Kate and gedit. Kate is a text editor for KDE, while gedit is currently the official text editor of GNOME. Both are similar in terms of features and functionality, but I have always found Kate far more enjoyable to use that gedit. Gedit has a laggy feel to it, when opening menus, working with various dialogs, pasting in significant amount of text, scrolling through large files, and so forth. Kate, on the other hand, has always felt very fast; there is typically no noticeable delay between invoking a particular action, and the results of that action being available.

In relation to Chrome, a more apt comparison would be between existing browsers that use GTK+, and browsers that use Qt. Thankfully, we have several examples we can use. Epiphany is a Gecko-based browser coming from the GNOME project, and uses GTK+ for its UI. Many builds of Mozilla Firefox for Linux also use GTK+ as the underlying toolkit. On the other hand, we have Konqueror from the KDE project, and Opera, both of which use Qt.

An employment opportunity over the past six months has resulted in me making extensive use of all four of those browsers, on a variety of different PCs running various Linux distributions. After all of this use, I have to say that I've found Opera and Konqueror to offer the most pleasant Web browsing experience. While Epiphany and Firefox aren't bad browsers, they've always felt bloated. This isn't the feeling that one gets with Opera, for instance. And while we can't attribute their responsiveness solely to the underlying UI toolkit, it does help that Konqueror and Opera are both built on a solid Qt foundation. Pages appear to render faster in both, scrolling is much smoother, the browser menus and dialogs open without delay and can be manipulated without flicker, and both Konqueror and Qt feel like more polished, professional software products than Firefox and Epiphany do.

So based on my experience using other Web browsers that make use of GTK+ for the UI, I have not been very impressed. Qt-based browsers like Konqueror and Opera offer a much more enjoyable experience. Given Chrome's emphasis on providing a speedy and stable browser, Qt seems like the natural choice. The developers of Qt have put a lot of effort into making their toolkit one of the fastest out there, and this is reflected by the responsiveness of the applications that make use of Qt.

Qt also seems like a better fit for Chrome. Much of the source code for Chromium is implemented in C++. Likewise, Qt is also written in C++. But GTK+, on the other hand, is written in C, using pseudo-OO techniques. Integrating the Qt object model with that of Chromium may not be straightforward, but it likely would be cleaner than trying to integrate GTK+'s object model.

In terms of licensing, the recent announcement from Nokia that Qt 4.5, expected for March, would be available under the terms of the LGPL should make it much more appealing. Chromium already makes use of LGPL'ed software, including the essential WebKit. So while the licensing of Qt may have been a valid concern in the past, this no longer seems to be the issue it might have been.

One benefit that Opera has offered for some time now are Linux binaries that are statically linked against Qt 3. Although this can bring in the various problems associated with static linking, it does greatly reduce dependency-related problems. The user doesn't have to install Qt 3 themselves, whether from source or via the package manager of their distribution of choice. Assuming the licensing could be worked out, it would be helpful if static binaries of Chrome for Linux were available, to make installation more straightforward.

So while GTK+ will no doubt suffice as a toolkit in this case, it is too bad that Google opted not to use Qt. In many ways, Qt appears to be a better choice, and would help allow Chrome become a responsive, stable, high-quality browser for Linux. Like the OSNews article points out, a Qt-based implementation of Chrome may need to be written by the community, rather than by Google. I hope it doesn't come down to that, but it seems that Google has made up their mind and will use GTK+ for the time being. So those of us who prefer a Qt-based browser may need to just stick with Opera and Konqueror for now.

Today I read yet another criticism of the GTK+ file selector dialog. And I must say, the criticism is completely valid, but nothing new. The GTK+ file dialog has always been one of the shames of the open source world.

Anyone reading this who doesn't agree and hasn't yet looked at the screenshot included in the article linked to above, please go check it out. There is no way that the appearance and layout of that dialog can be justified. It goes beyond a minor bug or annoyance, to the point of the dialog being unusable.

The poor state of the GTK+ file chooser dialog has been noted by a number of other people in the past. This artice, from 2007, goes step-by-step through the pains one must endure to just save a file using the GTK+ file selector dialog. There is an Ubuntu Brainstorm idea from 2008 that is calling for improvements to the GTK+ file dialog. There is a forum post from early 2005 pointing out the various UI design flaws of the GTK+ file selector dialog, plus a screenshot comparison to the much better KDE file dialog. Even regular GNOME users feel it is confusing and needs improvements, and it is also inefficient to use.

In fact, we can go all the way back to this archived screenshot from the GTK+ Web site, apparently taken before the end of January 1999. As we can see, there has been little real improvement over the past decade. While the file selector dialogs of other UI toolkits and environments have evolved and improved over time, the GTK+ file dialog started out lousy, and has remained that way for years. And I don't think it can be salvaged. What's there now needs to be trashed, and re-implemented properly, drawing from the more usable file selector dialogs of Qt, FOX Toolkit, and even Microsoft Windows.

Kubuntu 7.10 RC was announced as available several days ago. I installed it immediately, and I have to say, I'm very impressed! Although it's still just a release candidate, it has all of the necessary ingredients: stability, responsiveness, innovation and coherency.

While other articles will no doubt focus on the many benefits that Kubuntu 7.10 will bring, I'd like to look forward into the future. Namely, this is because of the upcoming release of KDE 4, which is currently planned for December 11, 2007.

Kubuntu 7.10 RC includes KDE 3.5.7. This is the latest in a long line of KDE 3 releases. The initial KDE 3.0 release was over half a decade ago, on April 3, 2002. Even the KDE 3.5 branch initially dates from November 29, 2005. But during this timeframe we've seen much work done on KDE 4.

It's without doubt that KDE 4 will be a major revolution within the open source desktop environment world. The benefits we will see will be enormous:

• Qt 4: An already-responsive desktop environment gets even faster!
• HIG: Greater UI consistency.
• Oxygen: SVG-based icons and visuals.
• Plasma: Combining the desktop, panel and more.
• Phonon: A modern multimedia framework.
• Solid: Better network and portable devices support.
• Decibel: Communication protocols galore.
• Kross: Easier scripting integration.
• Dolphin: A new file manager.
• Sonnet: Spellchecking with automatic language detection.

What's more, we haven't seen comparable innovation from the GNOME developers. When the final release of KDE 4.0 comes around, I don't think that GNOME will really be able to compete any more. It will likely take years for them to catch up, at which time KDE will likely have gotten even further ahead, in terms of quality, capability and usability.

So we may be at a turning point. If the next release of Kubuntu is based around KDE 4, a shift may start away from GNOME-centric Ubuntu, towards KDE-centric Kubuntu. Were Ubuntu to move away from GNOME towards the more capable KDE 4, that would put the Kubuntu project in an awkward position. In essence, they would make themselves irrelevant due to the very act of basing their offering on the best product available.

However, it would also signify a major accomplishment within the open source community, with regards to maturity. KDE 4 will really become a platform that can compete with the likes of Windows Vista and Mac OS X. While desktop environments like GNOME and XFCE would always have their niche, KDE 4 has the potential to become the first open source desktop environment to see a far more widespread usage. This is a very important milestone for the entire community, and also the industry as a whole.

Regardless of what actually happens, the next six months will be very exciting times within the open source desktop environment arena. The impact of KDE 4 will no doubt also be felt by many of the other Linux distributions, as well as the broader BSD and Solaris communities. These sort of widely-felt changes are rare, usually limited to the likes of X.org and GCC. Interesting times lay ahead, my friends!

About a month ago, I considered the factors that were holding back one open source project with much potential, Parrot. Today I will do the same for another open source project: .

Anyone who has used NeXTSTEP, OPENSTEP or Mac OS X knows the inherent power and quality of this API. It was designed extremely well, successfully taking into account OO principles long before other mainstream platforms got around to it. Even now, many years after it originally appeared on the scene, it has very few rivals.

What's more surprising is how little the core API has changed. A NeXTSTEP developer straight from the early 1990s would feel right at home developing software for a recent release of Mac OS X. And as we've seen with Mac OS X, it's a framework that allows for some truly remarkable applications to be developed with relative ease.

So one would think that GNUstep, an open source implementation of such a framework for Linux, *BSD, Windows and other systems, would be quite popular. But that apparently isn't what has happened.

Some people might blame the relative obscurity of Objective-C for this lack of widespread popularity. I'm skeptical of this claim. Objective-C is part of the reason that the framework can be so inherently powerful. Furthermore, Objective-C is just not a difficult language to learn. Most developers these days have some OO knowledge, whether they're coming from C++, Java, C#, Python, Ruby, Perl or even PHP. They should be able to readily pick up Objective-C, likely within a week. So I don't think Objective-C is the problem.

I also don't think it's a problem with the GNUstep implementation. There are some very talented people working on it, and they've done a great job. New releases are made rather frequently. And unlike Parrot, where we see lots of change but very little forward progress, each new GNUstep release does bring actual improvements.

One of the main reasons for its lack of popularity is that it never really meshed well with the other, more popular, open source desktop systems. In some ways, that is understandable. GNUstep has its own paradigm, and its concepts are sometimes at odds with what other desktops, like GNOME and KDE, offer. Somebody wishing to make use of GNUstep applications within the context of their KDE or GNOME installation will face a near-complete lack of integration. The problem is even more pronounced on Windows. Since GNUstep-based replacements aren't yet available for most major types of software, such as web browsers and office suites, at least some integration with existing desktops would be necessary.

The default appearance of GNUstep is an interesting issue to consider. It clearly draws quite heavily from NeXTSTEP. On one hand, this brings a lot of power. The NeXTSTEP-style vertical menus, for instance, prove to be quite efficient. The sizing and layout of toolbar buttons is another area where the NeXTSTEP way brings efficiency. Unfortunately, such things also differ quite significantly from how other desktops work. So on one hand, you want to keep the features inspired by NeXTSTEP, because they do bring many advantages. But they also bring disadvantages, namely because they mesh quite poorly with non-GNUstep X applications. Although there is theming support available, it may not be well-known or accessible to new GNUstep users.

Another major reason for GNUstep's relative obscurity is the lack of any coherent system specifically built around and upon it. That's not to say that there haven't been efforts towards putting together such a system. One notable example of this was Simply GNUstep. It even managed to get some publicity. But in the end, it faltered. I suspect this happened due to a lack of resources, namely in terms of manpower.

GNUstep and GNUstep-related packages are readily available for a variety of Linux distributions and the *BSD projects. So unlike in the past, it should be far easier for a typical user to get GNUstep, and GNUstep-based applications, installed and running on their systems. And we do see interesting work being built upon GNUstep. One example of this is the ��toil�� project. Time will tell if this greater accessibility and innovation leads to more widespread usage of GNUstep.

I'd like to remain hopeful that GNUstep will bloom into an effective desktop environment, capable of competing with KDE, GNOME, XFCE, Windows and Mac OS X. At this point, it may just be a matter of getting more people aware of GNUstep, the advantages it does bring, and the ways around some of its minor problems. If a supportive community could be built up, similar to what happened with Ubuntu, GNUstep could really take off, and provide us with an excellent open source alternative to the currently-popular desktop systems.

I was disappointed today to hear that the release of KDE 4.0 will be delayed by two months. The delay is caused by the insertion of two extra betas.

But this isn't a bad thing at all. In fact, I think it shows quite clearly how the KDE crew has a great grasp of the balance between releasing a product as soon as possible, but also releasing it with a reasonably high level of quality.

There's a very good chance that KDE 4.0 will bring a desktop revolution to Linux and the BSDs. We're at the point now where we're seeing significant divergence between GNOME and KDE. On one hand, the KDE 4.0 effort has been going at full-steam for some time now. We're seeing real improvements and innovation being made. They're going beyond just the typical incremental, evolutionary improvements we so often see with software projects. What we're seeing are jumps ahead.

The latest KDE 4.0 beta, Beta 1, was released at the beginning of August. I gave this a try, and it was quite good.

One program I was particularly impressed with was Okular. It's a viewer for a wide range of document formats, including PDF, PS, CHM, and others. I have to say, even at a relatively early stage in its development, it is already a very high-quality and effective piece of software. With it, I was able to view large PDF documents that caused other viewers, especially GNOME's Evince, to lock up or crash.

I just haven't seen the same kind of progress from GNOME. They've been putting in a lot of effort, as well, but with KDE we're seeing some pretty major results. This does not seem to be the case with GNOME. So as we move forward into the future, I tend to believe that KDE will really start to overtake GNOME, in terms of functionality, quality, and eventually popularity.