Re: Icons of program

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Wed, 22 Apr, 1998 at 03:30:16PM -0400, raster@redhat.com set free these words:
> On 22 Apr, Toshio Kuratomi shouted:
> ->  On Wed, 22 Apr, 1998 at 10:51:54AM -0400, raster@redhat.com set free these words:
> ->  > 
> ->  > * 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....
> ->  > 
> ->  Why?  Or rather -- why not a text file that points to an existing set of
> ->  images on the system?  (With imlib to do translation, this shouldn't be
> ->  overly complex :-)
> ->  + Can use any existing images (readable by imlib).
> 
> copyin an icon around then means finign everyhting the iocn file points
> to (ie the images) - pain pain pain pain. Trust me. its nto a good
> idea.. having ti all packaged up in one bundle is neater.
> 
Hmm -- that's true.  One disadvantage noted.

> Imlib coudl read them too. i just nee dmy own decompresseion routinge
> to put the data into a24bit buffer and tell imlib to make an imlib
> image out of that buffer - so imlib does support you writing your own
> loaders.
> 
Will imlib be able to spit back out the arbitrary text/value strings?  (I
haven't coded with imlib yet, so I don't know.)  (Side note:  Do you really
want imlib dealing with meta-data?  These files aren't images, they contain
images.)

> ->  + Don't need special tools to edit the metainfo (text editor for metainfo,
> ->    image manip. for images.)
> 
> library will do the job wuite well - function calls will be there - the
> text editor isnt' that useful when the porgrams primarily editing the
> icons will be the filemanager and apps for whom a library is easier.
> 
I'm saying this ties me to programs that use imlib to do their image
conversion.  (At least until someone else decides to write one).  And because
this is an icon file for a gnome desktop, this is a small enough niche that I
don't see anyone jumping up and down to implement it in their image editor.

> ->  + images can be reused for different apps with little file overhead. (saves
> ->    space)
> 
> ture.. one positive point... but the icons wil be REALLY small <5k so
> the impact isnt great...
> 
The images could also be used by the window manager, alternate filemanagers,
and other programs which don't rely on imlib (not that they shouldn't :-)
just that we can't force them too, so why make them feel like we've given them
the cold shoulder?

> ->  + an "icon file" is conceptually wrong: file holds extensible metadata about
> ->    the file.  The picture just happens to be one piece of information that
> ->    might be allocated.
> 
> well the amiga version wroked pretty damn well and to date i havent
> seen a better system - and systems suggested here, form what i can see
> and my experience with gui systems for the past 10 years is that the
> amiga has the right concept (if we discount the macs special fs for
> holdinding icons) .. some details (like icons were planar etc.) were
> due to their being designed aroudn the hware they were on and the icon
> palette was fixed wiht newicons to replace the old icon library.. but
> all in all it was a very nice, compact usableand maintainable system
> that worked well and cohesively.
> 
Hmmm.. from what I've heard here, I kinda think the amiga had the wrong idea
*gasp! sacriledge!* -- or rather, it had an idea that doesn't work for us.
(Because we're trying to retain compatibility with unix standards....)

But this is really not an important point -- who cares about concepts?
Elegance?  Aesthetics?  If it works, just hack it in!

> ->  - use more inodes (one for meta-data file, several for the images [active
> ->    inactive, etc.])(But we've got these to spare, right?)
> 
> yeah.. but they arent packaged together.. iyou have to thne keep track
> of ALL that data when moving it form one system to another etc... its
> much easier to have it packed up into a single file to move with the
> file that cion represents.. you cna make that icon be used by a new
> file by simply renaming the icon file.. :)
> 
That's true.  The offsetting weight is that an icon will have different
meta-info even when it doesn't have a different picture.  Keeping a text file
and images separate allows you to use this better.  Let's say my app needs
three states for icons.  Normal, highlighted, and active.  For image files, I
take a standard image file icon and grey/stipple it like the Mac does for my
active state -- okay.  I now have one icon file type with one image inside and
one image on my filesystem.  Then I take the standard image and add a little
thing that says "tiff" or "png" or "xpm" depending on the file type I have.
3 icons @ 2images : 4 images.  Then I decide to take my thumbnails for the
twenty images I have to be the highlighted state (after all, why would I want
to open a file just to find out what this picture looks like?) Now we have:
20 icons @ 3 images : 24 images.  Sixty images instead of twenty-four.
Hmm.....

By the way raster, what do you use your your themes in enlightenment?  Not a
new file format, right?  I get the impression it's a tar file that has the
necessary pixmaps and a textfile with the config options.... (And you can even
unpack the tar file if you want..?)

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~