Re: Icons of program

[Fred Bacon <bacon mediaone net>]

raster@redhat.com wrote:
> 
> 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.

This is really a non issue in my book.  1) A good data base will suffer
corruption on only an irregular basis, 2) so long as non vital
information is located in the database corruption is irrelevant and 3)
so long as you have a failsafe way of reconstituting the database there
is no danger.

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

Agreed.

> * You can't go developing new filing systems like macos's because it
> simply isn't protable. Macos isn't a good example 

I don't want to duplicate the Mac's file system, just its database. 
Trying to emulate the Mac's data+resource fork system is a non starter. 
It really isn't even needed.  I would bet that more than ninety percent
of the files on my HFS partitions contain information in only one of the
two forks.  The other fork is empty.  

Modifying file formats isn't needed either.  Sticking the icon inside of
a file isn't necessary, or desirable.  OpenDoc tried something like that
with the Bento container format and it was a disaster.  Perfectly common
image format files were unintelligible to non OpenDoc aware applications
because they had been wrapped with this unfamiliar Bento format
information.  

When you start out in the minority (as gnome undoubtably will) you can't
be incompatible.  Providing additional facilities is good.  Blocking
traditional facilities is bad.

> 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

Let's say I'm working on a large project. (I believe the program I'm
currently working on contains something like 5-600 files--counting the
external libraries--in the distribution.)  Are you saying that I would
have an additional 5-600 .info files in there as well?  Plus another 300
when I compile the *.o files?

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.  

The file manager in KDE is my least favorite component, and its least
used feature.  I honestly never use their trash can. (When I was first
learning my way around unix, I created a pseudo trash can called .trash
and aliased rm to simply mv files into the .trash directory.  Then I
wrote a script to pick through the trash and salvage the things I didn't
really mean to throw away.  I named it wino. :-)  I do like having icons
on the desktop for launching applications, but I don't use their drag
and drop facilities because it's too clunky and slow.  Plus, I never
know if I've hit my target or not.  A gui interface for my file system
is simply not a high priority for me.  Any application which clutters my
directories will be history inside of a week. 


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

It's also what a database is for, and of the two a database is more
appropriate.  A database doesn't have to be anymore difficult to use
than the file system.  

It just struck me a few minutes ago that what I have been advocating is
really a Corba Service.  It's an interface available for use by any
application.