Mode 2031 reports light when using a non-conditional theme despite a dark GTK color scheme #13448
Replies: 2 comments
|
Update: I managed to find the source of the issue. With an isolated Ghostty (debug build) instance launched using: ghostty --config-default-files=false --window-theme=darkGhostty's GTK log correctly reports: However, querying the current color scheme with which indicates light mode. I was able to narrow this down further by configuring an actual conditional theme pair: theme = light:Rose Pine Dawn,dark:Rose PineWith that configuration, the same query correctly returns: The issue appears to be in theme = Kitty Defaultdoes not add The surface and GTK runtime therefore know that the color scheme is dark, but the configuration copied into Termio retains its default The following minimal patch treats the theme state as relevant even when the configured theme itself is not conditional, and updates the existing test accordingly: diff --git a/src/config/Config.zig b/src/config/Config.zig
--- a/src/config/Config.zig
+++ b/src/config/Config.zig
@@ -4416,7 +4416,7 @@
// Conditional set contains the keys that this config uses. So we
// only continue if we use this key.
- if (self._conditional_set.contains(key) and !deepEqual(
+ if ((key == .theme or self._conditional_set.contains(key)) and !deepEqual(
@TypeOf(@field(self._conditional_state, field.name)),
@field(self._conditional_state, field.name),
@field(new, field.name),
@@ -10587,7 +10587,7 @@ test "changed" {
try testing.expect(!source.changed(&dest, .@"font-size"));
}
-test "changeConditionalState ignores irrelevant changes" {
+test "changeConditionalState preserves non-conditional theme state" {
const testing = std.testing;
const alloc = testing.allocator;
@@ -10600,9 +10600,12 @@ test "changeConditionalState ignores irrelevant changes" {
try cfg.loadIter(alloc, &it);
try cfg.finalize();
- try testing.expect(try cfg.changeConditionalState(
- .{ .theme = .dark },
- ) == null);
+ var cfg2 = (try cfg.changeConditionalState(.{
+ .theme = .dark,
+ })).?;
+ defer cfg2.deinit();
+
+ try testing.expectEqual(.dark, cfg2._conditional_state.theme);
}
}I changed the existing The drawback is that this replaces the test coverage for the original optimization, where genuinely irrelevant conditional-state changes should still return This was reproduced against commit 6687d60. |
Uh oh!
There was an error while loading. Please reload this page.
Issue Description
Opening Flow Control editor which supports Mode 2031 and looking at the log shows that Ghostty is reporting the system theme as being in light mode. I am on KDE using dark mode (and this is reflected in the gtk4 config files). This issue does not occur with Kitty and other terminals with said support. The Flow maintainer said this was likely a Ghostty and/or issue, but I have found nothing wrong with the gtk config created by KDE thus far.
Any help would be appreciated!
Original Flow Issue
Other Potentially Relevant Issues/Discussions:
#8906
#7404
Expected Behavior
Ghostty should report the proper theme mode.
Actual Behavior
Ghostty only reports light mode.
Reproduction Steps
Ghostty Logs
Ghostty Version
OS Version Information
CachyOS Linux
(Linux only) Display Server
Wayland
(Linux only) Desktop Environment/Window Manager
KDE Plasma 6.7.3
Minimal Ghostty Configuration
Additional Relevant Configuration
No response
I acknowledge that:
```) on separate lines.All reactions