Re: xpm vs. png

[Quantum Seep <qseep technojunkie com>]

I'm worried about how easy it is to change those images once the binary is
compiled.  If we update the images, but don't change the code, people aren't
going to want to download a whole new binary.  Can't we keep a lot of small
images in one file?  It could be saved as raw RGB.

/-------- Quantum Seep, qseep@iname.com ---
  "His funny bone's connected to the M-bone"
   PGP fingerprint: 5B 3B 7B EC AA 5B 4B 7F  65 7D 2A CD 69 11 29 2A

On Wed, 16 Sep 1998, George wrote:

> On Wed, Sep 16, 1998 at 05:47:08PM -0400, Federico Mena Quintero wrote:
> > >  including rgb data directly is better then xpm's ... like the gnome stock
> > >  icons ... the only reason to use xpm's is that it's easier
> > 
> > I don't think so.  Raw RGB data like in gnome-stock-imlib is a major
> > bitch to add or change.
> > 
> > What's wrong with inline xpms for application-specific pixmaps?
> 
> well then write a simple converter from xpm to rgb ... then you can just
> #include the result ... shouldn't be any harder then using xpms ...
> in gnome stock it's all in one file which makes it harder to keep up
> to date ...
> 
> also I guess it could be included in the makefile .... just build
> say .rgb files from .png's or xpms on make ... then you only change
> the .pngs, and the app includes the autogenerated .rgb file, this might
> be a good way to do the gnome-stock for example
> 
> one of the resons for including pixmaps in the program is that if you
> have a whole lot of small pixmaps, it would be too slow to read them
> from disk ... but the thing is xpm is slow to parse no matter what you
> do ... if you have a whole bunch of pixmaps it's much better to include
> rgb data .. since it cuts down on the work the program does on startup
> ... if you have a few larger images, it's better to just use .pngs
> 
> George
> 
> 
> -- 
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>