Re: gtk_color_selector bugs

[Owen Taylor <otaylor redhat com>]

[ original mail sent to gtk-bugs ]

Austin Donnelly <austin@greenend.org.uk> writes:

> Bug 1:
> 
>  o run testgtk with few free colours in the colourmap.
>  o get the colour selector up
>  o if you have few enough free colours, the circle and colour swatches
>      along with the entries and the buttons in the action area go into
>      a private colourmap, but the rest of the dialog doesn't.

OK, the problem here turned out to be that we were
doing a gtk_widget_push_colormap()/visual() in the init()
function, but the Window widget itself holding the 
dialog itself, is created in gtk_window_init() beforehand.

As a quick workaround, I moved the push/pop to the
new() function for GtkColorSelectionDialog. But it occurs
to me that this is not an ideal solution, since it
won't help people who do:

 gtk_widget_new (gtk_color_selection_dialog_get_type(), ...)

[ Or derive from GtkColorSelectionDialog, etc... ]


So it occurs to me that perhaps the right thing to
do is simply to adjust the colormap/visual of the
Window widget in GtkColorSelectionDialog's init().

This would require adding:

 gtk_widget_set_colormap/visual()

But since changing the colormap and visual of a widget on
the fly is not supported in GTK+, (some of the code
in GTK+ is written with an idea to supporting this
for unrealized widgets, but not all), there would
also have to be big disclaimers

 "Use these functions only before a widget is first
  realized and only if you know what you are 
  doing"

Anything else I am missing here?

                                        Owen