Re: gtk_color_selector bugs

[Owen Taylor <otaylor redhat com>]

Todd Dukes <tjdukes@flash.net> writes:

> This is similar to what I needed to put a jpg loaded by gdk_imlib
> into a GtkPixmap. I wound up calling 
> 
> gtk_object_set_data("gtk-colormap", gdk_imlib_get_colormap());
> gtk_object_set_data("gtk-visual", gdk_imlib_get_visual());

This will create a single toplevel window with widgets
of multiple visual/colormaps. Actually, unlike GdkRGB,
imlib will never use a private colormap, so this will
work. But this would be bad for gdk_rgb_get_colormap(), 
since on most hardware, you can only have a single colormap 
per toplevel window.

That's why, for the colorselector, we want to set the
colormap/visual on the toplevel and everything it
contains to the same thing.
 
> between gtk_window_new() and gtk_widget_realize(). Doing
> this seemed like a hack. Especially since those strings are
> defined in the .c files instead of the header.

In your case, there was cleaner way to do this:

gdk_widget_push_visual (...)
gdk_widget_push_colormap (...)
pixmap = gdk_pixmap_new (...)
gtk_widget_pop_colormap ()
gtk_widget_pop_visual ()

[ If you are going to be using things in the imlib visual
  extensively, you might just want to surround your entire
  program with such a call ]

Except that a GtkPixmap is a NO_WINDOW widget, so you
better make sure that whatever !NO_WINDOW widget it
is in is also in that colormap/visual.

> Is there an easier way to do this or should there be a way to 
> set the visual/colormap for a GtkWindow in an easier fashion?
 
Since there is currently an implied restriction on changing
the colormap and visual of a widget after creation, the
push()/pop() stuff should still be the only supported way
to change the colormap and visual for an application.

But I am tempted to add set_visual()/colormap() functions
to be used (with caution) in a widget's init() function.

> Did this not come up before because most X-servers on Linux have
> only one visual depth? One nice thing about Solaris's X-server is 
> support of multiple color depths. I just wish it wasn't so easy to
> crash. (No crashes from gtk in many months, but I've had my share)

Not really. People have been using GTK+ on multi-visual
machines for a long time. The problems appeared because
GtkPreview was rewritten in terms of GdkRGB, which currently
can only render in the single visual it decides that is
"best" for the display. 

(This is bad behavior for a widget, and GdkRGB actually
needs to be modified to work on whatever visual/colormap
it is given)

Regards,
                                        Owen