[398] in The GTK GIMP ToolKit mailing list archive
[gtk-list] colormap size bug in gdkcolor
daemon@ATHENA.MIT.EDU (T Marc Olano)
Fri Jun 27 23:14:34 1997
To: gtk-list@redhat.com
Date: Fri, 27 Jun 1997 23:14:10 -0400
From: T Marc Olano <olano@cs.unc.edu>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
I am running the GIMP 0.99.10 under HP-UX 10.20. I have a 24 bit
display, but the HP X server uses a default 8 bit deep PseudoColor
visual with *255* colormap entries. The 256th is stolen by the system
to support transparency. A PseudoColor visual with 256 colormap
entries does exist, but it is not the default.
The problem is that several places in gdkcolor.c (and possibly
elsewhere) have a colormap size of 256 hardcoded, instead of checking
to see how big the colormap really is. If the colormap only has 255
entries, the program crashes at the XQueryColors() call.
Gdk_colormap_get_system() does this after explicitly asking for the
default visual. Other offending places in gdkcolor have the visual
passed in as a parameter, so who knows what assumptions they should be
making.
I can think of two ways to fix the problem, but I am not familiar
enough with the gdk/gtk/gimp internals to know what the impact of
either would be. The first, if it is important to be able to use the
system visual, is to replace the 256s (255s) with something along the
lines of private->visual->colormap_size (-1). The second, if having
256 colormap entries is important, is to create and use something like
gdk_visual_get_best_with_colormap_size(). This would be similar to
gdk_visual_get_best_with_depth(), but would return a visual with 256
colormap entries if that's what you need.
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
