Re: Icons of program

[Ronald Offerman <ron bofh-home gjt-it nl>]

> robert havoc pennington wrote:
> > 
> > (Note to no one in particular: some people seem to be missing that there
> > are already foo.desktop and .directory files which keep icon information,
> > among other things. See share/apps and libgnome/gnome-dentry.[hc].)
> > 
> > What about this idea: it would keep everything nice and simple if these
> > files and regular files simply weren't allowed to exist in the same
> > directory. That is, the .desktop files are "shortcuts," and are in their
> > own directory tree.  Naive users should never even see the real file
> > system. If they create new files, Gnome will invisibly put the data
> > somewhere like ~/.gnome-stuff, and create a new .desktop entry.  By
> > default, it shouldn't even be possible to view the real Unix file system
> > from gmc, only the tree of .desktop entries.
> > 
> 
> How about this idea.  Just as rpm uses a data base to maintain a record
> of where files were installed, gnome could build a set of databases (one
> in each individual user's home directory and a system wide database)
> which would contain information about which application created the
> file, what type of data it contains (jpeg, text, html, etc.) and what
> icon should be used to view it.  When a gnome compliant application
> creates a new file, it registers this information with the database.  
> 
> You do have to patch cp, mv and rm, but only with a one line gnome
> system call which updates the database.  You could even design a daemon
> which runs every night trying to maintain the integrity of the database.
Providing wrappers (any *sh script would do) is maybe a better way than 
messing with the standard binaries, an extract(ion) option could be provided 
which is used by gnome-savvy apps, this could be extended to a more 
generalized filesystem-info db (an idea I have been playing with lately).
> 
> Installing a new piece of software means telling the database what icons
> it wants to use for itself and the files it creates.  (These could be
> overridden by the user.)  It would register a set of icons for different
> bit depths either during installation or the first time it is started. 
> This way, you can avoid having thousands of different .info files
> scattered around like dead leaves waiting for a fire.
> 
> In fact, when a gnome application starts to open a file, it could query
> the database and ask, "What do you know about this file?"  "That's a
> binary file from octave containing a set of matricies in floating point
> representation."
> "Yuck! I was expecting a text file.  Hey, doofus, I can't read this,
> give me another file."  
> 
> Or better yet, you could filter the files visible in the file selection
> dialog box so that you would never be given such a file. (Making certain
> that you cculd turn off such filtering at will.)
> 
> Fred Bacon
> 
Reading this carefully could give the impression that this is YAR 
(Yet-Another-Registry) but done properly, (as is usual in the Linux way of 
doing things) this could be an filesystem extension that is fs type 
independent AND could be applied to 'other' OSes as well ;=)

If this database interacts with the rpm db and vice versa it be a great way in 
getting control over what is on any filesystem and probably also provide a 
place where alien fs attributes could be stored (eg. for mars-nwe, atalk)

-- 
<- Ronald Offerman -IT Specialist
<- ron@gjt-it.nl - raaoffer@xs4all.nl 
<- Thieme MultiMedia
<- IT and MultiMedia services

"Daddy, why do those people have to use Microsoft Windows?"
"Don't stare, son; it's not polite."