Autoconnect removable-media for fre:ac snap


#1

I would like to request auto-connection of the removable-media interface for the fre:ac snap: https://snapcraft.io/freac

fre:ac is an audio converter and should be able to acces audio files on removable media for conversion. Also, the user should be able to configure an output folder on removable media.


#2

While it is clear to me why your snap should plugs the removable-media interface, it is not clear to me why it should be auto-connected for all users. The snapd system is meant to include several voices wrt auto-connection: the publisher (through the act of plugging interfaces), snapd (the default policy), the store (the snap declaration you are seeking) and the user. The user has the ability to connect the interface on an as needed basis (and can connect via a gui in gnome-software on Ubuntu and the snap-store snap elsewhere).


#3

Yes, it became clear to me that this would get controversial after I read other threads of developers requesting removable-media auto-connect. :wink:

In my opinion - but that’s just mine - it would make sense to allow auto-connecting the removable-media interface for apps like media players, converters, editors and file utilities. These types of apps simply are not very usable without having access to the files that a user might want to open with them and media files are commonly stored on external drives.

I think that most users won’t bother to find out why a Snap cannot open their files or how to fix it. They would just uninstall the Snap and look for alternatives. There are several posts in different forums and bug trackers complaining about e.g. the VLC Snap not being able to open files, without any indication that the users know what’s going on (e.g. [1][2]).

As far as I know, the removable-media interface currently is the only way for Snaps to access files outside of the users home directory, so to make these types of apps actually usable by default, I would expect them to be allowed to auto-connect this interface.

I know that work is going on to support the XDG desktop portal which would allow opening arbitrary files via the GTK and Qt file selector dialogs. That would be great and probably eliminate the need for bulk removable media access for some apps.

Ideally, from my developer perspective, the sandbox would automatically grant access to files if:

  • They have been selected via a file selector dialog (would be possible with XDG desktop portal support)
  • They have been dragged & dropped into the sandboxed application (there seems to be work going on on the XDK desktop portal side to support this)
  • They have been passed as command line arguments

I think this would remove the need to use the removable-media interface for most apps. So maybe auto-connect could be granted now, as long as other options are not yet available, but be reviewed once desktop portal support or some other solution is ready?

Of course it could (and probably should) be indicated to the user more clearly what access rights are requested before installing - e.g. by displaying the existing access rights dialog when confirming to install in Gnome Software.

[1] https://askubuntu.com/questions/875421/vlc-wont-open-video-files-from-a-secondary-interal-hard-disk
[2] https://trac.videolan.org/vlc/ticket/20218


#4

Thank you for your response. While I agree more should be done here (indeed, more is being done here with portals coming back to 16.04 and other methods of improving the sandbox), there are ways in which the user can be made aware that the interface is diconnected. Specifically via gnome-software and/or the snap-store snap, and in that the snap can detect the situation and let the user know to connect the interfaces.

-1 to autoconnect


#5

@reviewers - can one or more of you also vote on this?


#6

I agree, -1 to autoconnect as well. The experience is certainly not ideal, but things are happening to make it better, and the snap can suggest the slot be connected.


#7

-1 from me too - agree this is not ideal but it is consistent with other similar applications and this should get better in the future as @kyrofa mentions above.


#8

0 votes for, 3 votes against. Not granting auto-connect for the removable-media interface.