WIP: apprt/gtk: fix equalizing when doubleclicking near the divider

[Opposite34]

This PR aims to fix #4354 .

Before

Screencast.From.2025-01-03.07-30-23.mp4

After

Screencast.From.2025-01-03.07-31-07.mp4

As you can see in the fix, one problem is that sometimes the resizing is bounced back to the original sizing (I didn't show it here, but this happens prior to this fix as well). My suspicion is with the race condition of doubleclick to equalize (this PR) and with the dragging of the divider to resize the panes. However, the latter might be a GTK feature we just use (?) as I couldn't find it anywhere in the codebase...

Apart from that, the function equalizeTopSplit I added in this fix, which climbs up the split parents to the topmost one, seems to partially function similarly to equalizeSplits inside apprt/gtk/App.zig (in the app we can just get the topmost split, while here we have to climb up as the Splits only have the knowledge of its parent). I want to prevent code repetition, so some advice here will also be nice as well.

[Opposite34]

In the Discord server, Kat has confirmed that this work on their system without the size rebouncing back issue that I and some other people are having. I am wondering if a new discussion should be created regarding that issue or not, as it seems like that requires more of knowing how to work with gtk which I currently don't have.

Still also want some comments regarding equalizeTopSplit and the equalizeSplits inside apprt/gtk/App.zig on what approach we should do to organize these properly.

[mitchellh]

Note I reverted bec46fc

I'd still like double clicking dividers to equalize. That is something I've actually tried before and wanted to work, and something that I've found generally works in other "divided" programs.

[Opposite34]

Note I reverted bec46fc

I'd still like double clicking dividers to equalize. That is something I've actually tried before and wanted to work, and something that I've found generally works in other "divided" programs.

Good to know. In that case I will keep the issue as one then. Will rebase this for now and figure out a way for double clicking the divider itself to not be buggy like it currently is.

[Opposite34]

I have some updates. The bug with the rebouncing only occurs when double-clicking at GtkPanedHandle, which is supposedly the divider itself.

When looking through the GTK debug inspector (GTK_DEBUG=interactive ./zig-out/bin/ghostty), I found two things:

1. this GtkPanedHandle is not actually centered to the divider, but skewed to the right or the bottom of the split depending on the splitted direction.
2. When disabling its visibility, double-clicking where the divider is supposed to be works (so we have isolated that this widget is probably the culprit).

Moreover, GtkPanedHandle itself doesn't seems to response to gesture click properly. I am not sure whether this was due a logical error in the code I tried it with (I'm gonna assume it is this one for now, and will try to make it work later), or whether GtkPanedHandle really can't emit signals from gesture click. Either way, because of the hitbox of this widget itself being skewed to one side, it might be a bit weird to double click this properly even if we can get it working later on.

I have also been chatting with the author of the original PR in this thread of the Ghostty Discord, in which they suggested trying to bind the gesture click signal they did to GtkPanedHandle above but to no avail.