vslavik
commented
1 year ago Overview here: https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/ Implementation tips here: https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference
This is useful information, thanks!
(without just trying to "guess" whether the current GTK theme is dark or not)
I'll note that Poedit is not trying to determine user preference, which is irrelevant, but is making a decision on what custom colors to use that won't conflict with the current theme. And while there may be corresponce between user preference and what GTK+ is configured to present to Poedit as the theem, they may also be not.
IOW, it is correct to look at the theme and not any user preference. And while Poedit's logic may be poor, I quite like the observation from https://lzone.de/blog/Detecting-a-Dark-Theme-in-GTK: that is, text and bg colors must be high-contract and so if text is brighter, the theme is dark. That seems rather fool-proof.
[...preaching snipped...]
A patch with improvements (probably to wxWidgets) would be more useful that this lecture, though. As it is, it is unclear why you even filed this issue — Poedit does the right thing already.
Nowadays there is a standardized way for your app to authoritatively know (without just trying to "guess" whether the current GTK theme is dark or not) what the user's intent is in terms of light/dark themes, from a global desktop preference perspective.
Most applications already support this with GNOME 42+ and Elementary OS 6, even non-purely-GTK applications such as Firefox. I believe lots of applications on KDE support this standard as well.
Knowing "what the user actually wishes for" lets your app switch between the two styles in realtime with a clear standardized signal, and if also lets it confidently ship its own harmonized colors/stylesheet for both light/dark scenarios if needed.
Why is the realtime aspect important? Because users can configure their desktop environment to automatically switch between light and dark mode depending on the time of the day, whether by using an extension or natively (eventually); plugging into this standard lets your app conform to this system change "as it happens".
Text-heavy apps can let the user decide if they want the app to remain light (or dark) at all times or if they want it to follow/inherit the light vs dark status from the OS. Simple apps that don't have fancy stylesheets (unlike source code text editors) can simply offer the choice between: "Follow system's preference", "Always light", or "Always dark".
On the desktop side, an example of a commonly used UI for this in GTK and GNOME apps is the screenshot you can see here: https://github.com/mjakeman/extension-manager/issues/218 (otherwise I guess you could have a GtkComboBox widget with values such as "Automatic" (or "Follow system"), "Always light" and "Always dark").
Or, if you want to simplify your codebase by reducing settings, you may choose to have the app only follow the system dark/light preference at all times.