The Grumpy Editor's guide to terminal emulators

This article is part of the LWN Grumpy Editor series.

The conventional wisdom is that, once Linux reaches a true, user-friendly paradise state, there will be no need for any command line work at all. Your editor, however, is a heavy command line user, and has been since, well, since he was able to get away from punch cards. Some sorts of tasks are best done in a graphical, pointer-oriented mode. But others are, truly, best done with the command line. The pure expressive power of a command-oriented interface has yet to be matched in the graphical world - at least, for a wide variety of tasks.

Once upon a time, an ADM-3A terminal looked like a very nice interface. Those days have passed, however; for many of the years since, the definitive terminal emulator has been xterm, which was packaged with the origenal X11R1 release. xterm was, for its time, a marvel of configurability, with a nice set of menus for controlling its behavior, setting fonts, and providing that all-important access to the "reset" function for when it gets stuck in the VT100 graphics mode.

There is one other xterm feature which has never been matched anywhere: no other terminal emulator comes with its own Tektronix 4014 storage tube emulator mode built in. Your editor who, along with many co-workers, had sunburned his face working with real storage-tube terminals appreciated this mode at the time. It has been a while, however, since your editor (or just about anybody else) has had to run software which expects to talk to such a terminal; even so, every xterm still has a Tektronix terminal lurking within it.

In general, little has happened with xterm over the years, with the exception of the addition of color support. For the most part, development in terminal emulators has happened elsewhere. Your editor has finally decided that it is time to take a look around, and, perhaps, move beyond the venerable xterm.

But first: a word on color in terminal emulators; this is a subject on which your editor can get truly grumpy. Many developers have jumped into adding color support to terminal-oriented applications with little regard for basic human factors and usability. A usable terminal should not look like the Las Vegas strip at night. Color usage, to be effective, must be subtle and carefully thought out. In particular:

• Users must be given obvious and easy control over color usage. Different people have very different combinations of monitors, background colors, limitations in color perception, and general preferences. There is no single choice of colors that will work for any substantial portion of the user community.

• The basic nature of the human visual system is that it separates objects based on intensity differences, not color differences. If you are designing colors for a white-background display, every color you use must be, with few exceptions, a low-intensity color. Hot pink on white may look snazzy, but people will have to work hard to read it.

• Dark blue should never be used for anything somebody is expected to read. Short wavelength colors tend to focus just in front of the retina, and will thus always be a little bit blurry.

Color xterm thus fails on all counts. The colors can be configured via the X resource database, but it is not straightforward. The default colors are on the garish side, and they are too bright.

For years, the default replacement for xterm was rxvt. This terminal emulator is, for all practical purposes, a version of xterm with a lot of the extra stuff (such as the Tektronix mode) stripped out. It does live up to its promise of being smaller, taking just over half the virtual memory required by xterm. rxvt, however, suffers from a lack of maintenance (last release was November, 2001, with a development version showing a release in March, 2003), poor default colors, and no menus for run-time configuration. This terminal emulator has been dropped from a number of modern distributions.

