Wandering Thoughts archives

My sign of a good graphical interface

Here is a thesis I have about really good graphical interfaces, especially in the context of text editors:

In a good graphical interface, you not only can use the mouse, you want to.

There are a good number of graphical interfaces that are ordinary and decent and good enough. They make effective use of the mouse and graphics, they're nice, and they by and large fail to fill me with any particular actual enthusiasm for those graphical features. They're just sort of there, in an ordinary and perfectly acceptable way.

(Perhaps this is the mark of a good interface in one sense, in that the interface more or less disappears as something that I think about; it's just there, doing things for me.)

This has been especially visible in text editors, because (unlike many other such GUI-based programs) we already have a lot of experience with primarily text-based editing. As a result, a lot of the graphical text editors that I've used have left me feeling unenthused about their graphical nature; things like multiple windows and pointing at things with the mouse were nice to have around, but in practice I didn't use them much.

(You can see this in other programs too; consider the enduring popularity of keyboard shortcuts. In a sense, every keyboard shortcut that gets used is a failure of the graphical interface, in that the graphical interface was unable to make the mouse the faster and better way of doing the same thing.)

But this isn't always the case. There have been a few GUI programs that have not just let me use the mouse, but which have left me actively wanting to do so (and not because the mouse was the only way to use them; that trick doesn't work when you have alternative programs available). Thus, this has become my mark of a really good graphical interface: it is sufficiently cleverly designed that I actively want to use the mouse, that it feels totally right, entirely natural, and clearly the fastest and best way to get done what I want to do.

Unfortunately, these are very uncommon, and as a result I suspect that most people have never used one.

Exploiting the Bourne shell to parse configuration files

Suppose that you have what I will call a 'directive style' configuration file, where it looks something like (say):

fileserver fs1
exportto hostsa:hostsb
filesys /h/10 fs1/d100
filesys /h/11 fs1/d110

Further, suppose that you want to do things with this configuration file in a Bourne shell script, which requires parsing it to extract all of the information that you're interested in.

Normally this would be a pain, but it's recently struck me that you can exploit Bourne shell functions to do the parsing for you. Simply define a function for each directive that does something appropriate with its parameters, and then source the actual configuration file from your scripts (with the '.' operator). Bang, you're done, and you even get comments and line continuations for free.

(If you want to make this the official way that the configuration file is parsed, you can give people a fair amount of power with just things like shell variables to capture common pieces. You probably don't want to go all the way to encouraging them to use conditions and loops and so on, so that you can at least pretend that the configuration file can be parsed by something other than your Bourne shell scripts.)

Of course, half of making this useful here is figuring out how to represent and store the parsed data, since the Bourne shell is not exactly known for its data structures. But given that your main shell script code needs to use the information, you can always work backwards from how that code wants it to figure out a representation. And if you don't need all of the information (and you probably don't), you can just discard most of it, which simplifies storing the rest of it.

Disclaimer: this probably qualifies as an evil hack.