[Tile-dev] New paned window widget

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

Just checked in a new paned window widget, ttk::paned.
Documentation here:

    <URL: http://tktable.sourceforge.net/tile/doc/paned.html >

The API is designed to match the ttk::notebook widget.
Basic usage is similar to the core panedwindow and the BWidget
PanedWindow, but there are a few differences in the details.

~ Differences from the core panedwindow:

    + 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.  This is more flexible and, to me,
      more intuitive, than '-stretch {first|last|never|always}'
      as in the Tk 8.5 panedwindow.

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

    + Instead of separate 'paneconfigure' and 'panecget' methods,
      the 'pane' method is a generalized accessor like the
      ttk::notebook and ttk::treeview widgets use.

    + Panes do not have '-before' or '-after' options.  Instead,
      you can use the [$pw insert] method to specify the initial
      position or move an existing pane to a new position.
      (See below for rationale).


A couple open questions:

~ Shoving sashes:

In the 8.4 panedwindow, if there are three or more panes and
the user attempts to drag a sash over an adjacent one, the
adjacent sash gets "shoved" up or down to make room.

This seemed like a neat idea to me, and that's what I initially
implemented, but after playing with it some I'm not so sure anymore.
It's too easy to "overshoot" when dragging a sash, and end up
shrinking a pane that you didn't intend to shrink.  It feels
better to me if sash movement is bounded by the adjacent sashes.
Then again, I'm extraordinarily clumsy with a mouse so this
could just be me.

You can try it out both ways (change the SHOVE_SASHES #define
in paned.c); let me know what you think.

~ Default -weight.

I'm not sure if the default -weight should be 0 or 1.

If all panes have -weight 0, then the last pane stretches
or shrinks to make up the difference when the widget is resized.
This is the same as the 8.4 behavior [*], and is the Right Thing
more often than not.  On the other hand, sometimes it's the Wrong
Thing entirely (a good bad example is tkchat with the "Users Online"
pane visible -- here you want the _first_ pane to shrink and stretch
while the last one stays fixed size).

If all panes have -weight 1, OTOH, each pane stretches and shrinks
equally.  While this is never completely wrong, it's almost
never exactly right either.

Since it's easy enough for the program to specify appropriate
weights, this isn't a huge issue.

[*] Except that the ttk::paned window handles conditions
where the last pane(s) are completely shrunk better.


~ Stuff that might get added later:

    + "collapse buttons" on sashes, like in the Mozilla sidebar
    + Active / pressed feedback for sashes
    + Ugly sash separators with a square handle in the classic theme

Stuff that was considered and rejected:

    + -minsize and -maxsize pane options.
    + proportional resize of all panes when a sash is dragged


Anyway, please try it out and pound on it to shake out the bugs.
(Stuff to look for: horizontal vs. vertical botches, inappropriate
behavior when there are no panes, geometry propagation glitches.)


--Joe English

  jen...@fl...