Hi Alex,
thanks for moving on the process.
It would appear that I also need to add the “home” plug, which I had mistakenly assumed was automatically connected for read-write access to the users home directory.
I also remain unsure as to the needs for automatic connection to the network interface for read-write access to network connected storage, and I would be grateful if you would add this to the auto-connection requirement for photonotebook.
I have abandoned any hope of connecting to devices that use the mtp protocol with the mountpoints being in /run/user/"$UID"/gvfs/ …
While I greatly appreciate the improvements in security provided by snap containers (I am a CISSP) and the apparent ease that library dependencies can be managed, the impact on the user experience can be considerable for desktop apps which rely heavily on interfacing to storage both local and via comms channels though the file manager. The kind of users my apps on Android and now Linux are targeting are not primarily computer experts, so any technically oriented “drag” on usability is likely to result an a negative user response. Any chance of a “extended - storage” extension similar to the gnome-3-34 extension that greatly simplifies display interfacing? I’m sure that most serious desktop Apps that create, import and export data files will need to interface to storage and devices by whatever communication channels are available.
For example, I have published the App without waiting for your auto-connection and vetting results, and have included workarounds that will make the app usable, yet to some non-technical users these workarounds will be insuperable obstacles. In contrast I have a Windows 10 version of the App nearly ready for publication and on Windows 10 it’s just install, click and go, with no extra steps required!
may thanks for the help that you and your colleagues have shown in supporting this App.
cheers
Alan
