Is using system(nautilus home/path/to/folder) an alternative?
Greetings,
Michael
@cmichael - if you are saying this is what snapd could do on behalf of the application, it could, but this is the equivalent of 3 and 4, above. If you are saying that the application could do this, absolutely, but the application would need to ship nautilus and whatever file editors it would want to support (this is a variation on what I said about shipping a small file chooser and editor and using xdg-open to open them).
Hello @jdstrand,
Sorry for silly questions but completely unfamiliar with system dependencies like this, fortunately for macOS and Windows it has been way easier and straight forward to open a folder…
Does this mean that I have to package nautilus, or mention it as dependency? I am not interested in support other file managers.
Greetings,
Michael
It isn’t a silly question at all! 
There are two things at play here:
- strict mode snaps run in restricted environment where they may only run things that they ship, run things that can run under the same confinement as the snap and/or talk to an out-of-process helper to do things on the snap’s behalf
- the Vmanager snap itself is taking a shortcut to avoid code complexity and calling xdg-open rather than providing a user interface for navigation itself (importantly, I’m not saying that the shortcut is wrong, just that this is what it is doing)
In the traditional (aka classic) world where everything in the user’s session is considered trusted, applications could do literally anything, but in the modern app-centric world (eg snaps), applications need to only access other resources in controlled ways.
It is completely understandable that you don’t want to ship a file manager and editor (I mentioned this above too). Your comment about opening a folder is interesting: it is easy to open a folder with snaps if you are using a toolkit that supports it. Eg, using the GTK/Qt file chooser works fine within a snap for opening files. Perhaps there is something in the toolkit you are using that can achieve what you want? Barring that, and assuming you don’t want to ship a file manager and editor (quite reasonable IMO), then what that leaves is talking “to an out-of-process helper to do things on the snap’s behalf”, which is precisely what my comments on xdg-open are meant to address and get the ball rolling for a design discussion.
(Note: that design discussion will happen; it just so happens people were on/going on holiday when I mentioned this)
Hello @jdstrand,
And thanks for the clarification. I understand what you mean with App Centric confident which is a nice thing and I am very pro that. but I my case all though it might look like a shortcut it is not and it doesn’t open the user to any vulnerabilities the path to the folder is hardcoded the user can’t exploit this by any way. The suggested QT solution is not a solution for me. Our toolkit is build in house, and a base for multiple application. Something can’t just be replaced or changed which doesn’t even need to be.
To further in this subject as I mentioned I have already achieved that on Windows( which provides a c++ toolkit that I could use for that operation) and macOS(which all though has stricter confidents it still gives you a way to achieve that). My point is that I would expect snap to follow in those steps. Either provide a toolkit that solves the severed tight cause by sandboxing or provide a way.
Because for example in my case, Its to expensive to try and figure out how to ship an explorer or any workaround for an operating system with the smallest margin, and for something so simple. Which for me it drives me away from snap and not to close, and its a shame, because I really like the idea.
Unfortunately, I have to park it for now. But please include me in the conversation, I want stay up to date on the subject.
Greetings,
Michael.
@cmichael - I think you misunderstood my comments. I was describing the current situation and what future work would need to be done to support your snap in strict mode, and pulling others in so they could participate in the design of that future solution that would accommodate opening a folder more easily within snaps where their chosen toolkit does not do what they require. Part of the process for classic confinement requests is gathering information for why classic confinement is required, and we’ve done that. Way back in Vmanager Snap Classic confinement I gave options for you. Since then I was only answering questions and trying to push the xdg-open helper design forward. I apologize if that was unclear.
Since you want to use xdg-open and do not want to modify your application or snap, then only classic confinement is available to you today.
@evan - can you or someone from your team perform the other parts of Process for reviewing classic confinement snaps?
Actually, yes. xdg-open now supports file:// for files and directories as of 2.32 (see https://github.com/snapcore/snapd/pull/4766 and https://github.com/snapcore/snapd/pull/4794). Can you try snap refresh core --edge and see if it works for you?
Hello @jdstrand,
Thank you! I will check it today. One question please bare with me, is there a release notes page? I couldn’t find this info on GitHub.
Greetings,
Michael.
@mvo often lists the release notes here in the forum. Perhaps the snapd release team would want to consider utilizing github more for this as well.