Re: Icons of program

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

On Fri, 17 Apr, 1998 at 09:48:52AM -0400, raster@redhat.com set free these words:
> On 17 Apr, Sangsu Kim shouted:
> ->  Is there any standard method of include  icons into executable file?
> ->  I think that ELF format is generous and flexible enough to include the
> ->  icon information.
> 
> Bad Idea. We cannot generalize this to "any file" - time to take a
> lesson from the Amiga:
> 
> filename
> filename.info
> 
> The filename is the actualy file... nothing magic about it.
> filename.info is an icon file. ALL files with icons posess these and
> they "tag along for the ride" whenver you copy, move, etc. The icon file
> contains the graphic data for the icon, plus properties of the file (the
> amiga had an "icon" equivalent of comand-line-options for programs or
> data files when run with a program.. eg the icon would store what
> program to run to retrieve the data again.. each an image could store
> "ee" as the retrieval program.. or gimp - it could also store
> properties that were effectively command-line-options for the program
> being run. The icon file coudl stroe multiple images, eg for norma,
> selected etc.
> 
> fils that didnt have .inof fiels tagged along in the dir would be
> "given" and icon from a system repository of icons based on file
> (executable, project, device etc.) this can be expaned to use mimi
> types for extensions and magic numbers (i personally propose magic
> numbers as a FIRST means of identification - if this fails fall back to
> extensions.. if that fails treat the file as unknown data (unless stat
> on the file reveals its an executable, named pipe, fifo, directory,
> device etc.) the filenamager when it first scans a dir of files that
> havent been given icons can go create .info files so in future it
> doesnt have to keep working it out every time... the info file will
> store everything needed. If the user cannot write then the fm will have
> to work out what system icon to use each and every time. (unless we
> make the fm suid root and it will "become root" whenever it needs to
> create or modify icon files that the user cannot access normally - but
> now we're talking REALLY evil)... Anyway.. Just thought I'd throw this
> in...
> 
What's wrong with the approach of keeping a system and user file(s) which
contain this information?  (I know the dfm filemanager currently uses
something like this.)  You have a directory or file where file metainformation
is kept.  There is one that is set up by the sys admin and is not writable,
and another that is in the user's home directory and customizable by the user.

By keeping meta-info in two central locations, we avoid making a filemanager
write to a system directory.

-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  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature