[bug] Tauri does not detect system theme preference on Linux

[mirkobrombin]

Describe the bug

In my application I use the prefers-color-scheme media to change the color scheme of my app. It works on Chrome/Firefox/Epipahny (on Linux) but not on Tauri. I tried listening to tauri://theme-changed for what Tauri sees but the result is always light even if dark mode is enabled in GNOME.

Reproduction

1. Make a new Tauri project using V1
2. Listen to tauri://theme-changed for theme changes or directly print the appWindow.theme() promise
3. See that light returns even if a dark theme is active in the system

Expected behavior

I expect it to return dark if the system is using a dark theme.

Full tauri info output

[✔] Environment
    - OS: Linux Unknown X64
    ✔ webkit2gtk-4.0: 2.42.4
    ✔ rsvg2: 2.54.7
    ✔ rustc: 1.77.1 (7cf61ebde 2024-03-27)
    ✔ cargo: 1.77.1 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 18.19.0
    - pnpm: 8.15.5
    - npm: 9.2.0

[-] Packages
    - tauri [RUST]: 1.6.1
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.8
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite

Stack trace

No response

Additional context

For instance, I am using the default theme (Adwaita) in GNOME 44.8. I also managed to reproduce the same issue using Tauri v2.

[i-c-b]

The tauri://theme-changed event isn't supported for Linux as it listens for tao::event::WindowEvent::ThemeChanged.

I wasn't able to replicate the theme detection problem with Adwaita on Ubuntu 22.04.4 (GNOME 42) and Ubuntu 23.10 (GNOME 45) after installing gnome-tweaks to change from Yaru to Adwaita (and Adwaita-dark). In my tests, the dark theme applied correctly.

If possible, can you install neofetch (or an alternative that can read gtk-theme-name) and share what the Theme value is? The value doesn't always match the value set by gnome-control-center, as shown in the screenshots attached to the end of this message.

The WebKitGTK implementation discussed in https://bugs.webkit.org/show_bug.cgi?id=197947 reads the GTK_THEME environment variable or the gtk-theme-name GTK setting and expects a dark theme variant to end with -dark, -Dark, or :dark.

1_light_yaru-light_yaru-light_light 2_dark_yaru-dark_yaru-dark_dark 3_dark_adwaita-light_adwaita-light_light 4_light_adwaita-dark_adwaita-dark_dark

[Megamannen]

Yeah, it checks the "legacy theme" setting. I have dark mode in Gnome 44 but I got light theme in Tauri app until I changed this

[mirkobrombin]

The tauri://theme-changed event isn't supported for Linux as it listens for tao::event::WindowEvent::ThemeChanged.

I wasn't able to replicate the theme detection problem with Adwaita on Ubuntu 22.04.4 (GNOME 42) and Ubuntu 23.10 (GNOME 45) after installing gnome-tweaks to change from Yaru to Adwaita (and Adwaita-dark). In my tests, the dark theme applied correctly.

If possible, can you install neofetch (or an alternative that can read gtk-theme-name) and share what the Theme value is? The value doesn't always match the value set by gnome-control-center, as shown in the screenshots attached to the end of this message.

The WebKitGTK implementation discussed in https://bugs.webkit.org/show_bug.cgi?id=197947 reads the GTK_THEME environment variable or the gtk-theme-name GTK setting and expects a dark theme variant to end with -dark, -Dark, or :dark.

1_light_yaru-light_yaru-light_light 2_dark_yaru-dark_yaru-dark_dark 3_dark_adwaita-light_adwaita-light_light 4_light_adwaita-dark_adwaita-dark_dark

In many recent distributions the GTK_THEME env var is not set.

The theme found by neofetch is Adwaita which does not turn to Adwaita-dark when enabling dark theme in GNOME.

From what I understand, new versions of GNOME (and KDE) now use the freedesktop standard org.freedesktop.appearance.color-scheme to identify the system preference, rather than reading the theme name:

The new preference is defined in the settings portal as the org.freedesktop.appearance.color-scheme key.

xdg-desktop-portal-gnome already implements this key (in the main branch, not in 41), and there are work-in-progress elementary and KDE implementations.

This way it’s not tied to any particular desktop or toolkit — any application can access the settings portal via DBus and read the preference — so applications like Firefox have a canonical location to access the preference from instead of trying to guess it from GTK theme name. Being in the portal also means it’s accessible to Flatpak apps without opening any sandbox holes.

Sources:

• GNOME: https://blogs.gnome.org/alicem/2021/10/04/dark-style-preference/
• KDE: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/52

[jokeyrhyme]

Yep, one approach could be to use the ashpd crate (or bespoke D-Bus bindings maintained in tauri) to ask the Settings portal for the freedesktop.org-standardised color-scheme value, and to also subscribe to changes to the color-scheme value