Re: My thoughts on icons and meta-data

[robert havoc pennington <rhpennin midway uchicago edu>]

On 26 Apr 1998, Tom Tromey wrote:
> 
> This is rather long.  Sorry about that.  Please bear with me.
>

I'm not in a position to criticize. :)
 
> 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.
>

I think you're missing one category of user: applications-only users.
People that could just fire up StarOffice, maximize it, and never use
anything else. I think we want to appeal to them, eventually.

There are lots of people that can really work WordPerfect or Excel or
whatever, but get lost in the filesystem or installing software.

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

Precisely. All I'd add to this is that the special directory should
(configurably) be the default, and optionally the special directory would
have no links out to any real directories, to allow creation of a
fully-simplified environment. Also the special directory has to be
writable, not just share/apps. 

To try and tie up the thread: I think it's a false dichotomy between
hiding and not hiding the filesystem. If you have special directories, you
already have a special simplified filesystem. It's purely a matter of what
the file manager/file dialog is configured to default to. It shouldn't be
extra work to add the special simplified world, provided it's kept in mind
from the start. 

I'd like to suggest that the special directory can be a powerful tool for
power users, too; it'd really help keep things organized, I think. I for
one have an "applications user" mode and a "power user" mode, which
generally corresponds to writing documents and writing programs.

Let me mention again that StarOffice has an example of this; that might be
clearer than my attempts at explanation.

Doesn't matter to me if this is implemented as a database, .desktop files,
or whatever. Whoever writes it can decide. As long as it allows creation
of links (to files and directories), and one can specify "show me real
Unix" and "show me Gnome" on a directory-by-directory basis, and the
"special" directories are writable.
 
> 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.
>

This is why I'd like to divide Gnome directories from real directories, so
I can have places where those things do work. It should be trivial to
allow any directory to be designated "Gnome" or "not Gnome" according to
user preferences; the file manager shouldn't do things like invisibly
Gnomify a directory. 
 
> 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.
>

Should be able to do this on a directory-by-directory basis, for example
use full metainfo for special directories and automagical mime types for
others. 
 
> 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.
> 

I think the only real issue is .info files vs. a database. It's not easy
to do both of those, and I have no real preference either way so I won't
comment.

However, the dead horse I keep beating on is that the other stuff (special
directory, hiding reality, which if any directories are gnomified) is
mostly cosmetic -- thus easy to make configurable, as long as you keep
flexibility in mind while designing the meta-info scheme. IMO we should
end the thread based on that; configurability is always the best choice
when it's pretty simple to implement.

Havoc