I wrote OpenAudible, a cross-platform java desktop application to manage audible (and other) audiobooks. (users are 10% linux, 23% Mac, 67% Windows. Would like to get the linux number higher!)
I use install4j to create the .rpm and .deb installers. I then wrote a script to build an AppImage.
Latest version: https://openaudible.org/latest/OpenAudible_x86_64.AppImage
Now I’d like to make a snap. But the learning curve looks steeper. Is there a service or developer who can assist?
OpenAudible includes a copy of the AMD64 (x86_64) openjdk-12 jre and launches an eclipse swt java desktop application.
The app creates a home folder ~/OpenAudible for config files. The app allows a user to choose and import files from the file system, or choose a directory to save files outside the “home” directory.
Networking includes an internal web browser and calls to a version checker for product updates.
It would be nice if there was a tool that could go from .rpm, .deb, and/or .AppImage and build a first pass attempt. AppImage might be preferred, since it is already a self-contained system-- just not containerized. Then modify the containment settings (allow https networking for instance) and specify which part(s) of the file system are accessible? I admit I am not a regular linux on the desktop guy.
Any suggestions welcome! Willing to put a bounty on this, if that’s an acceptable thing to do.
Hi,
I’ve dedicated a bit of time to looking at this for you. I’ve got the app packaged and launching, but the browser interface is broken by the Snap confinement. There is a recent upstream SWT code commit that attempts to fix this. I suspect you’ll need to test the new upstream code against your app for any breaking changes and roll a new version of the deb package before I can get any further.
ref: https://bugs.eclipse.org/bugs/show_bug.cgi?id=540060
1 Like
Daniel,
Thank you! I am looking at the eclipse bug reference and see if I
can figure out if I can get a build of swt for gtk that includes it.
How can I thank you? Will send a license code so you can test
with the whole version (if you want…) Not sure what a standard
“bounty” would be. I know these can be time sinks, especially when
you hit a crazy gotcha in the underlying code.
FYI, the plan will be to go to swap out OpenAudible/libs/org.eclipse.swt.gtk.linux.x86_64.jar
for a newer one from that includes
that patch.
I currently include gtk swt 4930 in OpenAudible 2.0.3. I’ll grab some newer ones and send you an update.
Again… thank you.
I posted a new AppImage with SWT 4.15 (released 4/5) that may have your bug fixed.
https://openaudible.org/prerelease/OpenAudible-x86_64.AppImage
(If you were working on the .deb file, apologies, I didn’t build one. You can extract the AppImage file system with: ./OpenAudible-x86_64.AppImage --appimage-extract )
Again, thank you for your time if you can try it again.
Hmm, I’m still getting GDbus failure with the updated AppImage files.
@jdstrand, do we have support for private dbus, as alluded to being a thing that Flatpaks can use in the bug at eclipse? I’m wondering if the Flatpak world has some kind of dbus magic that we haven’t copied?
For anyone following along at home, here is the snapcraft.yaml that I’ve worked up so far:
snapcraft.yaml
name: openaudible
adopt-info: openaudible # see 'openaudible' part's parse-info property
grade: stable
confinement: strict
base: core18
architectures:
- build-on: amd64
run-on: amd64
parts:
openaudible:
source: .
plugin: dump
# set version number, snap summary, and snap description from metainfo file
parse-info: [squashfs-root/usr/share/metainfo/OpenAudible.appdata.xml]
override-pull: |
# get the AppImage
wget https://openaudible.org/prerelease/OpenAudible-x86_64.AppImage
chmod +x OpenAudible-x86_64.AppImage
# extract the AppImage
./OpenAudible-x86_64.AppImage --appimage-extract
# remove the AppImage so it doesn't get copied into final snap package
rm OpenAudible-x86_64.AppImage
# Fix the permissions
chmod -R go+rX .
# Set the user.home parameter to a writable location and don't fork the process
sed -i -E 's|^./jre/bin/java|exec ./jre/bin/java -Duser.home=$SNAP_USER_COMMON|;s| > /dev/null 2>&1 &||' squashfs-root/AppRun
# We're not forking java so disown and exit are not needed
sed -i -E '/disown/d;/exit 0/d' squashfs-root/AppRun
# Set the Exec= line and Icon= line of the .desktop file to values suitable for Snap
sed -i -E 's|^Exec=.*$|Exec=openaudible %U|;s|^Icon=.*$|Icon=${SNAP}/squashfs-root/OpenAudible.png|' squashfs-root/org.openaudible.OpenAudible.desktop
apps:
openaudible:
command: squashfs-root/AppRun
desktop: squashfs-root/org.openaudible.OpenAudible.desktop
common-id: org.openaudible.OpenAudible
extensions: [gnome-3-28]
plugs:
- home
- mount-observe
- network
- network-bind
- removable-media
- upower-observe
I just updated the prerelase AppImage file to a newer eclipse library. I linked to an older swt due to my build script. Sorry.
But it looks like it works! Wow!
After cleaning, I was able to build using your yml
snapcraft --clean
snapcraft
sudo snap install open*.snap --devmode
openaudible
Originally I didn’t think it worked because I was testing on windows and expected it to work on xterm… but tried it on the physical linux box and it worked on the first try…
[edited]
1 Like
OK. Its close. Still looking like the eclipse swt dbus has some bugs.
New snapcraft.yaml is: http://openaudible.org/prerelease/snapcraft.yaml
Which grabs a newer (prerelease) OpenAudible.AppImage with some snap specific files included to avoid the sed search/replace.
Error looks like a permission setting:
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.170" (uid=1000 pid=3030 comm="./jre/bin/java -Duser.home=/home/oa/snap/openaud" label="snap.openaudible.openaudible (enforce)") interface="org.gnome.SessionManager" member="RegisterClient" error name="(unset)" requested_reply="0" destination=":1.19" (uid=1000 pid=15162 comm="/usr/lib/gnome-session/gnome-session-binary --sess" label="unconfined")
Which is the same error as: Request for classic confinement: wireframesketcher – which I think was a call to go classic, as the strict wasn’t working.
The good news (?) is that the app loads and looks OK… But crashes with an assertion failure after clicking on some GUI items.
(OpenAudible:3030): GLib-GIO-CRITICAL **: 13:58:00.780: g_dbus_server_get_client_address: assertion 'G_IS_DBUS_SERVER (server)' failed
Aborted (core dumped)
I’ve had a poke about inside snapd to see whether there is an appropriate plug for this. There doesn’t seem to be any currently defined, so it might be that we’re missing this functionality presently. I’ve pinged @jdstrand in IRC to see if we have a way forward. The likely outcome is we add some extra holes in the desktop interface inside the snapd code…
I’ve not had a look at this, but @lucyllewy is right that these accesses are missing from the interface code and I’ve added investigating this to the next batch of policy updates.
I’m unfamiliar with OpenAudible, but will say the if it is a gnome shell extension, this is currently unsupported by snaps (AFAICS OpenAudible is not a gnome shell extension so hopefully my investigation will result in updates to snapd to make it work).
That’s correct. OpenAudible is a standard application. I believe it uses the RegisterClient dbus call to request that it be notified when the user is logging-out, though I might be wrong here - I’ll defer that to @openaudible
OpenAudible uses Eclipse SWT (standard widget library) to create a cross-platform desktop app using java. It isn’t a super popular platform for writing apps… Similar to Swing. I unfortunately don’t know a thing about linux desktops and dbus and such. Just wanted a solution for linux people.
I also noticed OpenAudible on snap doesn’t work over xterm… running the AppImage works over an xwindows style terminal emulator on windows. Not sure if that is true for all snaps or just swt apps or just OpenAudible.
1 Like
