Image converter toast shows & opens the wrong folder destination

[lo2dev]

Describe the issue Upon converting the image succesfully,the toast to open the parent folder shows and opens the wrong folder destination (some random sandboxed folder).

While also testing for this bug I also noticed the name of the converted image is empty, making it a hidden file that doesn't show up in the file manager unless "Show Hidden Files" is enabled.

To Reproduce Steps to reproduce the behavior:

1. Go to the image converter and open an image
2. Convert the image to any format
3. Click the "Open Folder" button in the toast

Expected behavior It should show and open the actual folder

Screenshots

https://github.com/user-attachments/assets/11defb1e-db08-4018-8998-fd5e8e3d83ad

Operating system (please complete the following information):

• Distro: Fedora Workstation 41
• Version: 1.2
• Desktop Environment: GNOME
• Xorg/Wayland: Wayland

Additional context Add any other context about the problem here.

[aleiepure]

Thank you for spotting this. Let me clarify a couple of things:

• flatpak apps are sandboxed, meaning they cannot access files outside their folder. Where needed a copy of only the selected file(s) is exposed from a temporary path (/run/user/1000/...). When saving the same applies, you select the actual destination path in the file picker but then the app has no idea where that is, hence the 'open folder' button location. If the app runs outside the sandbox (not something I support directly), the app can access every folder, and the paths are shown correctly.
• Because the name of the original image is lost upon closing the open dialog, when saving, the file name field is prefocused to allow you to type in a new name. The file extension is already precompiled. I am still running Fedora 40 (updating to 41 as I am writing), and this behavior works as intended. When the update finishes, I will check again and fix it if needed. Maybe I can precompile the name to something like converted-image.<extension>.

I will check if I can do something about the 'open folder' button to show the real folder but don't count too much on it.

[lo2dev]

Maybe you could open the image instead? Halftone for example does "Open Image" instead and you can open it in the image viewer which also displays the correct parent folder. The app i'm mentioning has access to system folder /tmp according to GNOME Software so i'm not sure if that's relevant or not.

I'm not familiar with this side of things yet, I'm still learning :))

https://github.com/user-attachments/assets/9a5f1e78-d42d-47ae-84ae-7247bc162bc7

If you can't do anything about it, it might be worth removing the toast.

[aleiepure]

Removing it is not an option as otherwise there is no confirmation that the image was saved correctly. I like the idea of opening the default app and I will consider implementing it, maybe without displaying the location. When I wrote the first version, launching other apps was not something possible yet.

[lo2dev]

Removing it is not an option as otherwise there is no confirmation that the image was saved correctly.

Yeah, no idea what i was thinking when i said that lol.

maybe without displaying the location

I would only mention the file name or just a simple label "Image converted successfully" if you go with opening in default app.

Maybe I can precompile the name to something like converted-image.

When an app generates a new file i expect it to give the file a default name or use the previous name but modified. I was confused for a minute or two because i didn't know why i couldn't see the files bc of the current behavior. Previous name would be ideal but a default name is still better than nothing :+1:

[aleiepure]

I have looked at the code of halftone and loupe. As far as I can tell, they use the same functions as mine, yet they manage to resolve the sandboxed path to the real one. I will keep investigating.

In the meantime, in #a69db2b I removed the paths from all toasts in the app, the buttons now open the relative file in the default app instead of the file browser in the parent folder and the text is a generic confirmation message. In addition, the save dialogs have been changed to the newer GtkFileDialog instead of the deprecated type I was using before, and the save names are precompiled to generic ones as the original names are lost after the files were opened.