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.

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.

One computing myth we hear quite often is that of Microsoft Windows offering a "common UI". That is, one toolkit or framework that is used by all applications, thus giving an experience that is well-integrated and shared. But anyone who has used Windows recently should know that this is clearly not the case.

Some programs offer theming of skinning support. Programs like Winamp, Mozilla Seamonkey and Mozilla Firefox fall into this category. Although they offer themes that mimic the appearance of other Windows applications, there are usually slight differences that aren't always obvious, but are noticeable.

Then take programs from Apple, like iTunes and Safari. The Windows versions of these programs clearly draw much more from their Mac OS or Mac OS X heritage than from Windows. In the case of Safari, you might as well consider yourself as using a Mac. Not only are the UI components completely different from that of virtually all other Windows programs, but they even go so far as to override the title bar at the top of the window.

We can't forget Java, specifically Swing. Although Sun has put a lot of effort into their Windows look-and-feel, a number of Swing-based Java applications use the cross-platform "Metal" look-and-feel. Thus they do not appear similar to other Windows applications in many cases.

Finally, we can't forget that even Microsoft makes radical changes to the UI quite frequently. The appearance of Office 2007 clearly deviates from most other software available for Windows, especially past versions of Office. Likewise, the UI for Internet Explorer 7 changed quite significantly, compared to previous versions of IE. But even between IE7 and Office 2007, there's relatively little UI commonality, especially when compared to past releases of those products.

So before suggesting that the Open Source community should decide on a single GUI toolkit to match the supposed "common UI experience" on Windows, realize that such an experience just doesn't exist. Windows suffers from as much UI fragmentation today as does a typical Linux distribution. Some of this fragmentation has even been caused by Microsoft itself, with some of their most popular products. The idea that a common UI exists on Windows is nothing but a myth.

Those of us who are serious users of UNIX or UNIX-like systems have no doubt looked at ��ric L��v��nez's excellent UNIX Timeline at some point. If you haven't, I suggest that you do! The amount of information it offers is truly spectacular. But looking at it today, I came to a somewhat sad realization: the UNIX world has become quite homogenized.

This history of UNIX starts out in September of 1969. From then until after the release of UNIX TSS Fourth Edition in November of 1973, we see no forking or derivation. Between Fourth Edition and Fifth Edition, we see some forking starting to take place, in the form of PWB/UNIX and MERT. We witness more and more branching, up until 1981.

It is around that point that I think UNIX really starts to enter a 20-year period of significant growth and "individuality". Between 1980 and 1984, we see some pretty significant divergence. First, many of the major UNIX variants begin their lives. XENIX starts on August 25, 1980, while 4.0BSD is released in October of 1980. UNIX System III comes out in November of 1981. QUNIX (the precursor to QNX) hails from 1981, as well. HP-UX starts its life in 1982. Two of the most important UNIX variants begin at this time, too: SunOS 1.0 is released in February of 1982, followed by UNIX System V in January of 1983.

The period between 1984 and 1989 is truly a glorious time in the history of UNIX. SunOS blossomed during this period, with SunOS 2.0, 3.0 and 4.0 being released. We have the major 4.2BSD and 4.3BSD releases. Mach arises in 1985. The roots of AIX go back to 1986, which is also when IRIX began. With an impact still felt by Mac OS X users today, we have the release of NeXTSTEP 0.8 on October 12, 1988, and the release of NeXTSTEP 1.0 on September 18, 1989. Although not derived from UNIX itself, the development of Minix started during this time period (and we all know the impact it would later have on Linus and Linux).

Mind you, those are just the variants that ended up having the most significant impact on the UNIX computing world. As is clearly visible on the timeline, there were numerous other variants, with many focusing on a specific platform or domain. Regardless, what we notice is that this was an era of growth and innovation. There was a lot of diversity.

This trend continues into the 1990s. We have major events like the beginning of Linux in 1991, and the release of Solaris 2.0 in July of 1992. UnixWare came out in November of 1992. NeXTSTEP continued to evolve. On the BSD front, we see NetBSD, BSD/OS and FreeBSD arise. But now notice the trend on the timeline; we see far less sharing of code and ideas between the variants. This is especially evident between 1998 and 2001.

At this point, most of the activity is between Darwin, Mac OS X and Mac OS X server. We see some transfers of code and concept, such as XFS from IRIX to Linux. But otherwise, there's little interaction between the different variants.

Things are really starting to look bland between 2004 and today. In terms of actively-developed UNIX or UNIX-like operating systems, we're down to only a handful. The BSD world is perhaps the most diverse, where we have NetBSD, PC-BSD, DragonFly BSD, OpenBSD and FreeBSD. Other than that, the most active variants are Mac OS X, Linux, Solaris, HP-UX, Minix and AIX. IRIX has become mostly irrelevant, as have Tru64 UNIX, OpenServer and UnixWare.

We will have to wait and see what the future will bring. But it looks like it will likely be pretty isolated to only a few major UNIX or UNIX-like systems: FreeBSD, Mac OS X, Solaris, and Linux. Although activity will continue on HP-UX and AIX, no doubt, their influence may very well be minimal.

I have mixed feelings over how things have evolved. On one hand, we do have more powerful features concentrated in a smaller number of systems. And these systems are fairly prevalent, and well-constructed. But the diversity of the 1980s and early 1990s brought upon change and innovation at an exciting pace. A balance between the two extremes would likely be best, although it is suspect whether we will ever get there.