Libraries Portal / Folders and Locations

[swick]

Currently there are two main methods for accessing files from the host.

1. Static permissions
2. File chooser portal

Applications which work on a collection of files, such as music players often choose to use static permissions to at least the XDG Music directory, often to the entire host. The reason for doing so is that the workflow of adding directories that contain music using the file chooser portal is a much worse user experience. On the other hand, apps are getting flagged by app stores for being potentially unsafe when using static permissions.

The goal of this portal is then to move applications away from static permissions by improving the UX of making folders available to the sandbox.

In its basic idea, it's very similar to the FileChooser portal. The differences for a user are that the UI shows a list of Folders and Locations on the system and the user can select and deselect any number of them. Any time the portal UI shows up, its immediately obvious what the app already has access to. It allows the user to share multiple locations easily, such as a USB drive, the XDG Music directory and a folder on a NAS. The locations should be the same as shown in the File Manager but it should be possible to add custom locations.

From a technical perspective, this is very similar to the FileChooser portal when opening a directory. The difference is that this handles adding and removing multiple directories at once.

Absolutely horrible mockup, but I think it helps to illustrate the idea:

[sonnyp]

Applications which work on a collection of files, such as music players often choose to use static permissions to at least the XDG Music directory, often to the entire host. The reason for doing so is that the workflow of adding directories that contain music using the file chooser portal is a much worse user experience. On the other hand, apps are getting flagged by app stores for being potentially unsafe when using static permissions.

I've been planning to address this differently.

1. Write an article / documentation on what apps should do. Which is asking users to pick a directory on first launch.
2. Make it clearer that entries in the document portal are permanent, a lot of people are surprised by this
3. Allow selecting the default directory in the file picker. For example default the selected folder to xdg-download.

I don't think this new portal would do something the file chooser portal can't do.

Apps don't usually need multiple well-known location at once like Music + Downloads.

[Mikenux]

This is generally for users with local and remote locations. However, showing irrelevant folders is not a good idea, even more so for devices and remote locations. See the following discussion for devices and remote locations: #1287.

However, I agree that presenting devices and remote locations more as selectable items - if that is the user's choice - would probably be helpful in case it's not clear that it is a selectable item in the sidebar.

Another possibility would be to have an "Import files [file type]" dialog box where we select some relevant locations to search for the requested file type(s). Also, another idea is to use the system's "search engine" to locate folders that appear to be a library, an idea (or a derivative idea?) taken from #334, at least for local folders.

[sophie-h]

I think we should be very specific about which existing apps and potential future apps can benefit from a new portal.

• As I see it, Amberol does not need any new portal. Music is hard-coded to one specific folder anyway, so pre-selecting it seems fine or the folder can be selected once.
• Loupe/EOG want to browse through images when you open one image from Files. So this portal wouldn't be suitable here either.
• Browsers opening a .html file depending on .css files and images on the system, face the same issue as image viewers do. So the portal also doesn't help here.

Maybe I'm overlooking the app where this is useful. But currently, I don't see it.

I have thought a lot about these issues, currently, I don't see another option than adding support for giving apps access to certain mime types like image/* or text/css.

[Mikenux]

Here are some examples:

• Audio: Music, Rhythmbox, Kodi.
• Images: gThumb, Shotwell, Kodi.
• Videos: Videos, Kodi.
• Books: Foliate.
• Documents: Paperwork.
• Games: Cartridges, Steam, Lutris. This one, however, certainly requires more thought: clear if it is a specific file type, like ROMs or disk images, less when it is installed games with many files.

UI point of view, if done well this might be an alternative folder selection interface allowing multiple locations to be selected if necessary. This could perhaps also be clearer for the user on the fact that several files will be imported and that it involves adding specific folders or objects, while helping them with "library" detection (if there is the implementation behind it).

[swick]

The examples from @Mikenux are good. Apps like Blender, Inkscape, etc. also always have access to all of home but they could use this portal to let their users select their Workspaces. Especially something like Blender where you might want access to your photos, Downloaded reference images, your Krita drawings, a texture library and want to share the 3D models with Godot.

[Beryesa]

An xdg-projects for such a standardized "Projects" location could be valuable and incentivize more people to clean their home while creative apps default to that location 😄

[swick]

As I see it, Amberol does not need any new portal. Music is hard-coded to one specific folder anyway, so pre-selecting it seems fine or the folder can be selected once.

Apps don't usually need multiple well-known location at once like Music + Downloads.

