Request to autoconnect removable-media for gnome-text-editor

[SergioCostas]

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.

[sahnaseredini]

This a clear case and the user should expect this. +1 for auto-connect to removable-media for gnome-text-editor snap

[soumyaDghosh]

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.

[SergioCostas]

Mmm… good point. So it isn’t using portals by default…

[SergioCostas]

I’ll try with GTK_USE_PORTAL=1

[SergioCostas]

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…

[SergioCostas]

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.

[James-Carroll]

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

[SergioCostas]

The odd thing is that the gnome-text-editor code does have some extra checks for “GTK_USE_PORTAL”…

[SergioCostas]

Ok, setting both GTK_USE_PORTAL and GDK_DEBUG=“portals” seems to work…

[soumyaDghosh]

gnome-text-editor version 45 will fix this issue. Before this release, Gtk.FileChooserNative was used, which for some reason was not able to use portals in snaps, but were able to use it in flatpaks. Gtk.FileDialog fixes it. I have two such snaps clapper, metadata-cleaner facing the same issue. This is a related forum post.

Doesn't use the xdg desktop portal

Hey everyone, I’m creating a snap package of a GTK4 app but it doesn’t seem to use the xdg desktop portal despite using Gtk FileChooserNative: To test it if needed, login to an instance and try to upload or save media. logs: = AppArmor = Time: Mar 16 14:01:28 Log: apparmor="DENIED" operation="open" class="file" profile="snap.tooth.tooth" name="/proc/3253/mountinfo" pid=3253 comm="gmain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 = AppArmor = Time: Mar 16 14:01:28 Log: apparmo…

EDIT: gnome-text-editor version 45 have not implemented Gtk.FileDialog yet. Sorry about that

https://gitlab.gnome.org/GNOME/gnome-text-editor/-/blob/main/src/editor-window-actions.c#L349

[SergioCostas]

I created an extra patch that adds GDK_DEBUG=portals

Add full portal support

But I’m not sure if it’s a good idea… What do you think?

[soumyaDghosh]

Shit, I made one too!

Update to version 45 and force the use of portals

[jamesh]

@James-Carroll

@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

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:

1. Follow up on this thread in GLib MR !3037, and make glib_get_sandbox_type a real exported API of libgio.
2. In GTK, replace gdk_running_in_sandbox body with glib_get_sandbox_type() != G_SANDBOX_TYPE_UNKNOWN or 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.

[sahnaseredini]

Hi @SergioCostas , I see that the issue has been solved using portals. Do you still need auto-connect to 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.

[SergioCostas]

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.

[soumyaDghosh]

@SergioCostas what about old Ubuntus?

Autoconnect request for celluloid

Hey there similar to Autoconnect Request For MPV i want to seek autoconnect request for removable media for celluloid, its a media player and users would expect access to removable-media OOTB. Hence please initiate this request. Do note; Celluloid Snap is recognised by upstream as a acknowledged way of application distribution. See : https://celluloid-player.github.io/installation.html & https://github.com/celluloid-player/celluloid/blob/master/README.md Snap Manifest; https://git.launchpa…

Like here mentioned, that it didn’t work in Jammy. It’s not that much old.

[SergioCostas]

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.

[soumyaDghosh]

Yeah… that should not work but it works when opening the dialog from within the text-editor right?

[SergioCostas]

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.