[woldercraft]

On Linux systems running native Wayland compositors (such as KDE Plasma with Dolphin), winit currently lacks full Wayland drag-and-drop data transfer, preventing files from being dropped onto the window.

This adds an --x11 CLI flag (and FILMCRAFT_X11 environment variable) that configures the event loop builder with b.with_x11() on Linux. When launched via XWayland, file drag-and-drop from Wayland file managers works seamlessly.

[FredApps]

The change is small and follows the existing pattern: the flag is parsed in args.rs, native_options and agent_event_loop take it, and on Linux the event-loop hook calls with_x11(). The winit entry is in the cfg(target_os = "linux") table of apps/filmcraft/Cargo.toml, next to the macOS one, so there is no duplicate key, and eframe already enables x11 on main (Cargo.toml:30), so the feature adds no new crates.

I'm holding this as a comment because it is a second answer to a problem another open PR already solves, and that is a decision for a maintainer:

• #2012 fixes the same Wayland file-drop problem a different way. It makes the Linux desktop app prefer a working X11/XWayland connection by default, falls back to the default backend if there is none, and adds FILMCRAFT_WINDOW_BACKEND=x11|wayland (documented in crates/ui-egui/README.md). This PR instead adds --x11 and FILMCRAFT_X11, both opt-in. The two would give users two overlapping knobs for the same thing. Please agree on one with the #2012 author; if #2012 lands, this one is redundant.
• If this is the one kept: FILMCRAFT_X11 is read with var_os(...).is_some(), so FILMCRAFT_X11=0 and FILMCRAFT_X11= both turn X11 on. Please either parse the value or say in --help that any value enables it. The --help text only mentions the flag.
• --x11 is accepted on Windows and macOS and silently does nothing there (let _ = (agent, x11)). The help text says "on Linux", so this is fine, but it is worth a line in the PR text.
• What happens with --x11 when there is no X server? with_x11() forces that backend, so I expect the event loop to fail to build instead of falling back. Please say what you saw and, if it is an error, whether the message is readable.

There is no test. args.rs has a test module (args.rs:155 on main) that parses flag sets, so a one-line case for --x11 would fit there. I am not asking for it as a blocker.

Hosted CI does not build or test filmcraft, so I'm leaving this as a comment. The drop behaviour itself needs a Wayland session with XWayland, which the pool does not have, so I'm relying on your manual check; please add the compositor and file manager you tried to the PR text.

Validation request (head 80f914155b5902347fa0189a032a824239ece72c):

• os: linux
• commands: cargo fmt --all -- --check; cargo clippy --workspace --all-targets --locked --offline -- -D warnings; cargo test -p filmcraft --locked --offline
• expected: all pass, 0 ignored
• holds: overlap with #2012 (decision for a maintainer); clippy nonminimal_bool on main (#2007) is not caused by this PR