tktable-tile-dev

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

Re: [Tile-dev] New paned window widget

[Brian G. <bgr...@mo...>]

Joe English wrote:

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

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

>    + 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.  There may not be slow machines any more, 
but networks are still slow for a lot of reasons. This is something the 
application user needs control over since the application author cannot 
predict what the operating environment will look like. Also, you cannot 
predict the complexity of the panes contents.  It may be that a redraw 
takes seconds rather than msec., so you need to give the application 
authors this control.

Note that the Tk panedwindow has both <Button-1> and <Button-2>  
bindings for sash motion so that the user has a choice of opaque or not.

>    + 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.  This 
makes teaching Tcl/Tk a bit more complicated, unless we go back and 
retrofit all Tk widgets adding "item configure" and "item cget", etc.

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

Yea!  I've never liked the -before & -after as configure options since 
their values are meaningless once the operation is complete.

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

I think this depends on the application. This should be configurable 
when used.

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

As you point out, a default of 1 is almost never right, therefore, I 
would go with "-stretch last". :-)

>
>~ Stuff that might get added later:
>
>    + "collapse buttons" on sashes, like in the Mozilla sidebar
>  
>

I was contemplating adding this to the Tk panedwindow. It should also be 
possible to bind a menu and balloon help to the sash.

>    + 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...
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Tktable-tile-dev mailing list
>Tkt...@li...
>https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>
>  
>

-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-------------------------------------------------------------

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

Re: [Tile-dev] New paned window widget

[Brian G. <bgr...@mo...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Joe English wrote:
<blockquote
 cite="mid...@dr..."
 type="cite">
  <pre wrap="">Brian Griffin wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Joe English wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">   + 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. [...]
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
<br>
What I meant by "my experience" is that I looked at several non-Tk
applications and this is the behavior I saw. I believe most, if not
all, were 3 pane style layout, where two of the panes would grow/shrink
proportionally to their starting size.<br>
<br>
-Brian<br>
<br>
<pre class="moz-signature" cols="72">-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ <a class="moz-txt-link-freetext" href="mailto:su...@mo...">mailto:su...@mo...</a> --
-- Sales and marketing info ....... <a class="moz-txt-link-freetext" href="mailto:sa...@mo...">mailto:sa...@mo...</a> --
-- Licensing .................... <a class="moz-txt-link-freetext" href="mailto:li...@mo...">mailto:li...@mo...</a> --
-- Home Page ........................ <a class="moz-txt-link-freetext" href="http://www.model.com">http://www.model.com</a> --
-------------------------------------------------------------
</pre>
</body>
</html>

Re: [Tile-dev] New paned window widget

[Michael K. <mi...@mu...>]

On Mon, 14 Mar 2005, Brian Griffin wrote:

> What I meant by "my experience" is that I looked at several non-Tk applications and this is the behavior I saw. I believe most, if not
> all, were 3 pane style layout, where two of the panes would grow/shrink proportionally to their starting size.

FWIW, the paned windowing setup I use with MIB Smithy works like this:

1. There's a top pane and a bottom pane.
2. Each of these are split into left/right.
3. Each can be shown or hidden by the user by selecting options from the 
View menu.
4. When you resize the window, each pane is given exactly the same 
percentage of the window it had before the resize.

So if you have the sash halfway between the left and right edges 
(left/right panes each currently have 50% of the window) and you maximize 
the window, they still each have half the width of the window.  If it's 
1/4 the window's width in from the left before resize, it'll be 1/4 of the 
new size in from the left after resize.

Is this right?  I dunno, but that's what I do currently. :)  As long as 
you don't have to go through hoops to prevent resizing a window smaller 
from completely obscuring a pane and its sash (a la Tk 8.4.*) I think I'm 
fine with whatever method is used.

--
Michael Kirkham
www.muonics.com