Quick terminal on Linux

[pluiedev]

As discussed in #4361, it appears that we could implement the quick terminal on Linux if we make use of the wlr-layer-shell protocol.

For our specific use case as a GTK4 application, however, we might also consider an off-the-shelf, battle-tested solution such as gtk4-layer-shell instead as to reduce the burden of maintaining our own Wayland glue code (at the cost of introducing a new dependency, of course).

A perhaps ironic downside to this is that GNOME users won't be able to use this, though the stubbornness of GNOME developers is scantly our fault...

[gucci-on-fleek]

(sorry if this comment belongs in a discussion thread instead)

A perhaps ironic downside to this is that GNOME users won't be able to use this, though the stubbornness of GNOME developers is scantly our fault...

Guake works on my Gnome+Wayland system, so wlr-layer-shell shouldn't be strictly necessary to implement a quick terminal. The only tricky thing is that a Wayland application cannot add a global hotkey, but Guake solves this by having the user manually register it with their desktop environment, so having the +toggle_quick_terminal action (or similar) work from the command line should be sufficient for this to work.

[pluiedev]

Guake is GTK3, though. GTK4 removed a LOT of APIs that allow windows to position themselves (since that is something Wayland explicitly forbids), so I doubt their approach still works

[pluiedev]

After looking at the gtk4-layer-shell docs, I realize that it's not exactly the best solution for us — not only does it mean even more C code (yikes) it also has its own Wayland register roundtrip logic which is terribly redundant.

I think writing the glue ourselves shouldn't be that bad, given a) how small the API is in reality (and how many of them are simple wrappers around existing Wayland protocols) and b) we can use Zig for a large part of the Wayland interface code thanks to zig-wayland, which should be a lot easier than trying to write raw C.

[MakotoTheKnight]

Going to capture this since it came up in the Discord:

Looking at prior art with ddterm, which bundles the terminal within a whole plugin, or with another plugin which attempts to do the same, this could set some direction on how to tackle this within GNOME. It'd likely need to be something that isn't directly bundled with Ghostty but could be offered as an addition to the platform, since GNOME's native approach is to use plugins.

Simply put, this appears to be the "workaround" that GNOME has to go through in order to place arbitrary windows of varying width and height on the screen. Doesn't have to be an option today, but could be revisited when libghostty is released.

[pluiedev]

Looks like reimplementing gtk4-layer-shell may be more difficult than I initially thought. The core problem is that GTK forces its windows to be initialized as xdg_toplevel windows, while we want them to be zwlr_layer_shell_v1 windows. (These are known as "roles" in Wayland jargon, and you cannot set a new role when one's already been set.) gtk4-layer-shell uses an extremely unsightly hack to essentially intercept any attempt by GTK to set the toplevel role and ignore them, thereby avoiding the collision.

I... am not down for patching and overriding symbols inside dynamic libraries. We should probably try doing something else (if an alternative exists).

[jcollie]

Ugly. I'd say us Gnome users just lose out until hell freezes over and Gnome implements the layer shell.

[pluiedev]

This isn't even just exclusive to GNOME — it's GTK being GTK 😛

[jcollie]

So a big FU from Gnome to everyone else too, huh?