Re: GtkPaned vs. GtkBox

[Owen Taylor <otaylor redhat com>]

Fritz Jetzek <fritz.jetzek@i-dmedia.com> writes:

> Karl Nelson wrote:
> > 
> > Can I suggest an alternate design?  Rather than trying to
> > turn a box into a paned, we could just create a special
> > type of separater.  This would be a PanedSeparator.  You
> > could place in inside any Box and thus change the widgets
> > on either side to act like panes.  Thus if you want to have
> > a paned set up like say xfontsel, you make a Vbox with a menubar,
> > then a button bar, a PanedSeparator, a label, a PanedSeparator,
> > then a drawing area.
> > 
> >       -------------------
> >      | Menu              |
> >      +-------------------+
> >      | Buttons           |
> >      +-----------------O-+  PanedSeparator
> >      | Label             |
> >      +-----------------O-+  PanedSeparator
> >      |                   |
> >      | Drawing area      |
> >      |___________________|
> > 
> > This would give the same effect as creating a mult-paned which
> > you desire and remove the need to a special Paned with 2 areas.
> > (Could be made backwards compatible with some wrapping code.)
> > 
> > (It would be really cool if the PanedSeparator could be made
> > to work with tables as well, but not necessary.)
> > 
> > What do you think?
> > 
> > --Karl
> > 
> >
> 
> makes much more sense than my suggestion imho - i have no idea how
> difficult it would be to implement a standalone PanedSeparator since i
> haven't looked into the code of GtkBox and GtkPaned but i'll definitely
> do so soon and come up with something. i might be more efficient if the
> guy who already made GtkPaned could do that, but i'm aware that i
> triggered the discussion so i'll allocate some time to that thing ;)

I don't think this is a good idea. The problem with this is that it
makes the (already complicated) operation of GtkBox _more_ difficult
to understand, by adding the concept of a "cell resizeable by the
user" to it.

A clean patch to add n-child operation to GtkPaned would have a good
chance of being accepted; I tend to think that greater-than-two-way
separations are rather confusing to the user, but they are occasionally
useful. (One would have been useful in memprof program.)

The reason why the two parameters for GtkPaned (resize and shrink)
are not the same as the parameters for GtkBox (expand and fill)
is that the environments are quite different; for example:

 - A GtkPaned widget has to maintain the size set by the user in
   some fashion when resized to a different size
 - It makes no sense to have fill = FALSE for a GtkPaned: why
   would the user want to make a partition bigger simply
   to add white space around a widget?
 
However, the resize and shrink parameters do extend pretty logically
to greater than 2 panes.

(Also, note that GtkPaned has been rewritten quite a bit now for
GTK+-1.3 to allow dragging anywhere along the length of the
separator. Making patches against the GTK+-1.2 GtkPaned would
not be particularly useful at this point.)

Regards,
                                        Owen