Frequently Answered Questions

1. Does Bantam run on Microsoft Windows?

No, and I do not plan ever to create a Windows version. See #3.

2. Does Bantam run on Mac OS/X?

Apparently so. One user has reported success in compiling and installing
Bantam on OS/X. Please note, however, that there is currently no "user
community" to speak of, and I have no access to an OS/X system, so you
are on your own for the time being.  If you do try Bantam on OS/X, I'd
be interested to hear what happens.

3. Why not create a Windows version?

In general I am a strong proponent of cross-platform development. But I
doubt that it is a good idea to create a file manager that attempts to
run on two systems as different as POSIX and MS Windows. The way files,
and information about files, are organized, is at the very heart of what
makes an OS distinctive. Trying to develop Bantam for both POSIX and
Windows would mean either (a) supporting only those functions that are
common to both systems, or (b) creating two programs in one. I am
unwilling to do either of these, because my objective is to create an
excellent file manager for POSIX/X11 systems.

Bantam is open source software. If you like the way it works, and would
like to create a similar file manager for Windows, go ahead. But please
don't call it Bantam.

4. Is Bantam compliant with GNOME/KDE/ standards?

No, and I doubt it ever will be.

While I don't wish to create something gratuitously different, I have
some strong disagreements with the leading desktop projects. In a
nutshell, I believe both GNOME and KDE, like Microsoft Windows, embody
the conventional wisdom about usability rather than pursuing a genuinely
better user experience.

Though Bantam is hardly a model of how an interface should be (it would
be difficult or impossible to create such a thing using any standard GUI
toolkit), it differs from the mainstream usability guidelines for
specific reasons.

For example, it uses single-keystroke commands for almost everything
because they're fast and easy for those who are used to the keyboard;
and since the number of keys is limited, it inevitably uses keystrokes
that wouldn't be allowed by the GNOME Human Interface Guidelines.

And there's no menu bar because Bantam is targeted at power users--
people who presumably aren't put off by learning a few simple commands.
And given the nature of the program--a file manager--most of the
commands and their abbreviations should be fairly obvious.

And so on ...

5. Will Bantam have icons?

Probably not. Icons hurt performance, and one of the primary objectives
is for Bantam to be very fast. Besides, I don't believe icons in general
are very useful to Bantam's target audience (geeks).  They may tell you
the type of a file, but you can very often tell that from the file's
name; they don't convey a lot of other information you might want to
know. The one exception to this rule is thumbnails-as-icons for image
files. That can be a very useful feature, but as of this writing I don't
feel it really fits into the Bantam approach.

6. Why is everything keyboard-driven? Why no menu bars or toolbars?

First of all, I don't believe there is any way to make a truly fast
and light file manager that is also full of clickable widgets and eye
candy. And the keyboard is generally far more efficient than menu
commands--provided you know what to type. Bantam is an interface for
performing some very common and fundamental operations; anyone with a
basic understanding of file systems and the things that are done with
files should find it easy to remember most of the keyboard commands: 'm'
for Move, 'c' for Copy, and so on.

But why not offer GUI controls as an optional feature?

Geeks tend to believe that choice is good, and more choices are better.
In some respects I agree, but based on personal experience, observation
of non-technical computer users, and extensive reading in the user
interface/HCI field, I have come to believe that it is often
counterproductive to provide multiple methods to perform any given task.
True, a one-way-to-do-it design forces the user to learn that one way.
But once you've learned how to operate the program, it becomes second
nature, and you can then concentrate on the choices that really
matter--what to do with the data you are manipulating with the program.

Speaking of choices: remember that there is a huge variety of file
managers available. Use whatever works best for you.

7. Why can't I select multiple files at once? Isn't this supposed to be
a *powerful* file manager?

Does seem a bit contradictory, doesn't it? However: Bantam makes it
really easy to perform destructive operations like deleting and moving
files. I'm afraid that if you could select multiple files, it might be
too easy, for example, to hit the delete key, thinking you were just
deleting a single file, but forgetting about several others you selected
earlier, but which are now out of view.

But I haven't forgotten about convenience. Hopefully, that concern will
be answered by the Workbench, coming soon. In brief, the Workbench will
be a way to collect a group of files from one or many directories, then
perform a single operation on all of them. It should be great--but if it
turns out to be less great than I imagine, I will reconsider allowing
multiple selections in regular directory panels.

8. How can Bantam be really lightweight with a GTK GUI?

The short answer: maybe it can't--not as lightweight as I would like it,
certainly. But since the ideal GUI toolkit doesn't exist, I have had to
compromise. See #9 for a way to speed up perceived startup performance.

A longer answer: I don't particularly like GTK myself; Bantam was
originally implemented in Tk, which is quite lightweight and makes
simple things simple for developers. However, for at least four reasons
I found in impractical to continue using Tk: first, there were several
features I consider important which couldn't be done in a clean and
straightforward manner in Tk (tooltips, for example), and I found myself
spending way too many hours working around these limitations; second,
Tk's text rendering is ugly, and I care a great deal about how text is
rendered; third, Tk is not yet properly internationalized; finally,
since the OCaml wrapper library executes all Tk operations as text
messages to a Tcl interpreter, error handling is awful.

9. Bantam takes too long to start up! How can I speed it up? 

You can't actually make it start up faster, but you can make it *seem*
to start faster by using daemon mode. Start bantam like this:

  $ bantam -d &

The program will run hidden in the background, waiting for instructions.
The following commands are recognized:

  $ bantam -s     Show the GUI
  $ bantam -q     Quit

In daemon mode, the interactive 'quit' commands ('q' key or pressing the
'close window' button) actually just hide the GUI. The 'bantam -q' shell
command really exits the program.