You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GTK: Splits are equalized when double clicking anywhere, not just the divider #4354
Originally posted by Opposite34 January 1, 2025
Referring to #3557
Some people brought up that the splits are equalized when double clicked anywhere on the window, which of course shouldn't be done as some TUIs rely on double clicks to work properly (selecting words in some editors, etc).
In the PR above, the author mentioned double clicking on a handle bar (aka divider) to equalize the splits. However, the gtkMouseDown callback they wrote seems to just check for double clicks without checking the mouse position:
Cross-posting from Discord. Essentially I tried something and found some roadblocks:
It seems like on my system, if I double click directly at the divider, it equalize for a split second and then resized back to the way it was (I'm gonna assume this could be some kind of race condition between the mouse dragging resize and the double click to equalize). Anyway, for now I solve this by having a leeway (~20px or so) that you can double click away from the divider itself.
Now here's the next problem. Adapting the current logic we had, because equalize is done recursively from the current split, when you double click on a divider of the children splits, only those equalize... Not sure how to redesign this though...
Going to take a break for now. I will try to think about how to get the proper behavior for this.
Edited: branched a partial fix I did on my fork in case people want to look into this, but didn't PR as it doesn't address everything wrong here.
Activity
Opposite34 commentedon Jan 2, 2025
Cross-posting from Discord. Essentially I tried something and found some roadblocks:
It seems like on my system, if I double click directly at the divider, it equalize for a split second and then resized back to the way it was (I'm gonna assume this could be some kind of race condition between the mouse dragging resize and the double click to equalize). Anyway, for now I solve this by having a leeway (~20px or so) that you can double click away from the divider itself.
Now here's the next problem. Adapting the current logic we had, because
equalizeis done recursively from the current split, when you double click on a divider of the children splits, only those equalize... Not sure how to redesign this though...Going to take a break for now. I will try to think about how to get the proper behavior for this.
Edited: branched a partial fix I did on my fork in case people want to look into this, but didn't PR as it doesn't address everything wrong here.
mitchellh commentedon Jan 3, 2025
I reverted the commit for now to resolve this: bec46fc