File chooser: would you take a portal backend for Folio? #40

The plan lists this as an open question:

File chooser. Open/save dialogs in other apps come from xdg-desktop-portal-gtk, not Nautilus, so they keep working. Should Folio later provide the portal's FileChooser so dialogs look and behave like Folio?

I'd like to build it, if you want it.

I've already written one for Omanta, my own Qt Quick file manager for Omarchy. It implements org.freedesktop.impl.portal.FileChooser (OpenFile, SaveFile and SaveFiles, with filters, multi-select, folder mode, the suggested name and folder, and app-supplied choices). I've been using it as my daily chooser on Omarchy, so the awkward parts are known ground.

For Folio I'd keep the D-Bus side and build the picker from Folio's own views, so an Open or Save dialog is just a Folio window with a filename field and two buttons: same grid, list and columns, same sidebar, same keys, same theme.

Before I write anything, three questions:

1. Do you want this in Folio at all, or would you rather stay on the GTK chooser?
2. If yes, where should it live: in the folio binary (a --portal service mode), a separate small binary, or a plugin once Move Tailscale, Dropbox and LocalSend into plugins #33 lands?
3. Should I wait until the current round of dialog and chrome work (Clearer files: selection, cursor, search, details, dialogs #18, Calmer chrome: Home row, quieter toggles and a folding path #19, Undo, clash choices, cancellable progress, Extract Here, drives with Format and Burn, servers #32) has settled?

I'd keep the PR to the backend, the picker window, the .portal and D-Bus service files in the PKGBUILD, and tests. Making it the default chooser would be a separate change in Omarchy's portals config, and yours to make.