Not A Commander - a look back from the 1st anniversary

It's October 2001. Slightly over one year has passed since I've started writing Not A Commander. This looks like a convenient time to look back and share my experiences, expectations and general views. This whole thing is organised as questions and answers where I both ask the questions and give the answers. I hope this will answer to some of the questions of the users of NAC as well. If you have other questions, ask me.

All these look-alikes of Norton Commander(tm)

Q: Why did you create Not A Commander? Are not there already enough of the look-alikes of Norton Commander?
A: Two reasons: First, I wanted to learn Tcl. I've got to support some large Tcl (not Tk) script at work, plus I wanted for a long time to learn Tcl/Tk. So I've read a book about it. And writing a real program is a fun way to get some practical feeling of the language. Second, I liked the Norton Commander on MS-DOS and wanted to write something like this for Unix. Yes, I've seen some of the other file managers of this kind on Unix but they all suck horribly. They are just not something I'd ever use, the plain command line is way nore convenient to me than them. Actually, after starting NAC I've looked at more of the look-alikes and at the newer versions of those I've seen before, and alas, still all of them suck horribly.

Q: What exactly do you mean by saying "suck horribly" about the other NC look-alikes?
A: They are not really horrible but just oriented towards the other kind of users. They concentrate on the file panels and tend to complicate the use of the command line. Most of them don't even allow to make only one panel visible. Which is exactly how I prefer[red] to use the Norton Commander: close the left panel because most of the time it's useless anyway and see this part of the screen unobscured. While NC was a practically transparent addition to the command line, these look-alikes usually are impediments. I don't need that "dumb-user friendly" stuff, I want an efficient interface. That is not to say that the plain command line is perfect. No, there are quite a few repetitive tasks which can benefit a lot from a menu-based interface. And none of these look-alikes seems to be doing that well. No, the Norton Commander did not do that so well either. And no, Not A Commander does not really do that much of them too, yet.

Q: Are not the limitations of the Unix text interface at least partially to blame?
A: Indeed they are. And not just partially but largely. To put it plainly, the text interface support on Unix had always sucked horribly, and considering the current state of affairs will ever do so. Partially the problem is that it got jammed between the hard-copy typewriter (the original interface) and the graphical interface (to which the Unix research crowd has switched in the early 80s). Partly the problem was in the available hardware terminals and slow serial lines with which they were connected. There just never was a widespread decent kind of terminals, everywhere you look were the VT100-like monstrosities. That is, I don't know any decent model of hardware terminals at all though I hope that there were some, at least as prototypes (the Lisp machine from the MIT AI lab comes to the mind as one such possibility).

Q: Is that your first attempt at writing an NC look-alike?
A: No, actually it's the third one. Once I've started writing one for the text interface but then we've got the Mecomp Commander, so the local attempt was dropped. Then the second time I tried to learn Perl/Tk (the Tk part) and write a NC look-alike in it as an exercise. The problem was that I've tried to learn it by reading the man pages, so I had problems with understaning the Tk philosophy. I also went too much into the widget inheritance instead of composition (one of these philosophical misunderstandings) and was not able to quite figure out what exactly Tk does with the keyboard events and I've got other things to do, so the experiment has died quickly.

Q: Why are these NC look-alikes more popular among the people from Europe in general and from the former Soviet Union in particular?
A: I guess because there were exposed to the Norton Commander for a longer period of time. Computers are not only more affordable but also cheaper in absolute amounts of money in US. So the US have migrated to the graphical user interfaces earlier. And the industry in US could afford using more of the mainframes and mid-size computers, so the PCs were more of an end-user phenomenon in US and the programmers have touched them less.

Q: Is not it stupid to reinvent the wheel in the each NC look-alike?
A: Partially, yes. I hope to re-use some things from the others in NAC. The first target is to support the viewer configuration file from Midnight Commander. I don't particularly like its format but it's OK and at least a good placeholder until (if ever) I come up with something better. I also hope to adapt some of what they call Virtual Filesystems from Midnight Commander or Northern Captain. However my ultimate target for the code re-use is Mozilla or at least Mosaic. After all, Microsoft is right that the file managers and browsers are essentially the same thing.

Mice and men

Q: Do you hate the graphical user interface?
A: Not really. With the modern computers it's (finally!) not even slow any more. Well, except when working through a dial-up network. And it actually does allow to do more interesting things, even for the purely text-oriented applications, than the text-based interface. The problem with it is that the programmers using it tend to get mouse-happy. Instead of giving some thinking to the ways of interaction with their programs they slap together a few windows and hope that the users will click their way through. Actually, we can see now some movement away from the slap-together idea in the form of the "wizards" that essentially are a sequence of modal dialogs. It's a great shame that the long experience of good interface design gained with the text interfaces (and in programs for MS-DOS in particular) was thrown away.

Q: Why do you hate mice?
A: They make my wrist hurt. Moving the mouse around is a stressfull operation by itself, but pressing the buttons and especially dragging the mouse with a button pressed is much worse yet. This is further complicated by the fact that by some reason the industry does not make mice of a size suitable for a man's hand: the mice available are of a right size for a child (or a small person). I can't just rest my hand on the mouse because the mouse is too small, I have to keep my hand suspended in the air in an uncomfortable position all the time. But of course there are applications for which a mouse is the best (or at least very good) input device. Graphical editors for example. Just the mouse must not be used as the main input device for most of the applications.

