xdg-app lets us package applications and their dependencies together for Linux, so a user can just download the application and run it without either the developer or the user worrying about whether the correct versions of the dependencies are on the system. The various “runtimes”, such as the GNOME runtime, get you most of the way there, so you might not need to package many extra dependencies.
I put a lot of work into developing Glom, but I could never get it in front of enough non-technical users. Although it was eventually packaged for the main Linux distros, such as Ubuntu and Fedora, those packages were almost always broken or horribly outdated. I’d eagerly fix bugs reported by users, only to wait 2 years for the fix to get into a Linux distro package.
At this point, I probably couldn’t find the time to work more on Glom even if these problems went away. However, I really want something like xdg-app to succeed so the least I could do is try it out. It was pleasantly straightforward and worked very well for me. Alexander Larsson was patient and clear whenever I needed help.
I first tried creating an xdg-app package for PrefixSuffix, because it’s a very simple app, but one that still needs dependencies that are not in the regular xdg-app GNOME runtime, such as gtkmm, glibmm and libsigc++.
I used xdg-app-builder, which reads a JSON manifest file, which lists your application and its dependencies, telling xdg-app-builder where to get the source tarballs and how to build them. Wisely, it assumes that each dependency can be built with the standard configure/make steps, but it also has support for CMake and lets you add in dummy configure and Makefile files. xdg-app-builder’s documentation is here, though I really wish the built HTML was online so I could link to it instead.
Here is the the manifest.json file for PrefixSuffix. I can run xdg-app-builder with that manifest, like so:
xdg-app-builder --require-changes ../prefixsuffix-xdgapp manifest.json
xdg-app-builder then builds each dependency in the order of its appearance in the manifest file, installing the files in a prefix in that prefixsuffix-xdgapp folder.
You also need to specify contexts in the “finish-args” though they aren’t explicitly called contexts in the manifest file. For instance, you can give your app access to the network subsystem or the host filesystem subsystem.
Creating the manifest.json file feels a lot like creating a build.gradle file for Android apps, where we would also list the base SDK version needed, along with each version of each dependency, and what permissions the app needs (though permissions are partly requested at runtime now in Android).
Here is the far larger xdg-app-builder manifest file for Glom, which I worked on after I had PrefixSuffix working. I had to provide many more build options for the dependencies and cleanup many more installed files that I didn’t need for Glom. For instance, it builds both PostgreSQL and MySQL, as well as avahi, evince, libgda, gtksourceview, goocanvas, and various *mm C++ wrappers. I could have just installed everything but that would have made the package much larger and it doesn’t generally seem safe to install lots of unnecessary binaries and files that I wouldn’t be using. I do wish that JSON allowed comments so I could explain why I’ve used various options.
You can test the app out like so:
$ xdg-app build ../prefixsuffix-xdgapp prefixsuffix ... Use the app ... $ exit
Or you can start a shell in the xdg-app environment and then run the app, maybe via a debugger:
$ xdg-app build ../prefixsuffix-xdgapp bash $ prefixsuffix ... Use the app ... $ exit
Creating or updating an xdg-app repository
xdg-app can install files from online repositories. You can put your built app into a repository like so:
$ xdg-app build-export --gpg-sign="email@example.com" /repos/prefixsuffix ../prefixsuffix-xdgapp $ xdg-app repo-update /repos/prefixsuffix
You can then copy that directory to a website, so it is available via http(s). You’ll want to make your GPG public key available too, so that xdg-app can check that the packages were really signed by you.
Installing with xdg-app
I uploaded the resulting xdg-app repository for PrefixSuffix to the website, so you should be able to install it like so:
$ wget https://murraycu.github.io/prefixsuffix/keys/prefixsuffix.gpg $ xdg-app add-remote --user --gpg-import=prefixsuffix.gpg prefixsuffix https://murraycu.github.io/prefixsuffix/repo/ $ xdg-app install-app --user prefixsuffix io.github.murraycu.PrefixSuffix
I imagine that there will be a user interface for this in the future.
Then you can then run it like so, though it will also be available via your desktop menus like a regular application.
$ xdg-app run io.github.murraycu.PrefixSuffix
Here are similar instructions for installing my xdg-app Glom package.
I won’t promise to keep these packages updated, but I probably will if there is demand, and I’ll try to keep up to date on developments with xdg-app.
7 thoughts on “Playing with xdg-app for PrefixSuffix and Glom”
I try it, and I did:
xdg-app add-remote –user –gpg-import=murrayc.gpg glom http://www.murrayc.com/xdg-app/repos/glom/
xdg-app install-app –user glom org.glom.Glom
** Run the xdg-app like so:
xdg-app run org.glom.Glom
# int main(int, char**): exception from std::locale::global(std::locale(“”)): locale::facet::_S_create_c_locale name not valid
# int main(int, char**): This can happen if the locale is not properly installed or configured.
# (process:2): Gtk-WARNING **: Locale not supported by C library.
Using the fallback ‘C’ locale.
# Gtk-Message: Failed to load module “canberra-gtk-module”
# Gtk-Message: Failed to load module “canberra-gtk-module”
sys:1: PyGIWarning: Gda was imported without specifying a version first. Use gi.require_version(‘Gda’, ‘5.0’) before import to ensure that the right version gets loaded.
# Glib::ustring Glom::Conversions::format_date(const tm&): exception from std::locale(“”)): locale::facet::_S_create_c_locale name not valid
# Glib::ustring Glom::Conversions::format_date(const tm&): This can happen if the locale is not properly installed or configured.
# ERROR: sanity_check_date_text_representation_uses_4_digit_year(): Sanity check failed: Glom does not seem to use 4 digits to display years in a date’s text representation, in this locale. Defaulting to dd/mm/yyyy though this might be incorrect for your locale. This needs attention from a translator. Please file a bug – see http://www.glom.org
# Unexpected date text:
# (glom:2): glibmm-ERROR **:
# unhandled exception (type std::exception) in signal handler:
#Â what: locale::facet::_S_create_c_locale name not valid
Thanks for trying. You are not the first to have this problem with the locale: https://bugzilla.gnome.org/show_bug.cgi?id=619445
What distro is this? And what is your locale? For instance, what does this say in a terminal?
$ echo $LANG
If you are on debian or Ubuntu you might try the suggestion here:
Hmm, maybe you need to pull in the right locale for the runtime for this to work.
xdg-app install-runtime –user org.gnome.Platform.Locale.sv
for the swedish locale.
Does xdg-app-builder perhaps let you get away with “__comment__” keys? (Sadly I can’t test myself immediately.)
It does whatever json-glib does, which i believe should allow __comment__ keys.
Maybe you can also try AppImageKit (https://github.com/probonopd/AppImageKit) for packaging Glom.
While xdg-app sounds like it will eventually provide more advanced features — like sandboxing — AppImageKit works right now.
And for the end-user “installing” an app packaged as an AppImage is as easy as downloading one *.appimage file and making it executable. Then the only thing the user has to do to run your app is to execute that file — it doesn’t really get any simpler.
Hello, Have you thought about upgrading the procedure to provide a flatpak package for Glom?.
Recently, the project has been renamed and has taken momentum, generating interest in several projects to offer their applications in this way, including software stores to improve usability and ease of installation for the end user. It would be interesting to have Glom. Thank you.