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.
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.
GTK4 version 4.16 split the environment variable `GDK_DEBUG` into `GDK_DEBUG`
and `GDK_DISABLE`. This is being done by using the helper function `atLeast` to
handle certain versions accordingly.
`GSK_RENDERER` also only needs to be set in later GTK versions (>=1.14.0).
First, this commit modifies libghostty to use a single unified action
dispatch system based on a tagged union versus the one-off callback
system that was previously in place. This change simplifies the code on
both the core and consumer sides of the library. Importantly, as we
introduce new actions, we can now maintain ABI compatibility so long as
our union size does not change (something I don't promise yet).
Second, this moves a lot more of the functions call on a surface into
the action system. This affects all apprts and continues the previous
work of introducing a more unified API for optional surface features.
This is the way to override the color in libadwaita < 1.6. We can
transition to named colors, specifically headerbar-{fg,bg}-color for
libadwaita 1.6.
Fixes: #2266
Signed-off-by: Tristan Partin <tristan@partin.io>
Notify the user with in-app notifications if libadwaita is available.
Co-authored-by: Paul Berg <paul@ber.gp>
Signed-off-by: Tristan Partin <tristan@partin.io>