Hard disagree with this sentiment. Amberol is not a good example because it doesn't maintain a library of songs and something like Rhythmbox or Gnome Music are better examples.

The idea that all Music rests neatly in a single directory is just wishful thinking and doesn't match reality:

• People use syncing services for a lot of files, including music. Syncing happens often in one directory which is not a XDG location.
• People use external hard drives to store and share media. This is not some power-user situation but average people, sharing rather big media not over the internet but via external storage.
• People have NAS. We don't magically make network attached storage available in the XDG locations.
• Separate mount points. Home is often on some fast, small storage (SSD) and media on some slower and bigger hard drives. We also can't magically make this available at XDG locations.

For NAS and external media the filechooser completely falls apart. In a lot of situations you also want to share multiple of those locations, such as the XDG Music directory, the NAS or syncing direcetory and maybe some external hard drive a friend brought over. The filechooser is utterly useless in this situation as well because you have to repeatedly select the right folder, possibly at a weird path and there is no indication that the previously selected folder is still being shared.

Loupe/EOG want to browse through images when you open one image from Files. So this portal wouldn't be suitable here either.

Agreed, and this is not an attempt at solving that problem.

[Mikenux]

@swick:

Apps like Blender, Inkscape, etc. also always have access to all of home but they could use this portal to let their users select their Workspaces. Especially something like Blender where you might want access to your photos, Downloaded reference images, your Krita drawings, a texture library and want to share the 3D models with Godot.

While I agree with media libraries, I am however mixed about asset libraries as there is no real reason here to access all files (like managing) as usually only some of them are used. For reference, I've already explored this a bit at #283, but in the case of an app-owned asset library (#283 (comment) for the proposal; you were also on this issue).

The thing here would be to differentiate between directories to be "watched" (where files are supposed to be automatically added when there are new ones), and those only as a way to easily add files ("workspaces"). However, it will be difficult to achieve the ideal where apps use what suits their case. In my proposal, I simply used an option to add assets using the file chooser; note that there could also be a specific interface to only display files from a specific folder, and create a multi-window environment when there is what is necessary on the wayland side.

[snwh]

The differences for a user are that the UI shows a list of Folders and Locations on the system and the user can select and deselect any number of them.

Where does this list come from? User bookmarks and mounted/visible devices/volumes?

From a technical perspective, this is very similar to the FileChooser portal when opening a directory. The difference is that this handles adding and removing multiple directories at once.

Would it be simpler to add this functionality into the file chooser portal? So we don't need to come up with a whole additional portal UI for something that seems like it would be an extension on the functionality of FileChooser.

---

The assumption in all this seems to be that these locations that are being granted access to are guaranteed to be unchanging. But what comes to mind is that in some cases what folders that are relevant to applications may change often, so a user would have to constantly manage what folders a given app has access to via this portal.

Seems to me that a need for some sort of middle ground between "the whole filesystem", "all of a user's home" and "specific folders" needs to be found.

What I'm inclined to suggest is letting users carve out a subset of folders/locations they are comfortable letting sandboxed applications have access to--lets still call it a Library for now--and the thing that applications ask for via the portal access to is that whole "library" (which can also be revoked). This still comes with a need for a UI to manage what folders are in the library or libraries...

[swick]

Where does this list come from? User bookmarks and mounted/visible devices/volumes?

yes

But what comes to mind is that in some cases what folders that are relevant to applications may change often, so a user would have to constantly manage what folders a given app has access to via this portal.

Can you be a bit more concrete on what you have in mind here? Sophie already mentioned an image viewer as example and the only response I have to this is that a portal doesn't have to be able to resolve all problems. I believe that there is a reasonable number of use cases where the locations are static (just not always available) which would benefit a lot from this portal.

[swick]

Would it be simpler to add this functionality into the file chooser portal?

It certainly would. I would expect the xdg-document-portal to be the component handling the request so this is just a question of creating a good API for developers. Not sure if a new "portal" or extending the FileChooser is the right choice.

[snwh]

Can you be a bit more concrete on what you have in mind here?

I don't have concrete examples, it's more a theoretical application that has that sort of use case which might have to be accounted for. As I'm not clear on the scope of this proposed portal I'm thinking of hypotheticals that it might have to work with, but as you say it's not out to solve all problems so I might be being too broad with my thinking.

[Mikenux]

@snwh: See #1301 (comment), you have two types of libraries.

[Mikenux]

This is a case where permanent access to files will have to be removed when a location is removed from the UI.