Open X-m7 opened 1 year ago
Also, using the portal to check the light/dark preference also means that apps will be able to respond immediately to the user switching between light and dark modes, while with the current method changing the GTK theme requires a restart of the apps.
This is not true... I believe Firefox/Chromium also uses only GTK themes.
If we decided to use XDG portal color-scheme, does that mean users have to install xdg-desktop-portal-*
on their system. That is a overhead, IMO.
I believe Firefox/Chromium also uses only GTK themes.
Firefox responds to my changing the colour scheme on KDE without changing the GTK theme (this effect is visible with the Alpenglow theme for example), so no it doesn't rely only on the GTK theme.
If we decided to use XDG portal color-scheme, does that mean users have to install xdg-desktop-portal-* on their system.
That is already a necessity for anyone using Flatpak and Snap applications (so they can do things like open files without having to give them access to the entire system), as well as anyone wanting to do things like screen recording on Wayland (at least without apps needing to use private compositor specific APIs).
I think the ideal solution would be to prefer using the portal if it is present and a preference has been set (in case either the portal does not exist or the portal backend does not have support for that preference), and otherwise use the current method with the GTK theme name.
Firefox should respect your GTK theme settings and your OS-wide dark appearance settings (as in the Appearance section of GNOME's settings or KDE system settings). If the latter does not work, make sure to have a suitable xdg-desktop-portal package installed.
https://wiki.archlinux.org/title/Firefox#Dark_themes
My mistake. Just checked Archwiki. Quoted above.
Currently as I understand it TAO checks the current GTK theme to see if it contains "dark" in the name, however now there is a way to ask the desktop environment using XDG portals and D-Bus. The protocol was added here, and GNOME has provided documentation on how to use it here (specifically see the "Other" section, which has example code written using C, SDL and GDBus/GIO, while the other sections assume libadwaita or libhandy is used).
The advantage of this method is that starting in GNOME 42 and elementaryOS 6 there is a global light/dark theme selector in their settings apps, which does not change the selected GTK theme, so only apps that check the portal setting will be able to follow that global light/dark preference. KDE Plasma also has such a light/dark setting, although ultimately the reported value from the portal is calculated using the selected colour scheme.
Also, using the portal to check the light/dark preference also means that apps will be able to respond immediately to the user switching between light and dark modes, while with the current method changing the GTK theme requires a restart of the apps.