feat(linux): Add support for system color scheme using xdg-desktop-portal

[haecker-felix]

Use the Linux XDG Desktop Portal to add support for the system color scheme. This works independently of the Linux distribution, desktop environment or toolkit used. If the system colour scheme changes to "dark mode", the window will adjust automatically.

For reference: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html

Screencast.From.2025-08-29.09-30-17.webm

Closes:

• Use the color-scheme XDG portal on Linux for checking if the theme should be light/dark #643
• [bug] Tauri does not detect system theme preference on Linux tauri#9427
• System theme detection for Dioxus Desktop (Linux) DioxusLabs/dioxus#3700

[github-actions]

Package Changes Through 0c2c526

There are 1 changes which include tao with minor

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tao	0.34.6	0.35.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[haecker-felix]

error: package zvariant v5.7.0 cannot be built because it requires rustc 1.77 or newer, while the currently active rustc version is 1.74.1

I downgraded ashpd from 0.12 to 0.7 with the hope that this will make it possible to compile with rustc 1.74. Alternatively, would it be an option to upgrade rustc to something newer?

[FabianLars]

1.77 is fine since that's tauri's msrv

[FabianLars]

the real problem though is the dependence on tokio or smol as we try or tried to keep tao and wry runtime agnostic and using dbus/zbus would also make it harder to get back to winit rust-windowing/winit#1549 🤔

really not sure how to proceed so i'll wait for feedback from the others.

does ashpd require the tokio or async-std feature flag to be enabled or could it work without either as well? (if it requires one i think tokio makes more sense since we use that downstream)

[haecker-felix]

1.77 is fine since that's tauri's msrv

Ah, good to know! But let's wait for others feedback first before making any further changes.

does ashpd require the tokio or async-std feature flag to be enabled or could it work without either as well? (if it requires one i think tokio makes more sense since we use that downstream)

I could switch to tokio, but that would likely require async-compat then, as it's not possible to spawn tokio futures directly from glib. But yes, ashpd either requires the async-std or tokio feature to be enabled.

[FabianLars]

hmm that sucks 😅

[Hofer-Julian]

@FabianLars if the dependency on any async runtime is truly a blocker, we could also directly call the portal with dbus. That would suck though, since we'd basically re-implement parts of ashpd then.

You mentioned that you'll wait for feedback from others, who specifically do you mean?

[FabianLars]

@amrbashir is the closest we have to a tao maintainer though idk how active he is at the moment. If he's unavail or has no opinion we could also ask @lucasfernog and @Legend-Master . If they don't have an opinion either i'll have to follow whatever winit decides/decided on 🤷

[Legend-Master]

ashpd uses zbus underneath the hood and zbus seems to be an async based crate, so unless we use something like dbus-rs and implement the theme settings ourselves (which doesn't seem to be that hard from the ashpd implementation, not sure with dbus-rs though), we'll need an async runtime

If we are going with the async runtime route, I think it'll have to be in feature flags, defaults could be discussed though

[Hofer-Julian]

What would be your preference @Legend-Master?

Reimplement with dbus-rs or using ashpd?

[Legend-Master]

What would be your preference @Legend-Master?

Reimplement with dbus-rs or using ashpd?

I don't know how much work would it take to re-implement it in dbus-rs, if that's manageable then I would prefer that as that makes the API simpler (no need to think about the async runtime when using tao)

[haecker-felix]

Reimplemented using dbus-rs instead of ashpd/zbus 👍

[FabianLars]

sorry i was away over the weekend. we actually deliberately got rid of dbus-rs in the past eg tauri-apps/tauri#6332 so idk how to feel about this. I think i'll pull myself out of this PR (i'm away for 2 weeks anyway).

[haecker-felix]

I will wait with further changes until it is clear what is desired and what is not :/

To summarize, the current available options are:

1. ashpd/zbus + smol runtime (allows reusing of already existing glib main thread / context)
2. ashpd/zbus + tokio runtime
3. dbus-rs (no async runtime, but needs dedicated thread with message passing)

[Legend-Master]

we actually deliberately got rid of dbus-rs in the past

Do you remember the reason for that? (also it seems like tauri currently doesn't depend on dbus nor zbus)

dbus-rs (no async runtime, but needs dedicated thread with message passing)

Personally I would prefer this, but take my opinion with a pinch of salt, I'm not the most familiar with the Linux ecosystem

Also I feel like we shouldn't be as strict as winit when considering these things, that's part of the reason why we branched out right?

And, I'm travelling from 11th to ~25th this month so I probably can't reply between this time period

[FabianLars]

Do you remember the reason for that?

Linked in the PR. basically linking to a system library was a pain 🤷

(also it seems like tauri currently doesn't depend on dbus nor zbus)

correct, a few plugins use zbus (single-instance and notification come to mind)

Also I feel like we shouldn't be as strict as winit when considering these things, that's part of the reason why we branched out right?

to a degree yes, but we're also looking to get back to winit. as long as we still use webkitgtk we still need our own linux backend though (much work on their side going on to make that possible next release(s))

And, I'm travelling from 11th to ~25th this month so I probably can't reply between this time period

Safe travels and have fun :)

[haecker-felix]

Hey folks, I hope you had a great vacation / time off! :)

I wanted to follow up to see if there is any new info on how we are proceeding with this PR so that Linux will get dark mode support as well. I summarized the possible options in #1141 (comment) - let me know what you think.

[FabianLars]

I believe re-introducing dbus-rs should be avoided if possible. Knowing the zbus community we probably would get a PR "fixing" that later on :D

Also whatever we'll use we should put the dependency behind a feature flag.

Speaking of, how about we mirror rfd's approach and offer both zbus-tokio and zbus-smol/async-std ? I'd really love to avoid the latter in tauri downstream (even considering the downsides of the tokio version you mentioned) but it may help other tao consumers not using tauri.

[about winit] as long as we still use webkitgtk we still need our own linux backend though

btw, without this i would have turned down this PR in favor of something downstream (easy to do but obv would keep ThemeChange noop on linux)

[Legend-Master]

Speaking of, how about we mirror rfd's approach and offer both zbus-tokio and zbus-smol/async-std ?

If we can't use dbus-rs here, this would be the preferred way for me as well

[haecker-felix]

I believe re-introducing dbus-rs should be avoided if possible. Knowing the zbus community we probably would get a PR "fixing" that later on :D

Alright, zbus then, no dbus-rs :)

