Re: Icons in fs (Was: Re: undo/redo)

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Thu, 23 Apr, 1998 at 02:49:20AM -0000, Russell Nelson set free these words:
> 
> I thought more about it, and it doesn't need any kernel support.  Not
> only that, but it doesn't require Linux.  All that it requires is a
> will to lose transparent backward compatibility.  ALL of the schemes
> proposed so far lose some sort of backward compatibility.
> 
That's not true -- I think all the schemes proposed so far lose "forward
compatibility"; a few also lose transparent backwards compatibility.
Meaning?  If you use the shell without thinking about how you are affecting
metainfo, then you are probably going to separate metainfo from its data file.
The view of the shell user under those conditions will not be impeded however.
The proposal to put the .icon/.info files directly into the fs tree next to
the file it refers to, however, does change the view the shell user has of the
fs -- which means it loses 'transparent backward compatibility".

> If you wish only to solve the problem of assigning an icon to a
> program, #4 (separate .icon file for each executable) is sufficient.
> Users can override the system default by creating a symlink to the
> executable in their ~/bin, and a matching .icon file.  The problem is
> keeping the .icon with the executable.  People don't install
> executables by hand *too* often (when was the last time you did
> "cp prog /usr/local/bin"?), so that's not too difficult a problem.
> 
> Still, it comes nowhere near solving the problem of associating an
> icon with a data file.  If icons are good, then more icons are better.
> 
This isn't clear -- I can see you pointing out several things with this
statement, but I'm not sure which it is.

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~