#2260 panedwindow geometry propagation

[Lars Hellström]

It seems a [panedwindow] doesn't notice
if the geometry requests from its panes
change, which can lead to surprises if
interactively writing commands for creating
a layout.

The following procedure demonstrates the
problem in Tk 8.5a6 aqua (although I first
observed it in Tk 8.4.10 aqua):

proc layout {} {
set t [toplevel .test]
pack [
panedwindow $t.panes -orient vertical
] -expand true -fill both
$t.panes add [frame $t.f1] -sticky nsew -minsize 50
$t.panes add [frame $t.f2] -sticky nsew -minsize 50
update
canvas $t.f1.c -width 200 -height 150 -relief solid -borderwidth 1
canvas $t.f2.c -width 200 -height 150 -relief solid -borderwidth 1
pack $t.f1.c -expand true -fill both
pack $t.f2.c -expand true -fill both
}

After calling [layout], the .test toplevel starts
out with a width of about 5 and a height of
about 100. In particular, [winfo reqwidth .test.f1]
is a bit over 200 as one would expect, but
[winfo width .test.f1] is 1.

Removing the [update] makes the window open
with a more normal geometry, but e.g. when
debugging there may well be some trips through
the event loop between adding a frame as a pane
and completing its contents. I don't recall other
forms of geometry management being this
fragile.

[Joe English]

Logged In: YES
user_id=68433
Originator: NO

There is (probably) a good reason for this: if the panedwindow honors geometry requests from mapped slaves, it leads to even worse problems. See bug#1325286 for an example (there, adding a BWidget ScrolledWindow to a ttk::panedwindow thoroughly horked up interactive resizing. Problem was fixed by changing ttk::panedwindow to ignore geometry requests from mapped slaves just like the core panedwindow does).

Note that managing all children before managing the parent (or, as noted, just omitting the unnecessary [update] call) will yield the right results.

[Lars Hellström]

Logged In: YES
user_id=938835
Originator: YES

> There is (probably) a good reason for this:
> if the panedwindow honors geometry requests
> from mapped slaves, it leads to even worse
> problems. See bug#1325286 for an example

Aha! Seems reasonable.

I would then say that this is a documentation problem
(not at all uncommon for Tk, unfortunately). Knowing
what to look for, I can sort-of deduce this behaviour
from the documentation of the -height and -width
pane options, but having to do so isn't at all natural.
Adding a paragraph like the following to the "Resizing
panes" section could help:
[quote begin]
Unlike slave windows managed by e.g. pack or grid,
the panes managed by a panedwindow does not change
width or height to accomodate changes in the requested
widths or heights of the panes, once these have become
mapped. Therefore it may be advisable, particularly when
creating layouts interactively, to not add a pane to the
panedwindow widget until after the geometry requests
of that pane has been finalized (i.e., all components of
the pane inserted, all options affecting geometry set to
their proper values, etc.).
[quote end]

> Note that managing all children before managing
> the parent

Yes, that is what I ended up doing, though I then
saw it more as a work-around than as "best practice".

> (or, as noted, just omitting the unnecessary
> [update] call)

(Which, as explained, was given here just to
emulate the effect of single-stepping through the
code when trying to debug another issue (which
eventually turned out to be #219967 et al.).)

> will yield the right results.