Also whatever we'll use we should put the dependency behind a feature flag.

Just to make sure, if I understood you correctly, I would add a async-std and tokio feature flag, and enable the async-std one by default (to mirror rfd here)? Consumers would need to pick either async-std or zbus then.

[FabianLars]

yep. though i don't care which flag will be the default, we could even have neither in the defaults 🤷

[FabianLars]

it will be enabled on the tauri side (without opt-out probably) which is also why i wanted a tokio option cause that would make the most sense there. my concerns were only about tao (and wry) for those hardcore users (or those building frameworks on top of it like dioxus)

[Hofer-Julian]

I am happy to hear that, seems like we misunderstood your intentions :)

[Hofer-Julian]

Hey @FabianLars!

@haecker-felix made both tokio and async-std opt-in in a7104e7

Is there anything else to be done before we can get this merged? :)

[Andrew15-5]

One nitpick I have is that Cargo.toml now lost its EOL newline at EOF, which is not great for diffs. And it's not even consistent, as the new src/platform_impl/linux/portal.rs file has it. Though I haven't looked at all other files.

[FabianLars]

sorry for the silence here. end of last year and beginning of the new year was an insanely busy time for me. Another reason was that i wanted to see how PolyMeilex/rfd#286 plays out (they removed zbus again).
I'm still pretty busy this and probably next week but will get back to you then. We're not talking about months this time 😅 sorry again.

[FabianLars]

I absolutely hate myself for it but i changed my mind, i'm so sorry for the time you wasted. Can we go back to dbus-rs? Perhaps in a follow-up PR we can do something like rfd and get rid of that as well (but really, in a follow-up! let's get it working first).

Since tao is specifically for tauri which depends on libdbus because of webkitgtk anyway it should be fine to use it here as well. Perhaps behind a default feature though just in case someone needs to disable it.

[Hofer-Julian]

@FabianLars I switched back to dbus-rs. I really hope that this is now the last time we have to do this switcheroo

[FabianLars]

no promises hehe

[Hofer-Julian]

@FabianLars can you please approve the workflow?

[Hofer-Julian]

@FabianLars seems like it's difficult to get this to work without bumping the MSRV. Would you be fine with bumping it from 1.74 to 1.85?

[FabianLars]

sadly not, 1.77 is our current max. I tested felix' old commit 7c04b06 a few days ago and that seemed to work fine. Should we roll back to that? (missing the fix: Emit ThemeChanged events commit tho) Seems like he also copied that to a backup branch https://github.com/haecker-felix/tao/tree/color-scheme-dbus-rs

i think i have a few minutes free some time this weekend so i could do that if you're okay with that approach - would also solve the problem with the unsigned commits 😅

[Hofer-Julian]

i think i have a few minutes free some time this weekend so i could do that if you're okay with that approach - would also solve the problem with the unsigned commits 😅

That would be much appreciated. Let me know if you need help with verifying that it actually works :)

[Hofer-Julian]

Thank you @FabianLars!