Portal to open file and neighbouring files

[hadess]

We're missing a UI that would make it possible to opening a file, eg. a project file, and also give access to the rest of the files in that same directory. This is useful for:

• audio or video authoring with a project file and assets
• video playback where subtitles could be external files

UI-wise we could have:

• post-file selection question "also allow to access the other files in the same directory"?
• checkbox in chooser dialogue "[X] Allow app to access neighbouring files"

New use cases, UI ideas, or prior art? Please list them below.

[hadess]

From flathub/flathub#1415, sqlite would like to be able to write the main db, as well as some files in the same directory such as its journal.

[TingPing]

I wonder if its valuable to limit it to just specific files matching a pattern rather than all of a directory.

[hadess]

I wonder if its valuable to limit it to just specific files matching a pattern rather than all of a directory.

Maybe, for something like video players wanting to access subtitles, but that might be complicated for all other types of projects, where the name/extensions of assets wouldn't be known until the main file was parsed.

[TingPing]

Yeah media players is what I was thinking of, using a pattern could improve the UX, it could know no other files match and just behave as normal without constant double prompts.

[matthiasclasen]

Am I wrong to expect this to be just an option in the OpenFile method of the file chooser ?

[hadess]

Am I wrong to expect this to be just an option in the OpenFile method of the file chooser ?

The priority would be to discuss the UI and the use cases for now, not the implementation. This will tell us whether we want an option for the OpenFile method, or something else. For the media players use case discussed above an option won't be enough, as we need to return multiple files.

[saivert]

I feel this is going to get very complicated. At some point you just have to concede and accept a gaping hole in the sandbox for certain kinds of applications. Music and video apps that need access to companion .cue or .srt files will just need access to the same folder (and subdirs) so they can load those files. Otherwise you need various mechanisms of increasing complexity to allow the portals to figure out which files to give access to.

For fun I could think of using javascript programs that is submitted by the app via the portal API and which will parse the selected file in the file chooser and spit out a list of associated filenames. But for very complex file formats this could be a daunting task. For things like .srt and .cue it should be fairly trivial to write some javascript for that purpose. With very limited API surface in the jvm this could be made perfectly safe and it would only understand a list of filenames coming from the script and it would have to be limited to the folders that the flatpak app currently has permissions to access. Or if not javascript maybe even some DSL that is designed with functions to open, read, seek and do data conversions. Or even BPF.

My skin in the game here is that I currently maintain a flatpak manifest for DeaDBeeF music player. So mp3/cue is something I would like support for opening.

[ptomato]

In case more use cases are wanted: the Inform compiler takes as input a project folder "Foo.inform" (which the user can select with a file chooser in the UI) and expects to be able to create an assets folder "Foo.materials" as a sibling of "Foo.inform".

I think this would be able to be handled by a new option for the OpenFile method.

[somas95]

And more use cases: currently I have to disable the sandbox in Apostrophe because otherwise I can't render a markdown document with images (which are not embedded due to the plaintext nature of markdown)

I can see the same happening for IDEs, which need access to a whole folder, or any kind of editor where data is linked instead of bundled

[teohhanhui]

Another media player use case in flathub/io.github.celluloid_player.Celluloid#28

[Mikenux]

Hello ! It is also needed for playing external audio files (and maybe video files) linked to PDFs (software use here: GNOME Document Viewer [Evince]) in full sandboxing.

[gasinvein]

Apps that run win32 binaries via Wine, e.g. Bottles and protontricks, could benefit from this as well. An .exe can be opened via portal, but if it's not self-contained and require some .dlls in the same directory, it won't work.

[BrainBlasted]

For image viewers like EOG, we want to be able to browse images adjacent to the one the user opens.

[ssokolow]

Aside from GTK applications that haven't yet migrated to GtkFileChooserNative yet, this is probably the number-one reason I have huge exceptions in my sandboxing:

1. Browsers need to read subresources when loading file:// URLs and need to write _files directories when Ctrl+S-ing.
2. MPV needs to read subtitle files when opening video files, and needs to read video files when opening the .edl files I generate to skip ads, sponsor notices, and the odd skit that goes on too long in old Spoony videos. (Currently, I've used overrides to disable MPV's network access and grant host:ro.)
3. Emulators need access to .bin files when they open .cue files
4. Anything that uses SQLite for its container format, for previously stated reasons.

[BrainBlasted]

There's an adjacent issue - when passing a URI (for opening via the file manager or app chooser portal) apps also need a way to handle that. A solution for GtkFileChooser doesn't work for every case.

