Tk Source Code

I could find a still undetected bug with container widgets. Try this script:

pack [tk::panedwindow .mw -width 400 -height 400]
tk::frame .f -background red
.mw add .f

This works as expected. Now try next script, where first and second line have been swapped:

tk::frame .f -background red
pack [tk::panedwindow .mw -width 400 -height 400]
.mw add .f

This doesn't work, the red frame will not be displayed, although from the logical point of view we are doing the same. Note that this behaviour also happen with other container types, like ttk::notebook, and ttk::panedwindow. So probably this is a problem of Tk_ManageGeometry()?

Serhiy, many thanks! Merged into main, core-9-0-branch, and core-8-6-branch by commits [ca16e5ad], [eb7a029b], and [43f0110c].

Oops, last description was an accident, wrong tab in my browser.

Under my system DejaVu Sans looks perfect, see attached screenshot (DejaVuSans-Ubuntu.png). Is this font installed under the different systems, please try:

puts [font actual {{DejaVu Sans}}]

> Users sometime use this to hide elements until needed.

I cannot believe this, because panedwindow provides option "-hide" for this reason (I'm talking about tk::panedwindow, not ttk::panedwindow, the latter one is a mess). And probably this will solve your issue with resizing, provided that your are talking about tk::panedwindow. So I'm still thinking that a fix (automatic change of stacking order) is appropriate, at least for tk::panedwindow.

And I have found a test case where the window will not be displayed even with the right stacking order. I'm still working on a minimized example.

Users sometime use this to hide elements until needed.

Yes, it is unexpected.  I've run into this several times and I often forget why my windows are not showing up.

It could be documented much better.

Flexible/dynamic layouts sometimes cannot specify a parent/child relationship and must be stacking order aware.

Off topic: The expand (based on window weight) / shrink (based on stacking order) issue when resizing could also be documented much better.   Getting my windows stacked properly so that the UI shrinks properly is painful.

> Not a bug.
> The stacking order in tk is preserved.

Then I would say that this must be documented, because the added frame is something like a child, and I think that everybody assumes that a (quasi) child has a higher stacking order. But I would suggest to admit this report as a bug, and to fix it with an automatic raise of the child. Probably you agree that's it useless if a container element has less stacking order than the container, thus I cannot believe that this fix would cause portability issues.

Not a bug.
The stacking order in tk is preserved.
raise .f .mw  will show the window.

bll-tecra:bll$ rlwrap wish
% set a hello
hello
% entry .e -textvariable a
.e
% frame .d -bg blue -width 200 -height 200
.d
% pack .d
% pack .e -in .d  ; # .e is not visible.
% raise .e .d ; # now .e is visible.