Gnome-text-editor should be able to edit files located in removable media, thus we added to the last snap version the removable-media plug. I request to allow the autoconnection of that plug. The package is maintained by the desktop team at Canonical.
This a clear case and the user should expect this. +1 for
Hi, gnome-text-editor should be able to use portals, but as I see it is not. But, I can fix it. Should I share a PR?
EDIT: This is how we can achieve it
But, the icon is missing too.
Mmm… good point. So it isn’t using portals by default…
I’ll try with GTK_USE_PORTAL=1
Anyway, I presume that it is still required to have the removable-media plug for the case when the editor tries to open a file passed by command line…
Mmm… it doesn’t work… I tried to open the .bash-history file using the portal, and it allows me to select it, but can’t load it because I don’t have permissions.
I remember GTK discussing removing
GTK_USE_PORTAL in favour of
GDK_DEBUG=portals. Relevant discussion https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829, which looks like it’s been in for long enough that I’ll just assume it’s in the latest releases.
Up until recently I’d been under the impression the GTK4 libs in the Core22 Gnome extension were fairly fixed, but apparently they have been rolling since the extensions release. I think in effect, portals probably worked for GTK4 apps when the extension was released, but might not be now, since the GTK upgrades?
@jamesh does GDK_DEBUG=PORTALS need appending alongside the older GTK3 logic here? https://github.com/snapcore/snapcraft/blob/4b1cff546cde4ddd933e92ae928ba140a78cef2b/snapcraft/extensions/gnome.py#L149
The odd thing is that the gnome-text-editor code does have some extra checks for “GTK_USE_PORTAL”…
Ok, setting both GTK_USE_PORTAL and GDK_DEBUG=“portals” seems to work…
gnome-text-editor version 45 will fix this issue. Before this release, , which for some reason was not able to use portals in snaps, but were able to use it in flatpaks.
Gtk.FileChooserNative was used
Gtk.FileDialog fixes it. I have two such snaps
metadata-cleaner facing the same issue.
This is a related forum post.
gnome-text-editor version 45 have not implemented
Gtk.FileDialog yet. Sorry about that
I created an extra patch that adds GDK_DEBUG=portals
But I’m not sure if it’s a good idea… What do you think?
Shit, I made one too!
This is a bit of a pain. That might be worth doing in the short term, but it is clearly not something they want us doing. Slightly longer term, we probably want:
- Follow up on this thread in GLib MR !3037, and make
glib_get_sandbox_typea real exported API of libgio.
- In GTK, replace
glib_get_sandbox_type() != G_SANDBOX_TYPE_UNKNOWNor whatever the public API ends up being called.
It looks like glib’s use of
GTK_USE_PORTAL was also changed in GLib MR !3602, but it correctly detects snap confinement already so the portal calls there function correctly.
Hi @SergioCostas , I see that the issue has been solved using portals. Do you still need
removable-media interface (e.g. for cases where desktop portals are not available)? In case it’s not needed anymore I can go ahead and remove this request from our queue. Thanks.
Ops… yes, you can remove this. It seems to work fine. If there are people with problems where portals aren’t available, I’ll open this again. Sorry.
@SergioCostas what about old Ubuntus?
Like here mentioned, that it didn’t work in Jammy. It’s not that much old.
Mmm… You are right, doing “double click” in nautilus to open a file with gnome-text-editor from a removable media could be a problem… So yes, it seems that autoconnect is needed here too.
Yeah… that should not work but it works when opening the dialog from within the text-editor right?
Yes. With portals enabled, you can open files from a removable media from within GTE, but can’t pass a URI that points to a file in a removable media. for the later, the “removable-media” plug must be connected.