Neighboring Files: Same Category and Name Matching Methods

[Mikenux]

Apps must be able to open neighboring files of a first open file.

Below, two methods and their requirements for accessing these additional files are described. An app can only use one.

Methods for applications using files that contain links to external files, whether text files or binary files, are not seen here.

Basic Requirements

• A database of file types. It will be used for sandboxing and checks, and could be used for user interfaces. This database must have at least categories (i.e. image, video, audio, etc.) and file extensions/mime types relating to them.
• The portal must be aware when a file is opened from the file chooser or from the file manager.

Method: Same Category

Target Cases

Apps wanting to browse image files.

Requirements for Apps

• Use of the file chooser portal.
• Writing file extensions in a reference file. The rule is that all extensions must belong to the image category.

Question

Image browsing seems to be a common case, which is why I only put this one in the proposal. Are there any other common cases? For videos, is it browsing all neighboring videos or watching videos from the same season or topic?

Method: Name Matching

Target Cases

Apps wanting to open additional files sharing their name with that of a first opened file, e.g. video players opening subtitles based on the name of an opened video.

Requirements for Apps

• Use of the file chooser portal.
• A reference file to write relationships between file categories, as well as extensions.

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:

1. Relationships are unidirectional. For example, if the relationship video->subtitles is written because it is wanted, then the relationship subtitles->video is not allowed.
2. File categories in a relationship are different. For example, the relationship video->video is not allowed.
3. All written extensions belong to the correct category. File extensions under the wrong category are not allowed.

For variable digit extensions (usually for split files), the rules are:

1. The entire extension has at least one letter. Each letter of the entire extension is written, and each digit is replaced, for example, with an asterisk ("*"). Examples: .r01,.r02,... -> .r**, .part01.rar,.part02.rar,... -> .part**.rar, .7z.001, .7z.002,... -> .7z.***.
2. Relationships can be bidirectional. Examples: bi: .rar->.r**, bi: part**.rar->.part**.rar.
3. Extensions belong to the same file category.

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.

Relationships must follow only one rule: folder extensions must be different.

Questions

• Are there other common cases that want to open additional files of the same category as the first one opened?
• How should name matching work? Simply matching the full name and keeping a more complex match for file managers when renaming files? Or do a partial name match, such that storyV1-subtitles.srt is opened after storyV1-video.mp4 but not storyV2-subtitles.srt?

Missing Extension, Category, or Rule

Adhering to this proposal also means accepting that app developers can request the addition of file extensions and categories, the addition of an extension/mime type to a category, and the addition of other rules. The addition of rules can only be requested for the Name Matching method, and in relation to extensions or what should be considered an extension.

[Mikenux]

For the Same Category method, perhaps have subcategories that will be more recognizable by all users:

• Still Images. Common image formats.
• Animated Images. Particularly useful for older animated image formats that have been assigned to the video mime type.
• Special Images. For app-specific image formats. For users for whom it would not be clear, e.g., that Krita images belong to the Image category. Any other more meaningful label is welcome.

[Mikenux]

Mockups: https://gitlab.gnome.org/Teams/Design/whiteboards/-/issues/221