dtourolle/DarkRoom
1
0
Fork 0
Code Issues 39 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

Say the folder dialogue is the portal, and what the Flatpak has not proved

Browse Source 
distribution.md §4, outstanding.md's FR-PLAT-LIN-3 entry, the Flatpak
manifest's comment and the README all said a library was chosen by
typing a path and that nothing in the tree called the FileChooser
portal. Since 6683c14 every folder the desktop asks for is chosen
through rfd's xdg-portal backend, so those sentences were false.

What they now say instead is narrower than "it works in the sandbox":
no Flatpak has been built here, so whether the portal's path opens a
library, holds across a restart and takes a sidecar is unobserved, and
volumes() still cannot see a host card. The chooser also landed in ui/
rather than behind the dr-plat seam distribution.md had proposed, and
both documents say so. FR-PLAT-LIN-3 gets a status note to the same
effect.
This commit is contained in:
dtourolle
2026-09-26 14:52:44 -04:00
parent e57c5b8182
commit caaae11d98
5 changed files with 98 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dev/outstanding.md
+14 -8
View File
@@ -275,14 +275,20 @@ Intent read over JNI, and an `ExportProvider` rooted at `getFilesDir()` rather t
been exercised on a device** — the tests read the manifest and the Java through `include_str!`,
which catches a deleted filter but not a class loader that cannot find the class.
**FR-PLAT-LIN-3 — packaged, not satisfied.** There is a Flatpak manifest now, granting no
filesystem permission of any kind, plus AppStream metainfo and `docs/distribution.md`. The
requirement is still not met, and cannot be met by packaging: a folder library is chosen by typing
an absolute path, nothing in the tree calls the FileChooser portal, and inside the sandbox `$HOME`
holds only `.var/app/...`. `dr_plat::volumes()` reads `/proc/self/mountinfo`, so a card mounted on
the host is invisible to a sandboxed process as well. The fix is an `ashpd` directory picker beside
`LocalStorage::grant`, not a change to the manifest. No Flatpak has been built here —
`flatpak-builder` is not installed — so the permission set is reasoned, not observed.
**FR-PLAT-LIN-3 — packaged and wired, not yet proved.** There is a Flatpak manifest, granting no
filesystem permission of any kind, plus AppStream metainfo and `docs/distribution.md`. Until 0.17.0
the requirement could not be met by packaging: a folder library was chosen by typing an absolute
path, nothing called the FileChooser portal, and inside the sandbox `$HOME` holds only
`.var/app/...`. Since 0.17.0 every folder the desktop asks for — the library, an import's source
and second copy, Lightroom presets, an album's folder — is chosen in the platform's dialogue
(`ui/dr-ui/src/folder_dialog.rs`, `rfd` over the XDG portal), which is what a sandbox needs. Two
things stop this entry being struck. No Flatpak has been built here — `flatpak-builder` is not
installed — so the portal path has never been seen to open a library, reopen it after a restart,
or take a sidecar inside the sandbox; [distribution.md §4](distribution.md) says what has to be
checked. And
`dr_plat::volumes()` still reads `/proc/self/mountinfo`, so a card mounted on the host is invisible
to a sandboxed process; the import page's `Browse…` reaches one through the portal instead. The
chooser landed in `ui/` rather than behind the `dr-plat` seam distribution.md had proposed.
**NFR-COMPAT-2 — distribution channels. Stated, which is all this requirement asks.** The paragraph
above cites [distribution.md](distribution.md) and it is the same document that answers this: §1