Oppening Pinta by clicking on a png file does not work under Ubuntu 24.04 Gnome

[qwalker666]

Description When you try to open Pinta by clicking on a .png image file, it just opens with a blank canvas. The image file can be loaded manually without issue.

To Reproduce Just define Pinta as default for png files and click on a png image.

Additional Info If applicable, add a screenshot or attach an example file that demonstrates the issue.

Version Pinta 3.0.1 under Ubuntu 24.04.2 LTS, Gnome 46 with Wayland and Linux 6.11.0-26-generic

[cameronwhite]

Thanks for the report! Which method did you use to install Pinta? (e.g. snap, flatpak, other ..)

I tested in a 24.04 VM and this worked for me with the snap package

[qwalker666]

Hi Cameron,

Thanks for your response. I have Pinta 3.0.1 installed as a snap package in the gtk3 v 2.1.2 channel. Perhaps this issue is peculiar to my system. I should mention that I have the / partition in an ssd drive and my files in another partition in a hard disk...

However, I tried opening a .png file with Pinta by doubleclick in the /tmp directory and the same error results:

GLib.GException: Error when getting information for file “/tmp/SouthAmerica_map_orig.png”: No such file or directory at Gio.FileHelper.QueryInfo(String attributes, FileQueryInfoFlags flags, Cancellable cancellable) at Pinta.Core.GioExtensions.GetDisplayName(File file) at Pinta.Core.WorkspaceManager.OpenFile(File file, Window parent)

As usual, the file is opened with no issue from the Pinta "Open image file" menu ...

Please let me know if I can be of further assistance, Pinta is a great simple tool for me.

Gonzalo

El dom, 29 jun 2025 a la(s) 1:51 p.m., Cameron White ( @.***) escribió:

cameronwhite left a comment (PintaProject/Pinta#1569) https://github.com/PintaProject/Pinta/issues/1569#issuecomment-3016854545

Thanks for the report! Which method did you use to install Pinta? (e.g. snap, flatpak, other ..)

I tested in a 24.04 VM and this worked for me with the snap package

— Reply to this email directly, view it on GitHub https://github.com/PintaProject/Pinta/issues/1569#issuecomment-3016854545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHGRM7KAHK4WI75R74RVYNT3GAKPJAVCNFSM6AAAAACAHOAYM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJWHA2TINJUGU . You are receiving this because you authored the thread.Message ID: @.***>

[cameronwhite]

I was testing Pinta 3.0.1, but it's quite possible that there is different behaviour if you're actually using v2.1.2 which is the old GTK3 version

However, if you're opening files from /tmp/ I think the sandboxing can interfere with this (see #1357 for the flatpak package). The file open dialog goes through the sandbox portal so that would succeed

[JGCarroll]

For the snap, /tmp can't be worked around. The Flatpak can with the comment above to disable the sandboxing for it (either per folder or for the whole system).

The ideal situation for Pinta (and all Flatpaks/Snaps) would be that the file browser would use the same underlying implementation of the documents portal and pass the file to Pinta through the backend document Portal. Unfortunately I don't think any do at the moment, even for Flatpaks, but I've always assumed the long term interest is there because when I was working with the org.freedesktop.portal.OpenURI.OpenFile portal there's actually a writable flag which I believe is intended to make sure the receiving application has write access even if the sandbox would usually prevent it, and the file manager should be capable of something similar.

For now however, /tmp is inaccessible to the snap entirely unless you were to access it through e.g., $HOME/tmp as a bind mount specifically, a regular symlink won't work as they can be made by non root users. You could do this by e.g., modifying /etc/fstab to automount /home/$USER/tmp to /tmp each boot, and this applies equally to all strictly confined snaps.

Otherwise, the GTK3 and GTK4 versions of the Pinta Snap would both have direct access to $HOME, /mnt, and /media, but everything else would only be accessible when opened via the file browser inside Pinta itself.

[cameronwhite]

When doing some googling I came across the --file-forwarding argument for flatpak run which is interesting (https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-run)

--file-forwarding
If this option is specified, the remaining arguments are scanned, and all arguments that are enclosed between a pair of '@@' arguments are interpreted as file paths, exported in the document store, and passed to the command in the form of the resulting document path. Arguments between "@@u" and "@@" are considered URIs, and any "file:" URIs are exported. The exports are non-persistent and with read and write permissions for the application.