One of the complaints people had with Polarr version 4 on Linux was that we took away their ability to edit photos on SD cards that they used to have with our deb package. I added the removable-media flag to the package.json for Polarr version 5 so that people have the option to open gnome software > search for “polarr” > click on polarr > click the “permissions” button > toggle “Read/write files on removable storage devices” to on. That’s a lot of steps so it would be convenient if the default auto-mount value for removable-media was “on” for Polarr.
If not using auto-mount for this permission, what’s the right way to 1) tell that a file failed to open because of the user’s snap permissions and 2) prompt the user to update their snap permissions to open their file?
A file in /media could fail to open because of permissions unrelated to Snap, couldn’t it? I could simply not have permission to read/write to a file in there. Do I have to hard code the /media path?
As a user, it’s confusing to me that some applications install with different permissions than others. I’ve been using snaps for a year now and I had no idea until recently that one could request auto-connection. I can’t even tell what permissions something is going to have until I’ve installed it and then it’s too late. The “permissions” button doesn’t show up until I install an application, so there’s no way to configure app permissions before it’s installed.
The app permissions should be apparent and configurable when before installing a piece of software. The reason I put Polarr in a snap with strict confinement was so that people would know what permissions we’re running with. I would expect an application designed to edit raw images on cameras to have permissions to at least read images on SD cards but that should be configurable by the user. Here’s how I would design our Polarr software store page so that people know what permissions they’re giving us when installing our app:
As for how to prompt, you could do something simple like @Lin-Buo-Ren suggested. Alternatively you could check to see if the interface is connected with snapctl get --plug :removable-media during a hook, then do something interesting with that (eg, touch a file and have your app see if it exists and let the user know how to connect the interface).
There are other snaps that do this. It is also surprising to me that polarr would have removable-media auto-connected and there are nice ways of letting the user know what to do. -1 to auto-connect.
When a file fails with EACCESS to open a file in /media and process.env.SNAP is set, I’ll try executing the command jdstrand specified in an Electron child process to check whether snapparmor is blocking access to the path. This needs to be implemented regardlesss of the default removable media connection state because the user can toggle it off after it’s set to on.
Is there a way to prompt the user for permission to open the file they just tried to open, or is the recommended flow to ask the user to open the software store and then search for our app and then press the permissions button to toggle the removable media permission? It would be great if we could default to minimum permissions without confusing people.
Note that use of the snapctl command can’t happen outside of hooks, but you can run the command as part of hooks and touch a file or something that electron could check for.
Not yet, but this is something on the roadmap. Today, you might also consider using the gtk3 filechooser which would use the file portal. I’m not sure how well portals work today with electron-- ISTR other had trouble with this a while back.
The file chooser should really be part of electron, but seeing as to how it’s not, I may be able to call it through the C++ API using a Node native addon. We already have native addons for raw processing and face detection. Could you link the documentation for that API?
The other way of opening files is with drag and drop. Drag and drop should be a trusted action but if I drag in photos from a USB stick then they fail to open. Is there a fix for this?
Missing snap information is an issue with the snap server, right? If you snap download polarr, then its permissions can be found without needing to install it by looking in polarr_9.snap/meta/snap.yaml at apps:polarr:plugs:
Portals won’t help with DnD currently. In an X11 session, DnD is entirely implemented through client side conventions as a data transfer between the two applications.
For Wayland, the compositor/shell has more knowledge that a DnD transfer is occurring. I’ve seen suggestions about how this could work: if the shell knows which clients are confined and what their app IDs are, then it could intercept the DnD payload and register the dragged URIs with the document portal and pass those modified URIs on. I don’t think this has actually been implemented anywhere yet, so it can’t be considered solved there either.
This topic is a bit sprawling, so I’ll try to bring it back to the original question.
-1 to auto-connect the removable-media interface since the user should have the choice to connect or not IMO. polarr itself could be adjusted to be more informative to the user and new developments like portals support can obviate the need for auto-connection in many cases.
a minor bug in the UI?