[pluiedev]

One major todo is moving splits across different split trees (i.e. moving across tabs and windows), but that would involve a lot more logic. This MVP version works for now.

Video demo (somehow the encode quality is terrible - I'll fix this later):

2026-01-24.01-13-44.mp4

GTK version of #10090

Closes #10224

[jcollie]

After playing around a bit, I got this panic when exiting Ghostty:

thread 627727 panic: reached unreachable code
/nix/store/z3mbm3szjjacd2q2kaa795ik361w1irr-zig-0.15.2/lib/std/debug.zig:559:14: 0x2aa13bd in assert (ghostty)
    if (!ok) unreachable; // assertion failure
             ^
/home/jcollie/dev/ghostty/src/App.zig:114:11: 0x2d0fb0d in deinit (ghostty)
    assert(self.font_grid_set.count() == 0);
          ^
/home/jcollie/dev/ghostty/src/App.zig:120:16: 0x2c7ee50 in destroy (ghostty)
    self.deinit();
               ^
/home/jcollie/dev/ghostty/src/main_ghostty.zig:98:22: 0x2c7ea56 in main (ghostty)
    defer app.destroy();
                     ^
/nix/store/z3mbm3szjjacd2q2kaa795ik361w1irr-zig-0.15.2/lib/std/start.zig:627:37: 0x2c7f295 in main (ghostty)
            const result = root.main() catch |err| {
                                    ^
???:?:?: 0x7ffff682a4c4 in ??? (libc.so.6)
Unwind information for `libc.so.6:0x7ffff682a4c4` was not available, trace may be incomplete

???:?:?: 0x7ffff682a577 in ??? (libc.so.6)
???:?:?: 0x276a8a4 in ??? (???)
debug(io_exec): termios change mode=.{ .canonical = true, .echo = true }

[pluiedev]

Hmm.. what does the font grid have to do with any of this...?

[pluiedev]

Hang on. Why is the surface not getting deinit'd when the whole app closes? This is sus. Lemme think about this

[pluiedev]

I think I realized why - the content provider is constantly holding a stale ref to the surface, so the surfaces themselves are actually never unref'd. Good thing we had an assert there, since otherwise we could have had a gigantic leak

[pluiedev]

Hmm.. Resolving this turned out to be much more difficult than imagined. The GLib APIs I've been given here aren't really flexible enough, so I might need to wait for us to assign each surface a unique ID and then make the split tree fully ID-based instead of holding pointers to the RtSurface structs, to fully sidestep the refcounting mechanism. Gonna mark this as draft for now.

Blocked on #8200 or a functional equivalent

[pluiedev]

Wouldn't you know it, switching to u64 IDs fixed all the issues completely :bobr:

[jcollie]

Nifty! Now the GTK devs can get people complaining about the drag handle too! One nice thing to have might be is suppressing the drag handle when there's only one split but I won't block this PR for that.