Hi –
I have a snap ‘draftman’ currently available in the snap store with classic confinement. I have completely rewritten it and would like to request classic confinement for my new snap, ‘draftman2’.
In short, I need classic confinement because draftman2 lets the user select arbitrary paths to installed markdown editors and backup locations for open projects. E.g. the user can double click a file within the app and it will use the user-chosen editor to open the file.
This is forum link to the version 1 of this snap which was approved a while ago:
I’m hoping someone can approve the manual review. Thanks!
Back when this was discussed for draftman, there was a suggestion to use portals, but the conclusion then was that portals were still a bit immature - I wonder if the situation has improved and whether this would be a viable option this time around? @jamesh can you comment on the status of portals and core18 etc? It looks like draftman2 already uses base: core18 and the gtk3 desktop helpers (https://github.com/jsseidel/draftman2/blob/master/snap/snapcraft.yaml) so I am hoping this might be better alternative.
This would be great. @jamesh, if portals are mature enough to use, can I trouble you to point me towards some docs, or better, examples?
Looking back on that thread, this is what concerns me about portals:
The main problem is that there is currently no guarantee that the portal service will be available on the user’s system. We’ve got xdg-desktop-portal 1.0.3 successfully backported to xenial, bionic, and cosmic, but there’s nothing to get it installed on people’s computers. That will probably require adding it as a dep for ubuntu-desktop , since it’s not really an appropriate dep for snapd itself (since that would bring the whole desktop stack into server images, for instance).
Another is that it is possible to use a command-line editor (vim) with my app if you open it from a terminal. I’m not saying that’s a normal use case, but maybe someone would want to do it, who knows?
Portals, as I understand the world, and I could be totally wrong, obviously, work similarly to how gnome chooses appropriate applications by mime-type, which isn’t quite right for what my app does. For example, I almost never use a WYSIWYG for opening Markdown files, unless I’m using my own app for writing 
In other words, I need to choose specific apps for files based on their content and not their mime type, which is, I suppose, the main thrust of my argument.
Granting use of classic since the publisher was previously vetted and this is an iteration on the same application.
I do think the portals question is worth looking into and if/when it suits your application, you can move towards it.
Thanks. I agree about portals. It would be great to have a clean way of doing this kind of thing.
