paulhoule / tentacruel

MIT License
0 stars 0 forks source link

Browse Windows expand to fit all content #10

Closed paulhoule closed 5 years ago

paulhoule commented 5 years ago

This is part of #2.

Right now the scrollbars appear, but they are not active because the window is full with results; it expands to fit all of the results, even if the window hangs far off the bottom of the screen.

paulhoule commented 5 years ago

Ok, to set the size of a window we have to use the "geometry" method.

When I lock this down at the beginning I often get a window that is too big. I think I need something to lock down the geometry to a maximum after (or as we) load the window.

paulhoule commented 5 years ago

So I struggled just a little bit to figure out when exactly to do the geometry change and how to get a reference to the window there.

For instance if I tried to do this in the fill_source() method I don't know if the geometry change would be visible then or after the UI gets updated.

Then I looked at it and saw that the update_region method gets called when the geometry of the frame is changed, and probably the size of the window updates with that. Let's check.

Actually the geometry that I get for that window is always the same, at least in size:

723x51+104+104

or

723x51+130+130

which makes me wonder if we are seeing the wires get crossed in the static scope or something. Note that the 723x51 wide but not very tall, it is about what I'd expect before the window expanded. That may not be all that strange, however, it could be that the hook gets called for the frame and then everything works outward from there. We certainly could lock down the geometry of the window from here but then it might not be reflective of all the chrome...

paulhoule commented 5 years ago

Going a bit further it seems that events are propagated up the widget chain, so that if i set events on the window, I get events all the way from the canvas. The sequence I get is this:

The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=865 height=775> directed at .!application.!toplevel3
The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=865 height=775> directed at .!application.!toplevel3
The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=399 height=269> directed at .!application.!toplevel3
The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=399 height=269> directed at .!application.!toplevel3
The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=865 height=775> directed at .!application.!toplevel3
The window named .!application.!toplevel3 saw event <Configure event x=130 y=130 width=865 height=775> directed at .!application.!toplevel3

So the obvious consideration is that the object is being laid out multiple times, probably there is some negotiation going on between the parts of the system.

I put in a sleep(1) statement in the event handler for events originating from the window and found that the window was in different phases of drawing itself and it really did change in size a few times.

paulhoule commented 5 years ago

So I just put in a "maximum" size which seems to work the way it is intended. There is still some flickering as it paints, but I have to look carefully.

The main trouble I have now is that once it hits the maximum size it is no longer responsive if I try to resize the window with the mouse. That isn't so bad.

paulhoule commented 5 years ago

it is good enough for now and if it needs to be better I can do something about it.