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.

KDE 4.0 was released several days back, and thanks to the KDE Four Live CD, I was able to give it a try with very little effort. Having used it for about a day and a half now, I'd like to share some of my impressions of this new release of KDE. Specifically, I will be focusing on the Konqueror 4.0 Web browser. But please keep in mind that I have not performed any formal studies or benchmarking, and what follows is merely my opinion.

Qt 4.3 is phenomenal. The KDE 4.0 applications in general, including Konqueror 4.0, feel far more responsive than in the past. Menus open without any noticeable delay. The scrolling of Web pages has a beautiful fluidity. The major effort that Trolltech has put into Qt over the past few years has surely paid off, and the results are immediately visible.

One other major benefit of Konqueror 4.0 is that it still feels very much like Konqueror 3.x, in terms of its appearance and layout. Long-time Konqueror users won't have to adjust to a new menu layout, or anything of the sort. In many ways, this just further indicates the maturity of Konqueror. It has had a very clean organization and interface going back several years now, and the Konqueror developers apparently knew not to change what was already working so well.

One thing that has changed is the Konqueror configuration dialog. It has been reorganized, and I think for the better. The general layout of the configuration options is similar to that of Konqueror 3.x, but it should now be easier for users to find the settings they wish to change. Nevertheless, the default settings are quite sensible, and should work fine for most users.

The JavaScript implementation, KJS, has undergone some significant optimization. Various JavaScript-intensive Web sites, such as Digg, that used to run slowly under certain versions of Konqueror 3.x now work perfectly fine with Konqueror 4.0. I think it would be interesting to see some benchmarks comparing the performance of the new version of KJS with that of other JavaScript or ECMAScript implementations, including Mozilla's SpiderMonkey, Mozilla and Adobe's Tamarin, Opera's linear_b and Opera's futhark.

One feature I particularly like is that the 'Go' menu now sports a 'Closed Tabs' submenu, which lists browser tabs that have recently been closed. This is of course a major benefit for when a tab or tabs are accidentally closed. By using that menu, it is possible to return to those pages quite quickly, and with little effort. The 'Undo' menu item of the 'Edit' menu now also allows for the restoration of a tab that was just closed.

We have to keep in mind that Konqueror 4.0, and KDE 4.0 for that matter, are still quite young. This is a fact that the KDE developers themselves freely admit. Nevertheless, KDE 4.0 proves to be a very suitable platform upon which the KDE developers can continue to build and optimize. It gives me a good feeling to see this high level of quality so early on in KDE 4's lifetime. I have no doubt that it will get even better as time goes on. And to all of the contributors who have put in countless hours working on KDE 4 and Konqueror 4, thank you for your effort!

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.

Those who follow GNOME have probably read about the GNOME Online Desktop. After reading about this concept, I find myself very confused at what it is they're actually trying to accomplish.

Take what is, at the time of writing, the second paragraph under the "Philosophy" section: Imagine an OS that keeps all its information online, so you can use a live CD as easily as a full installation. When you start up a newly-installed computer, or visit a friend's house, your whole environment will be waiting for you, with no setup to redo. For the techies, think Stateless Linux Desktop; your files and settings are somewhere else.

Why do I need to imagine that sort of an operating system? I've had that for years now. It's really quite simple: I have a system at my house running Solaris, connected to a broadband Internet connection. Using SSH, I can connect to it from virtually any other network-enabled computer. And over that secure connection I can run X-based applications quite well. All I need to bring with me is a USB key with an X server installed. Since most UNIX or UNIX-like systems, like Solaris, Linux and Mac OS X often already have an X server present, it's really only a matter of using Xming on Windows.

Best of all, I get to use real desktop applications. I don't have to bother with lousy JavaScript-based web apps, and I have full access to all of my data. Also very important, I have much more control over how my data is stored, copied and backed up. Yes, it's a little bit more effort on my part, but I think it's well worth it to know how my private files are being stored and used.

So I find it difficult to understand what exactly the GNOME developers here are trying to accomplish. Using my setup, it's already possible to use the existing GNOME applications from other computers quite comfortably. We get the benefits of web apps, without what is often the poor quality they exhibit, and without having to worry about who else has access to our information.

Now is major turning point for the GNOME project. KDE 4.0 is coming soon. GNOME isn't prepared. We may very well see a mass exodus of users from GNOME to KDE, just because KDE 4.0 will be so far ahead of GNOME. It's doubtful that this GNOME Online Desktop idea will bring any benefit.