Replies: 6 comments 9 replies
-
|
Checking Support in Runtimes and Extensions (from #1257 (comment)) Runtime and extension developers can add a file with the file types they support if they want. However, the following must be kept in mind:
|
Beta Was this translation helpful? Give feedback.
-
|
Update! Functioning and DCF have changed. See also the other sections. |
Beta Was this translation helpful? Give feedback.
-
|
Update 6:
|
Beta Was this translation helpful? Give feedback.
-
|
Update 7:
|
Beta Was this translation helpful? Give feedback.
-
|
Update 8:
|
Beta Was this translation helpful? Give feedback.
-
|
Update 9:
This should be the last update. |
Beta Was this translation helpful? Give feedback.
-
|
Update 10
|
Beta Was this translation helpful? Give feedback.
-
|
A mockup has been added, in Mockups section. |
Beta Was this translation helpful? Give feedback.
-
|
Thread for comments on the mockup |
Beta Was this translation helpful? Give feedback.
-
|
What do you think about adding a choice guide? https://gitlab.gnome.org/Teams/Design/whiteboards/-/issues/239 |
Beta Was this translation helpful? Give feedback.
-
|
Another possible idea to explore is to use the file manager as a file browser that opens the file in the app. This is based on the previewer from a file manager like sushi (GNOME). This is also a case for a portal. |
Beta Was this translation helpful? Give feedback.
-
I need to be developed 🙂
Goal and Target Case
The goal is to allow apps to access all files of the same category (e.g. images) in a folder, excluding subfolders. The target case is apps that are supposed to do this in order to browse files in a folder containing files of different categories (e.g. images and audio files). This is the equivalent for the user of selecting several files of the same category, but more convenient for them because this selection is not easy when there are files from other categories and they does not know what file types are supported.
Requirements
Portal
App Developers
Example:
Database of File Categories
Note On Supported File Categories, File Subcategories, And File Types
For a first version, this portal may support the image, video and audio categories; at least the image category. Any other file category, file subcategories, and file types can be requested, evaluated, and possibly added later into a minor version of xdg-desktop-portal.
For images, I recommend dividing this category into two subcategories: (1) still and animated images and (2) source/project images. A source/project image is an image format used for image creation and advanced image editing. It constitutes the source of an image before exporting it to a plain image. This includes, for example, XCF (e.g. GIMP), KRA (Krita), and SVG. This allows users to grant access permission to neighbors in the case of still and animated images, but not in the case of source/project images. If adopted, this reasoning will then apply to any other category of files if such a distinction can be made. Other types of subcategories can be distinguished if relevant.
Validation of File Categories
There are two options to validate file categories, one of which needs to be chosen for the development of this portal:
File Category Validation Rules
The following rules are used by the validation program to validate file categories written in the app reference file:
Any invalid type invalidates the subcategory or category with no subcategory, and any invalid subcategory invalidates the category and other subcategories of that same category.
Validation When Installing the App
When an app is installed, the validation program performs validation of files categories with the help of the file category validation rules and the database.
When the validation has been performed, the following information is stored in the permission store:
Finally, permissions for the categories and subcategories are set to "none".
Validation When Updating the App
When the app is updated, the program performs validation using the file category validation rules and the database, takes the difference between this validation and the one stored in the permission store, and does the following in the permission store:
And so on.
Functioning
Note: The following text is for understanding purposes only. Things can be done differently if wanted; only the end results are important.
Checking Tags and Permissions Before App Startup to Manage Changes
When the app is launched, but before it starts, the portal checks the permission store for the presence of "removed" tags, "new" tags and and subcategories with permission set to "new". If there are categories and subcategories that have both the "removed" tag and a permission set to "none", the portal deletes them from the permission store.
Next, it displays a window showing the remaining types, subcategories and categories that have a "removed" tag, as well as those with a "new" tag and a "new" permission. The portal communicates which ones have been removed and which ones are new. For ease of reading, the types are classified by subcategories which are themselves classified by categories.
The portal also communicates that permissions must be set again for categories that have not been removed, that already have a permission that is not "none", and that have removed and/or new items (including subcategories with permission set to "new").
When the user has confirmed that they has read the text, it displays a window to set permissions for categories that have not been removed, that already have a permission that is not "none", and that have removed and/or new items (including subcategories with permission set to "new"). Removed items are not shown because no permissions need to be set for them. When the user has set all permissions, the portal stores them in the permission store and removes all "new" tags (only tags) and all remaining types and categories that have a "removed" tag.
File Opened From File Manager or File Chooser
Here are the checks and their values, with the necessary information retrieved from the permission store:
To begin, the user selects a file to open via the file chooser or file manager; the file is not returned to the app. Then the portal performs check (1). If the value of check (1) is "none", then the portal returns only the file selected by the user to the app. If check (1) has the value "related-files", then the portal uses the method for related files (see proposal of Related Files). If it has the value "same-category", the portal continues by performing check (2). If there are the values "same-category" and "related-files", the portal performs check (2), and will have to use the method for related files after the "same-category" method.
For check (2), the file category to which the user-selected file belongs and the subcategories of that category are retrieved from the permission store and are used when performing check (3).
Check (3) is performed for the retrieved category or subcategories. The portal behaviors are as follows, depending on the resulting values of checks (2) and (3):
Once the app is no longer running, the portal removes access to neighboring files. This automatic removal of file permissions avoids doing so when the access permission is reset to "none", set to "ask", set to "never" after being set to another value, or when a category or subcategory has been removed. This also prevents the app from acquiring many files over time, especially if the app's static permissions change from something good to something bad, at least if the app has not copied the files.
Folder Addition Limited To Supported File Categories, Subcategories, and Types
When opening a folder (including adding it as a library) is requested, via the file chooser, file manager, or by drag and drop, checks are performed. The relevant portal checks in the permission store whether the app supports neighboring files of the same category and related files. If so, it scans whether all files in the folder (including of all subfolders, etc.) belong to valid file categories, including subcategories, and valid first file categories of relationships between file categories (if any). A dialog box displays the progress of the scan. Once the scan is complete and the file categories and subcategories are determined, the dialog box asks the user which valid file categories and subcategories they wants to import, allowing multiple ones to be imported. If the user chooses to import one or more categories and subcategories, the portal returns only files from the selected ones to the app.
This is done because apps will be able to use both "same-category" and "related-files" methods, and adding a library for related files is not wanted as there will be the method for them. This is for example the case for videos: a video library can be added, but not a subtitle library because subtitles can be acquired using the "related-files" method.
If the app wants to access more file types than those defined for neighboring files of the same category and for related files (if any), then it must define them in the app reference file; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
However, the portal must communicate this to the user, so that they are aware of it. This must be communicated when setting permissions. Optionally, the user can be reminded of this in the file chooser.
Other Ideas
Filters in the File Chooser
All valid types in the permissions store are used as filters in the file chooser. There is a filter for each valid category, even if it includes subcategories, and for each subcategory. These filters are automatically added.
The file types accessible from the file chooser are only those for which a filter has been defined. So, if the app wants to access more file types than those defined for neighboring files of the same category and for related files (if any), then it must define them in the app reference file like for when opening a folder; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
Multiple Selection Limited To Supported File Categories, Subcategories, and Types
Same process as when opening a folder, but when the user selects multiple files in the file chooser or file manager. This allows them to easily selects multiple files at once, without individually selecting or deselecting some of them. Note that if the app wants to access more file types than those defined for neighboring files of the same category and for related files (if any), then it must define them in the app reference file like for when opening a folder; file types of second file relationship categories of file and use of the wildcard "*" are not allowed.
This must also be communicated to the user.
Removal of "ask" Permission
If we have the filters in the file chooser and the limitation to supported file categories, subcategories and types for folders, and optionally for multiple selection, then the "ask" permission is not needed because the portal will open only relevant files for the user.
Questions
Mockups
Contact
On GNOME Discourse via personal message to Mikenux.
Beta Was this translation helpful? Give feedback.
All reactions