This removes `launched-from` entirely and moves our `gtk-single-instance`
detection logic to assume true unless we detect CLI instead of assume
false unless we detect desktop/dbus/systemd.
The "assume true" scenario for single instance is desirable because
detecting a CLI instance is much more reliable.
Removing `launched-from` fixes an issue where we had a
difficult-to-understand relationship between `launched-from`,
`gtk-single-instance`, and `initial-window`. Now, only
`gtk-single-instance` has some hueristic logic. And `initial-window`
ALWAYS sends a GTK activation signal regardless of single instance or
not.
As a result, we need to be explicit in our systemd, dbus, desktop files
about what we want Ghostty to do, but everything works as you'd mostly
expect.
Now, if you put plain old `ghostty` in your terminal, you get a new
Ghostty instance. If you put it anywhere else, you get a GTK single
instance activation call (either creates a first instance or opens a new
window in the existing instance). Works for launchers and so on.
The XDG Freedesktop Portal has a _major_ undocumented requirement for
programs that are launched/controlled by `systemd` to interact with the
Portal. The unit _must_ be named `app-<appid>.service`. The Portal uses
the systemd unit name figure out what the program's application ID is
and it will only look at unit names that begin with `app-`. I can find
no place that this is documented other than by inspecting the code or the
issue and PR that introduced this feature. See the following code:
7d4d48cf07/src/xdp-utils.c (L152-L220)
This may fix many people's issues with getting global shortcuts
to work.
Note that this is a breaking change if you have been using Ghostty
compiled from source since #7433 was merged. You will need to ensure
that any Ghosty systemd unit files _not_ prefixed with `app-` are
deleted.
Original discussion/PR in the XDG Desktop Portal repository:
https://github.com/flatpak/xdg-desktop-portal/issues/579https://github.com/flatpak/xdg-desktop-portal/pull/719
Originally discussed on Discord:
https://discord.com/channels/1005603569187160125/1394845362186879026
Co-authored-by: ambareeshbalaji@gmail.com
This allows `systemctl` to send SIGUSR2 to Ghostty to trigger a reload,
which is more convenient than scripting `ps` and `kill` to find the
Ghostty main PID.
Fixes#7673
This adds `Ctrl+Alt+T` as a KDE shortcut to the desktop file. If Konsole
is installed (or any other prorgam that has the same shortcut) the user
will need to go into the KDE system settings and manually reassign the
`Ctrl+Alt+T` shortcut to Ghostty.
If Ghostty is the only terminal installed that claims that shortcut KDE
_should_ automatically enable the shortcut (but YMMV).
Non-KDE systems will ignore this setting and if the user desires a
global shortcut to open a Ghostty window it will need to be accomplished
in other ways.
This will allow users to enable Ghostty startup on login. Users will
need to explicitly enable startup on login via this command:
```sh
systemctl enable --user com.mitchellh.ghostty.service
```
Replaces #7676
When building as a flatpak, don't install the systemd user services
since flatpaks can't use them. Remove references to the systemd service
from the DBus service.
Also, customize the app metadata depending on the debug mode.
Co-authored-by: Leorize <leorize+oss@disroot.org>
This replaces #7433. The improvements are:
1) Install the systemd user service in the proper directory depending
on if it's a 'user' install or a 'system' install. This is controlled
either by using the `--system` build flag (as most packages will) or by
the `-Dsystem-package` flag.
2) Add the absolute path to the `ghostty` binary in the application
file, the DBus service, and the systemd user service. This is done so
that they do not depend on `ghostty` being in the `PATH` of whatever
is launching Ghostty. That `PATH` is not necessarily the same as the
`PATH` in a user shell (especially for DBus activation and systemd user
services).
3) Adjust the DBus bus name that is expected by the system depending on
the optimization level that Ghostty is compiled with.
Reverts two commits:
977cd530c7820b7e432b
These break build from source on Linux for two reasons:
1.) The systemd user service needs to be installed in the `share`
prefix, not the `lib` prefix. This lets it get picked up in `~/.local`
but is also correct for just standard FHS paths.
2.) The `ghostty` path in the systemd user service needs to be absolute.
We should interpolate in the build install prefix to form an absolute
path.
This should make testing Flatpak builds a lot easier.
To build, enter `flatpak/` directory and run:
flatpak-builder --repo=repo builddir com.mitchellh.ghostty.yml
alternatively, using org.flatpak.Builder flatpak:
flatpak run -p org.flatpak.Builder \
--repo=repo \
builddir \
com.mitchellh.ghostty.yml
The resulting flatpak can be installed using
flatpak install ./repo com.mitchellh.ghostty
Credit of AppStream metadata goes to @yorickpeterse.
Removed check for plasma in build.zig, it installs it anyways now
Added executable permissions for ghostty_dolphin.desktop since Plasma
requires them for context menu items
The app.desktop file shipped with the default build presumes the install
location of the binary. Let the OS determine the executable through it's
normal PATH variables.
Flatpak support has been a HUGE pain to keep working, the builds take
forever and cost me real money, and there are very few users. Ideally,
we want to just use native system packagers for each distro. I thought
Flatpak would make it easy to support many distros but that ended up
being false.
Inspired by #413.
This modifies the .desktop files so that it's possible to right-click on
the Ghostty icon in a dock and get the "New window" action.
Apparently this is how you implement that in GTK applications. In order
for us to also get "New tab", we'd have to implement a CLI flag, I
think.
Mitchell Hashimoto