Replies: 7 comments 10 replies
-
|
For my use case, I'd need to be able to create the related folder if it didn't exist in (2b). Would that be possible here? |
Beta Was this translation helpful? Give feedback.
-
|
No, but I had opened #997 for this. This solution is more general and independent of any solution for opening neighboring files. Maybe I can take another look, especially since no new cases have surfaced. |
Beta Was this translation helpful? Give feedback.
-
|
Thread for updates to the proposal Changes made to the proposal can be viewed using the "edited" button. Update 1:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Maybe having such a signal is a privacy issue. However, if we are sure that a specific folder is always required for a specific file or folder, then assuming that they do indeed form a "project" - so that they conceptually represent a single object as you assume - then we can either not return all files/folders or create the partner folder if it does not exist. Then, if no file or folder is returned, we return an error to the user. It would be a matter of making it a general rule, hoping that there are no cases that contradict it. @ptomato: What do you think of this? |
Beta Was this translation helpful? Give feedback.
-
|
In my use case (two side-by-side folders called "My Project.inform" and "My Project.materials") the .materials folder is allowed to not exist, and will be created if needed. It's possible that a project doesn't have materials, and in that case the folder isn't needed. It would be OK with me if the portal always created the folder, although maybe slightly odd in the case of projects without materials. If the portal denied access to the .inform folder when the .materials folder couldn't be accessed, that would not be so great for my use case. |
Beta Was this translation helpful? Give feedback.
-
|
@ptomato: When I click "Compile and run the story" (without having created one), it automatically creates the |
Beta Was this translation helpful? Give feedback.
-
|
Not sure I agree with that. You could be trying to browse an Inform project without materials that is on read-only media, in which case you might want to re-save it somewhere else where you can give the app access to create the materials folder. Or you could have accidentally created a non-folder file called "My Project.materials", and I don't think that should prevent the whole project from being opened; for one thing, because it would be very difficult to communicate to the user what the problem was. |
Beta Was this translation helpful? Give feedback.
-
|
I am thinking of the following:
|
Beta Was this translation helpful? Give feedback.
-
|
For relationships between files, I would like to make it possible to search for related files that are not just neighbors of the first open file. This was requested on the issue of neighboring files. This is important when the user has, for example, video subtitles in a Subtitles subfolder. However, my concern is performance. So, which is the best solution between the following two?
|
Beta Was this translation helpful? Give feedback.
-
|
Note that the solution where the portal searches for related files in the same folder and in the first subfolders (without going deeper in the hierarchy) is better for the user. This would not force them to think about adding new folders or deleting folders if they renames them or moves related files to a newly created folder. However, performance must be there. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to rewrite this proposal, as I did for "Neighboring Images" which became "Neighbors Of The Same File Category". I would also like the case to be identified rather than having the permissions set at app startup. This case identification is done with the file selected by the user and the presence of other files of the same name and relevant types. For this, I really need to know:
|
Beta Was this translation helpful? Give feedback.
-
|
Could this satisfy the use case of reading files that are referenced from a file that the user picked via the file picker, for example importing a playlist into a music application? #1288 |
Beta Was this translation helpful? Give feedback.
-
|
Closing in favor of #1290. |
Beta Was this translation helpful? Give feedback.
-
Goal
Allow apps to request access to neighboring files/folders with the same name as a first open file/folder, limited to relevant relationships between file/folder types.
Requirements
App Developers
File Types and Categories Database
Flatpak Validation
Flatpak must be able to validate relationships defined in the app reference file, including categories and types/extensions under each category, using the database and the relationship rules. When an app is installed, flatpak performs validation and only valid relationships are remembered. When an app is updated, flatpak validates the relationships and compares them to previous ones, spotting new, stable, and removed relationships. New relationships are marked as new. Stable relationships are marked as stable and their set access permissions remain those chosen by the user. Removed relationships have their access permission set removed; these can be marked or not.
Portal
Relationship Rules
Relationships Between Files
For files, the relationships between categories are written (e.g. "video->subtitles"), then the relevant extensions are written for each category (e.g. video: mp4, mkv, webm). The relationships must respect certain rules, depending on the type of file extension.
For extensions with letters (e.g. .webm) and extensions with letters and fixed digits (e.g. .mp4), the rules are as follows:
For variable digit extensions (usually for split files), the rules are:
Relationships Between Folders
For folders, the relationships between folder extensions are written. This means that additional folders, and therefore their contents, can only be opened if a first folder has been opened.
There is only one rule to follow: folder extensions must be different.
Functioning
Note: The following text is for understanding purposes only. Things can be done differently if wanted; only the end results are important.
Set Access Permission at App Startup
When the app is launched, whether a file or folder is open, an access permission dialog box is first presented, telling the user what "related" files and folders are, depending on valid relationships defined by the app. This dialog box offers to set access permission for each file category (e.g. subtitles, audio) or for a folder type of a relationship (e.g. video->audio, video-> subtitles, inform->materials). If enabled, access is automatic access to file/folder types based on valid relationships. Alternatively, access permission may affect all relationships at once rather than separately; in this case, a "confirm" permission (i.e. always ask to grant access) can be included.
If there are changes in relationships, the portal must detect them when the app starts. If there are new relationships, a dialog box to set access permission for them is displayed; this dialog can also indicate which relationships were removed if this option was chosen in flatpak validation. Note that changes are handled for relationships between categories, not between specific file types/extensions; informing the user that a specific file type is no longer supported is up to the app developer.
Access Related Files/Folder
Checks and their values:
To begin, the user selects a file or folder with an extension to open from the file chooser or file manager. Then, the portal does check (1). If check (1) is "file", then the portal performs check (2a); if the value is "folder", the portal does check (2b). If check (2a) or (2b) is "no", then the portal stops the checks and only the file or folder selected by the user is opened. However, if they are "yes", the portal selects the relevant files or folders and then continues with check (3).
If check (3) is "no", the portal only opens the file or folder selected by the user. If check (3) is "yes", then the portal selects the files or the folder with the same name as the file or folder selected by the user and performs check (4).
After performing check (4), the portal selects only the files or folder for which "automatic" access has been set, and these are accessible by the app, including the file/folder selected by the user. If all relationships have "never" access permission, then only the file/folder selected by the user is accessible by the app.
However, if a global permission has been chosen, the portal will have one of the following behavior depending on the value of check (4):
Once the app is no longer running when it has been closed, the portal removes access to the files or the folder selected by the portal.
A Simpler Portal
View
Requirements
Portal
App Developers
Functioning
Note: The following text is for understanding purposes only. Things can be done differently if wanted; only the end results are important.
Checks and their values:
To begin, the user selects a file or folder with an extension to open from the file chooser or file manager. Then, the portal does check (1). If check (1) is "file", then the portal performs check (2a); if the value is "folder", the portal does check (2b).
If check (2a) or (2b) is "no", only the file or folder selected by the user is opened. However, if check (2a) or (2b) is "yes", the portal selects all files or folders having their name matching the name of the file or folder selected by the user, and performs check (3).
If check (3) is "none", then the portal only opens the file or folder selected by the user. If its value is "some", the portal selects all files or folders that have a different extension between them and compared to that of the file or folder selected by the user, and performs check (4).
The portal has one of the following behaviors, depending on the value of check (4):
Once the app is no longer running when it has been closed, the portal removes access to the files or folders selected by the portal.
Questions
Beta Was this translation helpful? Give feedback.
All reactions