Re: GtkButton as a no-window widget

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> At 19:34 05.11.01 -0500, Owen Taylor wrote:
> >
> >The following patch makes GtkButton a no-window widget, using an
> >input-only window to catch events.
> >
> >Advantages:
> >
> > - Many less subwindows - less temporary pixmaps created for exposes,
> >   less invalidation regions, etc.
> >
> - less problems with a resource limited OS (uhm windoze 9x)
>
> - probably less flicker when invalidating occurs on the toplevel 
>   window, because all the buttons are blitted at once (with there
>   owning window) ?

Well, there is never clear/redraw either way but it does make resizing
toplevels look quite a bit smoother since you don't have problems like:
button is resized smaller clipping right edge of shadow, then shadow
is drawn at the right place.

> > [...]
> > 
> > - Much code simplification in GtkToggleButton, since it doesn't
> >   need 

need to do the trick where it sets itself as a WINDOW or NO_WINDOW
widget depending on whether draw_indicator is set or not.

> Isn't there something needed ?
> But even without what it doesn't need: a patch removing more source
> as adding while improving functionality looks always appealing ...
> 
> > - Get rid of some of the awful "pretend that things are transparent
> >   by using parent relative backgrounds" hacks.
> >
> >Disadvantages:
> >
> > - The optimization that I got working over the weekend no longer
> >   helps for button widgets. Which was where it mainly helped.
> >
> Do I have missed any anouncements of them on the list ?

See the "Size allocation and redrawing issues" thread; basically
the optimization was avoiding queueing a redraw when a window
widget was moved but not resized.
 
> >Incompatibilities:
> >
> > - Widgets deriving from GtkButton need to modify their code to
> >   take into account the fact that they are NO_WINDOW. I'm 
> >   not sure there are many of these outside of GTK+, which
> >   has GtkToggleButton and GtkOptionMenu.
> >
> Doesn't the change propagate to Widgets derived from these, too ?
> 
> > - People putting GtkButton widgets into custom widgets have to
> >   take care to propagate exposes.
> >
> On which level does it break (while compiling, g_(warning|assert),
> drawing failures or even crashing without note) ?

The buttons simply won't appear.

> And shouldn't the patch include some change of Changes-2.0.txt.
> Also it appears that some files are missing from the ChangeLog
> entry: gtk/gtktogglebutton.c gtk/gtkoptionmenu.c gtk/gtkclist.c 
> gtk/gtkcheckbutton.c

Since I was posting the patch as "here's what I'm doing, what
do people think" rather than "here's a patch I think that should
be applied", I didn't finish up all the details ... so yes,
the ChangeLog wasn't complete and yes, there should be a 
Changes-2.0.txt entry.

Regards,
                                        Owen