Closed ukscid closed 1 year ago
This is not good. Why resizeMainBoard is called with the same size? It is necessary to understand and fix that. With a quick grep I found only this:
bind $w <Configure> {+::resizeMainBoard }
and if I were to guess probably the function is invoked by children windows (can be verified checking the %W param).
Indeed, all children from .main call resizeMainBoard. The bind command seems to be inherited to all children. I tried
bind $w.board.bd
Probably not. In ::resizeMainBoard there are:
set availw [winfo width .fdockmain]
set availh [winfo height .fdockmain]
and there is no guarantee that those values will be correct. I do not rember why:
+::resizeMainBoard
instead of ::resizeMainBoard
. I think there was the hideous bind $w <Configure> "recordWinSize $w"
somewhere, but I can't find it.winfo width .fdockmain
instead of winfo width .main
bind $w <Configure> "+if {%W eq $w} { ::resizeMainBoard }"
did not work. I remember I tried it and sometimes the board was not resized, but i do not remember the details.I think "+" is not necessary, i also havn't found a "recordwinSize" for .main .fdockmain or .main make no difference. I test you suggestion to check "%W eq $w". The problem is: toggle on/of children like material, info or evalbar then the configure event ist not triggered for .main, only for children like .main.board.score or .main.board.bd the event is generated.
I made some tests and found:
If the size is changed in y-direction (height) then only a configure event is triggered for .main, but not for any child. If the size is change in x-direction (width) then events are triggered for all children. Therefore bind configure event only to a child e.q. .main.board does not work (as you assumed) and resize ist not performed. Is this a hint for the structure/attributes of the grid configuration? Looking on the structure and layout of .board need more time. Maybe you have an idea with this information.
I changed the patch in that way to disable the configure event when resizing the board. This reduces the calls already drastically. But this is working an symptoms than on finding, why a child is not triggered. So it is ok, not to use this pull request at the moment.
Maybe the "after cancel" "after idle" trick will work:
bind $w <Configure> {
after cancel ::resizeMainBoard
after idle ::resizeMainBoard
}
I tried your solution. There is no difference of the amount of call for resizeMainBoard. Your solution cancel existing events, my solution prevent creating events. On large changes of size your solution starts the resizing after the movement of the mouse stops and no changes are displayed until this. My solution is more dynamic and you see changes during mouse movement. You can decide what is the better solution.
The proc resizeMainBoard was called 20-40time with the same size. No the resize is only performed if the size has changed.