Closes https://github.com/ghostty-org/ghostty/issues/4089
Gave it a shot and implemented the custom css loading.
My general idea is to use a provider for each stylesheet the user wants
to load and then when the config changes unload them and create new
providers.
A separate provider has to be used for each stylesheet the user wants to
load, since when the provider loads the css it clears all the previously
loaded styles, so in effect we cannot use one provider to load multiple
stylesheets, but maybe there is a better way to overcome this limitation
which I'm not seeing.
On my system (pop-os 22.04 LTS) with system theme and seperate light and
dark themes, ghostty always defaults to light mode. Switches between
light and dark mode are properly handled.
In the logs this error is reported:
error(gtk): unable to get current color scheme:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method
“ReadOne”
The spec notes that the other functions are "[Deprecated, use ReadOne
instead.](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html)"
so using ReadOne is cerainly the correct path.
I've managed to fix this on my system by checking for the error and
falling back to an implementation using the deprecated Read.
Discussion: https://github.com/ghostty-org/ghostty/discussions/3704
Issue: https://github.com/ghostty-org/ghostty/issues/4038
Before this change, there seemed to be some artifacting in the window
corners due to the window border no longer outlining the content
properly. By detecting the situation, we can turn the window border
radius off.
Signed-off-by: Tristan Partin <tristan@partin.io>
This gives people finer-grained control over the coloring of their
window titlebars. Currently only implemented for GTK.
Signed-off-by: Tristan Partin <tristan@partin.io>
This looks better than the regular dark color. It also happens to match
what Ptyxis does. It does not support non-libadwaita builds.
Signed-off-by: Tristan Partin <tristan@partin.io>
This backs out commit bb185cf6b695420ce8b43b5c1cadd16ef71c481a.
This was breaking IME input for some users and overall I couldn't find
other users where this really fixed anything other than me so I'm going
to back this out and fix this using my own system.
I'm unsure if this is an environmental issue just for me or if this is
more widespread or what other downsides this may have. I'm more than
willing to revert this if it ends up causing different issues.
I found that with NixOS 24.11 and GTK 4.14 on my system, the default
Wayland GDK backend fails to initialize EGL. With GTK 4.16 everything
is fine.
If I force X11 then everything also works fine. This commit forces X11
for GTK 4.14 specifically (4.16+ is allowed to use Wayland).
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.
