Repository navigation
apprt/gtk-ng: create/close split functionality - #8202
Conversation
2d96a03 to
441af83
Compare
| .{ "new-left", actionNewLeft, null }, | ||
| .{ "new-right", actionNewRight, null }, | ||
| .{ "new-up", actionNewUp, null }, | ||
| .{ "new-down", actionNewDown, null }, |
There was a problem hiding this comment.
A future TODO is to change this to take a direction as a parameter, but I'm not super familiar with how to do that AND bind it in a blueprint file so I'm going to defer this in the interest of getting things done (and doing things the way we always have in the mean time).
|
Ouch that looks like a lot of flashing... definitely needs to be ironed out before we make -ng the default |
00-kat
added
os/linux
gui
As a heavy user of splits, it's not that bad. It has to be fixed, but I don't think it needs to block making So you only see the flash momentarily, then you work for a long time without issue. The demo here is sort of a worst case and unrealistic scenario. 😄 Its also a lot better in ReleaseFast builds. Like I said, it still needs to be improved, but not a fire. I have some ideas to improve it. |
|
#8208 so we don't forget the flicker. |
…t time for our GTK backend) (#8210) This continues #8202 by fixing two of the known issues: `goto_split` key binds work and closing a split moves focus to the proper place. A big improvement in this PR is that for the first time ever in our GTK backend, the up/down/left/right `goto_split` bindings **use spatial navigation.** "Spatial navigation" means that the direction to move focus is done based on the nearest split _visually_ from the current split, rather than via a tree traversal. We did this on macOS a couple months ago, with a lot more details there: #7523 Similar to macOS, the spatial navigation is currently based on top-left corner. Now that our split tree is implemented in Zig though it should be a lot easier for us to work in the current cursor position as the reference point. ~~🚧 TODO: Going to add some unit tests for the spatial navigation before merge.~~
This adds on to our existing foundations from #8165 and adds the ability to create and close splits. We're still missing split navigation, resizing via keybindings, etc. And there are a number of known issues (listed below). But this is a strict improvement from where we're at and includes a number of important bug fixes to our split tree.
The only nasty thing in this PR is that I learned that GTK did not like rebuilding our split widget tree on every data model change. I don't know enough about how all the re-parenting plus size allocation interactions work together. As a compromise, this PR adds a listener, waits for our surface tree to "settle" by having all surfaces have no parents, then schedules a single rebuild after that. This works well, but results in some noticeable flashing for a frame or so. I think we can improve this later, it works completely well enough.
Importantly, all of this is Valgrind clean. I long suspected our splits on legacy are NOT free of leaks, but never proved it, so this makes me happy.
Demo
CleanShot.2025-08-10.at.12.46.10.mp4
Known Issues
I may fix this in this PR, I may follow up.
goto_split(including spatial navigation for the first time for our GTK backend) #8210)goto_split(including spatial navigation for the first time for our GTK backend) #8210)