-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Theme mode API #1549
Comments
I did some research on detecting light/dark mode on linux. Basically, you have to get the current theme, and see if it ends in
As you can see, it's kinda a mess. I would either:
|
I'm unsure how useful just detecting if using a 'dark theme' would be on KDE (and perhaps Gnome and related ones?). A theme can be anything, and there are ones that even do odd things like have a dark style system but really bright windows that are well used. The proper way would be to read the actual theme data and use or at least expose to the user the proper theme values for things like background color and text color and the 200+ other settings. As I recall Windows also had very detailed theme settings like that as well. Just having dark or light mode would not be sufficient to be able to make something that 'fits in'. Even just among, say, dark themes some use a dark slate gray like I do, some use a very dark blue like my wife, some use a very dark purple like a friend of mine, etc... In addition KDE (and I'm pretty sure Gnome as well) can set per-application or even per-window themes (fantastic for, say, running things as root or distinguish window themes based on whether related for work or play or so). And don't forget that theme changes can happen in real-time with KDE as well. |
Here's my proposal for how to determine light/dark (And I agree the event should always be sent on startup):
As you can see, for Linux there is no good option. At best, you can support a subset of desktop environments (too many to maintain support for realistically), and when not sandboxed. |
I've just found out about https://github.com/elementary/os/wiki/Dark-Style-Preference, which looks like it would be perfect. Desktops set prefers dark/light, and then apps get notified when it changes, and choose whether to render with a dark, light, or other theme. Unfortunately, only elementary os supports it right now, as it's not an official spec. |
An update on this:
Where the system API exists, winit should return Apps are free to follow the system preference or ignore it, it's only a preference. |
Just for some information on the |
Can we have the API to force a dark/light mode from application itself? Or even better a way to provide own colours for decoration. |
I assume you're talking about macOS/Windows decorations. Linux (wayland) has no standard decorations - you have to draw them yourself, so you could make them anything you want. Someone with more knowledge of the relevant platform API's would have to comment on whether it's possible or not. |
There is a dark-light crate which does only this. Linux support is in progress using the new XDG Desktop Portal dbus API with fallbacks to checking if the theme name has "dark" in it. I propose considering removing ThemeChanged from winit's public API. This is not trivial to implement cross platform and seems to me to be tangential to the purpose of winit. Dark versus light mode is a system setting, not a per-window setting, even if Windows exposes it in its windowing event loop. |
A problem with the |
There is an open issue for providing a callback to notify of changes to light/dark mode in dark-light. |
I'll get on that as soon as I'm done with this 👍🏼 |
interesting that winit considered this feature in scope. the flutter engine also provides access to other related options that winit may want to expose in the future too (although I've not looked into how it's implemented for each platform):
which together with
also related is a LocaleChanged event. |
Yes, will this issue provide the ability to force light or dark modes for applications that use winit? I created this Alacritty issue asking to set light or dark at the application level rather than just using the global desktop preference. In my case I use a light desktop but I much prefer a dark theme just for the terminal. The Alacritty maintainer (@chrisduerr) referred to this upstream issue since it appears Alacritty can't set light or dark on macOS or Windows by itself. Hopefully this issue will look at Best regards. |
The proper way to check for dark / light is via an XDG portal call. https://flatpak.github.io/xdg-desktop-portal/
Then there is a signal for SettingsChanged and you can sync with that. Doc
|
In Linux, with freedesktop portal supported, the color theme preference as well as changes can be detected using zbus. |
Using side channels like dbus is out of scope as of now. |
Can you elaborate how its a side channel? FreeDesktop portals are the DE-independent standard for this type of GUI interaction/requests. |
dbus is a side channel, it's coming from neither Wayland nor X11 directly. You can use it in your code just fine without any help from winit. |
Just FYI, there's an open PR that implements a way to provide a closure to handle changes in the color scheme. |
The (minimal) documentation for
WindowEvent::ThemeChanged
does not clarify whether apps should query the theme on startup or simply wait for aThemeChanged
event.From a quick look at the code, I think the only way to determine the theme at startup is via a platform-specific
is_dark_mode
function. This is problematic in three ways: (1) lack of documentation, (2) API is only partially cross-platform, (3)is_dark_mode
has a completely different (and less flexible) API toThemeChanged(theme)
.Suggestion 1: always send
ThemeChanged
on start if the theme is notTheme::Light
(or whatever the default theme is called), and document this.Suggestion 2: add a
Window::theme
method.Related: #1217
The text was updated successfully, but these errors were encountered: