Re: Icons of program

[Mark Andrew Hulme-Jones <ceemahj cee hw ac uk>]

I have to say I am _very_ against the idea of embedding image information
along with the meta-data. There are many reasons why this shouldn't be
(The way I see it)...

- There are four different fundamental types of file which an icon may be
associated with, people posting here seem to be providing for one or two
of the behaviors associated with these different types, but not all...
I'll try and list what I think these four types are:
1) Desktop links, or *.link shortcut-style files (say I have ~/programs/sunos/crap/program, I could create a
shortcut in ~/bin/gnome which would run this from the filemanager by
double clicking [just like Windoze shortcuts] or from the shell by running
it [file format is a text file style shell script] )

2) Documents - documents should automatically be assigned an icon in the
filemanager based on their filename suffix (failing this some sort of
magic number system could be employed, like the Amiga's multiview program
did). This icon, when double clicked on, would open the file with the
default app associated with that file type, but the user could configure
what that app was... Again this work in the shell as well, by making the
file format an ascii shell script which ran the program with the file as
its parameter.

3) Programs in the system bin directories - A user can't really change
what the icon file associated with these is unless they
a) Have a file with a list of programs, where they live and the
associated icon file [You should need no meta-data for a binary, as it's
config file should provide any alterable information, right? At least that
would be the case for gnome apps, if anyone can think of relevant meta
data for binaries then say so]
b) Have directory which mirrored the system directories.
Frankly approach b) sucks, so you use a).... With which I can see no
problem really - pretty much all window managers employ such files for
configuring icons etc. which are associated with a particular XResource
name.

4) Programs in users own directory... Well, you can just stick a default
shortcut (.lnk, .info whatever) file next to the app (if you want to)

5) Directories - I haven't given these much thought, but they should work
pretty much the same as shortcuts to executables.

You could maybe add to that list files which are in user-unwritable
directories which are not binaries, but I haven't been intelligent wnough
yet to think up how to deal with those =)

Note that whether or not to use these .info/.icon/.whatever files or not
should be completely user configurable - so people who don't want them all
over their homedir don't have to put up with them. Such users would just
have to put up with mime-types associating what app to use to load the
file and the default icon for that file etc.

Something which occurs to me now is the following - provision of a
shortcut file in the same directory as the file itself would provide
alternate meta-data/icon information for the file itself, so if you have a
document ~/foo.txt you can right click, go to properties and change the
icon/associated app. and the fm would create the .lnk file for foo.txt,
before which it would not exist.  A desktop link (or link from anywhere
else for that matter) would be a file following the same format, but would
have a line saying #SHORTCUT /home/person/foo.txt so that the fm would
know it was a shortcut and not an associated resource file... This
principle should work for all file types above in some way or another :/

I don't understand why raster seems to think apps like the filemanager
would have trouble finding the icon image, they should all be stored in a
system wide directory like /usr/share/gnome/icons/picture.png and would be
specified with a line in a .lnk file like #ICON picture.png [or whatever
format you use] and the fm would know where to look already. Oh yes, you'd
better stuff in a directory where the user could stuff icons of there own
which the libraries [so you could have a simple call like get_icon(file)]
would know where to look in.

Even if somehow the icon specified in a .lnk file _isn't_ found, you still
have the system default [via mime-types/magic numbers] to fall back on.

The advantages of having separate images far outweigh the disadvantages -
they've pretty much all already been listed but it's my belief that
despite what raster says, diskspace _is_ a consideration... Separate icon
images were _wonderful_ on the Amiga - which was a _single user system_.
This system has (as I've said before) 1200+ users, which means that with
30 icons/user (a conservative estimate) at 5K/icon, you're using 180MB of
disk space - how many sysadmins are going to like that? OK, my situation
is both rare and contrived [not all users are going to use the gnome - or
will they, a system which used to be installed here used by default a
custom desktop thing based around DECAthena - pretty much all users stuck 
to it]. The other thing about separate picture files is you can have _one_
picture file associated with all of several files without silly amounts of
duplication (eg. I have 200-300 .c files in my src directory, which I,
being the foolish user that I am wish, to create .icon files for - using
a 2 or even more image .icon file in 24bit color for each of these is very
messy - We have to face it folks, people are going to be stupid enough to 
do this crap.) 

Not to mention the fact that I would almost definately want to 
a) alter meta-data with a text-editor [can someone please flesh out
_exactly_ what sort of meta-data we're talkin' 'bout??? other than
obvious ones...]

b) alter images in non-imlib programs - lets face it, sometimes we're
forced to do this... 

To sum up, I always thought that one of the aims of the Gnome project was
to remain as friendly as possible to users of all
users/UNICES/programming languages and of course file
formats/image/text manipulation programs... I
remember a posting a while back where someone complained bitterly about
the fact that the .kdelnk format was in some proprietary (I know nothing
about this so correct me if I lie) and I have to agree, I would _love_ a
way to edit my windows shortcuts with vi or emacs but it does not give me
the opportunity [yes I do have _both_ installed on my windows machine =)].

I'm bound to have missed something, so feel free to correct [or throw!]
away if you please,

Mark

PS Oh yes, excuse me for using () and []-style brackets seemingly
randomly, but I'm currently trying to teach myself Objective-C!

-- Mark Hulme-Jones <ceemahj@cee.hw.ac.uk> - http://www.cee.hw.ac.uk/~ceemahj --