Note though, that I think our long term approach should be to make it seven simpler, integrate all these Xwayland bits into our various extensions and make them respect a snap setting for running in kiosk mode.
I.e. today when packaging an actual wayland app with the gnome extension the only difference between a desktop and a kiosk application is the “daemon” line in snapcraft.yaml.
If we can get the same behavior for X11 apps and make the extension respect a snap setting to launch the app as daemon automatically you would just have to do:
snap install mir-kiosk
snap install eog
snap set eog kiosk=true
… and you got your pictureviewer kiosk up and running …
That will not only make electron packaging even easier but also save users from having to develop their own snap if they just want to “kioskify” an existing application from the store.
For policy reasons, we don’t support X11 on Ubuntu Core systems nor with mir-kiosk, only Wayland. That means making "kiosk"s of X11 applications will always need extra work within the snap. (See https://ubuntu.com/tutorials/x11-kiosk.)
In principle, some of that work could be rolled into a snapcraft extension, but would we want to pull an “X11 on Wayland” stack into every X11 application just in case someone wants it as a kiosk?
a big chunk of X11 bits are already in the extension anyway to support desktop apps (xkb, xcb, xfixes, xinerama, xrandr, xcursor, fontconfig and libX11 are all in there already).
so all we would need to add to the extension would be a few script changes, xwayland itself and any potential preload libs, that should not be a lot in case you are concerned about the size …
i find the policy argument a little moot as long as we still support you using X11 apps via xwayland on top of mir, we just make it harder for you to do so by forcing you to maintain a separate package (and we just push up our own hosting costs by forcing people into duplicating apps)
no, just a single X11 (kiosk) session that multiple apps shipped inside the snap are sharing, you didnt talk about “other snaps” above but i get what you mean … in either case that policy doesnt really matter for the “single kiosk app” use case … in fact it supports it wrt greater security IMHO.
@ogra Just happened to stumble upon this thread and I figured I’d let you guys know that Electron 12 (released to stable a couple of weeks ago) can now run under Wayland natively, courtesy of Chromium adding support for it upstream. This is the approach I’m currently taking for BeWell’s kiosk snap.
I can’t share a full working snapcraft.yaml file yet at this point, still figuring some things out on our end. But in theory you should now be able to launch Electron apps under Wayland natively (without Xwayland) by adding the following command line arguments:
No prob! By the way, I was wondering: in the example above you’re using the gnome-3-28 extension. Is there any reason you’re not using gnome-3-34 here? It’s more recent and seems to be better documented in the Snapcraft docs.
I’m asking because I’ve been switching between the two today, but the gnome-3-34 extension appears to be throwing me some errors on runtime. Might just be me, but was wondering if you saw the same behavior.
Hi Jake! Despite all the bits and pieces seemingly being available now, I couldn’t get this to work immediately and ended up sticking with Xwayland after all for now. It gets the job done!
I feel optimistic that running natively under Wayland should work now, but the cost of figuring it out myself outweighed the benefit of stripping out the relatively small amount of boilerplate left in @ogra’s original post.
I noted down my findings (on a Pi4) trying to make electron work as native wayland client (the first link in that post also goes to an updated electron-kiosk source that uses base: core20 and the gnome-3-38 extension with the old XWayland setup) at: