Re: Icons of program

[raster redhat com]

On 22 Apr, Dwight Hubbard shouted:
->  Miroslav Silovic wrote:
->  
->  > Andreas Kostyrka <andreas@rainbow.studorg.tuwien.ac.at> writes:
->  >
->  > > Actually we are talking here not about a global config registry, but
->  > > more something like a per-file registry.
->  >
->  > I was actually talking specifically about windows registry. Now let's
->  > take a cut into GNOME:
->  >
->  > Okay, the list mentioned the four distinct ways to handle per-file
->  > info:
->  >
->  > 1) single, big file somewhere in the user's home directory
->  > 2) single, big system-wide file (handled with a daemon)
->  > 3) small files in a separate tree in the user's home directory
->  > 4) small files in the same dir as the files they affect
->  >
->  > Advantages and disadvantages (IMO):
->  >
->  > 1)
->  >
->  > + low inode cost
->  > - won't cooperate with the existing UNIX tools (cp, mv, etc)
->  > - needs separate mechanism to handle permissions (as permissions of the
->  >   file won't necessarily match permissions of its meta attributes)
->  > - other users won't get meta data of the same file
->  
->  - Difficult to extract data for one file when moving to another system or
->  removable media.  This also means that metainfo on removable media from
->  other systems will not be present.
->  - File corruption will affect all file's metainfo.
->  
->  >
->  >
->  > 2)
->  >
->  > + low inode cost
->  > + this system can migrate to kernel
->  > + users can share meta-data, even remote users
->  > - won't cooperate with the existing UNIX tools
->  > - won't work with removable devices (CDs, floppies) without extra work
->  > - needs admin access to run daemon (not suitable in multi-user
->  >   environment where users compile GNOME for personal use) - this is
->  >   marginal disadvantage
->  
->  - Difficult to extract data for one file when moving to another system or
->  removable media.  This also means that metainfo on removable media from
->  other systems will not be present.- File corruption will affect all file's
->  metainfo.  On bigger systems, there is a likelihood that with this setup
->  the metainfo and the files would be on different filesystem/drives.  A bad
->  hard drive could loose all metainfo on the system even though the files
->  are there.
->  
->  >
->  >
->  > This system is actually the closest we can get to having the metadata
->  > implemented on the FS level - provided that removable media get their
->  > own db.
->  >
->  > 3)
->  >
->  > Same as 1), but at high inode cost. This looks like a bad idea to me.
->  
->  Not the same as 1)+ Corruption of one files metainfo will not affect other
->  files metainfo.
->  
->  >
->  >
->  > 4)
->  >
->  > + works passably well with existing tools
->  > + works well with mounted filesystems and removable media
->  > + simple to implement
->  > + users can easily share metadata
->  > - high inode cost
->  > - 'ls' gives litter
->  >
->  
->  +Corruption of one files metainfo will not affect other files metainfo.
->  
->  > Well, that's it. I like 4) and 2) - and am sort of undecided between
->  > these two. 4) looks least bad (as its disadvantages are mostly
->  > aesthetic). Flame on. :)
->  
->  I personally like 4.  Although, it is a bit annoying to have the .info
->  files together with the file.  It has several  advantages as well, the
->  biggest one is it is very difficult to screw up all your info files.  I
->  think it would be beneficial to have the system have a central repository
->  of default .info files that get used for files based on their magic if the
->  file doesn't have a .info file for it.  That way the .info files would
->  only be needed to override the default.
->  
->  In addition, it would really be nice to have multiple simple vfs
->  implementations that implement solutions 1, 3 and 4.  That way the user
->  can decide on how metainfo is handled.

Well I think it's time for me to chime in again after having
observerd/read everything everyone has said.

I still thik (4) is the best solution overall why?

* you can't go corrupting a DB.

* 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).

* other unix utils can easily move the icons around with the file
without having to go rebuild databases etc.

* a filing system is already a reasonably efficient databasing system
on its own.

