Pinderkent

Very recently, Google announced their upcoming Google Chrome OS product. One sentence in particular from the announcement caught my eye, that stating, "The software architecture is simple - Google Chrome running within a new windowing system on top of a Linux kernel." While much of the current discussion regarding this announcement focuses on the Web-related aspects of Google Chrome OS, I think this new "windowing system" for Linux is interesting in itself.

The X Window System is no doubt a very useful and effective windowing system in many ways, especially when making use of its network-oriented functionality. But as with everything, there are many things about it that could be better. Some of the main complaints revolve around its performance, resource usage, and complexity.

Although there are currently very few details about the "windowing system" for Linux that we're supposed to be getting with Google Chrome OS, I do hope we eventually see a system that is completely new. This presents us an opportunity to get rid of a lot of the cruft that has accumulated within the X-based stack, in order to produce a lean, efficient, and effective windowing environment. The initial targeting of netbooks, as mentioned in the announcement, will surely help with this.

Other efforts to provide an alternative to X, such as Fresco and the Y Window System, have unfortunately stagnated. But this windowing system would have the support of a major backer, and it sounds like it may achieve a significant market share within a short period of time.

I'm eagerly awaiting more details regarding this windowing system. It may very well have the potential to provide a more enjoyable Linux-based desktop experience, even for those of us who aren't overly interested in the Web-related aspects of it.

Today we finally heard the sad news about what's probably going to be the end of SGI. This doesn't come as a surprise to anyone who follows the industry, of course. SGI's fortunes have been steadily declining for the past decade. But it's still humbling to think of how what was once a great company could fall so far.

The Silicon Graphics of the 1980s and 1990s can perhaps best be compared to Apple today. There was always a certain excitement around SGI's offerings, often due to their quality and power, but also due to their unique flair. This really isn't surprising; they were at the forefront of computer graphics technology. Their systems allowed for the creation of what were, at the time, very spectacular visual effects. Seeing an SGI system at work didn't just leave a strong visual impression of whatever was rendered, however. The unique designs of many of their systems also left an impression.

SGI is best known for their MIPS-based systems, their IRIX operating system, and OpenGL. In terms of hardware, SGI was typically at the forefront of the market. For instance, they offered 64-bit MIPS systems in the early 1990s. This may not seem like much now, but it wasn't until a decade later that we saw the x86 world start to move towards 64-bit computing. And in terms of advanced graphics hardware, they led the way for many years.

Although I didn't work with companies who used SGI workstations for their high-end graphics capabilities, I did use an Indy workstation for some time during the 1990s, and was able to work with some companies who used SGI systems as servers because of their power and flexibility. And as servers, they were always very reliable, and often a pleasure to work with compared to the UNIX-based offerings of various other vendors.

Their IRIX operating system was always interesting to work with. During the time when I worked with such systems, they'd already moved to X and 4Dwm. While I always sort of preferred CDE, 4Dwm nevertheless did provide a unique desktop experience.

Aside from its graphical nature, IRIX was always known for scaling quite well. Given the needs of many of SGI's customers, high performance was always a necessity, and scaling well was typically the only way to get that sort of performance given the hardware of the day. One aspect of IRIX that was particularly interesting was its XFS filesystem. Being a 64-bit journaled filesystem, it was always capable of reliably storing huge amounts of data. While this was necessary for those doing video capture and editing, for instance, it nevertheless proved very useful for others who needed to store huge amounts of non-graphical data. Thankfully, XFS was released as open source software, and has been integrated with the Linux kernel. Even today, fifteen years after it was first released, XFS is still a very usable and practical filesystem, employed by many.

For some time, SGI had many of the brightest minds in the field of computer graphics working for them. OpenGL was one of their notable achievements. Like XFS, they were quite open with OpenGL, and thus it flourished, with it now being well-supported on many modern operating systems and graphics hardware. Just over a week ago the Khronos Group announced the release of the OpenGL 3.1 specification.

One thing about some SGI workstations is that they had a distinct appearance. Take their O2 and Octane systems, for instance. Both offered curved designs with uniquely powerful color schemes. It was easy to recognize such systems, even from a distance, in much the same was as many of Apple's designs stand out. And for their systems with a less-remarkable appearance, the 3D wire cube logo they used to use always made their systems identifiable.

It's unfortunate to see SGI end like this. Even if their products were expensive, they were typically quite innovative, and were the sort of products that one could get genuinely excited about. Not only did they give their systems a unique appearance, but they followed through and produced systems that were very capable, extremely powerful for the time, and generally quite reliable. Unfortunately, market pressure from below took its toll on SGI. Many of their higher-end customers reportedly moved towards commodity hardware. The loss of talent to companies like NVIDIA and ATI didn't help the situation, either. And although their future may be limited, it's likely that we'll see at least some of their work live on for some time in the form of XFS and OpenGL. Hopefully it's not forgotten where such achievements originated.

For years now, Andy Tai has done a great job of maintaining the The GUI Toolkit, Framework Page. It's a very extensive list of GUI toolkits and frameworks, both open source and commercial, for a wide variety of languages and platforms. In fact, it's almost too complete. Many of the toolkits listed are no longer developed or became obsolete years ago. So my aim here is to narrow down his huge list to the toolkits and frameworks that are practical, from a developer's perspective, and worth using today.

First and foremost, we have Qt. Many consider it to be the premiere C++ GUI toolkit. That's not surprising, of course. It has a long history of being developed as a commercial product, first by Trolltech and then by Nokia after they acquired Trolltech. Nevertheless, it has also been released under a variety of open source licenses throughout its lifetime. Given its maturity and use in a wide variety of software systems, including KDE, Opera and Google Earth, it has become known as a very reliable, portable, high-performance and high-quality toolkit.

Although Qt is written in C++, a variety of bindings have been developed for other languages. Some of the most notable include QtAda for Ada 2005, PyQt for Python, PHP-Qt for PHP, QtRuby for Ruby and qtHaskell for Haskell. In short, it proves to be a great toolkit, almost regardless of what language or platform you're using.

After Qt, we can consider wxWidgets to be the next most practical GUI toolkit. Like Qt, it is written in C++, is available under an open source license, is extremely portable, and can allow for the development of a professional-grade UI. Also like Qt, there are bindings for a number of popular languages, including wxPython for Python, wxRuby for Ruby, wxHaskell for Haskell, wxPerl for Perl, and even wxErlang for Erlang and wxLua for Lua.

One of the main benefits of wxWidgets over other GUI toolkits is its use of native controls. This allows applications developed using it to integrate nearly seamlessly with the host operating system, even while remaining somewhat portable. So while other toolkits offer themes that try as best as possible to emulate the behavior and appearance of the native platform's UI toolkit, this is often done imperfectly. A perceptive user will know they're not using a native application. But with wxWidgets, we typically don't find this happening.

After wxWidgets, GTK+ can be considered the next most usable toolkit. One difference that it has from Qt and wxWidgets is that it is written in pure C, rather than C++. While this makes language bindings easier to develop, it does have some drawbacks. One such drawback is that it makes extensive use of the GObject object system to provide object-oriented-like functionality for C. This typically feels inferior to using an actual OO language.

While it is portable to other platforms, its origin as an X Window System toolkit can still be felt. Applications using the Windows port of GTK+, for instance, typically don't truly feel like a native Windows app. Nevertheless, the Windows ports of applications like GIMP and Inkscape are usable and reliable. For the best experience, however, it's usually recommended to use GTK+ applications within an environment such as GNOME or Xfce, both of which are built upon it.

Like wxWidgets and Qt, GTK+ also has a wide variety of language bindings. Some of the most widely used include gtkmm for C++, PyGTK for Python, Gtk2-Perl for Perl, Ruby-GNOME2, PHP-GTK for PHP, Gtk2Hs for Haskell, Gtk# for the languages supported by Mono and .NET, and LablGTK for OCaml. Unlike Qt and wxWidgets, which are quite usable for large applications written in their native language (C++), it's probably best to use GTK+ from one of its more mature bindings, such as gtkmm, PyGTK or Gtk#, rather than from straight C.

Swing is relatively old and well-known. Originally Java-centric, it is becoming a more viable option as languages like Scala and Clojure, which target the JVM, become more prevalent. Other language implementations targeting the JVM, like Jython for Python and JRuby for Ruby, make it even more usable. Unfortunately, it does have a number of problems. It has never been known for offering high performance, and is somewhat memory-intensive. Applications written using Swing never truly feel like native applications, even when using a platform-specific theme. The API itself is also quite messy, having accumulated much cruft after a decade. And many developers don't want the extra baggage associated with the Java runtime, which makes it less appealing for those not writing an application specifically for the Java platform.

The FOX Toolkit is likely the most practical toolkit after Qt, wxWidgets, GTK+ and Swing. Like Qt and wxWidgets, it's written in C++. But unlike them, it doesn't offer as much of an accompanying framework. So in many respects it's a much more lightweight toolkit. And unlike some other toolkits, it doesn't (yet) include support for themes, so it has its own unique look and feel that is reminiscent of the traditional Windows look and feel. Nevertheless, it is portable and released under an open source license.

Unlike the aforementioned toolkits, the FOX Toolkit doesn't have as wide of a variety of language bindings. FXRuby for Ruby is a mature and usable binding, but others, like the FXPy binding for Python and the EiffelFox binding for Eiffel, have stagnated. So the FOX Toolkit is probably best used from its native C++ or from Ruby.

FLTK is similar to the FOX Toolkit in many ways. It's also written in C++, is portable, and is more lightweight than toolkits like Qt and wxWidgets. Unfortunately, it doesn't have as many bindings for other languages, and the ones that do exist (like the Ruby wrapper and pyFLTK for Python) aren't updated very frequently. So while FLTK is usable, it probably isn't the best option for more complex applications that are expected to have a long lifespan.

There are many other GUI toolkits out there, both commercial and open source. In terms of cost, portability, usability, user-experience and programming language interoperability, the toolkits mentioned above are typically the best options. Qt is perhaps the most flexible option for writing high-quality, portable GUI applications, followed closely by wxWidgets. GTK+ is good for software running on UNIX-like systems, but doesn't offer as seamless as an experience on other platforms. Swing is typically the choice for those targeting the JVM. And toolkits like FOX Toolkit and FLTK provide alternatives for those who don't want the baggage of the larger and more complete frameworks. While no toolkit is perfect for every piece of software, picking Qt, wxWidgets, GTK+, Swing, FOX Toolkit or FLTK should prove to be a safe, viable, practical and capable choice.

Through my work, I get to visit and work with many different businesses and organizations each year. And like anyone involved in business, meetings happen (far too) frequently, and they often include presentations. Although I don't have to give them very often, I do get to sit through them frequently enough. As laptop computers and projectors have become more prevalent, we've seen slideshows and similar presentations become used more often. While major mistakes can be made easily enough when using whiteboards, handouts and other presentation media, the laptop/projector/PowerPoint combination makes mistakes almost certain for some people.

By "mistakes" I don't mean minor stumbles while speaking, momentarily forgetting what to say, and so forth. I'm talking about incidents that can, within a few seconds, ruin the reputation of the presenter and the party or parties they may represent, or perhaps put an end to a valuable deal that has been in the works for some time. Although somewhat rare, they do happen more frequently than they probably should.

Those who have sat through enough presentations will no doubt have seen scenarios where a rogue popup alert window, often from a networked application like and email client or an instant messenging client, inadvertently displays some unsavory or very personal information. Similarly, some malware may open popups with various advertisements that do no reflect well on the presenter. Another major problem is personal and/or inappropriate photographs accidentally being displayed as thumbnails in the file browser while the presenter is starting to open their presentation. And sometimes laptop users have set a sound file to automatically play when their laptop turns on, but forget to turn down the speaker volume before turning their laptop on before the presentation.

Matt Hulett recently gave some tips to help avoid such mistakes. With respect to his first two tips, one good method of achieving that is, as mentioned by one of the commenters, to have a separate account on the laptop solely for presentations. I know some frequent presenters who take that a step further, and have separate accounts for each presentation, to avoid having the presentation for one group inadvertently displayed to another.

Some of those presenters even have a separate laptop they use just for presentations, and another laptop computer they use for work and personal purposes. I know one fellow in particular who uses a very minimalistic installation of Debian on his laptop. He doesn't even bother with installing a desktop environment, instead just using twm. Essentially, he has stripped his presentation laptop down to the bare minimum needed to make his presentations, and by doing so has eliminated many of the possible causes of major incidents. One thing he even told me is that he uses a shell session running in xterm to navigate his filesystem and start his presentations, to help avoid unintentionally revealing unwanted information to his audience.

With some care, preparation and forethought, it's often relatively easy to make a presentation go well. But it's also quite easy to be in a rush and forget something minor, such as closing down a running email client. Soon enough this can balloon out into an angry audience, and possibly even the end of valuable business relationships. A secondary, minimalistic, presentation-only laptop with separate user accounts for each presentation will go a long way towards preventing some of the most common incidents. Adequate preparation usually takes care of the rest. And if all goes well, the presentation will be a success.

It's no secret that PC hardware is continually getting faster. For most people, this is a very welcome improvement. Unfortunately, we seem to have a bad habit of throwing yet another layer of software into the mix to negate any such performance improvements. While this made sense in the past, as it often brought a huge increase in productivity, it hasn't made as much sense lately.

One such example of this was the move towards virtual machines, such as those provided by Java and .NET. Aside from a small number of microbenchmarks suggesting otherwise, the performance of real-world applications developed using these technologies took a hit relative to equivalent apps developed using languages like C or C++. But at least such environments provided a boost to programmer productivity. In most cases, this was enough to offset the slower runtime performance of the applications themselves.

Unfortunately, the Web browser has become a similar execution environment. But unlike Java and .NET, it was designed as a tool to retrieve and display hyperlinked documents. Only later was programmability tacked on haphazardly, in the form of JavaScript. This has brought a whole host of problems, ranging from security issues to extremely poor performance to the locking up of the browser itself in some cases.

We have recently seen the canvas element of HTML 5 becoming more prevalent due to it now being supported by the Safari, Firefox, Chrome and Opera Web browsers. It essentially provides a rendering surface that is accessible via JavaScript.

While this increases what can be done with the Web browser, it's clear that this functionality will be misused. One such example of this is Bespin. It claims to be "an open, extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards."

One part of Bespin is a text editor. Ben Galbraith has recently written about how the canvas element was used to develop this functionality. He does address the performance of this editor by saying, "for large classes of users, performance is really, really good."

On one hand, we shouldn't expect there to be any performance problems. Text editors are not overly complicated, nor are they particularly resource-intensive applications. We've had literally decades of experience writing text editors. Even more advanced features, like syntax highlighting, could be performed suitably fast on computers well over a decade ago. If there were any performance problems implementing a basic text editor, it would be because something has been done very, very incorrectly.

On the other hand, his description of its implementation goes a long way towards showing the wasteful overhead that is required to run such a simple application. Let's suppose we're running Bespin in Firefox on a Linux system. At the highest level, we have the JavaScript code that makes up the logic of the Bespin editor. This JavaScript code in turn is interpreted by Gecko, which also handles the manipulation of the canvas element. Since we're running Firefox on Linux, Gecko is likely using GTK+ to provide the basic UI functionality. GTK+ in turn is calling down to GDK and GLib. GDK and GLib call down to the C standard library, Xlib, other X11 libraries, possibly Cairo, and so on. The X server makes use of the C standard library, video drivers, and the Linux kernel. Finally, the Linux kernel itself accesses the actual hardware.

Only the lowest portion of that stack really provides unique functionality. When it comes to text editors, by the time we get to X we're just repeating what we had at a lower level, albeit with a slightly different API or slightly more expanded functionality. Vim, for instance, is a very full-featured command-line editor, including syntax highlighting, advanced searching, and the ability to invoke makefiles. You get more than you would with Bespin, with a fraction of the resources being needed and used.

It's clear that we've gotten stuck in a cycle of waste. We're now trying to recreate what we already had at a lower level, except with much worse performance, greater memory and CPU usage, and less functionality. And while we've seen some stunning hardware improvements over the past couple of decades, we've done a good job of eliminating them through this repetitious software reimplementation. Unfortunately, we really haven't gotten much benefit from these extra layers. For example, all we get with Bespin is a text editor that pales in comparison to Vim.

I wonder if the next step backwards will be the implementation of an HTML rendering engine written in JavaScript and targeting the HTML 5 canvas element. Running a Web browser in a Web browser may unfortunately be the next step we take to further waste our computing resources.