Re: [Tile-dev] New paned window widget

[Joe E. <jen...@fl...>]

Brian Griffin wrote:
> Joe English wrote:
> >    + Each pane has a -weight option, which is an integer value specifying
> >      the relative amount to shrink or expand the pane when the
> >      overall widget is resized. [...]
>
> My experience has been that paned views, where there are more than one
> pane that was not fixed, the panes would grow or shrink proportional to
> their initial size when the window was resized. You can't get this
> behavior with -weight.  It's a subtle difference.

Hm.  When experimenting with it, I came to the opposite
conclusion -- it seemed to feel better to me if the extra
space were distributed equally across all panes regardless
of their initial size.  (With one exception: if a pane is
completely collapsed, then it should stay collapsed even
if the overall window grows).  OTOH, I was experimenting
with a contrived example, so I can't say for sure.

By far the most common cases are 2-pane layouts, and 3-pane
layouts with one vertical sash and one horizontal sash;
where in both cases there is exactly one stretchable pane
and the other(s) have fixed size.  Next most common are
"studio"-type applications with multiple, multiply-nested,
user-configurable pane layouts; I confess I really don't
know what's reasonable there.


> On the other hand,
> weight has never been intuitive to me because it's non-linear. Maybe if
> it was a real number it would make more sense.

The ttk::paned widget does use a linear algorithm for resizing,
just that it's linear over the ring of integers modulo total_weight :-)


> >    + There is no -opaqueresize option; opaque resize is always enabled.
> >      As long as performance is not an issue (which it doesn't appear
> >      to be), this is better usability-wise than deferred resize.
>
> This _is_ important when working with slow devices, say VNC over a slow
> or congested network. Window managers still support this kind of option,
> I think for the same reason.

Others have also asked for this, and on further investigation
it turns out that the current implementation _does_ have performance
problems, especially on slow X servers.  These look fixable,
but even then it might still be too slow, so I'll probably add
deferred resize after all.  This will probably be an application-
or desktop-wide option.

> >    + Instead of separate 'paneconfigure' and 'panecget' methods,
> >      the 'pane' method is a generalized accessor like the
> >      ttk::notebook and ttk::treeview widgets use.
>
> I like this notion, but it does not match the core Tk paradigm.

Agreed, it's a departure from the usual Tk idiom, but
I think in this case it's worth it to start a new idiom.
A dictionary is just way more convenient to work with than
a list of 5/2-tuples, and it replaces a pair of nearly-redundant
commands with a single more useful one.  Also, it's not _entirely_
without precedent; [font configure] works this way too.

See also: http://sourceforge.net/mailarchive/message.php?msg_id=9616698


> >~ Default -weight.
> >I'm not sure if the default -weight should be 0 or 1. [...]
> As you point out, a default of 1 is almost never right, therefore, I
> would go with "-stretch last". :-)

If all panes have -weight 0 it's the same effect as if
they all had -stretch last; and since the common case
has exactly one stretchable pane, using -weight 0 as
the default makes the most sense.



--Joe English

  jen...@fl...