Re: GtkExpander/GtkDisclosure

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-03-12 at 18:45, Mark McLoughlin wrote:

> > > 	I'm not sure there is too much point in enumerating each API until a
> > > decision is made on which approach to take.
> > 
> > My opinion is that if 2) allows for the right visual layout, then
> > it is more like the rest of the GTK+ API and probably easier to 
> > use as well for the programmer.
> 
> 	As regards the visual layout, I'm not sure what is "right" but an
> expander arrow with a label with the child directly underneath seems
> appropriate to me (label/arrow reversed in RTL locales). More
> specifically:

The specific situation that was floating around in my head was something
like:

  Widget
  Widget

 > Expander

  Widget3
  Widget4

That is, the widgets inside the expander are aligned with widgets
outside the expander but the expander is, say, outdented.

It's perfectly possible to get this with the bin, but it (perhaps)
might be a little more natural without Widget3, Widget4 being
children of the Expander.

I'm not sure I could say how much this matters in practice without
trying to lay out a couple of dozen real dialogs. I do like the
bin API a lot more, so perhaps we should go with that, and try
to get it in use before freeze the API.

> 	http://bugzilla.gnome.org/showattachment.cgi?attach_id=14946
> 
> 	It may be beneficial to allow the arrow/label to be below the child,
> but I'm not so sure.
> 
> 	See below for a proposed API (different from whats in the bug). Some
> things worth considering:
> 
> 	* The simplest constructor is without a label, I'm not sure if that is
> of any use. Probably should have to at least specify a label.

Yeah, matching gtk_frame_new (const gchar *label) [and allowing NULL]
would seem best to me.

> 	* Should we put "spacing" in the constructors like gtk*box?

IMO, no. The reason I don't like this is that while the label is
obvious when reading code, a number 

 gtk_expander_new ("Hello", 5)

is not obviously meaningful.

> 	* Matthias suggests that it may be worthwhile to allow arbitrary
> widgets to replace the label.

Definitely. I'd probably copy GtkFrame for the API.

> 	* I considered adding gtk_expander_expand/collapse but I don't think it
> adds much.

Sounds just confusing to me to have both that and 
gtk_expander_set/get_expanded.

> 	* I haven't exposed anything in the instance struct. It may be
> worthwhile to expose the label widget there.

As long as there is a getter for the label/label_widget, I don't
think it's necesary.

Looking at GtkFrame, we made:

 gtk_frame_set_label (frame, "Hello");
 gtk_frame_get_label_widget (frame);

Return the label widget not NULL.  (Hmm, bug 108305.)

I'm not sure this is actually best ... the properties behave the same
way, which will force a GUI builder to special case the 'label_widget'
property. But since GtkFrame works that way, it's probably best if
GtkExpander works the same.

> 	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.

Other than that and the comments above, the API looks good.

Regards,
                                           Owen