Re: GtkButton as a no-window widget
- From: Owen Taylor <otaylor redhat com>
- To: Hans Breuer <hans breuer org>
- Cc: gtk-devel-list gnome org
- Subject: Re: GtkButton as a no-window widget
- Date: 13 Nov 2001 23:51:08 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]