Pinderkent

Apple recently released a beta of their Safari 4 Web browser. This release brings with it some relatively significant UI changes. The change that is perhaps most obvious, especially in the Windows version of Safari, is the placement of the browser tabs. By default, they are now within the title bar of the main Safari window: This is a most unfortunate place to put the browser tabs, with this location causing a number of usability problems.

The first problem is that it's unexpected. Although there has been some UI consistency loss within the Windows world over the past decade, I don't recall us ever seeing behavior like this in such a well-known application. The window title bar has solely been for identifying the window, selecting the window, and performing other manipulations of the window itself. It has always been "outside" of the application, physically and in terms of functionality.

A related problem is that of selecting the window. The mere act of giving it focus by clicking on the title bar can inadvertently cause the displayed tab to change. This can be pretty annoying, and now requires the user to be more careful where the click in the title bar when giving focus to Safari.

This is perhaps the most subjective of the problems, but I just find the title bar to now be distracting. It's much too "busy" now. Aside from the application icon in the top-left corner, we now have a mix of tab borders, close buttons, browser title text, the button for creating new tabs, and the typical three minimize-maximize-close buttons at the top-right corner.

Another significant problem occurs when running Safari fullscreen under a RDP session, or under a virtual machine like VMware. Such software can optionally put some command buttons centered at the top of the screen, to allow for the parent window to be minimized, maximized, closed, options adjusted, and so forth. While such a panel can usually hide itself, I've always found it useful to leave it expanded. Traditionally, such panels have slightly overlapped the title bar of any maximized windows, but have otherwise been unobtrusive. Unfortunately, they now obstruct a core feature of Safari. In the best case, the tab is only partially hidden, or totally hidden in the worst case. One must reduce the size of the Safari window just to switch tabs, and then maximize it again.

This idea should be considered a failure. It's a complete mistake to put such core application functionality into the window title bar like that. It doesn't work well for the user, other applications too easily interfere with it, and it's much more distracting. Worst of all, there's really no added benefit. Whatever small amount of area is gained within the browser window does not make up for the inconvenience and problems the new tab position brings.

Today I read an article suggesting that 8 GB of RAM is "only just enough" memory for a typical developer's PC running Windows. I'm not here to dispute that claim. Indeed, the RAM usages given in the article are somewhat realistic. Using recent versions of Microsoft's various software and database development tools does require a significant amount of RAM. In many ways, the need for that much RAM is unfortunate and likely quite unnecessary.

In the mid-1990s, I had the pleasure of doing software development on a NeXTstation Color. Unlike the base NeXTstation Color models, which came with 12 MB of RAM, the system I was using had been upgraded at some point to 16 MB of RAM. But by that point, it had been used by several developers before being passed on to me. Yet it was still an extremely powerful development system.

Now, it might be argued that Windows development today isn't much like the software development we did on a NeXT system 15 years ago. In some sense this is true, but for the most part very little has changed. Objective-C is relatively similar to C#. The various NeXTstep kits are fundamentally similar to the .NET standard class library. We had Project Builder for development, as well as Interface Builder for drag-and-drop GUI creation. And although it wasn't available yet when I was developing on that NeXTstation, NeXT would later introduce WebObjects for developing Web applications.

Anyone who has done any Mac OS X development lately has a general idea of what it was like to develop software on a NeXT system. It was an experience quite comparable to software development today, due to how far ahead of its time NeXT and their software offerings were. And although many people today might find it difficult to believe, we actually were able to develop relatively complex business software on a system that had only 16 MB of RAM. To put things into perspective, the article I read today claims that at least 500 times as much RAM is needed today than was needed 15 years ago. But the software we're developing today really isn't much more complex.

It's obvious why this has happened. Since then, the price of RAM has dropped considerably. It has become far cheaper to acquire more RAM than it is to pay a developer to write more efficient software. In fact, we see this reflected throughout the entire software stack. It's no secret that Windows Vista requires a significant amount of memory to run efficiently. The same goes for .NET. Developer tools like Visual Studio are also very memory-intensive. Given the platform and development tool vendor's general disdain towards writing memory-efficient software, it's no surprise that the applications developed by software developers using those tools would also consume more memory than necessary.

