Re: Icons of program

[robert havoc pennington <rhpennin midway uchicago edu>]

On Tue, 21 Apr 1998, Andreas Kostyrka wrote:
> But it all doesn't solve the problem, that I user may want to use a
> different program depending upon the file and not the type of the file.
>

I'm not arguing with that. I'm proposing:

- meta-information; if this fails or is turned off by the user,
- automagical meta-information generated by file type; if this fails or
  is turned off by the user,
- use a generic icon

SimpleVFS is a separate idea; a virtual fs implemented on top of a Unix
directory with meta-information.
 
> Additionally, extensions are not a really good idea to determinate the
> file type (see Windoof for a proof of this sentence).

Agreed, that's why you have all the above options.

> The problem is, that gimp should generate this by default. So images the
> user works upon are by default opened by gimp.
> And the UI has to deal with ``open default for file'', ``open default for
> type'', and ``open with ...''.
>

Not a problem. Has nothing to do with the (non)existence of a simplified
filesystem abstraction.
 
> > Then everyone has the choice of: regular Unix fs; Unix fs with guesses
> > based on extension, 'file', etc.; Unix fs with some meta-info scheme;
> > Simple fs; Simple fs with Unix fs as a subdirectory; Unix meta-info fs
> > with Simple fs as subdirectory. You can have various combinations of those
> > options, or only one. It's all based on the same meta-info code. Everyone
> > should be happy.
> It's not that easy. Actually, when we are creating an ``icon store'' for
> files used by gmc, why doesn't the programs use this store to fetch their
> information? Why limit it to the icons? Why not store the positions and
> sizes of the document windows in the icon, so when the user reopens the
> file, the program will be in the same state it was when the file was
> saved?
>

You can do all that stuff with meta-info. I'm not saying anything about
what you're saying here, except that it should be optional and it should
be implemented in a flexible way that supports a simple virtual fs.

> > This is what it does, only there's no distinction between the desktop and
> > the fs. That's why it's not confusing.
> I still prefer to augment the whole filesystem, without shadow trees in
> each homedir (just keep the tree synced, when the admin install/erases
> packages, moves dirs, etc.)
>

With my scheme, you have this option. You just have a systemwide
SimpleVFS, or a systemwide Unix directory with meta-info (i.e. what Gnome
now has in [datadir]/share/apps/).
 
> And the meta info (or resource fork, or icon file, suit your vocabulary
> *g*), should be stored in the proximity of the file, so an advanced user
> on a non-GNU system (I'm still proposing a configure option for GNU file
> utils to make it transparent on the commandline) knows that he has not
> only to move file but also file.info (or whatever it is called :) ).
>

This is fine with me, as long as the meta info is optional, and
implemented in such a way that a simple virtual fs can be constructed in
terms of it.
 
I don't think we disagree; what I'm suggesting doesn't really impact what
you're suggesting. The only thing is that however the meta-info is
implemented, I think it should keep in mind the virtual fs possibility. I
don't think it's hard to do so.

Havoc Pennington
http://pobox.com/~hp