Re: Icons of program

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

On Thu, 23 Apr, 1998 at 01:48:31AM -0400, raster@redhat.com set free these words:
> On 23 Apr, Fred Bacon shouted:
> ->  raster@redhat.com wrote:
> ->  > 
> ->  > * even ls will indicate that an icon is associated - for file that dont
> ->  > have icons assigned the FM can dynamically assign them and not have to
> ->  > create info files (the users ~/gmc/default_icons/*.info can contain
> ->  > template icons for file times based on magicnumber/extensions (read
> ->  > magic number - if unknown check extension, if unknown give up and call
> ->  > the file data) and the fm will ue one of these icons depending on
> ->  > filetype if no icon exists).
> ->  > 
This is a bug, not a feature!

[snip]
> 
> ->  Your method has some merits, but I would honestly not be willing to use
> ->  a system that littered my directories with scads of useless files.  One
> ->  of the reasons that I never use xv's visual schnauzer is that it
> ->  produces so much clutter.  The fact that /usr/bin isn't cluttered by
> ->  this technique is irrelevant.  It clutters where I live.  A gui file
> ->  manager is far less important to me than a tidy home directory.  
> 
> if you USE a filemanager u never see the .info files.. - and onyl if
> you have extra non default data associated wiht files do you see it.
> 
And also: If you don't use the filemanager, you shouldn't have to be bothered
with the info files.

[snip]

> now remember,.. we shoudlnt be selfish and think of yourselves.. think
> of the USERs.. the peopel who have used a mac or win95 box for years..
> they neither know nor care anout the .info file existion.. they just
> want a pretty picture.. maybe want to assing different pictures to
> files - change how that file is used (ie this image is opened by xv,
> this opened by ee, this oopened by gimp) and when they move the file
> the icon follows, with proprties.. it's also easy to then xfre files
> WITH their properties form one system to another.. just tar up
> everyhting... alos useful: icons for dirs:
> 

Item: The GUI filemanager needs metainfo (in .info files if you're raster, in
a db if you're Fred Bacon.)

Item: The shell does not need metainfo

Item: People new to UNIX are going to use the filemanager and not the shell.

Conclusion: Putting metadata into the filesystem alongside the regular files
is the wrong way to go about this.  Users who only use the filemanager are
never going to know where the metainfo is anyways.  People who only use the
shell are not going to have to look at the extra .info (actually:  have to
have another name -- .info's already taken :-)  files.  People who use both
the filemanager and the shell are the only losers, but they're the loser's no
matter what -- They will always be forced to move their metainfo along with
their files, whether the metainfo is in the same directory, another directory,
or in a database.  Sometimes having it right next to the real file will be
better (cp gnome* public/) other times it won't (cp gnome*html public_html/).

what we should do is provide tools to move metainfo along with normal files
(we could hack cp -- or we could simply provide a shell script) -- People
unconcerned with metainfo can go on using cp, mv, etc and not care whether
meta-info is there or gets lost.  People concerned with such things can use
gcp gmv etc....

-Toshio

(I think we should think about leaving hooks for both db and file-dir
meta-info, and whoever has the time and will to code the backends is welcome
to do it and we can judge relative merits then.... What I am against is .info
files in directories alongside normal files.)
-- 
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  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature