feat(desktop): open a local file with a chosen application

[ralyodio]

Right-clicking a local file now offers Open with…. The dialog opens with the system default preselected and the applications registered for that file type listed under it, so the ordinary case is just Enter and picking a different one is there when you want it.

How it finds them

From gio, which is what the desktop itself consults: gio info for the content type, gio mime TYPE for the default and the registered set, and the entry's own Exec line via gio launch rather than reconstructing its argument syntax. With no handler chosen it is shell.openPath — the plain double-click.

Two parsing details that are wrong in the obvious implementation

Both covered by tests against real /usr/share/applications entries:

• Localised keys. Name[zh_TW] comes after Name in the file, so matching Name anywhere names btop "系統監視器".
• Action groups. A .desktop file can carry [Desktop Action new-window] with its own Name=. Only the [Desktop Entry] group is read.

NoDisplay and Hidden entries are skipped — that is plumbing the desktop keeps out of menus, and this is a menu. A Terminal=true application says "Runs in a terminal", because launching one from a file manager usually flashes and exits, and a choice that appears to do nothing is worse than one that is labelled.

Scope and safety

The item is disabled for a pane pointed at a server (that path names a file on that machine, so there is nothing here to hand to a local application) and for directories. handlerId is validated as a bare *.desktop filename in the main process and resolved only against the XDG application directories — a renderer that could pass a path there would be choosing which program runs.

One more instance of a trap from earlier today

The list is a bounded flex column with the ScrollArea as min-h-0 flex-1, not max-h on the ScrollArea root. The root form does not clip: the viewport is size-full, so with no definite height it grows to fit and the last rows are cut off by the dialog with no way to scroll to them. Same trap as the mirror preview's delete list, found the same way — by looking at it.

Verification

Headless Chromium under the app's real CSP, both themes: the menu item appears on a local file and is disabled on a directory, the dialog lists the handlers with the default marked, Open with nothing chosen sends a null handler, and choosing Visual Studio Code sends code.desktop.

pnpm test 546 passing, pnpm -r typecheck clean, pnpm smoke:desktop all three guards ok.

What is not verified: handler enumeration end to end. This box has gio but no registered desktop associations, so gio mime returns nothing for every type. The parsers are tested against real gio output and real desktop files; the live lookup on a machine with actual applications installed is not.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VScug5VRbcTuhiAoieeQ52