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.
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.
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.
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.