We could maybe change https://github.com/telegramdesktop/tdesktop/blob/9604a3bd800f34188a5b7679f2f241513a47babc/Telegram/SourceFiles/platform/linux/specific_linux.cpp#L463 to #if 1 and https://github.com/telegramdesktop/tdesktop/blob/9604a3bd800f34188a5b7679f2f241513a47babc/Telegram/SourceFiles/platform/linux/integration_linux.cpp#L214 to #if 0 to bring back the old behavior...

If I run Telegram like this:

> QT_QPA_PLATFORMTHEME=xdgdesktopportal telegram-desktop

I do get the option back in the chat settings. Could that be a solution? To use that launch command if the optional dependency `xdg-desktop-portal` is installed?

Ugh, never mind. I get the option back to being visible in the settings, but enabling the option doesn't actually trigger the dark/light theme change on dark/light mode switching.

Yes, because that requires a qt patch as in https://github.com/desktop-app/patches/commit/dbd8a5b00f5a0e7e09b11878b9e46afeb4b593c0 , as mentioned in https://github.com/telegramdesktop/tdesktop/commit/07bbfd13537033d727e650dcc2c17e79a43d7486 .

So in all honesty, I don't know if I understand fully yet. Is this something we can expect to be fixed in QT in the not-so-distant future, or do we need to patch this for the foreseeable future? Thanks, and sorry if this isn't the "ask questions" kind of medium.

We are not going to patch Qt with unofficial patches from third party projects. It is upstream's responsibility to get their changes merged in Qt. If someone relies on features that require a patched Qt, they should switch to flatpak for now.

We could maybe patch telegram instead like I mentioned in the first comment?

Alternatively, those who want to get this working now using extra/telegram-desktop could use a platform theme that provides the necessary code for dark mode switching to work, e.g. qgnomeplatform (which unfortunately has just been dropped from the official repos).

I've switched to flatpak for now, because I get flash-banged every time I open Telegram at night these days. x_x Thank you for your replies! I'll keep an eye on the conversation here though, because ideally I'd just like to use the Arch package. <3

We tried a static patched version of qt once but it gave us all kinds of other issues. I'm really not sure what the best way forward would be here.

I would just patch telegram instead...

Perhaps, if that is maintainable over longer periods of time. Care to make a patch against the current package?

Beware that this is untested though, as I do not yet have the resources to build tdesktop.

Patching tdesktop would get rid of xsettingsd dark mode support (with QT_QPA_PLATFORMTHEME=gtk3). Why patching tdesktop and getting rid of the advantages of Qt plugin architecture when you can encourage developers of such plugins like qt6ct to support this feature? That's against Arch Linux philosophy after all.

Ilya, it was my assumption that you guys already tried to upstream this but somehow upstream didn't take it and as such you patched Qt6 downstream. If this hasn't happened yet, we could try to get the ball rolling from Arch but generally speaking, it'd be better if application developers communicated their needs directly with the toolkit devs. Distros are just the ducttape/middlemen.

Well, it's not a proper fix to be upstreamed, the proper fix would be for Qt to watch for portal changes. I'm also afraid submitting the None == Light mapping cause all the bureaucracy they have. My personal hope is that the initial implementer (https://codereview.qt-project.org/c/qt/qtbase/+/396655) will step up and finish the implementation. Personally I'm tired of their bureaucracy for a while, so don't expect me to upstream anything that big in near months. You can also try to report this to Qt bugtracker and mass-upvote the report so maybe they will prioritize this and fix in a way they would like.

The current situation doesn't look that bad for me: the gtk3 plugin supports this properly and qt6ct could get an implementation if someone would actually care.

> the gtk3 plugin supports this properly

In my testing w/ extra/telegram-desktop and `QT_QPA_PLATFORMTHEME=gtk3` dynamic switching works both ways when tdesktop was started in light theme, but when tdesktop was started in dark theme it doesn't work at all, maybe it's a bug in tdesktop somewhere?

QT_LOGGING_RULES=qt.qpa.gtk.debug=true should show what Qt thinks about your color scheme

OK the reason for that seems to be gtk-application-prefer-dark-theme=1 in my gtk-3.0/settings.ini, which is of course not reloaded when the system theme changes. Removing that line fixed dynamic switching with the gtk3 platform theme, but 1) the GNOME control center dark mode toggle does not change the gtk3 theme 2) the gtk3 platform theme forces the gtk3 filechooser which does not have grid view, unlike the gtk4 x-d-p-gnome or other portals like -lxqt or -kde.

Now, my two cents:

Short term we can patch telegram to optionally force the old behavior via a runtime env var instead of a build time switch, or we can package qgnomeplatform for a bit longer and tell people on GNOME to use that instead.

Long term, ideally a portal listener could be upstreamed (there's already one in https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp?ref_type=heads, maybe it can be somehow reused?) But unknown->light should still be handled inside telegram, though I'd say that the portal platformtheme shouldn't fallback to the base theme in the case of None.

Qt::ColorScheme::Unknown is documented as "The appearance is unknown." and so handled accordingly (unsupported -> the checkbox is hidden)

The portal's no-precedence (-> None -> Unknown) has another meaning: use app's default mode. There's no 1:1 mapping in Qt.

Mapping Unknown as Light on Telegram level will lead to problems when there's no portal and on other platforms without system dark mode support.

> there's already one in https://invent.kde.org/qt/qt/qtbase/-/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp?ref_type=heads, maybe it can be somehow reused?

Yeah, it's a weird one, they create a listener but never use it. I created QTBUG-116197 a while ago about that but given their philosophy of highly relying on XDG_CURRENT_DESKTOP it might be that xdgdesktopportal will never be used outside of flatpak/snap and this QGenericUnixTheme may never evolve. A way forward might be for someone to contribute a GTK4+libadwaita QPT to support these modern GNOME things.

For now, the gtk3 QPT behavior is the intended one from their PoV, even if you don't like it.

> Short term we can patch telegram to optionally force the old behavior via a runtime env var instead of a build time switch, or we can package qgnomeplatform for a bit longer and tell people on GNOME to use that instead.

Or you can create a small custom QPT. Or you can add support to qt6ct. Such won't be that small anymore and all the other options don't require patching.

*Such patch