My thoughts on icons and meta-data

[Tom Tromey <tromey cygnus com>]

Tonight I caught up on my Gnome email.  In particular I read the
entire Icon thread.  Anybody who read the whole thing deserves a
medal, me included.

This is rather long.  Sorry about that.  Please bear with me.


I thought I'd write a note explaining what I think we need, and why,
and what I don't like about some of the proposals that have been
floated.  Some of the ideas below are blatantly stolen from other
people on the list.  I haven't attributed them, sorry (though Jim Pick
gets a special mention for injecting CORBA into the discussion).


First, the high-level view.  We definitely need some way to meta-data
with files, on a file-by-file basis.  While I sympathize with those
who support "icons by file type, not by file", I think this isn't
sufficient.  The reason is that icons aren't the only kind of
meta-data.  You also want to preserve icon placement in the file
manager windows.  People like to feel that they have some kind of
control over their workspace; for this reason forced automatic "icon
cleanup" is bad.

Once we have some kind of meta-data that must be associated on a
per-file basis, it clearly makes sense to allow icons and whatever
else we want.


Now that we have that as a requirement, we can look at two problems.
These problems are completely separable, and in fact it does help to
consider them in isolation.

1. How is the information served (the "interface")
2. How is the information stored (the "implementation")

(As an aside, I think this is a useful way to break down many
problems, especially in this space.  And generally speaking when I
haven't done this I've later regretted it.)


In principle I agree with Jim that CORBA should be used for the
interface.  However, its possible that current CORBA technology won't
provide the performance we need for the file manager.  It also isn't
entirely clear that this information is actually useful outside the
file manager (in which case the whole interface question goes away, as
it is completely an implementation detail).

For those fond of meta-data, note that I think that other sorts of
meta-data (e.g., undo histories) really do differ in kind from icon
information.  Or, rather, it is the case that different applications
of the meta-data idea might require different implementations, and so
must be considered separately (e.g., you might not want Emacs to store
auto-save files using the same mechanism the file manager uses for
icons).

Right now I lean towards the idea that this is an implementation
detail of mc, though perhaps with some minor external ramifications
(when installing application XYZ, how do I set up its initial icon
info?).  (If this turns out to be wrong, it doesn't matter, in the
sense that it doesn't actually affect my implementation ideas.)



Now some notes on implementation.  This gets into some general UI
philosophy that we've talked about before on this list (a long time
ago).

I think it's important to consider not only our target audience(s),
but also what effect we'd like to have on them.  While I think
usability for novices is important, I think it's more important to
recognize that our real audience is intermediate users.  Only dummies
and magazine reviewers (:-) stay novices for any period of time.
Everybody else advances up the learning curve to some point.

What does this mean for us?  I think it means that a scheme to
completely hide the Unix filesystem is probably not right.  Instead we
should have sensible defaults (mc defaults to showing $HOME, not /),
but let the user explore the system as it really is.

Things like the list of most-recently-used files, the list of
preferred applications, and the desktop can then be implemented in a
quite straightforward way: a special directory somewhere.


I don't like any idea that involves rewriting the shell utilities,
libc, etc.  This is just bad.  It's a shame, perhaps, that the Unix fs
model doesn't allow for extensible file properties.  But it doesn't,
and I think any attempt to patch that up in user space is going to be
a losing proposition.  It's better to just inform users that certain
things will never work.


I don't like the `.info' file idea.  At least, not if the file is kept
in the same directory as the real file to which it is attached.  There
are several problems:

* I don't want those files cluttering up my fs (I agree in advance
  that this point might not matter to everybody)
* Doesn't scale to multiple users (I want to control my own view of
  /usr/bin)
* There are two choices in the file manager:
  1. Show the .info files, leading to needless clutter (again, IMHO)
  2. Don't show the .info files.  The outcome here is that we'll have
     to modify more and more things to hide these to live up to user
     expectation.  E.g., the file dialog box, the find application, ...
     Again, hiding reality is bad.
* In any case, having the `find' application find the files
  implementing meta-data seems ugly.
* The extension `.info' is already in use (:-)


I think it is better to have a binary database that contains the info.
For instance, the Berkeley "db" package could be used (I understand it
is fast and reliable). Yes, this means moving stuff around via the
shell will lose. Too bad.  Renames, copies, and so forth in the file
manager will still work correctly.  I think fears of corruption are
probably unfounded, and in any case for this application they won't
matter.


I think it must also be possible to eliminate this database altogther
if one is so inclined.  For instance, you could do this by enabling
auto-placement for all icons, and setting an option so that only the
extension/`file' methods would be used to determine icons.


One thing I'd like to hear is ideas on how we could find a way to come
to a conclusion here.  Its all too easy for discussions like this to
cycle endlessly.

Tom