There was a recent change (April 14th) to FvwmIconMan's source code
to, to quote the changelog:
* FvwmIconMan/x.c (change_colorset, recreate_background)
(create_manager_window):
fix bad hilight colour on some systems (64 bit issue?)
Unfortunately on my machine[*] the effect is exactly the opposite: this
change destroys the correct colours in my FvwmIconMan setup. In fact it
appears to do very odd things. I've produced two PNGs to illustrate:
http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-good.png
http://www.cs.toronto.edu/~cks/fvwm-test/fvwmiconman-bad.png
(both of these are from the current fvwm CVS.)
The only difference between these two screenshots is that the 'bad' one
is using the current CVS FvwmIconMan and the 'good' one is produced
with a FvwmIconMan binary built with this change reverted. (I literally
swapped the binaries back and forth and then had fvwm restart the
module.)
My FvwmIconMan colour-related configuration is:
*FvwmIconMan: FocusAndSelectButton flat goldenrod maroon
*FvwmIconMan: FocusButton flat goldenrod maroon
*FvwmIconMan: SelectButton flat goldenrod maroon
*FvwmIconMan: PlainButton up goldenrod maroon
*FvwmIconMan: IconButton up goldenrod maroon
I don't set a general FvwmIconMan foreground or background colour.
Setting them explicitly doesn't fundamentally change the results; the
only net effect is that the iconified 'xterm1' FvwmIconMan button
doesn't have the grey cast it does in the -bad PNG here.
I can easily test patches/changes if people would like.
Thanks in advance.
- cks
[*: my machine is 64-bit Fedora 18 with an ATI graphics card and the
normal Fedora 18 open source drivers. These particular screenshots
are from an Xephyr session, but I first saw the effect on the real
display.]