* You can't go developing new filing systems like macos's because it
simply isn't protable. Macos isn't a good example - AmigaOs and Windows
are examples of our situation - windows implimented the "one big
database" solution - amigaOs implimented the - use the filingsystem as
a DB and keep lots of icon files around - windows's registry does blow
up - it happened to me a long time ago.. I dont have windows anymroe..
but it could not fix its own registry, even though it claimed "copying
known good backup onto registry". The problem here is permissions.. the
amiga (unless you installed mufs) didn't have permisssions so the user
could create icons whenevre they wanted... - this can be fixed as
follows: ".info" file tags along in the same dir as the file - the
filemanager uses this UNLESS there is a .info file in lets say
~/.gmc/icons/usr/local/pix/water.png.info for a file in
/usr/local/pix/water.png - that info file overrides the system .info
file that is with the file - a system admin can setup icons for files
on the system easilly to make it easy for new users.. if a user wants
different settings for that file he/she can "edit" the icon info in the
filemanager and the fm creates the new icon in ~/.gmc/icons/.... - now
we have the bets of both worlds.. and it is implimented the same way:

sprintf(ico,"%s/.gmc/icons%s.info",homedir,file);
icon=load_icon(ico);
if (!icon)
  {
    sprintf(ico,"%s.info",file);
    icon=load_icon(ico);
    if (!icon)
      {
        filetype=filetype_of(file);
        sprintf(ico,"%s/.gmc/default_icons/%s.info",homedir,filetype);
        icon=load_icon(ico);
        if (!icon)
          {
            icon=default_compiled_in_icon;
          }
      }
  }

now that code, assuming we have an icon struct and a loading routine
(and some other assumed routines) We're set - no database that has to
brebuilt and modified when we delete an iocn in the middle (then have
to repack the data all the way to the end) - thats what filing systems
are for.

* inodes are cheap - my 6.1gb HD is 71%full - and well. I'm using about
5% of my available inodes. My last linux box wiht a 2gb Hd wasn'y
dissimilar - piles of inodes to kill. I think we can safely ignore the
inode problem. The only mahcines with inode problems are generally
news-servers. Systadmins have to format them differently form normal to
get higher inode counts. In addition there probably wontbe an icon for
EVERYTHINg on your system.. what's the point of an icon for "grep" u
need arguments and other stuff - and most binary utils are used by
tohers.. yes a user MAY want to give an icon to grep sometime.. but
normally they wont.. icon files will be created when users use
dfferent-than-default icons (ie icons that the filemanager doesnt pull
out of its default_icons dir based on filetype - but the fm doesnt save
the icos file int he dir.. it only uses the default.. doesn't go
creating new icons all over) the different-than default will only be
created when either 1. an app ships WITH icon files (ooh nice.. imagine
gimp shipping wiht a nice icon for itself - and other apps) 2. a user
edits/creates an icon (most likely will be the case with image files -
to have a "thumbnail" as an icon possibly and to run the imageviewer
with the image when "run") - so it wont be that bad.

*  we have to accept cp, mv, rm etc. are NOt goign to deal wlll with ANY
icon system we use that has any power at all. you are goign behind the
filemanagers back - the amiga had the same problem. People savvy enough
to use the copy, move, delete (or on my amiga i had csh and all the unix
cmds) were assumed to be asavy enough to realize ythe .info file had to
move too. Otherwise use the filemanager to copy/move etc. thats' what
it's there for!. The onyl way this will work is "patchting" EVERY
utility to look for an icon file ANd copy/move whatever it too. - bad
move. SO we have to acept a break between the cmd-line and the GUI
environment.

* using icon files is piss-easy to impliment - it's simple, easy, hard
to break (ie the KISS prinicple. Keep It Simple Stupid) so corupt
databases aren't a possability - it also will speed up implimentation
time/development of it.. infact i plan on writing icon
file loading/saving routines into gnome sometime in the near future,
which is why I am paying attention to this thread. Plans are:
Tag/chunk base d9ie extenisble.. ooh sounds like IFF format to me..
(WHEEE amiga formats kick back in), will allow 24bpp,16bpp,or
8bpp+palette formats for icon images (will see about usng zlib to
compress/decompress) - will have multiple images for an icon staged
with state names so you check for the "normal" state image, the
"selected" state image, the "busy" state image etc. Other chiunks will
be tagged for "tooltypes" (ie options for a command) and "tool" for the
tool to run ont he data file (if its a data file, not an executable) -
since the format is extenisble there isnt much else I have to do - the
routines will allow reading and writing of arbitary chunks of an icon...
Well I'll use Imlib of course for the image stuff... :) Once done
Miguel shoudl have a nice set of routines at his disposal....

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/