Pinderkent

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.

A colleague forwarded me the link to these sed, ed and awk reference sheets. One great thing about them is that they're available in text form, so they're easily viewable on UNIX systems where X hasn't be installed, or otherwise isn't running.

I recently wrote about Pyro Desktop. Pyro is essentially an effort to merge the desktop and the Web, which I think is a poor idea. I've gotten some interesting feedback on that article from others, and I'd like to address their comments.

The first comment is from Manuzhai, over at Reddit. It focuses on the suitability of the Web as an application development platform. The basic suggestion is that while the browser may not have been an adequate platform in the past and even the present, the continual evolution of JavaScript will change that.

I do agree, to some extent. We are seeing an evolution of JavaScript. But the problem, I think, isn't so much about change that needs to still happen. The problems we see are inherent to the very nature of HTTP, JavaScript, and the concept of a Web browser. They can't be solved by evolution alone.

What's missing is the support necessary for large-scale application development. JavaScript is excellent for adding a small degree of interactivity to an otherwise static Web page. But we start running into problems when we push it beyond that. We end up with the problems we see from many Web apps today, even those developed by well-funded companies with some of the top talent. When using a technology such as AJAX, such problems include excessive memory consumption, a lack of responsiveness, security issues, excessive CPU consumption, and so forth.

It'd be one thing to suffer some performance, reliability and quality loss were there major gains being made in other areas. But that's just not the case with Web applications. We don't get an increase in developer productivity. It's quite the opposite; complex Web applications are often far more difficult to effectively develop, implement, debug and maintain. Likewise, the user experience is often inferior to that when using equivalent desktop software.

The only way to fix many of these issues would be to strip away the browser, to strip away JavaScript, to change the nature of HTTP and the related conventions. But by that point we've essentially changed everything about the browser. Thus I would tend to think that the problems we encounter are inherent to the concept and idea of the Web browser.

The second comment, by beza1e1, was left as a reply to the article itself. It focuses on the only benefit we see from Web apps: accessibility from essentially any Internet-enabled computer. For people on the go, it is essential to have access to your information rapidly and effectively. But we don't need the Web for this, and we certainly do not need Web applications.

In the past, I've written about how easy and effective it is to just use existing, decades-old technology to access your typical desktop applications from virtually any Internet-enabled computer. All we need to do is use proven technologies like SSH and X11, or VNC. We get the benefits of our full-featured desktop apps, with the high degree of connectivity many of us need, while having far greater control over how our important (and often private) data is stored and managed.

In closing, I would like to thank those two individuals for their comments. They provoked some interesting thought and consideration on my part, and hopefully for you, as well.

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.

It's often the most flashy and rapidly-developed open source applications that get the most attention. Most people focus on projects like Beryl, Metisse, Firefox, OpenOffice.org and Ubuntu. But we can't forget the importance of the open source software an average user doesn't see every day. This is a list of nine such programs and libraries.

9. GNU GDB
As any C or C++ developer knows, a good debugger is an essential tool. On many open source operating systems, GNU GDB plays that role. The innards of applications can be examined using GDB, allowing one to determine where in a program a bug exists, and what may need to change to fix the problem. It is without doubt that GDB has contributed greatly to the high degree of stability we experience when using systems like Linux, FreeBSD, OpenBSD and NetBSD.

8. X Window Server
The command line is all that is needed for many tasks. But others, including web browsing, image editing and video manipulation, benefit greatly from the use of a graphical environment. This is where an X Window implementation comes in. Some of the most popular implementations today include X.org and XFree86.

7. GNU Binutils
The tools of the GNU Binutils package may be among the most unknown to non-developers. But those who do implement software know the importance of tools like ld, as, and ar. Without linkers, assemblers and library archivers we likely wouldn't be able to produce the large scale systems we have today.

6. GNU Bash
To truly make use of an open source UNIX-like system, one needs to have a good shell. GNU Bash is just such a shell. The default shell of many Linux distributions, Bash draws features from existing shells such as sh, ksh and csh, in addition to adding useful functionality of its own.

While system like FreeBSD, NetBSD and Solaris offer their own shell implementations, many users and administrators on those systems still choose to use Bash, just because it has a large feature set and is widely portable. They can learn how to use it on one system, and will be able to bring that knowledge to any other system they use that has Bash installed.

5. tar, gzip and bzip2
A major aspect of open source software is how it is distributed. In source form, a popular distribution method is that of a tar archive compressed using either bzip2 or gzip. To create and extract the actual tar files, a number of applications exist, including GNU tar, FreeBSD tar, OpenSolaris tar, and star. Without these utilities, it would be difficult and costly to share our open source software.

4. GNU GRUB
While not all open source operating systems use GNU GRUB as their bootloader, it has become a major player because it so easily allows a single PC to boot operating systems as diverse as Linux, Windows and FreeBSD.

3. C Library
The C library is one of the most essential libraries on a UNIX-like system. Without this library, the vast majority of open source applications will not run. Even applications written in languages like Python or Perl depend on a C library being present, as the standard interpreters for those languages are themselves written in C.

Being somewhat system-specific, a number of C library implementations exist. Most Linux distributions use Glibc or uClibc. FreeBSD libc, OpenBSD libc, NetBSD libc and OpenSolaris libc are also well-known C libraries used by many people every day. Thanks to these libraries, we are able to write portable C code with relative ease.

2. Open Source Operating System Kernel
The kernel of an operating system provides the basis upon which we can implement higher level functionality. For most of the major open source operating systems, the kernel provides the basic infrastructure needed for us to build device drivers, filesystems, networking support, and also the userland applications and libraries we directly interact with.

Linux distributions are clearly built around the Linux kernel. As with the C libraries mentioned above, the FreeBSD kernel, OpenBSD kernel, NetBSD kernel and OpenSolaris kernel are also frequently used by many. They form what may be among the most essential parts of an open source operating system.

1. GCC: The GNU Compiler Collection
Without a good compiler for various high level languages, it's quite difficult to write the large scale applications that we depend on today. That's why GCC, the GNU Compiler Collection, is listed here as the most essential open source application. Even software as essential as the Linux or FreeBSD kernels would not be usable without the presence of GCC.

GCC is truly a remarkable compiler system. It supports languages like Ada, C, C++, Fortran, Objective-C and even Java. It also includes the runtime and class libraries needed for such languages. Even more remarkable is the number of platforms that GCC not only runs on, but can generate code for. When we consider that even some of the major open source operating system kernels are useless without GCC, we can truly see how important of an application it is.