"Auto-night mode" / "Match the system settings" option gone

[WhyNotHugo]

Steps to reproduce

1. Open telegram
2. Go to hamburger > settings
3. Go to chat settings

Expected behaviour

There's no option for dark mode to match the system setting.

Actual behaviour

An option for dark mode to match system setting.

This option used to be around until a few months ago. There's even an issue referencing it here: #26725

I have confirmed that other applications can read the current dark mode just fine. I've also confirmed that the value is properly exposed using:

gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.Settings.Read org.freedesktop.appearance color-scheme

Operating system

Alpine Linux Edge x86_64

Version of Telegram Desktop

4.14.9

Installation source

Other (unofficial) source

Crash ID

no crash

Logs

No response

[ilya-fedin]

It works on top of QGuiApplication::styleHints()->colorScheme(). If it doesn't return a valid result (not Unknown), the switch is hidden. If you have any problems, feel free to report to Qt.

[WhyNotHugo]

It'd unclear to me what I have to report to Qt in this case.

In this a regression on Qt's side? How can I test the return value of QGuiApplication::styleHints()->colorScheme()?

[WhyNotHugo]

Reported as https://bugreports.qt.io/browse/QTBUG-121811

Any extra input is appreciated.

[ilya-fedin]

In this a regression on Qt's side?

I'd guess you have changed your system configuration and Qt doesn't know anymore how to get dark mode state on your system.

It'd unclear to me what I have to report to Qt in this case.

What you expect it to return on your system configuration I guess. They have a rule of avoiding portal as they don't recognize it as a standard (something like that they have told me when I tried to make a change) so you would have to provide them with official API documentation of your desktop environment as they prefer to integrate with such APIs.

[WhyNotHugo]

I'd guess you have changed your system configuration and Qt doesn't know anymore how to get dark mode state on your system.

Nope, nothing has changed on my side. I'm exposing the value via the xdg desktop portal interface. I'm pretty sure that Telegram was using this interface in the past.

They have a rule of avoiding portal as they don't recognize it as a standard (something like that they have told me when I tried to make a change) so you would have to provide them with official API documentation of your desktop environment as they prefer to integrate with such APIs.

I'm not a fan of portals, but they're a de-facto standard, especially on this particular topic.

I use my own tool to handle dark mode, darkman. It exposes its own custom API and also handles the portal API. I guess that if Qt doesn't want to integrate with portals they can integrate with darkman's API, but it's a tool with only a few dozen users, it really sounds like integrating with portals is the ideal thing to do.

[WhyNotHugo]

Yeah, the change that introduced the regression was on Telegram's side. Specifically, 0ffaff2. Previously Telegram read the value from the portal. Now it uses this new Qt's API.

If Qt's API won't use portals, then I think it's a bad idea to use it (at least on Linux). There's no other standard interface for querying this information.

[ilya-fedin]

I'm pretty sure that Telegram was using this interface in the past.

tdesktop has switched to the Qt API as it provides abstraction for every OS and in Linux case provides support for systems with portals which also was requested by some users

I'm not a fan of portals, but they're a de-facto standard, especially on this particular topic.

I've tried to explain that tot hem but failed, Qt is very bureaucratic. I bet they will close your issue because formally it doesn't follows their reporting guidelines (e.g. you're supposed to write a minimal reproducible example and there's a list of supported platforms, Alpine is not one of them). So I do portal improvements in the tdesktop Qt patchset, I bet the static binary that uses the patches would work correctly on your system.

[ilya-fedin]

If Qt's API won't use portals, then I think it's a bad idea to use it (at least on Linux). There's no other standard interface for querying this information.

Well, it's your idea, Qt folks have their own idea and tdesktop has to trust something, trusting Qt sounds like a good idea as that's what tdesktop is built upon. The code seem to work for major environments and minor environments don't sound like a good reason to make the code more complicated.

[WhyNotHugo]

There's nothing Alpine-specific about this issue, because there's nothing distribution specific (e.g.: it's not like musl is messing up).

[ilya-fedin]

My position is such: given that there are lots of differences in Linux, bugs for third party code are accepted only for official builds where third party libraries are under full control and could be patched. If you use a third party build, you have to contact to those libraries directly and reach the consensus with their maintainers, as that's how open source works. Using Qt API here is the best choice as it's pluginable and different environments could use different APIs (the official builds are tweaked for portal+gtk3 combo which provides the best UX, way better than custom portal handling and I won't write my own gtk code for sure) and work even without portals.

[ilya-fedin]

There's nothing Alpine-specific about this issue, because there's nothing distribution specific (e.g.: it's not like musl is messing up).

I remember I used the fact that Pantheon uses portal as argument but they answered me that elementaryOS nor Pantheon aren't supported platforms.

[WhyNotHugo]

If I wrote a standalone library for querying dark mode, would you consider using that instead of Qt's broken implementation?

BTW: the Linux binaries published in the releases page dynamically link a few libraries glibc, so isn't really portable.

[ilya-fedin]

If I wrote a standalone library for querying dark mode, would you consider using that instead of Qt's broken implementation?

It won't handle Windows/macOS I guess. tdesktop build system is also complicated and adding new libraries is not an easy task (one has to tweak build scripts for all the platforms and build libraries statically). Qt is good that it handles any system tdesktop can theoretically run on as that's what makes tdesktop run in first place.

[ilya-fedin]

I guess you can rather just write a custom Qt plugin or try to add portal support to something like qt6ct. As I said, it's good that it's pluginable.

[MikeWalrus]

I've implemented ColorScheme() in https://github.com/MikeWalrus/qt6ct/tree/colorscheme-portal . Telegram's Auto-night mode seems to work out-of-the-box with it.