Improve image page

[Antolius]

In case image is bigger than the application window it should scale down to fit the window.
User should have an option of zooming the image to its full dimensions or fitting it to window.
User should be able to right-click on the image, and the popup menu should have option to save or copy the image.

[Suzie97]

Hey @Antolius, I had this weird and probably impractical idea. But how about opening images using a proper image viewer and not inside Starfish? That would be proper UNIX philosophy.

Especially in elementary OS, the photos app opens single images pretty fast, and it would be one less thing to maintain for Gemini devs.

[Antolius]

@Suzie97 this is actually a great idea! I made a quick prototype and I'm really happy with how it works, UX-wise. Unfortunately, I don't know how to make it compatible with flatpak sandboxing.

I want clicking on an image link to either immediately open the image in the appropriate app or to prompt user to pick an app with app chooser portal first (if no default is established). This means I need to save the image into some directory accessible to other apps. To do that I can either:

1. Drill a hole in the flatpak sandbox and request a permanent write access to something like usr's home directory. Then I can freely save image files into downloads or images, or some other place and they will be accessible to the Photos app. The "only" problem is that I don't want to have this kind of access. Having read access is scary enough, I don't think write would be appropriate. (btw, this approach is what I tried out)

2. Or I can open a file chooser each time image link is clicked. This will allow the user an opportunity to grant Starfish write access to some shared part of the file-system. But in this case, as far as I know, user would need to manually launch Photos (or any other app) and then open the downloaded file themselves. This also breaks the flow completely. Even if I could trigger opening of the image saved in this way it would mean user has to go through both file chooser and app chooser portals in a sequence in order to get to the image. This, I fear, is too much.

I admit I'm not an expert on flatpak and portals, and there might be a third option that eludes me. But conceptually, what I'm trying to do is create a file from my app and have it opened by some other app. This does seem precisely like a security issue that sandboxing is meant to prevent.

[Suzie97]

@Suzie97 this is actually a great idea! I made a quick prototype and I'm really happy with how it works, UX-wise.

1. Drill a hole in the flatpak sandbox and request a permanent write access to something like usr's home directory. Then I can freely save image files into downloads or images, or some other place and they will be accessible to the Photos app. The "only" problem is that I don't want to have this kind of access. Having read access is scary enough, I don't think write would be appropriate. (btw, this approach is what I tried out)

I'm not an expert in flatpak and portals. So when we download a file using Starfish, how does it save the file to downloads? Doesn't that require write access? If that can already be done, then Starfish can simply download image files temporarily and delete them when the preview is closed.

[Antolius]

OK, turns out I was totally wrong about the "flatpak issue". I can download images into something like XDG_CACHE_HOME directory, and they will be accessible to Photos (or any other app). I'll clean up my feature branch, add some cleanup code and merge it in.

@Suzie97 thanks again for this suggestion, it's gonna be great!