Re: Icons of program

[robert havoc pennington <rhpennin midway uchicago edu>]

On Tue, 21 Apr 1998, Mark Andrew Hulme-Jones wrote:
> 4) Whilst the idea of this SimpleVFS is a nice one, I think it has one
> inherent fault, which I'll illustrate with an example. When I started
> using the Amiga, I had had no experience with a proper command line
> interface, I had used the BBC's command line, but that had no
> hierarchical filesystem support (or not a proper one unless you owned a
> Master) so I was pretty unfamiliar with the concept. Instead, I used the
> Amiga's drag 'n drop filesystem, (Workbench) which up until a point
> served my purposes very well. When I later moved up to the command line,
> the directory structure which I had created existed exactly as one would
> expect from that command line. This is the crux of my point, for new
> users migrating from something like gmc to a shell, they're going to
> have to recreate their VFS from scratch elsewhere, as a non-VFS, which I
> personally would find extremely irritating.

In my proposal there are several ways to handle the migration.

1) Never use SimpleVFS in the first place. 
2) Move your SimpleVFS directory to your home directory, and it's
   suddenly a regular directory; just as if you moved something from 
   gmc's tar VFS to a regular directory.
3) Use .desktop links to embed Simple in non-Simple, or vice versa.

My point is that you can have all these things with a trivial amount of
additional code over just having meta-information. It's a lot more
flexibility at very little cost.

> A mime-types database should be used to associate filename suffices with
> an appropriate program (eg .jpg with ee), this should be changeable by
> the user. This would represent the default action associated with
> double-clicking on a file. It would also set the default icon for that
> type of file.

This isn't much different from what gmc does now, I don't think. It's not
at all mutually exclusive with meta-information or the SimpleVFS idea. 

> The user should also be given the _advanced_ option of providing the
> document with an info file, which specifies an alternate behavior for
> that particular document (eg. opening a .jpg file with gimp instead) and

Sure. But once you do this you already have almost everything for
SimpleVFS, so that option may as well exist. 

> The above seems to me to be the only way to reconcile the problems
> between those who want to completly abstract away the standard UNIX
> filesystem, and those who still want to use the shell, without needing
> any ELF-specific binary patches etc.
>

You haven't provided any way to abstract away the standard Unix fs.  The
way to reconcile the problem, IMO, is to have two "modes," "worlds,"  or
"partitions," one is the standard Unix fs (optionally with
meta-information), the other abstracts the Unix fs (but, this is key, is
*implemented as* the first world, Unix fs with meta-information). Since
the abstract fs is implemented as the non-abstract one, it's not much more
work to provide this easy-to-use feature for newbies.  All you have to do
is write the meta-info scheme correctly in the first place. 

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.

> I think the best place for the SimpleVFS idea is for representing the
> desktop, (which may be the intention, I'm not sure) at least this way

This is what it does, only there's no distinction between the desktop and
the fs. That's why it's not confusing.

> you avoid confusing the user by telling them that the desktop
> (apparently the top level of the filing system) is in fact about three
> levels deep on the C Drive (?, I still wonder how MS came up with that
> one) 
> 

You don't tell them. The fact that it's in fact about three levels deep is
the same as the fact that /home/hp on my system is really /dev/hda8. i.e.,
totally irrelevant to daily activity. If they need to access the real Unix
fs, they can do so by switching modes or by making a link to it in
SimpleVFS; but then they're still using their SimpleVFS files from
SimpleVFS, so no confusion. There's never a reason for them to know how
SimpleVFS is implemented. If they need SimpleVFS files from non-Gnome Unix
programs, they copy the files from SimpleVFS to the regular fs.

The problem with the MS approach is that they didn't finish the
abstraction. It was a half-ass semi-break with the past. You can't really
live entirely in the old or the new scheme, you're forced to use both.

The basic trait of any viable solution here has got to be configurability,
because we have to make most people happy. That's the nature of free
software. I'm simply suggesting that the meta-info scheme be abstract and
flexible enough to permit a fs abstraction scheme. My argument is that
this is pretty easy to do.

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