Better description of gdk_rgb_set_min_colors. Stric pointed out that

the previous documentation suggested using 256 to request a private
colormap, which is currently broken. This was making Mozilla crash.
This commit is contained in:
Raph Levien 2000-03-14 22:20:20 +00:00
parent 10ba4fd066
commit 146313a3d2
2 changed files with 14 additions and 5 deletions

View File

@ -1,3 +1,8 @@
Tue Mar 14 14:17:46 2000 Raph Levien <raph@acm.org>
* gdk/tmpl/rgb.sgml: Better explanation of gdk_rgb_set_min_colors.
Thanks to Stric for spotting it.
2000-03-07 Damon Chaplin <damon@helixcode.com>
* gtk/tmpl/gtkclist.sgml: fix to gtk_clist_set_reorderable(). It

View File

@ -58,11 +58,15 @@ gdk_rgb_set_min_colors (). The default is 5x5x5 (125). If a colorcube
of this size or larger can be allocated in the default colormap, then
that's done. Otherwise, GdkRgb creates its own private colormap.
Setting it to 0 means that it always tries to use the default
colormap, and setting it to 256 means that it always creates a private
one. Note, however, that setting it to 0 doesn't let you get away with
ignoring the colormap and visual - a colormap is always created in
grayscale and direct color modes, and the visual is changed in cases
where a "better" visual than the default is available.
colormap, and setting it to 216 means that it always creates a private
one if it cannot allocate the 6x6x6 colormap in the default. If you
always want a private colormap (to avoid consuming too many colormap
entries for other apps, say), you can use gdk_rgb_set_install(TRUE).
Setting the value greater than 216 exercises a bug in older versions
of GdkRgb. Note, however, that setting it to 0 doesn't let you get
away with ignoring the colormap and visual - a colormap is always
created in grayscale and direct color modes, and the visual is changed
in cases where a "better" visual than the default is available.
</para>
<example>