I am the author of WireframeSketcher wireframing tool. It’s a Java based Eclipse RCP application. It is already packaged and distributed as a deb/rpm/tgz package, but I wanted to try to provide a snap package too.
WireframeSketcher at its heart is a reduced version of Eclipse IDE. There is a snapcraft.yaml for Eclipse already, and I’ve used it as a reference for creating the snapcraft.yaml for WireframeSketcher. Since Eclipse uses classic confinement, I believe the same arguments apply to WireframeSketcher to prefer the same confinement. In any case the application works well with classic.
I did try to see what would it take to make strict confinement work, but honestly I don’t have enough know how to do it. Using gnome-3-28 extension I could launch the application. However there are several things that didn’t work out of the gate: printing, launching files in external viewer (for example opening a PDF) using SWT API, installing new plugins break the application completely. There are various dbus errors in the console that probably have something to do with the way dbus is being used in SWT. Printing wireframes and exporting them to various formats is the main task of WireframeSketcher so fixing these issues is a must.
As I see it, to make strict work might requires a deeper understanding of snap, and also might require some changes in the Eclipse platform which I am not in position to make. I believe that once Eclipse IDE can be made to use strict confinement, all others Eclipse RCP/SWT apps can follow and be made to work the same way too. But until then classic is probably the way to go.
Printing should be able to work by plugging the cups-control interface and to launch external applications, you can launch them via xdg-open using the desktop interface. To do this, you declare these interfaces as plugs in the snapcraft.yaml using something like:
As such I hope wireframesketcher should be able to run as a strict mode snap without the need for classic confinement - my understanding is that unlike Eclipse it is not a general purpose IDE so it should not need the full requirements of a general purpose IDE and so classic confinement should not be required.
Alex, thank you for the tips. I’ve tried connecting the snap-control interface and it does seem to solve the printing issue.
However other issues seem to be out of my control. Files are launched by WireframeSketcher, and by underlying Eclipse framework, using SWT API, which is a cross-platform Java API for GUI applications. I can see that on Linux SWT API uses g_app_info_launch_default_for_uri method to open a file in the default application, not xdg-open. Do you think that it’s the wrong API to use? If this method is not good for Snap applications then this must be changed in the SWT API (I can open a bug at bugs.eclipse.org for that).
Eclipse and WireframeSketcher also embeds the browser component which doesn’t work in the strict mode. The browser tab just opens and gangs there. In the console I can see messages like this:
** (WebKitWebProcess:21231): ERROR **: 09:23:14.580: SWT web extension: Call failed because ‘GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.eclipse.swt20932 was not provided by any .service files.’
SWT SessionManagerDBus: Failed to RegisterClient: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.1330" (uid=1000 pid=20932 comm="/snap/wireframesketcher/x7/opt/WireframeSketcher/j" label=“snap.wireframesketcher.wireframesketcher (enforce)”) interface=“org.gnome.SessionManager” member=“RegisterClient” error name="(unset)" requested_reply=“0” destination=":1.38" (uid=1000 pid=4494 comm="/usr/lib/gnome-session/gnome-session-binary --sess" label=“unconfined”)
No such problems in classic mode. I can’t say what SWT does wrong here, but yet again this is out of my control.
I am not sure what would make WireframeSketcher an IDE. It doesn’t bundle plugins for Java development and the like. However, like Eclipse, the general interface is still based around a file explorer and file editors, and requires access to a workspace directory (which can be under user.home). If needed, extra plugins can be installed, for example version plugin controls like EGit. I believe that IDE or non-IDE classification is not relevant here. The decision should be made based on whether the application works well with strict confinement or not. And from this point of view I believe that WireframeSketcher is not much different from Eclipse.
Based on this topic, it seems clear to me that on principle, wireframesketcher is an application that has a discrete set of tasks that is it meant to do, as opposed to an IDE that might invoke arbitrary build commands, pull in development files from /usr, require editor plugins and the like. I agree with @alexmurray that this sounds like a candidate for strict mode (not being able to make a snap work in strict mode is not typically a justification for classic).
That said, GUI java applications can be challenging to make work in strict mode for the reasons outlined. g_app_info_launch_default_for_uri() is a glib API, so in theory it could work with a new enough glib in the snap that supports portals. Even if it can’t, xdg-open is a freedesktop.org standard that Java should be using (and may, with the right options). For the embedded browser, you likely need to plugs ‘browser-support’ (we have several different browsers that use this, including webkit-based), though the DBus service error seems to indicate that it expects something on the system to be there/autostart that isn’t. The fact that it is calling gnome-session-binary is a bit odd and may indicate the end of a list of cascading failures. There is a ‘dbus’ interface that is meant to be used for this sort of thing, so perhaps you need to start a service that plugs that interface (hard to say based on the information given).
The snapcrafters team has snapped a number of applications and I suggest creating a new topic in the #snapcraft category to ask for specific help on the java issues from them and a whole bunch of other knowledgeable folks.
Thank you for the suggestion. I did test browser-support plug and the webkit error shown above was generated with this plug added.
Unfortunately the work required to make Java/Eclipse work as a strict snap app requires resources that I simply don’t have. I may revisit this task in the future, but for the time being I’ll continue providing Debian and RPM packages.
In my case I didn’t see specific Java problems. The problems that I saw are related to SWT and Eclipse API. WireframeSketcher is an Eclipse RCP app, which means it’s based on the same framework that is used by Eclipse. I imagine that most of the required changes to make strict mode work must be made in the SWT API.
The easiest way to see what changes are needed is to try and make strict mode work for Eclipse itself, and then try and fix the discovered issues in the SWT API. Even if in the end Eclipse will remain in classic mode, the fixes will be useful for other SWT and Eclipse based apps that require strict confinement. I’ve filed an initial bug report in Eclipse’s Bugzilla here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=552387
AIUI, Eclipse is classic not because it needs it to run, but because it needs to run compilers, access files in the host’s /usr, etc. I could be wrong; @reviewers, @advocacy, et al - feel free to correct me.
Yes, in some configurations Eclipse needs to have access to the development environment. What I am saying is that if it didn’t need such access, it still wouldn’t work in strict mode because of the outlined low-level problems.
Heh, yes, and I’m saying that there might be ways to make it work without modifying eclipse itself, through various techniques that those I’ve asked for help might be able to chime in on. Perhaps there are still some things needed. Thanks for creating the upstream bug (fun that a flatpak developer said not to bother with snaps ).
I think we are on the same page now. Hopefully we’ll get some good feedback.
).