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.
Are not the limitations of the Unix text interface at least partially
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).
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.
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.
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.
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.
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.
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.
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.
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.
Any other short-term plans ?
A: I want to complete the set of file operations and do something about the viewers.