One thing to consider is how we now approach a simple task, such as reading and writing data files, versus how it was done 15 years ago. Today, we're likely to see some given data persisted to an XML file on disk. To work with such files, we'll need an XML parser, some way of representing the XML document in memory, custom code to tie everything together, and so forth. Fifteen years ago, we would have used a custom binary format, and written the serialization and deserialization code ourselves. Although it would have taken longer to develop, the overhead in terms of memory usage and CPU usage would have been considerably less with the custom binary format.

But to require over 500 times as much memory today is still quite excessive. I think it just goes to show how little developers today care about minimizing memory usage of their applications. The low cost of RAM no doubt helps our "cause" immensely. Today we can get away with waste that would have been considered intolerable a decade ago. But on the other hand, I think we are shortchanging ourselves to some extent. The memory we consume today, essentially out of waste and carelessness, could no doubt be better used for other purposes. Extra memory put towards even just caching data from disk is typically beneficial to system performance, even in systems with significant amounts of RAM.

Fifteen years ago, I don't think I would have believed it if somebody from now had come and told me that we'd have low-end PCs with 4 GB of RAM, typical development systems with 8 GB, and we'd actually need that much RAM to run contemporary applications. Yet here we are. And I don't even think it'd take that much more care or effort to minimize the amount of RAM we use, or at least bring it down to a more reasonable level. To have any effect, we'd need to see this initiative at all software levels, from the operating system, to any higher-level runtimes like .NET and Java, to our software development tools, and finally to the applications we develop. Unfortunately, I don't see this happening.

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.

Although Java's Swing has very little usage in consumer-grade software applications, it is used in a significant amount of in-house business software at many companies, as well as in a variety of system administration tools. While it was one of the major benefits of Java for some time, Swing is really starting to show its age. With it now being roughly a decade old, it's time to start looking for a replacement.

Jonathan Giles recently wrote about what he'd like to see in what he calls "Swing 2.0". His suggestions are excellent. Many of them revolve around updating Swing to make better use of the new language features introduced with newer versions of the Java language.

The use of enumerations is a must. One of the main sources of problems with Swing applications is an incorrect integer constant being passed to a method. The effects of such a mistake can vary significantly, and can often be very difficult to detect and debug. Unfortunately, Swing makes use of integer constants in numerous places. For compatibility reasons, these likely would have to remain as integers. Having a mix of integer constants and enumerations is arguably worse than just having one or the other.

Giles suggests that "Swing 2.0" would be a cleanup of the existing Swing code, with it being ideal if API compatibility could be maintained. My thought is that it's best to not base the updated library on the existing Swing codebase. The existing codebase has served us well (or not so well, in some cases), and given its age should probably be retired.

An added benefit of starting afresh would be the chance to eliminate the dependency on the AWT. In terms of desktop application development, the AWT is basically a relic now at almost 15 years of age. It came about in an age when Windows 95, Mac OS 7, and on UNIX the Motif toolkit ruled the roost. The amount of change since then has been huge. AWT is essentially useless on its own for modern software development, yet we still feel its presence when doing Swing development.

A new version of Swing should probably not take the same approach as that of SWT. Anyone who has worked with SWT knows the criticisms mentioned in the Wikipedia article quite well. Inheriting from existing widgets can be a hassle in many cases, and the manual resource deallocation of some SWT objects goes against the Java mentality of automatic resource deallocation.

However, it would be beneficial if the new toolkit did offer better performance than that of Swing. Giles mentions misuse of Swing's event-dispatch thread as one problem that needs to be addressed. But even well-written Swing applications running on a modern computer often don't feel as responsive as native applications do. A focus on making better use of resources and hardware acceleration may help with this.

Now would be a good time for the development of such a toolkit. Java 5 has become relatively widely deployed over the past few years, so it would be feasible to make use of the new language constructs it offers. And compared to .NET, Java as a platform has stagnated somewhat. A high-quality GUI toolkit may help bring developers back over to Java, or at least renew interest in it.

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.