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.
Cleans up the logic, checks for out of bounds using rows instead of
sel.contains because that excludes cases where a rectangle selection
doesn't include the leftmost column.
Also adds test for clipping behavior of rectangular selections.
Fixes an issue where rectangle selections would appear visually wrong if
their start or end were out of the viewport area, because when cloning
them the restored pins were defaulting to the start and end of the row
instead of the appropriate column.
Adds support for background images via the `background-image` config.
Resolves#3645, supersedes PRs #4226 and #5233.
See docs of added config keys for usage details.
> [!NOTE]
> Unlike what is implied by the original issue, because this is
implemented in the renderer it is inherently per-surface not per-window,
meaning a window with a split will have two copies of the background
image.
### Future work
- We should probably introduce code in the apprts that tells surfaces
their position and size relative to the window, which would allow us to
add a `background-image-area` config with options for `surface` and
`window` to control that behavior (and probably default it to `window`).
That apprt code would also allow for window-relative custom shader
locations, which is also a fairly common user request, so I think it's
worth it.
- Currently if you use a high res background image this is fairly
inefficient, since each surface independently loads a copy of the
background image. On systems with limited VRAM this could be an issue
for users who use a lot of surfaces, so it may be worth making a shared
image cache to avoid this problem.
- ~~It's probably worth using compressed texture formats for images,
I'll look in to doing that.~~ (c43702c)
BPTC is required to be available OpenGL >= 4.2 and our minimum is 4.3 so
this is safe in terms of support. I tested briefly in a VM and didn't
encounter any problems so this should just be a complete win.
(Note: texture data is already automatically compressed on Metal)
Adds support for background images via the `background-image` config.
Resolves#3645, supersedes PRs #4226 and #5233.
See docs of added config keys for usage details.
Reverts two commits:
977cd530c7bb9551de93900170bdaec4601b1b5b
820b7e432b57cd08c49d2e76cce4cb78016f0418
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.
Reverts two commits:
977cd530c7bb9551de93900170bdaec4601b1b5b
820b7e432b57cd08c49d2e76cce4cb78016f0418
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.
There are two main improvements being made here. First, we move away
from using autohash and instead use a one-shot strategy similar to the
Style hashing. Since the GlyphKey includes the Metrics struct, which
contains quite a few fields, autohash was performing expensive and
unnecessary repeated updates.
The second improvement is actually just, not hashing Metrics. By
ignoring the Metrics field, we can fit the rest of the GlyphKey into a
64-bit packed struct and just return that as the hash! It ends up being
unique for each GlyphKey in renderGlyph, and is nearly a zero-cost
operation.
This ends up boosting the performance (on my machine at least), from
around 560fps to 590fps on the DOOM-fire benchmark.
Flatpak currently does not export systemd user units. As such, remove
references to it from D-Bus services to prevent D-Bus daemon from trying
to start a non-existent service.
Additionally, make sure that the D-Bus service name is correct for debug
builds.
Follow up to #7433
There are two main improvements being made here. First, we move away from using autohash and instead
use a one-shot strategy similar to the Style hashing. Since the GlyphKey includes the Metrics struct,
which contains quite a few fields, autohash was performing expensive and unnecessary repeated updates.
The second improvement is actually just, not hashing Metrics. By ignoring the Metrics field, we can
fit the rest of the GlyphKey into a 64-bit packed struct and just return that as the hash! It
ends up being unique for each GlyphKey in renderGlyph, and is nearly a zero-cost operation.
This ends up boosting the performance (on my machine at least), from around 560fps to 590fps on the
DOOM-fire benchmark.
Flatpak currently does not export systemd user units. As such, remove
references to it from D-Bus services to prevent D-Bus daemon from trying
to start a non-existent service.
Additionally, make sure that the D-Bus service name is correct for debug
builds.
Without waiting on the xdg-open process on linux/freebsd, we end up with
a defunct (zombie) process after each time we open a URL.
For example, after click on two URLs in a ghostty, here is the output of
`ps ux | grep xdg-open`:
```
pbui 8364 0.0 0.0 0 0 tty7 Z+ 05:03 0:00 [xdg-open] <defunct>
pbui 8453 0.0 0.0 0 0 tty7 Z+ 05:03 0:00 [xdg-open] <defunct>
```
Perhaps we should revisit 695bc30, which removed the wait in the first
place. On my machine running Alpine Linux 3.22, `xdg-open` does not stay
alive and finishes immediately, thus making it safe to call wait (and
not block). This is also the case on my other machine running Ubuntu
24.04: `xdg-open` launches the URL in a browser and terminates
immediately.
Either way, this process must be waited upon eventually. Otherwise, we
will accumulate a collection of defunct processes until the terminal
itself terminates.
Introduces host resources directory as a new concept: A directory
containing application resources that can only be accessed from the host
operating system. This is significant for sandboxed application runtimes
like Flatpak where shells spawned on the host should have access to
application resources to enable integrations.
Alongside this, apprt is now allowed to override the resources lookup
logic.
## Description
Yet another edge case in #2484
When macOS's "Private WiFi address" feature is enabled it'll change the
hostname to a mac address. Mac addresses look like URIs with a hostname
and port component, e.g. `12:34:56:78:90:12` where `:12` looks like port
`12`. However, mac addresses use hex numbers and as such can also
contain letters `a` through `f`. So, a mac address like
`ab💿ef🆎cd:ef` is valid, but will not be parsed as a URI, because
`:ef` is not a valid port.
This commit attempts to fix that by checking if the hostname is a valid
mac address when `std.Uri.parse()` fails and constructing a new
`std.Uri` struct using that information.
It's not perfect, but is equally compliant with the URI spec as
`std.Uri` currently is. Meaning not at all compliant 😅
## Testing instructions
### Unit tests
> [!IMPORTANT]
> I don't know if these tests are run in CI or if they're picked up by
`zig build test`. I get an unrelated crash that mentions `minidump` and
an invalid OSC command when I try to run `zig build test` on my mac.
1. Make sure `zig test src/os/hostname.zig` is passing.
### Manual testing instructions
#### Setup - Enable the "Private WiFi address" setting
> [!IMPORTANT]
> You must be connected to WiFi to be able to test this.
1. Open your mac's "System Settings".
2. Go to Network → Wi-Fi → Details.
<img width="710" alt="image"
src="https://github.com/user-attachments/assets/fe30cfe7-8e77-4421-8b36-2f7aab0918dd"
/>
3. Set the "Private Wi-Fi address" setting to `Rotating`.
<img width="710" alt="image"
src="https://github.com/user-attachments/assets/bd695c20-106c-46bd-8862-cbdce55fed6f"
/>
> [!IMPORTANT]
> Now you wait. The private Wi-Fi address will eventually rotate to a
mac address that ends with a non-digit, e.g. `0a`, `ff`, `e2`, etc.
You'll notice this when your shell integration stops working, e.g. you
open a new tab in Ghostty and the shell is in your home directory
instead of whichever directory you had open in your previous tab.
#### Testing the changes
1. Open Ghostty.
3. `cd` to any directory that isn't the default (usually `$HOME`)
directory, e.g. `cd Documents`.
4. Open a new tab (<kbd>Cmd+T</kbd>) or split (<kbd>Cmd+D</kbd>).
5. Assuming the setup steps have been followed you should:
* On `main`: land in `$HOME` in the new tab or split.
* On this branch: land in the same working directory as the original tab
or split.
Introduces host resources directory as a new concept: A directory
containing application resources that can only be accessed from the host
operating system. This is significant for sandboxed application runtimes
like Flatpak where shells spawned on the host should have access to
application resources to enable integrations.
Alongside this, apprt is now allowed to override the resources lookup
logic.
This adds a new CLI `ghostty +edit-config`. This will open the config
file in the user's specified `$EDITOR`. If Ghostty has never been
configured, this will also create the initial config file with some
default templated contents (the same as that which we introduced back in
Ghostty 1.0.1 or something -- not new behavior here).
This is useful on its own because it will find the correct configuration
path to open. If users are terminal users anyway (not a big stretch
since this is a terminal app), this will allow them to easily edit
config right away.
This is also forward looking: I want to replace our "Open Config" action
to open a Ghostty window executing this command so that users can edit
their config in a terminal editor. This has been heavily requested since
forever (short of a full GUI settings editor, which is not ready yet). I
don't do this in this PR but plan to in a future PR.
Even further forward looking: when we have an API, we can have
`edit-config` auto-reload the config on exit. This isn't possible today
but this is where we'd put that.
This adds a new CLI `ghostty +edit-config`. This will open the config
file in the user's specified `$EDITOR`. If Ghostty has never been
configured, this will also create the initial config file with some
default templated contents (the same as that which we introduced back in
Ghostty 1.0.1 or something -- not new behavior here).
This is useful on its own because it will find the correct configuration
path to open. If users are terminal users anyway (not a big stretch
since this is a terminal app), this will allow them to easily edit
config right away.
This is also forward looking: I want to replace our "Open Config" action
to open a Ghostty window executing this command so that users can edit
their config in a terminal editor. This has been heavily requested since
forever (short of a full GUI settings editor, which is not ready yet). I
don't do this in this PR but plan to in a future PR.
This PR is a collection of small improvements, cleanup, and fixes to the
renderer, as a follow-up to #7620.
### Summary of changes
- The nearly identical-between-backends `cell.zig` and `image.zig` are
now both unified.
- Shader pipeline preparation is now even DRYer in preparation for
future changes that will involve adding new pipelines, where I don't
want to be slowed down by having to add them in multiple places to get
things working. There is now a single source of truth at the top of
`shaders.zig` for what core pipelines are available and how they're
configured.
- Global background color drawn in a separate step before individual
cell background colors, this is required to be able to draw kitty images
between these layers. Can't use the clear color for this because that
would require color space conversions on the CPU-side which we don't yet
have utilities for.
- Fixed a bug with the kitty image z-index logic where not having
foreground images made the background images act as foreground images.
- Moved the custom shader uniform buffer to the frame state so we don't
create a new one every frame like we were before.
- Fixed color glyphs under OpenGL being channel-swapped because the
texture format was RGBA when the data was BGRA (#7670).
Forgot to change these instances when I renamed rgb(a) to bgr(a), which
was breaking test builds. Also went ahead and fixed some code that was
assuming rgba was actually rgba order and added a note to another part.
Also changes color atlas to always use an sRGB internal format so that
the texture reads automatically linearize the colors.
Renames the misleading `rgba` atlas format to `bgra`, since both
FreeType and CoreText are set up to draw color glyphs in bgra.
In this format it will be a lot easier to iterate on this since adding
and removing pipelines only has to be done in a single place.
This commit also separates out the main background color from individual
cell background color drawing, because sometimes kitty images need to be
between the main background and individual cell backgrounds (kitty image
z-index seems to be entirely broken at the moment, I intend to fix it in
future commits).
The code in metal/image.zig and opengl/image.zig was virtually identical
save for the texture options, so I've moved that to the GraphicsAPI and
unified them in to renderer/image.zig
