[jcollie]

This PR adds a +new-tab CLI action, useful for automation on GTK. This mainly re-uses machinery added for the +new-window, but adds in a unique surface ID for identifying surfaces for IPC purposes (and eliminates use of raw pointers for callbacks from notifications).

[tristan957]

I think I would like to see the core ID portions pulled to their own PR. We have previously talked about adding a surface ID. In a dedicated PR, we could bikeshed the id format. I know Mitchell had a format in mind.

[jcollie]

I think I would like to see the core ID portions pulled to their own PR. We have previously talked about adding a surface ID. In a dedicated PR, we could bikeshed the id format. I know Mitchell had a format in mind.

The format really doesn't matter for this, as long as I can treat it as an "opaque" u64 that's not zero. Any further meaning to the bits makes no difference to the current use cases (+new-tab, notifications) or even some future uses that I have in mind.

[tryingET]

I tested this locally on Linux/GTK by cherry-picking it onto current main for an automation workflow (ghostty +new-tab -e ... to start a forked Pi session in a new tab).

Useful testing notes:

• cherry-picks cleanly onto current main
• I did not need any source changes on top of the PR
• when testing side-by-side with distro Ghostty, I had to run the patched build with a separate class and --gtk-single-instance=true, otherwise D-Bus calls were handled by the system Ghostty instance instead
• after that, new-tab was exposed correctly and the remaining failures were in my wrapper/tooling, not in Ghostty

One thing worth double-checking in the PR:

if (Action.newTab(...)) {
    log.warn("new-tab: unable to create tab", .{});
}

This may be inverted, unless Action.newTab(...) intentionally returns true on failure. From the name/signature I would normally expect true to mean success, in which case I would expect the warning to be under if (!Action.newTab(...)). I mention it because I was still seeing this warning in runs where the tab-launch path was otherwise progressing.

I did not validate the surface-id path end-to-end because GHOSTTY_SURFACE_ID was not present in the client environment I was launching from.

Overall: this was very useful in practice, and +new-tab is exactly the CLI surface I was missing.

[103sbavert]

This is such a useful feature to me. Could a maintainer please take their time to review this MR and merge it if approved? Thanks for all the work!

[gitzone83]

This is such a useful feature to me. Could a maintainer please take their time to review this MR and merge it if approved? Thanks for all the work!

Ditto for me, I switched to Ghostty because it is more modern and also more functional comparing to other solutions. I also wanted to add option to automatically save / restore tabs on startup, which requires me to be able to create tabs to begin with.

[103sbavert]

I hope a maintainer is able to look into this soon.

[103sbavert]

Did this just get approved?

[00-kat]

By the macOS team; someone from the GTK and terminal side need to approve it too. (IIRC GitHub doesn't show teams to everyone so I'm not sure if you can see this too.)

[pluiedev]

Let's do this

[lightningRalf]

Yes! Congratz! 5 months in the making!

[103sbavert]

HELLLLLLLLYEAH!