Subject: FVWM: Re: icons

From: Brian Sayatovic <[email-masked]>
Date: Fri, 22 Aug 1997 08:08:37 -0400

As far as sharing a single colormap, I feel your pain.  I wrote a combination C
program and perl script to process my pixmaps to a standard colormap.  I simply
generated a complete color spectrum to the reoslution of 128 colors, and
openened each pixmap, found the closest shade in the new spectrum to the one in
the pixmap and replaced it.  I did this on my original 24 bit pixmaps rather
than the 8 bit dithered ones.  The results have been VERY impressive (IMHO).
I'm not so sure this freed up my colormap as other programs sucked it up when
they saw the psace, but that's another story.

P.S. As for your bug.  If your FvwmButtons configuration lines are in the
.fvwm2rc, I believe that the line is ignored because it sees that # as a comment
starter.  Try quoting the color value to see if it fixes your problem:

Back    "#30c8c8"

If this doesn't work, try some other forms of expressing color, such as:
decimal, colorname (you can look in the color anme table and find the closest
match).

Brian.

--
 ___________________________________________________________
|                                                           |
|  Brian Sayatovic                 (mailto:[email-masked])  |
| --------------------------------------------------------- |
|  International TechneGroup, Inc. (http://www.iti-oh.com)  |
|___________________________________________________________|

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Santeri Paavolainen <[email-masked]>
Date: Fri, 22 Aug 1997 21:41:47 +0300 (EET DST)

On Fri, 22 Aug 1997, Brian Sayatovic wrote:
> the pixmap and replaced it.

As a related note, I have been thinking about hacking Xpm library a
little, so it would handle better with small colormaps (that is 8 bit
displays). 

The basic idea would be to have some value of "colormap fullness",
which libXpm would determine before allocating a new color. It would
then scan the current colormap and find the closest color match. Next,
based on the "fullness" value it would either re-use the closest found
color or choose to allocate a new cell from the colormap.

The effect would be something like that as the colormap gets more and
more crowded Xpm would accept "less close" colors than with an empty
colormap, until at some threshold value it wouldn't allocate any new
color cells and would re-use existing, no matter how "far" the "best"
color match would be. (You could leave something like 64 colors not to
be allocate by Xpm, so there would then be some cells free for random
applications.)

If you started with pre-allocated colormap portion (with xstdcmap -all) 
then Xpm would prefer to choose colors from the pre-allocated colormap 
portion before trying to allocate its own.. even better.

I have not had the time to pursue the idea, so if anyone would like to 
do something similar, feel free to do so.

--
[email-masked]                    I have become death, destroyer of the worlds.

---

From: Eric Brandwine <[email-masked]>
Date: Fri, 22 Aug 1997 15:03:17 -0400 (EDT)

ImageMagick can take a series of images in any format, and reduce them all
to one color map.  The only drawback is that it is a memory hog.  I have
often run ImageMagick jobs that exceeded 200 megs.  But it only has to be
done once, and the jobs are only huge if you have a lot of images.  If you
decide on a standard map ahead of time, you can run the images one at a
time.

Also, as far as universal colormaps go, I think that it should be
dynamic.  This is the way that Windoze (shudder) does it.  When you load
an image with a large colomap, the rest of the display is fit to that map.
'Course, that requires changing the values of the pixels themselves
sometimes, so...  

ericb