Re: GtkExpander/GtkDisclosure
- From: Owen Taylor <otaylor redhat com>
- To: Matthias Clasen <maclas gmx de>
- Cc: gtk-devel-list gnome org
- Subject: Re: GtkExpander/GtkDisclosure
- Date: 14 Mar 2003 10:35:31 -0500
On Thu, 2003-03-13 at 19:14, Matthias Clasen wrote:
> On Thu, 2003-03-13 at 16:20, Owen Taylor wrote:
>
>
> > > Overall though, I think the API should be a simple subset of
> > > GtkToggleButton/GtkButton.
> >
> > GtkFrame seems more like the closer comparison, as
> bin-plus-extra-child.
> >
> > > struct _GtkExpanderClass
> > > {
> > > GtkBinClass parent_class;
> > >
> > > void (*toggled) (GtkExpander *expander);
> >
> > I'd say people can just connect to notify::expanded. The duplication
> > shouldn't be necessary, and it's not like observing the state of
> > the widget is going to be common anyways.
> >
>
> You need to connect to toggled (or notify::expanded) in order to adjust
> the size of the toplevel, so I think it will be common.
Even if it's common, I think notify::expanded is fine... the only
reason that notify connections are even slightly confusing is
the additional pspec parameter, but you only need to learn to
ignore that once.
What do you mean exactly by adjusting the size of the toplevel?
- If the toplevel doesn't allow resizing, then things just work.
The size of the toplevel will always be requested size of
it's contents.
- If the toplevel does allow resizing, then things get more
complicated... presumably the ideal behavior is:
- When the expander is expanded, then the toplevel grows
by the requested size of the expanded section.
- When the expander is contracted, then the toplevel shrinks
by the current size of the expanded section.
But I can't imagine that we want application authors to
have to write that logic themselves. If we think this is
right, we are going to need some sort of GtkExpander
functionality for this ... gtk_expander_set_resizes_toplevel()
or something.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]