Fixes#2781
This commit contains two separate changes but very related:
1. We update the color scheme state of the app on app start. This is
necessary so that the configuration properly reflects the conditional
state of the theme at the app level (i.e. the window headerbar).
2. We take ownership of the new config when it changes, matching macOS.
This ensures that things like our GTK headerbar update when the theme
changes but more generally whenever any config changes.
And some housekeeping:
- We remove runtime CSS setup from init. We can do it on the first tick
of `run` instead. This will probably save some CPU cycles especially
when we're just notifying a single instance to create a new window.
- I moved dbus event setup to `run` as well. We don't need to know these
events unless we're actually running the app. Similar to the above,
should save some CPU time on single instance runs.
This resolves the toast showing up every time the surface config changes
which can be relatively frequent under certain circumstances such as
theme changes.
The prior light/dark mode awareness work works on surface-level APIs. As
a result, configurations used at the app-level (such as split divider
colors, inactive split opacity, etc.) are not aware of the current theme
configurations and default to the "light" theme.
This commit adds APIs to specify app-level color scheme changes. This
changes the configuration for the app and sets the default conditional
state to use that new theme. This latter point makes it so that future
surfaces use the correct theme on load rather than requiring some apprt
event loop ticks. Some users have already reported a short "flicker" to
load the correct theme, so this should help alleviate that.
Related #2755
From the mode 2031 spec[1]:
> Send CSI ? 2031 h to the terminal to enable unsolicited DSR (device status
> report) messages for color palette updates and CSI ? 2031 l respectively to
> disable it again.
>
> The sent out DSR looks equivalent to the already above mentioned. This
> notification is not just sent when dark/light mode has been changed by the
> operating system / desktop, but also if the user explicitly changed color
> scheme, e.g. by configuration.
My reading of this paired with the original discussion is that this is
meant to be sent out for anything that could possibly change terminal
colors.
Previous to this commit, we only sent out the DSR when the actual system
light/dark mode changed. This commit changes it to send out the DSR on
any operation that _may_ change the terminal colors.
[1]: https://contour-terminal.org/vt-extensions/color-palette-update-notifications/#example-source-code
Fixes#2745
GTK uses a delayed surface initialization since we initialize on
GTKGLArea realize not on the actual callback. Because of that, our
inherited directory doesn't always work since that depends on a
previously focused widget.
This copies our desired inherited directory to an allocation so that we
can set it during realize.
adw_application_window_destroy and gtk_application_window_destroy do not
exist. I believe that this didn't trigger a compile error because the
errdefer got compiled out because there are no potential error returns
after this code in the function.
Rather than storing a list of errors we now store a list of
"diagnostics." Each diagnostic has a richer set of structured
information, including a message, a key, the location where it occurred.
This lets us show more detailed messages, more human friendly messages, and
also let's us filter by key or location. We don't take advantage of
all of this capability in this initial commit, but we do use every field
for something.
This takes advantage of CSS variables and color expressions to improve
the `window-theme=ghostty` support. The only visibile difference from
the previous implementation is that the header bar will darken if the
Ghostty window is in the background, which is standard for GTK apps.
This is conditional at runtime. If Ghostty detects that you're running
against GTK 4.16 or newer it will use the CSS variables and color calcs.
If you're running against older versions it will use CSS classes to
achieve nearly the same effect.
This simplifies the math for calculating scroll vectors based on mouse
scroll events. This was done to fix inverted horizontal scrolling on
macOS with natural scrolling enabled. Many assertions were added for
assumptions and our preconditions are clearly documented.
The preconditions are:
* Apprt scroll offsets are negative down/left, positive up/right
* Terminal vertical scroll is postive down, negative up (opposite
since scroll for a terminal means how many rows to move down).
* `Surface.scrollCallback` is always call with an apprt offset.
* Apprt is responsible for implementing natural scrolling. Surface
always assumes negative is down/left.
macOS 12 is officially EOL by Apple and the project only supports
officially supported versions of macOS. Once publicly released, users on
older macOS versions will have to use older released builds.
