Re: GtkButton as a no-window widget
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, gleblanc cu-portland edu
- Subject: Re: GtkButton as a no-window widget
- Date: 13 Nov 2001 23:57:16 -0500
[ Cc'ing Greg because of LXR question below ]
Tim Janik <timj gtk org> writes:
> > Disadvantages:
> >
> > - The optimization that I got working over the weekend no longer
> > helps for button widgets. Which was where it mainly helped.
>
> could you extend on what optimization you meant here?
See my reply to Hans.
> > 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.
>
> i wouldn't expect too much to be affected by this. an appropriate
> Changes-2.0.txt entry would do.
>
> BTW, can someone please cvs.gnome.org/LXR?
Please ____ cvs.gnome.org/lxr? If you mean switch GTK+ to HEAD,
I think it should be simply a question of 'cvs up -A' in the checked
out copy. Greg?
> > - People putting GtkButton widgets into custom widgets have to
> > take care to propagate exposes.
>
> widgets not already doing this are _buggy_.
Yes and no ... if the widget created the widgets itself and
knew they were button widgets only then I'm not sure it would
have been worth writing the code, especially before we
had the handy gtk_container_propagate_expose().
But yes, it is a dubious practice, and I don't feel bad about
breaking such code ... except for having to do it at this
point.
OK, there seems to be more positive reaction than negative
reaction, so I'll look at finishing up some last details
and checking this in. I also have similar patches for
GtkRange and GtkNotebook which raise much less compatibility
issues.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]