Neighboring Files: Neighboring Images

[Mikenux]

I need to be developed 🙂

Requirements

Portal

• Supported image types must be defined. Mimetypes/extensions are defined and categorized into 3 categories: (1) still and animated images, and (2) source image formats (see Neighboring Files: Neighboring Images #1257 (comment)). Ideally (optional), the full name and a description is given for each image type/extension.
• Ability to perform the checks listed in "Functioning, Checks and their values" below.
• Ability to remove access to neighboring images. This means that the app can no longer automatically access these images on next launch.

App Developers

• They must write the image types/extensions they support into a reference file.
• They must use the file chooser portal.
• They should be allowed to request the addition of new image types and app-specific formats (e.g. Krita files) in xdg-desktop-portal. If allowed, each request must contain files of the requested types and a flatpak app to test and assign the types to the correct categories.

Desktop Containment Framework (Flatpak, Snap, Other)

The desktop containment framework (DCF) must validate the image types/extensions defined in the app reference file. When the app is installed, the DCF must consider as valid the types that are supported by the portal; valid types are remembered. When the app is updated, the DCF validates the types supported by the app, compares them to previous ones, and then marks which ones are new. Optionally, the DCF may also mark which types have been removed. And so on.

Note that the DCF must read supported formats from portal files. Keeping supported formats in the portal allows to receive updates for new supported formats regardless of the DCF used.

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:

• Check (1): The selected file is an app-supported and valid image file, verified by the DCF. Values: "yes" or "no".
• Check (2): Presence of other app-supported and valid image files in the same folder as the selected image. Values: "yes" or "no".
• Check (3): Value of the access permission. Values: "none" if permission is not set, "never" if set to never grant access, "confirm" if set to confirm access, and "automatic" if set to grant access automatically.
• Check (4): New valid image formats are supported by the app. Values: "yes" or "no".

To begin, the user selects an image 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 check (1) is "no", then only the selected image file is returned to the app. If check (1) is "yes", then the portal performs check (2).

If check (2) is "no", only the selected image is returned to the app. However, if check (2) is "yes", the portal performs checks (3) and (4) at the same time and acts according to the following values of the checks:

• Check (3) is "none", check (4) has any value: A dialog box asking to set the access permission is displayed. The user has the choice of giving access to neighboring images automatically ("automatic"), by confirming access ("confirm"), or never ("never"). When the choice is made, the value of check (3) is replaced by the value of the selected choice, and the portal acts according to this new value and the value of check (4).
• Check (3) is "never", check (4) has any value: Only the image file selected by the user is returned to the app; access to neighboring images is not granted.
• Check (3) is "confirm", check (4) is "no": The user must confirm whether they agrees to grant access to neighboring images. If the user grants access, the portal behaves as if the value is "automatic". If the user denies access, the portal behaves as if the value is "never".
• Check (3) is "automatic", check (4) is "no": The app has access to the image file selected by the user and automatically to neighboring images.
• Check (3) is "confirm" or "automatic", check (4) is "yes": A dialog box appears and tells the user that new image formats are supported and that the permission must be set again. The dialog box may also inform the user of image types that are no longer supported by the app if this option was chosen for validation by the DCF. When the choice is made, the value of check (3) is replaced by the value of the selected choice, and the portal acts according to this new value and the value of check (4).

Once the app is no longer running when it has been closed, the portal removes access to neighboring images.

"never" Access For Specific Folders

Instead of having "confirm" access, one idea is to have the option to add folders from which neighboring images will never be accessed when permission is set to "automatic" access.

A Simpler Portal

The following suggestions should help simplify the portal. One, some, or all may be used. A simpler version may be a good candidate for a first version of the portal.

No "confirm" Access Permission

Just do not implement the "confirm" access permission.

No Support For Source Image Formats

Such image formats are editable by being designed for this purpose. People using such formats have the app that goes with them. Additionally and generally, they are not shared as is, except for editing; they are shared in a common image format for viewing purposes. As such, it is perhaps reasonable to limit this portal to still and animated images primarily intended for viewing.

No Handling of Image Format Changes

Changes to the portal:

• The Desktop Containment Framework is not used, and only the image types defined in the portal are supported.
• Requirements, Portal: Check (1) consists of checking whether the selected image is supported by the portal, and check (4) is removed.
• Requirements, App Developers: They do not need to write the image formats they support.
• Functioning: Since check (4) is removed, then any results where it is "yes" do not apply.

Doing this means:

• An app can access neighboring images for formats it does not support if access is granted.
• Handling changes in image format support is not necessary, but the user will not be aware of these.
• Supported image formats cannot be displayed in the portal UI.
• It is important to tell the user that this is any format, regardless of whether the app supports it. However, this does not appear to give much confidence.

Mockup

See https://gitlab.gnome.org/Teams/Design/whiteboards/-/issues/221#note_1960562.

Questions

• Is it better to be able to set permissions for each image category?
• UI Design: How to adequately communicate to users what "source image formats" are? Communicate it with a description (and which one)? Or just show each specific format individually, assuming there won't be many of them? See Neighboring Files: Neighboring Images #1257 (comment)
• Would it be useful to instead set the permission at app startup?
• Is there another way to handle changes in app supported image formats that doesn't go through the DCE, but through the portal?
• Mockup: Any suggestions for better communicating that source image formats are not supported for the Simpler Portal?

[Mikenux]

Update (use the "edited" button):

• Small changes.
• Added validation of image formats (with flatpak) and a question relating to it.
• Added removal of permission to access neighboring images.
• Other suggestions to simplify the portal (no "confirm" access permission and no support for application-specific images).
• Added a mockup and a question relating to it.

[Mikenux]

Update 2:

• Some corrections.
• Optionally inform about the deletion by the application of image types that it supported.
• Added questions about setting permissions per image category and displaying app-specific image formats individually in the portal UI.
• Added "I need a developer 🙂"

[Mikenux]

Update 3:

• Supported image formats are defined in the portal, so they are updated regardless of the desktop containment framework used.
• I need a developer -> I need to be developed (there are also developer teams!).

[Mikenux]

Update 4: Added reference to #1257 (comment) which clarifies what I want when talking about app-specific image formats.

[Mikenux]

Update 5: Clarifications.

[Mikenux]

Update 6:

• Rename "app-specific image formats" to "source image formats".
• Added the section "never Access For Specific Folders", which is an idea to replace the "confirm" permission.

[Mikenux]

About app-specific image formats.

What I want to do is to differentiate between image formats that were primarily designed for viewing and those that are primarily intended for creation and design.

Examples:

• Designed to be viewed: jpeg, png.
• Creation and design: xcf (GIMP), kra (Krita), svg.

I hope what I want is a bit clearer.

[Mikenux]

I now use "source". "project" seems another good candidate. What do you think?

[sophie-h]

• They must write the image types/extensions they support into a reference file.

I don't think that's how it mostly works in practice. The libraries for image viewing I am familiar with are GdkPixbuf, Libheif, and Glycin (which I wrote.) All support adding support for more formats via Flatpak extensions.

Maybe that would work if the extensions bring files that are also checked by the portal.

[Mikenux]

Three questions here:

• Should I then also include the runtimes if they include one of these libraries?
• Wouldn't it complicate the portal to also check which version of an extension/runtime an app is using? In this case, I think a helper app would be better.
• Is it sure that an app using a library actually supports all the formats supported by this library?

[sophie-h]

• (still) images, animated images, and app-specific image formats

WebP, APNG, GIF, and JPEG XL can be animated without being part of the mime type. So I don't think that differentiation is practical and it also doesn't seem to be relevant later anywhere.

However, I think it's only a question of time until someone wants to build a viewer that includes images and videos when browsing as it is the standard on phones. So I think video should be considered in this proposal as well.

[Mikenux]

Ok thank you. The still-animated differentiation then no longer has any importance in the portal itself. However, in its user interface, it seems important to me to specify that images include animated images (that's how we call them, and besides I thought that GIF was only an animated format since it is mainly used for that on the internet).

Videos can be added, but then their access permission is separate from that for images. This would also remove the option of the "confirm" permission.

[Mikenux]

Aren't apps that support both videos and images apps that use "library" folders?

[sophie-h]

I thought that GIF was only an animated format since it is mainly used for that on the internet

Before PNG was available in browsers, GIF was the only supported format that supported transparency. So this is not at all true.

Aren't apps that support both videos and images apps that use "library" folders?

I have heard the same argument for plain image viewers. I don't think it makes sense to make that distinction.

[Mikenux]

I thought that GIF was only an animated format since it is mainly used for that on the internet

Before PNG was available in browsers, GIF was the only supported format that supported transparency. So this is not at all true.

That's what I thought, or believed if you prefer. I didn't say it was a certainty. How you perceive things depends on your experience with the Internet (not when PNG support in web browsers was added).

Aren't apps that support both videos and images apps that use "library" folders?

I have heard the same argument for plain image viewers. I don't think it makes sense to make that distinction.

This distinction is important in knowing whether we really expect videos to be automatically accessible, even when asking for permission. The thing is, I'm careful about what to add. If an app isn't expected to access videos for browsing outside of a library, it's best not to even suggest it in a portal UI. However, that doesn't mean I'm not open to it, I just prefer to add cases if they are truly expected.

[Mikenux]

Perhaps add it, and possibly any other type (but to be evaluated depending on what is requested), but only present the app request when the neighbors of the targeted type are detected (as in the proposal), instead of asking for everything at once; this attests a bit better that the app wants to access a type of file that it opens (or at least that the user tries to open with).

Also, in the UI it would be better to present this as an optional feature of the app rather than the app wanting or requesting something (like I tried to do). This seems reasonable to me. What do you think?

[Mikenux]

Closed in favor of #1271.