Linux port on shared agtermCore

[melonamin]

UPDATE - Linux port repository https://github.com/melonamin/agterm-linux

---

I've built a working Linux port of agterm and would like to know if you'd want it upstream. Asking before opening a PR, since onboarding a second platform is your call.

It's a native GTK4/libadwaita app (agterm-linux/) on the same upstream libghostty (pinned), Swift 6 strict concurrency.

The approach

Not a rewrite, and not a parallel Linux codebase. It sits on the existing host-free agtermCore and mirrors the macOS app's structure: thin UI, shared controller logic. All in pure Swift.

Rather than duplicating logic on the Linux side, I pushed it down into agtermCore as host-free, unit-tested modules - ~20 hoists: ControlDispatcher, PaletteCatalog, CustomCommandEngine, KeymapStore, SessionSwitcherModel, OverlayCapture, and others. The GTK layer is thin glue on top, same as the macOS UI.

Rough split:

• ~1.3k LOC new shared logic in agtermCore (reusable by macOS)
• ~1.1k LOC shared tests (swift test, runs anywhere)
• ~5.2k LOC Linux-specific UI + packaging (mostly GTK/C-interop, ~no business logic)

agtermCore stays free of GTK/AppKit/GhosttyKit, so the macOS build is untouched.

What it means for the macOS side

Net positive even if you never ship Linux: the hoisted modules let macOS drop several inline copies (control dispatch, palette catalog, custom-command matching, keymap loading) and share one tested implementation.

The ask

Would you want this upstream? If yes, what form fits best? I can split it into reviewable PRs: the agtermCore hoists first (they stand alone and help macOS), then the Linux target.

Here is the PR in my fork

[umputun]

splitting this into the two things you're really asking, because my answer differs on each.

the agtermCore hoists: yes, I want these. Pulling the palette catalog, control dispatch, custom-command matching, keymap loading, the switcher model and the rest out of the app and down into the host-free core is a real improvement for macOS on its own: that logic is inline in the app today, so it can only be exercised by running the whole thing under Xcode, and moving it into the core makes it pure and unit-testable in isolation. Nothing to do with Linux, it's just better structure. I'd take them as small, self-standing PRs, one coherent module (or a few closely related ones) per PR, each carrying its unit tests and repointing the macOS side onto the new core module in the same PR. That last part is the important one: the risky bit isn't the extraction, it's rewiring ControlServer/AppActions onto the core and confirming macOS still builds and behaves. The whole-module optimizer here has release-only failure modes that swift test doesn't catch, so I need each hoist proven end to end on macOS, not just green under swift test. Done that way they're welcome, and they stand on their own merit regardless of any Linux target.

the Linux frontend: no, and this is a scope call, not a knock on the work. Desktop Linux is too exotic for me to take on as a solo maintainer. It's a second full UI, larger than the shared core itself, on a toolchain I don't work in (GTK4/libadwaita, C-interop, its own packaging, a separate libghostty build and CI), all of which I'd have to review and then own for good. Most of what makes agterm what it is lives in the native layer that doesn't port anyway: the NSOutlineView sidebar with cross-section drag-reorder, the window chrome, the quick terminal, the LaunchServices/Gatekeeper integration. On top of that the macOS UI is in constant, active development, so every change there would have to be mirrored on the GTK side, and asking that of contributors who may have no interest in a Linux UI is too much to ask. I'm not the person to carry it myself either: as a non-UI person I already find the standard, well-documented macOS toolkit a struggle, and I can't see myself owning the Linux side on top of that. A GTK build would always be the thinner, diverging half carrying my name, and the cost isn't worth the reach for me.

so: bring the core hoists as reviewable PRs and I'll happily review them, they help macOS either way. The Linux app I'd rather you keep as your own fork. Glad it exists, it's just not something I can maintain here.

[melonamin]

Sounds good

[melonamin]

I moved the port to shared agtermCore - worked perfectly. Right now the Linux branch contains only Linux specific code, which is really nice.

Thanks for working with me on agtermCore refactor!

[umputun]

https://github.com/umputun/agterm#related-projects