Q: Whom to blame?
A: First, of course, Douglas Engelbart who has invented the mouse. Then Jef Raskin who has invented the mouse dragging. The story in a nutshell is that the developers of Macintosh have decided that the users are too stupid to use multiple mouse buttons. So they created a mouse with only one button and had to find some substitutions to the multi-button actions used at PARC, so they invented dragging the mouse with the button pressed. It's kind of funny that Jef Raskin also wrote a book named "The Humane Interface". I haven't read this book yet so maybe it actually is full of great ideas. But the fact itself that a book with such a name is written by an inventor of what is essentially a torture device looks interesting to me.

Tcl and Tk

Q: What do you think about Tcl after all this experience?
A: Tcl is a wonderful language for its original purpose, creating specialized control languages for applications. It is very extensible and due to this extensibility Tk is beautifully integrated into it (I think much better than say Perl/Tk). I also liked very much the ability to do a foreach loop with a whole set of loop variables. However as a general scripting language Tcl is rather strange and way behind Perl. It also has quite a few imperfections: No binary searches on sorted lists. The list searhing does not allow for easy insertion of the new elements into a sorted list. So after all I've ended up with implementing this stuff by myself. The string syntax does not allow to specify parts of a string with different quoting. For example, in B-shell you can write '$a='"$a" but in Tcl you can't write {$a=}"$a". This is especially annoying when specifying the regular expressions or the event handlers in Tk. The regular expressions are less powerful and convenient than in Perl. No built-in command to reverse a list. No way to split a string by a regular expression. No normal Unix calls (such as kill). Strangely, these calls are in XTcl (A 2003 note: it's TclX, not XTcl.) and VisualTcl but not in the standard Tcl. And the lack of them does not seem to me as any sort of win from the portability standpoint either, there already are plenty of things marked as "Unix only" or "not on Macintosh". The neccessity of explicitly naming the expr command for every expression is annoying. No command to append elements at the front of the list or remove elements at its either end. No command like info exists for the global scope. No obvious way to get the list of indexes of an array (and I'm not sure whether there is any way to get them at all). (A 2003 note: there is a way and it's obvious to the people who pay attention when reading the man pages.) No easy way to modify an element within multiple layers of nested lists. No easy way to search in nested lists. No direct support for keyed lists (although XTcl and VisualTcl do have this support). These imperfections make Tcl look a bit underbaked, like some things were left for future and then never fixed.

Q: What do you think about Tk after all this experience?
A: The Tk's approach with preference to building applications by combining widgets rather than inheritance is very nice. And again, it's quite well integrated with Tcl, so the code is easy to write. But alas many places in Tk seem to be kind of half-baked, with features done more as a guess, a placeholder for future use rather than as a result of writing actual programs with them and then doing corrections by results of these experiences (according to the way of Natural Stupidity as popularized by Larry Wall). Well, maybe these corrections were intended but never happened. The difficulties I've encountered include: The geometry managers are underpowered. No way to request a complete geometry recalculation in a specific subtree of widgets. No way to write the geometry managers in Tcl (had to implement it myself). The whole geometry management model is limited and does not allow to differentiate between the optimal and minimal sizes for the widgets (but on the other hand I know no other model than can). The keyboard event handling is not very obvious and the default bindings are not the most convenient ones. The text widget scrolling is broken. I can understand that, I've seen the same problem when implementing scrolling for my menus, but it takes not that much extra care to do it right. The size of the text widget is fixed, it can't adapt automatically to the size required by the text in it, and worse yet, there is no way to find this required size at all. There is also no way to figure out which part of the text is currently visible. And no way to page in and out the contents of a text widget on demand (if I want to look at a dump of a portion of a 2GB binary file, loading the whole file into the text widget is not the best way to do it even if the machine has enough memory). The labels don't support auto-wrapping (had to do it myself though in an ugly way). The standard menus are not particularly usable (had to re-do them myself). But again, this does not mean that Tk is worse than anything else. On the contrary, looking at the other applications, that seems to be the general state of the art in the graphics toolkits.

Not A Commander in particular

Q: Any comments about the current status of NAC?
A: As of now NAC has grown to about 17000 lines of code and the amount of work consumed has probably got close to a whole man-month. Honestly, it's the biggest program I ever wrote completely from scratch (even though I've participated in much bigger projects) so this is some degree of personal achievement. It is growing at a slower rate that I've thought originally. Partially this is because I've somewhat underestimated the size of the task, partially it's because some things that I've thought to leave for later have turned out to be needed earlier as a foundation for other things, and partially Tcl/Tk did not live up to my expectations. The current major roadblock is the rewrite or serious modification of the text widget. That's a large task by itself, so I contemplate it with some amount of scare.

Q: Will the X selection ever work?
A: I hope so. Currently I have not figured out yet how to do it right. For example, should the text in the labels be selectable? Probably yes. Should the data in the entry fields by selectable with the keyboard? Probably yes but it's not quite clear yet which keys to use. What happens if you start the mouse dragging (ew!, but that's the traditional action of X11) from a point slightly outside an entry field? Probably it should be able to select the contents anyway byt it's absolutely not clear yet how to implement that.

Q: Is there some better way to select the options in the dialogs rather than mouse-clicking or browsing with the arrow keys?
A: I plan to bind them to the functional keys but again it's not quite clear yet how to do it well.

Q: Any other short-term plans ?
A: I want to complete the set of file operations and do something about the viewers.