Re: Icons of program

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

While lying awake last night I found my mind drifting about thinking
about this whole Icons thread (for some obscure reason), and I came to a
few conclusions:

1) Patching commands like cp, rm etc. is extremely undesirable, as is
it's alternative, that is writing new versions of commands and somehow
making the shell which someone is using use those instead.
2) As a result of the above, having Amiga-style .info files littering
the filing system is also a poor idea, this combined with the fact that
in some ways .info files are a horrendous waste of disk space (when
you're talking about 24bit icons!) Can you imagine a multiuser system
such as the one I'm currently using with 1200+ users where everyone had
a 24bit icon for emacs on their desktop?
3) A registry has been noted as being susceptible to corruption, so it's
a reasonably poor idea to shove all icons into one single database file
(as one poster seemed to imply.
4) Whilst the idea of this SimpleVFS is a nice one, I think it has one
inherent fault, which I'll illustrate with an example. When I started
using the Amiga, I had had no experience with a proper command line
interface, I had used the BBC's command line, but that had no
hierarchical filesystem support (or not a proper one unless you owned a
Master) so I was pretty unfamiliar with the concept. Instead, I used the
Amiga's drag 'n drop filesystem, (Workbench) which up until a point
served my purposes very well. When I later moved up to the command line,
the directory structure which I had created existed exactly as one would
expect from that command line. This is the crux of my point, for new
users migrating from something like gmc to a shell, they're going to
have to recreate their VFS from scratch elsewhere, as a non-VFS, which I
personally would find extremely irritating.
5) Amiga info files were a good thing (tm) not just because of the icons
they provided, but also because they let you associate any document with
any program, so my readme files were all associated with MuchMore (or
some equivalent) and scripts and things associated with an editor.

With _all_ of the above points taken into account, I formulated the
following

Icons (that is the pictures themselves) should be stored in some central
repository (eg /usr/share/icons ) 
A user could install their own personal repository of icons if the
appropriate one was not provided in the system-wide directory (eg
$HOME/.gnome/icons/) just like with gimp plug-ins in other words.
A mime-types database should be used to associate filename suffices with
an appropriate program (eg .jpg with ee), this should be changeable by
the user. This would represent the default action associated with
double-clicking on a file. It would also set the default icon for that
type of file.
The user should also be given the _advanced_ option of providing the
document with an info file, which specifies an alternate behavior for
that particular document (eg. opening a .jpg file with gimp instead) and
an alternate icon (so you could make your picture of a frog have an icon
which resembled a frog). This .info file would be best to be a shell
script with #!/path/to/program at the top so that it would be of some
use in shell mode as well (The meta-information about the file could be
stored in comments, eg #ICON: frog.png
Exactly what other meta-information to include in such a file is
debatable to say the least!
All of this is great for Documents, but does not deal with executables,
which in most cases the user is only ever going to have shortcuts to
(since they nearly all reside in non-user-writable directories), so in
this instance just use the .info files as shortcuts (that is little
shell scripts which simply run that program. You can embed
executable-related meta-data in the comments as above. For the users own
program, or for when they are browsing through /bin or the like, either
use a file which specifies icons for specific executables (like
WindowMakers dock app, which uses XResources instead of pathnames) or
simply have a default icon for an exe which users can change when they
make their shortcut (probably best to emply both of these!).  
 
The above seems to me to be the only way to reconcile the problems
between those who want to completly abstract away the standard UNIX
filesystem, and those who still want to use the shell, without needing
any ELF-specific binary patches etc.

I think the best place for the SimpleVFS idea is for representing the
desktop, (which may be the intention, I'm not sure) at least this way
you avoid confusing the user by telling them that the desktop
(apparently the top level of the filing system) is in fact about three
levels deep on the C Drive (?, I still wonder how MS came up with that
one) 

As for the format of the icons, if PNG truly supports multiple images in
one file, why not just use this (I'm not familiar with the format [yet!]
so I don't know) This way you don't need an icon editor (although I
think such a thing would be nice, since you could use it to import old
Amiga icons/Windows icons), just a copy of gimp.

Another couple of points before I sign off,
1) Has any though been given to miniature icons (for the start menu,
window manager menu etc.). I know that imlib can do scaling, but how
much loss of quality would result. I'm pretty sure KDE employs mini
icons, but I may be remembering wrong.
2) A friend pointed out that doing _things_ to the fs in command line
mode would mean that the graphical display would need tidied up in real
time (or as near as poss.) has any thought been given to this?

Ok, that's enough for now,

Mark

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