[Feature Request] org.freedesktop.appearance.color-scheme support to read dark mode preference

[vimpostor]

Currently the "Follow global dark theme preference" switch on Linux uses an unreliable implementation.
Recently the org.freedesktop.appearance.color-scheme key got standardized across all DEs, which should be more reliable. It would be cool, if Telegram supported reading this setting and super cool if it could subscribe to its changes during runtime.

Useful links:
Gnome blog post
Spec
KDE initial implementation + proper implementation

[ilya-fedin]

Finally. I'm tired of this dancing with DE-specific keys.

[ilya-fedin]

Well, I implemented that locally, but I will push only when it would be possible to test how it works. Basically, that means 'after support of this preference will land to my desktop'. I have MATE on NixOS on host and a VM with KDE Neon. So, that means a MATE release with that feature in NixOS or a KDE release with that feature in KDE Neon.

[carnage-mode]

@ilya-fedin I think you can use https://gitlab.gnome.org/exalm/color-scheme-simulator to test the feature

[ilya-fedin]

Excellent. But there's another problem: IsDarkMode has four implementations and it's already big. I don't really want to add a fifth implementation. And I can't remove the others since I don't feel this spec will have a big adoption outside of GNOME & KDE since it's portal-based.

[carnage-mode]

Are those four implementations cross platform or Linux specific?

[ilya-fedin]

Are those four implementations cross platform or Linux specific?

Linux-specific. Both win/mac platform files have only one implementation of IsDarkMode. The Linux one has four implementations.

[carnage-mode]

Well GNOME and KDE account for the vast majority of Linux. Plus most other Linux DE's don't have their own app ecosystems, they use apps from those two. The only other app ecosystem is elementary, and they already follow the preference elementary/settings-daemon#38 (Telegram's dark mode doesn't really work on elementary rn). I think removing all the other implementations is safe choice. If that doesn't work, reducing the number of implementations and adding org.freedesktop.appearance.color-scheme could.

[ilya-fedin]

Sorry, but that sounds like a marketing bullshit. Since I'm not in the majority here, don't expect I'll remove these implementations.

[carnage-mode]

Fair enough 👍

[vimpostor]

IsDarkMode has four implementations and it's already big. I don't really want to add a fifth implementation.

The clean way would be to make an upstream Qt patch, such that QGuiApplication::paletteChanged triggers with the new key.
However I am also calling bullshit here and fail to see why adding the new key and keeping the 4 other methods as fallback would be a problem. Worst-case scenario you can remove the most unreliable of the 4 methods and replace it with the new one.

I don't feel this spec will have a big adoption outside of GNOME & KDE since it's portal-based.

Then the other DEs should implement Portal.

[ilya-fedin]

The clean way would be to make an upstream Qt patch

The feature will reach in multiple years to tdesktop, then. There's no updates for Qt 5 and there's no plan to migrate to Qt 6 in near future.

However I am also calling bullshit here and fail to see why adding the new key and keeping the 4 other methods as fallback would be a problem.

Well, this wouldn't be a problem if someone refactor the code. I don't want to do this right now.

Then the other DEs should implement Portal.

That's not how reality works. In the real world, you have things like anti-dbus cult, DEs that release once in multiple years, the lack of knowledge that new APIs appeared, no plans to implement them in near future and etc. I have a feel MATE/Xfce/LXQt won't have support for that.

[ilya-fedin]

So I finally managed to test with https://gitlab.gnome.org/exalm/color-scheme-simulator. It works. Will look at how KDE implementation lands, looks like it's still not merged. When it lands to a release KDE version, it would be possible to replace Gtk/Wayland (no gtk DEs except of GNOME exist on Wayland and Qt defaults to XWayland on GNOME, so the impact should be minimal) and KDE implementations with this one. But looking at the code in KDE review, their implementation doesn't seem to be good enough: tdesktop checks for color of the window backgroud, while their implementation checks for BreezeDark in color scheme name. I hope there's not so much KDE users using auto-night mode in Telegram. I have a feel this wouldn't work good anywhere outside of GNOME world.

[vimpostor]

I agree, the current state of the pending KDE implementation is a disaster, but I am pretty sure it will be implemented properly for whatever release it lands in.

[vimpostor]

their implementation checks for BreezeDark in color scheme name. I hope there's not so much KDE users using auto-night mode in Telegram. I have a feel this wouldn't work good anywhere outside of GNOME world.

KDE has now properly implemented dark mode detection: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/52
So this argument should no longer be valid.

Note that this will only make it into KDE 5.24, which will release Thu 2022-01-20, so next year - plenty of time for us to implement this :)