Context
On Linux, floem unconditionally pulls in muda with the gtk feature:
# floem/Cargo.toml
[target.'cfg(any(target_os = "linux"))'.dependencies]
muda = { workspace = true, default-features = false, features = ["gtk"] }
muda's gtk feature drags in the whole gtk-rs sys cascade —
gtk-sys, gdk-sys, gdk-pixbuf-sys, pango-sys, atk-sys,
glib-sys, gobject-sys, plus gettext-sys. Each of those has a
build script that calls pkg-config against the host's GTK3 dev
files.
This is the right default for floem apps that want native menu bars
(global app menu on KDE / Unity, in-window menus on GNOME). Layer-shell
overlays, tray apps, single-window utilities — nothing menu-shaped —
inherit the whole cascade just for the link.
Concrete cost
- Cross-compile pain. Cross-target builds for
aarch64-unknown-linux-gnu need an arm64 sysroot with GTK3 dev
files (Ubuntu's :arm64 multiarch off ports.ubuntu.com, since
security.ubuntu.com doesn't serve arm64 indexes). Musl targets
need a hand-rolled glib sysroot.
- Cargo-deny noise. The gtk-rs GTK3 bindings family is marked
unmaintained upstream (RUSTSEC-2024-0412/0413/0415/0416/0418/0419/0420),
so every downstream pikr-style consumer has to ignore those
advisories with rationale.
- Compile time. ~30 extra crates in the dep graph for a feature
the consumer may not use.
Ask
Add a feature flag that gates the muda import (or at least the
gtk muda feature) — something like:
[features]
default = ["menus"]
menus = []
# under [target.'cfg(any(target_os = "linux"))'.dependencies]
muda = { workspace = true, default-features = false, features = ["gtk"], optional = true }
Then consumers that don't render menu bars can opt out:
[dependencies]
floem = { version = "...", default-features = false }
Keeping menus on by default preserves existing behaviour for
everyone else.
Real-world consumer
pikr (https://github.com/kryptic-sh/pikr) — a wlr-layer-shell
launcher built on floem 0.2 (and currently the
mxaddict/floem:layer-shell-port branch on top of current main).
Pikr never opens a menu bar but still inherits the gtk-rs cascade,
which (a) dropped aarch64-unknown-linux-gnu and
x86_64-unknown-linux-musl from its release matrix during the
floem-main migration and (b) requires a cargo-deny ignore list
for the unmaintained gtk-rs advisories.
I'm happy to draft the PR if the feature shape sounds reasonable.
Context
On Linux, floem unconditionally pulls in
mudawith thegtkfeature:muda'sgtkfeature drags in the whole gtk-rs sys cascade —gtk-sys,gdk-sys,gdk-pixbuf-sys,pango-sys,atk-sys,glib-sys,gobject-sys, plusgettext-sys. Each of those has abuild script that calls
pkg-configagainst the host's GTK3 devfiles.
This is the right default for floem apps that want native menu bars
(global app menu on KDE / Unity, in-window menus on GNOME). Layer-shell
overlays, tray apps, single-window utilities — nothing menu-shaped —
inherit the whole cascade just for the link.
Concrete cost
aarch64-unknown-linux-gnuneed an arm64 sysroot with GTK3 devfiles (Ubuntu's
:arm64multiarch offports.ubuntu.com, sincesecurity.ubuntu.comdoesn't serve arm64 indexes). Musl targetsneed a hand-rolled glib sysroot.
unmaintained upstream (
RUSTSEC-2024-0412/0413/0415/0416/0418/0419/0420),so every downstream pikr-style consumer has to ignore those
advisories with rationale.
the consumer may not use.
Ask
Add a feature flag that gates the
mudaimport (or at least thegtkmuda feature) — something like:Then consumers that don't render menu bars can opt out:
Keeping
menuson by default preserves existing behaviour foreveryone else.
Real-world consumer
pikr(https://github.com/kryptic-sh/pikr) — a wlr-layer-shelllauncher built on floem 0.2 (and currently the
mxaddict/floem:layer-shell-portbranch on top of current main).Pikr never opens a menu bar but still inherits the gtk-rs cascade,
which (a) dropped
aarch64-unknown-linux-gnuandx86_64-unknown-linux-muslfrom its release matrix during thefloem-main migration and (b) requires a
cargo-denyignore listfor the unmaintained gtk-rs advisories.
I'm happy to draft the PR if the feature shape sounds reasonable.