Re: bug in gtkspinbutton

[Owen Taylor <otaylor redhat com>]

adrian <feiguin@ifir.ifir.edu.ar> writes:

> gtkspinbutton is an entry subclass ans has a panel window with the two
> arrows. The flag GTK_WIDGET_NO_WINDOW(widget) == FALSE, and widget->window
> = GTK_ENTRY(widget)->window. The problem is that when you move/resize/hide
> the widget->window, then you are changing GTK_ENTRY(widget)->window, but
> spin->panel remains unchanged. This causes serious problems in gtklayout
> (and gnome-canvas). Just to clarify what I'm saying try replacing
> gtk_button_new() with gtk_type_new(gtk_spin_button_get_type()) in the
> layout example in testgtk. You'll see that the entries are scrolled, while
> the arrows remain in their old positions. This means that the widget
> behaves as two independent windows. gtkcombo is a hbox subclass and it
> doesn't have this problem. I think this should be fixed.

GTK+ does assume that windows that are !NO_WINDOW should
not create windows within widget->window in a few places.

I think the only direct problem you'll see, other than
the Layout problem, is that spinbuttons won't reparent properly.
Which, in practice, probably isn't a big deal.

The GtkLayout currently in CVS is broken in a quite
a few ways; I've rewritten it recently to fix these problems
(see my post recently on gtk-devel-list), and I believe
that with that change, it will work fine with the 
current spinbutton.

I'm not sure how much work it would be to fix the window
heirarchy in GtkSpinButton to be more normal. The problem 
here is that GtkSpinButton calls GtkEntry's realize handler 
and then modifies the results. You're right that it
probably should be fixed, but I don't consider it a 
high-property item.

Regards,
                                        Owen