Re: [TCLCORE] tk frame does not shrink to 0 height if last children unpacked

[Brian G. <bri...@ea...>]

On Oct 13, 2016, at 2:33 PM, Harald Oehlmann <har...@el...> wrote:
> 
> Am 29.09.2016 um 18:28 schrieb Brian Griffin:
>> On Sep 29, 2016, at 6:32 AM, Harald Oehlmann <har...@el...> wrote:
>>> thank you for the message. For me, the bug matters when you have a frame where the childs are exchanged, like a scrolling widget.
>>> 
>>> Due to this bug, the scrollbars do not disapear if the canvas (frame) is empty.
> 
>> No, I have not had the chance to try this yet.  I do have an extremely complex GUI with lots and lots of widgets and frames and automatic scrollbars, etc., etc., and never came across this problem myself.  I have used every aspect of geometry managers grid, pack, place, panedwindow, canvas, text, and wm.  (Yes, canvas & text are geometry managers!)  I'm pretty sure every time I have run into a geometry manager issue it was because the geometry manager was being misused in some manner.
>> 
>> If there is a bug here, the virtual event doesn't seem like the right solution either.
>> 
>> If I get a chance I will try to run with the proposed changes, but I don't know when that will be.
> 
> Hello Brian,
> thank you for the message. My admiration for the big experience with geometry managers.
> 
> To explain why I think this is sensible, I have put an example to the TIP: http://tip.tcl.tk/454
> A simple scrolling megawidget is shown which suffers from the bug.
> May this convince you that the issue may be a problem for some people ?
> Or do I overlook something ?
> Or is this a miss-use of the geometry manager ?
> 
> I would also appreciate, if you could make a statement about compatibility.
> 
> Thank you and best regards,
> Harald


Hi Harald,

I played with the example, and I can see the behavior in question.  I was not surprised by overall behavior of the user interface.  Yes, it was strange that the scrollbar did not resize, but that's something you'd have to look for, whereas, the fact that the canvas starts empty and then goes empty is more of a surprise, from a usability perspective.  Having empty panes is kind-of a bad idea.  This does not mean that 0 boxes should be disallowed.  What it does mean is that something else should presented so as not to surprise the user when the last box goes away.  This may sound like nonsense when discussing an over simplified demonstration example, but it is critically important in real GUI's that do real work.  This is why I cannot get very excited about calling this behavior a bug.  I believe, from a usability perspective, if the GUI doesn't know what to do, don't do anything.  That is the case here with an empty frame.  When the rule is "resize to the aggregate size of my children", and there are no children, no answer (undefined) is better than having closure of 0.

So that's a lot of academic mumbo jumbo.  In practical terms, I'm pretty sure, once your GUI is fully implemented, with all the features, bells and whistles, you won't even run into this "bug".  And if others want to fix the "bug", by all means, go ahead.  I'm pretty sure I won't run into the problem either way.

Here is the demo with some "enhancements" that makes it more like a real GUI.  Note that the "bug" is no longer material.

# Button to add box on scrolling canvas
set itemNo 0
pack [button .b1 -command newBox -text +] -side left -fill y
proc newBox {} {
    puts +
    if {$::itemNo == 0} {
        puts "Show it!"
        .c itemconfigure win -state normal
        .c itemconfigure msg -state hidden
    }
    incr ::itemNo
    pack  [frame .c.f.i$::itemNo -borderwidth 4 -relief raised -bg red -width 100 -height 100] -side top
}
# Button to remove box on scrolling canvas
pack [button .b2 -command removeBox -text -] -side left -fill y
proc removeBox {} {
    puts -
    if {$::itemNo == 0} {
        return
    }
    destroy .c.f.i$::itemNo
    incr ::itemNo -1
    if {$::itemNo == 0} {
        puts "Hide it!"
        .c itemconfigure win -state hidden
        .c itemconfigure msg -state normal
    }
}

# This is the scrolling megawidget which exposes frame .c.f for users to pack or grid clients
# It has no knowledge, when the user adds or removes clients, e.g. when +/- is pressed
pack [scrollbar .s -command {.c yview}] -side right -fill y
pack [canvas .c -borderwidth 0 -yscrollcommand {.s set}] -side left -fill both
frame .c.f -background {light blue}
.c create window 0 0 -window .c.f -anchor nw -tags win -state hidden
.c create text 100 50 -anchor center -justify center -tag msg -state normal \
    -text "Intentionally left blank\nUse \[+\] button to add new windows"
lassign [.c bbox all] x1 y1 x2 y2
set b1w [winfo reqwidth .b1]
set b2w [winfo reqwidth .b2]
set sbw [winfo reqwidth .s]
wm geom . [expr {$x2-$x1+$b1w+$b2w+20}]x[expr {$y2-$y1+20}]

proc frameConfigure {{why -}} {
    puts "requested canvas size: [.c bbox all] because $why"
    .c configure -scrollregion [.c bbox all]
}
frameConfigure
bind .c.f <Configure> {frameConfigure Configure}
bind .c.f <Map> {frameConfigure Map}
bind .c.f <Unmap> {frameConfigure Unmap}


-Brian