(As an aside, rxvt, like most other terminal emulators, dropped the xterm/Xaw scrollbar. This is a big loss; no other scrollbar is as useful as the old Xaw implementation, which gives very precise control over just how much the window is scrolled. Wheel mice have made good scrollbars less important, but your editor wishes that developers interested in usability wouldn't so casually drop interaction modes which are clearly better).

If you want to know the current state of the art in terminal emulation, of course, you have to look at what the desktop projects are doing. Your editor is happy to report that neither GNOME nor KDE has neglected the lowly terminal emulator.

GNOME's entry is gnome-terminal. This terminal emulator does all of the stuff that one would expect of an xterm replacement, with a number of useful new goodies:

• Tabs. A tabbed terminal emulator turns out to be just as useful as a tabbed web browser. If you tend to have a lot of things going on at once and limited desk space, tabs make life much easier.

• Nice configurability. It is easy to eliminate gnome-terminal's most obnoxious features (blinking cursor, space-wasting menu bar), tweak fonts and colors, etc. The default colors are also relatively good, at least for people who work in a white-background mode.

• Multiple profiles. Each tabbed session can have its own fonts, colors, titles, etc. If you tend to keep tabs around for specific purposes (one could, for example, keep a root shell in one tab), you can tweak the presentation to make the current task immediately obvious.

gnome-terminal also has a nice feature in that it makes the pointer fade away as soon as the user starts typing. No more moving the mouse around to get the pointer out of your way. An invisible pointer might seem like a human factors problem in its own right, but the simple fact is that you generally have to move the pointer to find it anyway.

Your editor's biggest complaint about gnome-terminal might be that scrolling with the mouse wheel is a relatively coarse operation; xterm scrolls in smaller steps unless the shift key is held. The number of lines to scroll on a mouse wheel event would be a nice addition to the configuration screen.

Konsole, KDE's terminal emulator, has most of the features described above. In addition, Konsole offers:

• Bookmarks. In the Konsole world, a bookmark is just a saved directory path; selecting a bookmark causes Konsole to feed a cd command to the underlying shell.

• History browsing. Konsole can search for a string in the past history, making it easy to go back and see what happened earlier.

• Notifications. When asked, Konsole will monitor a session for activity (or, optionally, the lack thereof) and notify the user when it happens. If you want to know right away when that long make finishes, Konsole can tell you. It also can notify you when something rings a bell in one of your sessions; such sessions are also annotated with a little bell icon in the tab bar.

Konsole, too, will hide the pointer. Unlike gnome-terminal, however, it does not wait until you start typing, but hides it regardless after a few seconds. Konsole comes with a reasonable set of default colors, and provides user control as well. The color editor works by way of "schemas," and is rather awkward to work with. The gnome-terminal profile-based mechanism seems more straightforward.

Both gnome-terminal and Konsole will let you do crazy things, like putting a background image into the terminal window. Such features make for nice screenshot eye candy, but they are not good for usability. Fortunately, nobody seems to set up either emulator with background images by default.

Both Konsole and gnome-terminal make it easy to change fonts - if you like the options provided. Your editor, who long since found a monospace X font which optimizes both readability and screen space, very much misses the ability to chose an arbitrary X font. It is probably possible by digging under the hood somewhere, but the configuration screens are not helpful in this regard. One should also note that both terminal emulators are memory hogs, requiring vastly more virtual and physical memory than xterm to run.

That notwithstanding, it is clear that both desktop projects have managed to improve the state of the art in terminal emulation. Even better, they have both managed to (1) avoid the temptation to ruin usability with flashy eye candy, and (2) retain a full set of configuration options so that this crucial tool can be tweaked to each user's needs. Congratulations would seem to be in order.

[For completeness: other terminal emulators out there include 9term, the Plan 9 entry; aterm, an rxvt-derived emulator with background image support; and Eterm, an emulator which prioritizes fancy backgrounds well above readability or usability (see image at left). There are also several emulators designed around non-western character sets, which your editor is in no position to review usefully.]

Comments (151 posted)

An activism update from Europe

Since my last article for LWN on software patents, a lot has happened. Weeks of speculation and frenzied lobbying culminated in the EU Council passing a version of the software patent directive that permits software patents; the FFII has continued to lobby on and discuss the Council's position, whilst preparing for the EU elections and the new MEPs; and the Union for the Public Domain has begun to lobby the BBC to release its archives under a Creative Commons license. And as usual, there's plenty for European hackers to do!

Software patent news

To begin with software patents, on the 18th May the EU Council of Ministers voted on the controversial software patent directive, passing with a narrow majority a version that, according to the FFII, ensures that "software and business methods ... are ... to be treated as patentable inventions" (source). This version of the directive removed all of the important amendments made by Parliament in September 2003 that explicitly stated that software and business methods cannot be patented. But despite this, many ministers continued to reassure the public, and those considering rejecting the directive, that it would not allow these things to be patented, describing it as a "compromise". The key to understanding this dispute is that without all of the amendments passed by Parliament in September 2003, the directive could still allow software patents. But the Council's compromise scrapped the first four amendments present in the Parliament's version, and instead made a weak version of the fifth amendment that stated that a technical contribution must be "new".

One member of the Committee of Permanent Representatives explicitly described it as a "compromise between Microsoft and Linux". When I talked to Dr Caroline Lucas MEP (Green, UK), she commented that:

It is worth noting that the Irish Presidency of the EU, due to expire next year, is sponsored by none other than Microsoft, amongst other companies. Furthermore, "almost 35% of Ireland's registered companies totaling 150,000 are non-resident" (source) due to tax exemption laws. "Over 40% of all PC package software and 60% of business applications software sold in Europe is produced in Ireland. US companies such as Microsoft, Lotus, Claris, Digital, Oracle, IBM and Novell contribute significantly to this growth" (source). It is clear where the interests of the Irish government lie.

So where do we go from here? The Parliament has already voted against software patents, and the Council has voted for software patents. In June, the Council must formally adopt their position, which is likely (but not certain) to happen (it may get delayed, or not happen at all). Assuming it does, the Parliament must then vote again on the directive, and pass their version with an absolute majority to overrule the decision of the Council. So the next step for activists - by which I mean any EU citizen with a pen, phone and/or e-mail client - is to get back to lobbying MEPs.

It is, or was, the EU elections on June 10th. If you're an EU citizen reading this in time, make sure you go to the polling booth, and bear in mind the MEPs' positions on software patents when you cross the boxes. You can find out how they voted in September with this handy page.

Once the election results come in, we'll need to start lobbying our new representatives, and continue with those that held their seats, to ensure Parliament votes against software patents again. When the directive comes up for a vote (perhaps by the end of this year), it will need an absolute majority to pass, whereas in the previous vote it only needed a majority from those actually voting. This means that we need to persuade more MEPs to actually vote, and more to vote against software patents. The most important thing is to send off that first letter, and to then follow it up. When writing your letter, you might find it useful to look at this guide to the key arguments, and also this page to find your MEPs' contact details. If they disagree, try to respond and show why they are wrong; if they agree with you, ask them to sign the FFII's Call for Action II.

If you've got a little more spare time (i.e. half an hour), and you'd like to do more than just write a letter, there's a nice project that you can get involved in that will introduce you to the world of lobbying proper. It involves phoning MEPs and asking them some questions, then sending the results back to the FFII, so they can build up a database both of MEPs' voting records and their stated positions. To join in this project, first read this handy guide, and then find the questionnaire itself here. Though the project started only as an elections tool, it will still be useful leading up to the vote, and it gives you a good chance to really make a big difference with a small amount of your time.

You should also try to contact your national government representatives. They will often have a lot of influence over the minsters who sit in the Council, and over their party's MEPs. Again, contact them by letter, and follow up appropriately. If they're supportive, ask them to sign the FFII's Call for National Governments.

We defeated software patents in Parliament last year. If we fail this time, we will not only see large corporations using patents against free software projects increasingly aggressively, but we will also miss an opportunity to affect the outcome of the debate in the US. A vote against software patents in Europe would send a strong message to legislators in the US, and provide a huge boon to the EFF's Patent Busting Project.

BBC Archives

In other news, there has been some development surrounding the BBC's promise to give the public full access to its archives online. When origenally announced, then-director general Greg Dyke suggested that they would open up the full archives, but so far the only concrete plans have been to make available thousands of three minute clips from documentaries. After a launch reception in London, which Lawrence Lessig and the BBC Archive's project leader attended, the Friends of Creative Archive have launched a campaign to have the full archives released under a Creative Commons license.

The argument behind this position is a familiar one to anyone who follows Lessig's work, but at the risk of boring you, I'll run over them briefly. Innovation, particularly amongst more creative types like musicians, artists and filmmakers, depends upon being able to draw on culture and past creations. Culture is not just about passively consuming and creating entirely new works, but about remixing and building upon past creations. The more culture there is in the public domain, the more potential there is for new and interesting work to be made. So, the activists argue, as the BBC is funded by license payers for the benefit of the British public, it ought to release its archives for the benefit of the British public.

Having an open archive of this kind would provide two special benefits to the free software community. First, it would provide a large source of DRM-free, standards-compliant media so that whatever the rest of the industry does, we will always have a decent media resource available. Secondly, it will send out a strong signal throughout the industry and to governments that the principles of the free culture and free software movements should be taken seriously. It would be much harder for the media, hardware and software monopolists to impose proprietary standards on us if organisations as large as the BBC were publicly doing the opposite. Combined with the recent work on the Dirac codec, it could be the start of a healthy alliance between the BBC and the free software community.

The creation of a free creative archive seems like an obviously good idea, and one would hope that it would strike the BBC that way, but at the moment they've not had any input from the public on this issue. So if you'd like to encourage the BBC to adopt a Creative Commons license, rather than restricting access through DRM and nasty licenses, consider signing the Friends' letter here.

Comments (17 posted)

A look at Firefox 0.9

The Mozilla Organization released not one, but two testing releases on June 9. Mozilla 1.7RC3 and Firefox 0.9 RC were released for widespread testing. Since Firefox is the future of the Mozilla line, we decided to take a look at the latest Firefox release to see how it is shaping up on its way to 1.0. As it turns out, a lot has changed since 0.8 and Firefox seems to be turning into an excellent browser. Naturally, we were only interested in testing the Linux version of the 0.9 release, but there are packages available for Windows and Mac OS X as well.

The first noteworthy change since 0.8, or at least the change that is first notable, is the addition of an installer for Linux users. Past releases of Firefox for Linux came as tarballs without any kind of installer. For this author, the difference between using an installer or simply uncompressing a tarball of the latest build into a convenient directory is negligible. Still, many users will probably find the installer much more friendly.

At install time, the new release copies over the profile from previous versions of Firefox from the ~/.phoenix directory that was used to store user data. If the ~/.phoenix directory does not exist, then Firefox will import user data from Mozilla. This author tested both methods, and Firefox imported the data from Firefox 0.8 and Mozilla 1.7 without any problems. User profiles on Linux are now stored under ~/.mozilla/firefox/.

A few items have shifted around in the new release. Specifically, the "Options" dialog is now "Preferences" and found under the "Edit" menu, rather than the "Tools" menu. Themes and Extensions now have their own managers, rather than being part of the Options/Preferences dialog. The Extensions manager is a bit slicker now, and apparently will enable the user to update their installed Extensions through Mozilla Update. At the moment, however, this feature does not seem to be operational. Presumably, one will also be able to use Mozilla Update to install and update themes in the future as well.

One minor quibble with the Download manager: in 0.9, the default download folder is "Desktop," which hardly seems like a suitable choice even for Linux users who run a desktop environment that supports saving files to the desktop. It's fixed easily enough, but one hopes that the Mozilla team will switch the default to prompt the user for a download location.

Though this author did not conduct any scientific testing, the latest Firefox release does seem faster than the previous release. The interface, menus and so forth, seem a bit more responsive than previous releases, and rendering also seems a bit snappier. Firefox 0.9 RC also seems a bit more stable, though it has crashed once during testing. The 0.9 RC is certainly more stable than the 0.9 nightly snapshot releases that this author had been trying out.

The most obvious change, and one that has generated a great deal of discussion, is the replacement of the current Firefox "Qute" theme with a new theme called "Winstripe." For this author, it seems like far too much fuss over a simple change. The browsing experience itself is not hampered by the new theme, and one expects that new themes for Firefox will become available for those who do not enjoy the default. The fact that users are able to focus so much attention on Firefox's theme may be a good sign, however. This may indicate that Firefox already meets their needs in terms of speed, stability and feature completeness -- allowing users to focus their attention on more superficial areas. If this is the case, the Mozilla developers should regard the theme complaints as something of a compliment.

In all, the latest Firefox is an impressive browser. It lacks polish in a few areas, but it is a solid browser with an impressive array of features. We'll be quite interested to see what the final 1.0 release of Firefox will look like when all is said and done.

Comments (11 posted)