fix: stop file dialogs failing silently on portal-less Linux setups#97
Open
Zeus-Deus wants to merge 2 commits into
Open
fix: stop file dialogs failing silently on portal-less Linux setups#97Zeus-Deus wants to merge 2 commits into
Zeus-Deus wants to merge 2 commits into
Conversation
) The Linux dialog backend is portal-only (tauri-plugin-dialog with the xdg-portal feature; rfd falls back to spawning zenity when the portal call fails). On minimal window-manager setups (i3, dwm) with neither installed, every picker resolved None exactly like a user cancel, so Open Project and the new-project Browse button did nothing, with zero diagnostics: no Rust logger was installed, so rfd's log::error! output vanished too. - dialog_preflight.rs: probe the portal FileChooser version property over zbus plus PATH for zenity before every dialog command; return a marker error (NO_FILE_PICKER_BACKEND) with install instructions when neither backend exists - src/lib/file-dialog.ts: route all UI picker call sites through never-throw wrappers that turn the marker into an actionable toast and resolve like a cancel (settings export/import sites already surface errors inline) - tauri-plugin-log: warn+ to stderr and a rotating app-log-dir file so dependency failures are visible from a terminal - new CLI: codemux logs [--tail n] and codemux doctor, both fully local so they work when the app itself is misbehaving - dev mock: sessionStorage flag simulates the failure for visual toast verification under npm run dev - tests: env-isolated preflight integration test, file-dialog vitest suite, app_logs tail unit test; verified end-to-end in a clean Arch container with only the package runtime deps (doctor reports the failure with the install hint, passes after installing zenity) and on a portal-equipped host - package-lock.json: sync version field missed by the 0.9.0 bump The AUR PKGBUILD gains xdg-desktop-portal + xdg-desktop-portal-gtk as hard depends and zenity as optdepends at next release.
… test resolve_binary() step 1 prefers an agent-browser on PATH, so on any machine running a packaged Codemux (/usr/bin/agent-browser) the resolve_binary_finds_native_binary_from_project_root test failed by asserting the node_modules binary name against the system path. Accept the legitimate system-install resolution and keep the node_modules assertion for hosts without one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #95
Problem
On minimal window-manager setups (reporter: Arch + i3), clicking Open Project or the new-project Browse button did nothing. The Linux dialog backend is portal-only (
tauri-plugin-dialogwith thexdg-portalfeature; rfd falls back to spawningzenitywhen the portal call fails). With neither the XDG desktop portal nor zenity installed, the dialog resolvedNoneexactly like a user cancel, so the UI silently no-oped. Diagnostics were impossible: no Rust logger was installed, so rfd'slog::error!output vanished, and release builds ship without the inspector.Fix (four layers)
src-tauri/src/dialog_preflight.rsprobes the portal'sFileChooser.versionproperty over zbus (already in the tree via rfd → ashpd) pluswhich zenitybefore every dialog command, and returns a marker error (NO_FILE_PICKER_BACKEND) with install instructions when neither backend exists.src/lib/file-dialog.tswrappers, which turn the marker into an actionable toast (install xdg-desktop-portal-gtk or zenity) and resolve like a cancel. The settings export/import sites already surface errors inline.tauri-plugin-lognow writes warn+ to stderr and a rotating~/.local/share/com.codemux.app/logs/codemux.log(2 MB cap), so dependency failures are visible from a terminal.codemux logs [--tail n]andcodemux doctorcommands, both fully local (no running app needed).doctorreports desktop/session info, portal/zenity availability, and the log file location — future reports become "runcodemux doctorand paste the output".Packaging: the AUR PKGBUILD template now lists
xdg-desktop-portal+xdg-desktop-portal-gtkas hard depends andzenityas optdepends, taking effect at the next release.Verification
cargo test: full suite green, including a new env-isolated integration test (src-tauri/tests/dialog_preflight.rs) that replicates the no-backend environment (dead session bus + empty PATH → marker error; fake zenity on PATH → pass)npm run check+npm run test: 1851 tests green, including the newsrc/lib/file-dialog.test.tssessionStorage: codemux-mock-no-file-picker) confirmed the toast renders on the real Open Project pathcodemux doctorreports[FAIL] file dialogs cannot openwith the install hint; afterpacman -S zenity→[ok] file dialogs should work. On a portal-equipped host: portal v4 + zenity detected, all ok.Also includes a small test fix: the
resolve_binaryunit test failed on any machine with a system-wide packaged install (/usr/bin/agent-browserlegitimately wins the PATH probe); it now tolerates that resolution.