search

tauri-apps / tauri

Build smaller, faster, and more secure desktop applications with a web frontend.
https://tauri.app
Apache License 2.0
82.41k stars 2.47k forks source link

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

Open mirkobrombin opened 5 months ago

mirkobrombin commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

bild

mirkobrombin commented 5 months ago

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:

jokeyrhyme commented 5 months ago

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

MatthewScholefield commented 2 months ago

I think this is solved via tauri-plugin-theme right? I tried it and it now automatically follows the theme selector on GNOME.

bukowa commented 2 months ago

Can you check if you have the same problem using vanilla js? (without vue etc.)

mirkobrombin commented 2 months ago

It was a bit of a pain due to javascriptcoregtk-4.0 no more supported in Vanilla OS (and Debian Sid, at least for amd64), anyway I managed to perform a test on a fedora container (which has access to the dbus instance in the host) and the problem still occurs even on a JS vanilla project. I specify that it would be best not to give too much weight to this last test given the particular setup, I can try to test in a VM on a distro that offers that dependency, but not immediately.

Yanyan99999 commented 1 month ago

@MatthewScholefield which tauri version you use, i use tauri 1.5.3 and add tauri-plugin-theme, met issue: .plugin(tauri_plugin_theme::init(tauri::generate_context!().config_mut())) | ^^^^ not found in tauri_plugin_theme just want to ask have you ever met it?

MatthewScholefield commented 1 month ago

@Yanyan99999 See https://github.com/wyhaya/tauri-plugin-theme/issues/13#issuecomment-2300845486

Also though I'm using Tauri 2 which I think most people should start moving to anyways.