[WhyNotHugo]

Regarding the UX aspect of this: a clear and non-confusing API for this, is to:

• Use a regular FileChooser to pick a file.
• Application requests access to the portal to read other sibling files (e.g.: via the new API).
• Portal shows a new popup: "Application X wants to access directory /path/to/file/" with allow and deny buttons.
• Application gets access to the whole directory.

Some things I kept in mind:

• A flag to the FileChooser portal is tricky, since a FileChooser will pop up and it's very easy for a user to not-notice that they're being requested-than-usual permissions.
• Asking for access to a directory in the first place is tricky; picking a file often makes more sense than picking a directory. For example, an image viewer might want to pick the first image to view. Picking the directory means starting of on the wrong one.

[WhyNotHugo]

When starting applications that take a file as an argument (e.g.: an image viewer when double clicking on a file in a file manager), it would also be handy to sometimes have access to the directory containing the file.

For example, if I double click on an image, I want an image viewer to render it. But I also want to easily navigate back and forth across sibling images. Having to grant the flatpak access to that whole directory ahead of time is very inconvenient.

The same applies to double clicking on videos which have separate subtitles. This scenario doesn't go via a FileChooser portal, so might be trickier.

[wjt]

There's an adjacent issue - when passing a URI (for opening via the file manager or app chooser portal) apps also need a way to handle that. A solution for GtkFileChooser doesn't work for every case.

Another case where I ran into this: LibreOffice has a Help extension, and tries to open it in the system browser. The browser, if it is also sandboxed, gets access to index.html but not the neighbouring files. #555

[Mikenux]

@hadess: Assuming the goal is to at least always read files, isn't it safe to automatically allow apps to only read files? Isn't the problem in writing files?

[ssokolow]

@Mikenux I assume it'd reduce the threat potential... though there would still need to be some way to allow write access for things like opening a project in an IDE (open the project definition in the root of the project and get access to the rest of the source files) or using "Web Page, Complete" when hitting Ctrl+S in a browser.

[bertob]

I pushed an initial version of UI for this as part of the file chooser mockups. A dialog in a second step seems like the simplest solution, both because it makes the security implications clear, and because it has enough space to fit a proper explanation (as opposed to, for example, a banner).

[Mikenux]

Having thought about it more:

• If this dialog box appears automatically after selecting the file, without the app making a request, it will also appear for files that do not require other files.
• If this dialog box appears when requested by the app, it means that the app may request it at any time, which is not ideal.
• Having the app request the files in a batch would be better, if possible. As already said, on the mockup and here, the apps should adapt. Edit: For "project" files.

[ssokolow]

Having the app request the files in a batch would be better, if possible. As already said, on the mockup and here, the apps should adapt.

I suppose the thing to do then is begin talks with the Qt and GTK devs. My experience has been that portals are far more likely to get used by third-party developers if the're exposed by a widget toolkit API... especially if they're cross-platform apps.

Requiring apps to either add a new dependency or implement appropriate platform detection code and then speak directly to their chosen toolkit's D-Bus binding is a big impediment to updake.

(Hell, it's been enough of a slog just getting various applications to switch from GtkFileChooser to GtkFileChooserNative and, for cases where you don't need to customize the dialog beyond what the portal supports, that's a drop-in replacement which should be a simple find-replace operation followed by a little testing.)

[Mikenux]

GNOME and KDE developers track portal requests and therefore in principle proposals, so they can already see this if they are interested. They just need to communicate back.

I am currently in the process of updating my proposal (it takes time) and I will post a proposal at the same time to express the interest in having the possibility of requesting all files at once.

[Mikenux]

Revised proposal for neighboring images: #1257

Proposal for "project" files (i.e. any file with links to other files in the same folder): #1256

The revised proposal for "name matching" will come later.

Happy new year!

[Mikenux]

Related Files/Folders (Name Matching): #1259

I also opened a discussion about apps using Wine: #1260

The other proposals have been updated and all have a simpler version.

• Neighboring images: Neighboring Files: Neighboring Images #1257
• "project" files (i.e. any file with links to other files in the same folder): File Set Request (Files With Links to Other Files In the Same Directory) #1256

Follow these discussions if you're interested, I won't report anything here unless there is a completely different solution.

[moeenio]

As a humble user who was discouraged from extensively using flatpak because of not having this, I'd love to see progress on this. I'm not sure what I could actually do to help because it seems like this is primarily a matter of getting maintainers to agree on a design and the necessity of implementing this, so I'll just ask that this be seriously considered