feat(desktop): make libxdo opt-in on Linux via linux-libxdo

[nabbisen]

Problem

libxdo is a default feature of both muda and tray-icon, so dioxus-desktop links libxdo.so into every Linux desktop app. muda documents the feature's entire purpose:

libxdo is used to make the predefined Copy, Cut, Paste and SelectAll menu items work.

An app that never uses those items — including any app that calls .with_menu(None) — still hard-links the library.

That is normally just an extra build prerequisite, which is how it usually gets reported (#5090, #2219). The sharper consequence is at distribution time, and I haven't found it written down anywhere:

The soname is recorded at link time, so a release binary built on ubuntu-latest records libxdo.so.3. Ubuntu ships soname 3; Arch and other rolling distros ship 4. The dynamic loader will not substitute one for the other, so:

$ ./myapp
./myapp: error while loading shared libraries: libxdo.so.3: cannot open shared object file

Installing xdotool does not fix this — the user already has libxdo.so.4. There is no supported way to get soname 3 on those distros, so a prebuilt Linux artifact simply cannot run there, over a library the app never calls.

I hit this shipping a Dioxus app: of the binary's 146 dynamic dependencies, exactly one was unresolvable. GTK 3 and WebKitGTK 4.1 record identical sonames on both distro families and are fine; libxdo is the only one that skews.

Change

Mirrors what Tauri already does — tauri/Cargo.toml declares muda and tray-icon with default-features = false and exposes linux-libxdo as opt-in, since v2.0.0-alpha.11. Same crates, same maintainers, same reasoning.

• muda and tray-icon are declared with default-features = false
• gtk is kept explicitly on both — that is what actually renders menus and tray icons on Linux
• a new linux-libxdo feature restores the old behaviour for apps that use the predefined menu items

Verification

In this branch's own workspace:

$ cargo tree --manifest-path packages/desktop/Cargo.toml -e normal | grep -c libxdo
0

$ cargo tree --manifest-path packages/desktop/Cargo.toml -e normal --features linux-libxdo | grep libxdo
│   ├── libxdo v0.6.0
│   │   └── libxdo-sys v0.11.0

I also applied the equivalent change to dioxus-desktop 0.7.9 via [patch.crates-io] and rebuilt a real application against it:

• readelf -d shows no libxdo entry, where the unpatched build recorded libxdo.so.3
• libxdo-sys leaves the dependency graph entirely
• GTK 3 and WebKitGTK 4.1 are still linked
• the app launches and renders normally on a machine with no libxdo.so.3 present

Notes

This is a breaking change only for apps that rely on the predefined Copy/Cut/Paste/SelectAll menu items on Linux; they need features = ["linux-libxdo"]. Apps already passing default-features = false to dioxus-desktop pick up the fix with no change. Happy to add a CHANGELOG entry or adjust the feature name if you'd prefer it match something else.

[nicoburns]

Makes sense - thanks!