Write plugin for Gnome Software

[probonopd]

Gnome Software is supposed to be modular and supposedly supports plugins for other software distribution mechanisms such as AppImage. Is there any documentation on how to write a plugin, preferably in Vala?

Need to investigate gs-plugin-limba.c, too.

[probonopd]

@hughsie of gnome-software states that there is no public plugin API (yet?) but AppImageUpdate integration would be "a great thing to add, and should be pretty easy" and suggests to have a look at the limba plugin and the xdg-app plugin in the wip/hughsie/xdg-app branch which both do a similar thing. He also kindly offers his help if required.

[probonopd]

There is now a snap plugin which possibly could give us some hints on how to write one for AppImage.

GNOME/gnome-software@82b15e9
"This allows you to browse snaps installed on your system and search for snaps from the snap store."

The snap plugin communicates with snapd which seems to do the "real work", such as "list snaps in the store that match the search term and that this system can handle".
So it looks like the snap plugin doesn't rely on AppStream information to make snaps available, but rather communicates with Canonical's Snapcraft store directly.

https://github.com/snapcore/snapd/blob/master/docs/rest.md

For AppImage, we want something more decentral, where the upstream application author is in control.

Also see #48

[hughsie]

There is now stable plugin api. See https://blogs.gnome.org/hughsie/2016/05/19/external-plugins-in-gnome-software/ for a good intro. R

[probonopd]

Thanks @hughsie. If you have a spare minute or two, I'd appreciate your thoughts on #48 (comment)

Note to self: https://people.freedesktop.org/~hughsient/gnome-software/plugins.html

[probonopd]

Trying to compile gs-plugin-example.c I get:

$ gcc -shared -o libgs_plugin_example.so gs-plugin-example.c -fPIC  `pkg-config --libs --cflags gnome-software`  -DI_KNOW_THE_GNOME_SOFTWARE_API_IS_SUBJECT_TO_CHANGE &&  sudo cp libgs_plugin_example.so `pkg-config gnome-software --variable=plugindir`
Package gnome-software was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnome-software.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gnome-software' found
gs-plugin-example.c:22:28: fatal error: gnome-software.h: No such file or directory
compilation terminated.

Ubuntu does not seem to have the required gnome-software.h file: Search

[hughsie]

Right, you need gnome-software from git; 3.20 is too old for the external plugin work. We'll only support out-of-tree plugins going forward in a stable release once 3.22 is released, sorry.

[probonopd]

Now that gnome-software 3.22.0 has landed in debian sid, I have been looking for gnome-software.h but it still seems to be missing; is there an ETA for it?

[probonopd]

Alternatively, how would I build gnome-software using JHBuild or manually from git?

[hughsie]

You can build gnome-software using jhbuild buildone gnome-software but in debian I assume you have to install a -dev subpackage to get the plugin headers.

[probonopd]

We'll only support out-of-tree plugins going forward in a stable release once 3.22 is released

@hughsie now that debian carries gnome-software 3.22.5-1 do you think it can be used to write plugins?

https://packages.debian.org/sid/gnome-software

[hughsie]

Yes, very much so.

[Ads20000]

Given that this commit will make it impossible to run AppImages from Nautilus (i.e. the default file manager of Debian, Ubuntu, Fedora, openSUSE...) from Nautilus 3.29 onwards, perhaps the plugin could also surface AppImages that are in the AppImageHub and any other collection of AppImages that the user specifies? Nautilus dev Antonio Fernandes (antoniof on GNOME IRC) expects GNOME Software to handle AppImages going forward. I gave the use-case of people wanting to download apps and run them without installing but his argument is that AppImages clearly somewhat depend on the system anyway so he can't understand why someone wouldn't install an AppImage (and he argues that downloading and marking executable is a minimal form of installation).

[TheAssassin]

@Ads20000 that's the plan, the plugin should just download AppImages from the "stores" and "collections".

Desktop integration can be performed with e.g., AppImageLauncher, which is already available in some distros.

[Ads20000]

Does appimaged not do desktop integration automatically? I don't know exactly how that works tbh...

[TheAssassin]

appimaged is one of many approaches to AppImage desktop integration. At the moment, it has a lot of performance issues, as it tries to monitor a lot of directories using inotify. See https://github.com/AppImage/appimaged.

AppImageLauncher uses a different approach that allows users some more control about the integration process. Instead of monitoring directories, it intercepts all calls to AppImages, and can therefore handle them more efficiently. Also, it uses a more centralistic approach, moving AppImages to a central directory instead of leaving them scattered across the entire system.

But that's actually off topic. The main point of the GNOME Software plugin would be to connect to these collections of AppImages, and allowing users to download them with a single click, similar to https://github.com/nomad-desktop/nx-software-center.

[Ads20000]

Yeah fair, actually Antonio gave this useful sketch of what could happen:

1. download Musescore.appimage
2. open the Downloads folder, optionally move the file to another folder
3. double click Musescore.appimage (to open in Software)
4. click "Install" (or call it "Trust and Run" if that makes more sense)
5. enjoy Musescore's awesomeness

I suppose Install would run chmod +x and perhaps AppImageLauncher (and give the option to install that if it's not installed, with a choice to dismiss the option permanently).

[TheAssassin]

@Ads20000 we don't call it "installation" but "(desktop) integration".

By the way, who's Antonio, and what does he have to do with this issue?

[Ads20000]

He's a Nautilus dev and I was trying to show him why removing support for AppImage is problematic but he showed me why it's not and thought up some suggestions of how it could work via Software. I think this makes sense since Files should deal with, uh, Files and it makes sense that installing and running software should be done through Software.

Yes you could change the 'Install' button to 'Integrate' but I wonder if that would be more confusing than helpful, hmm. Also it wouldn't be possible to run the AppImage without clicking that button because you need the chmod +x, unless maybe the Run button could do that on first run if it hasn't been done yet.

[TheAssassin]

@Ads20000 desktop integration is a separate issue, and actually out of scope of the GNOME stuff. As we want to provide a consistent experience across distros, it seems more appropriate to maintain an external, independent project. At least for now.

What a GNOME Software plugin would have to do is help the user download AppImages. Then, the user can combine this with a desktop integration solution that fits their needs. Heck, GNOME could even ship their own tool for that. But you shouldn't depend on GNOME Software to run AppImages on GNOME. One of the core features of AppImages is their portability. They're self contained single files, which don't depend on any external tool or app store or whatnot. You shall be able to simply move them to a USB disk and use them everywhere, or delete them via a file explorer. They're simple files, after all. Users know how to handle simple files. Any soft of dependency on an external tool is against the goals of AppImage. But enhancements are welcome. These involve the desktop integration tools which improve the UX, and tools like NX Software Center that can be used to browse AppImage collections online.

IMO GNOME totally overrate the user experience of app stores... and slowly but steadily, they ruin the good ol' computer experience everyone's used to in favor of some bizarre new and completely abstracted approach that doesn't add anything to the user experience but makes understanding the processes on a computer way harder. Their desktop environment becomes more and more monolithic, and less interoperable with non-GNOME tools. That's not really POSIX-ish, and not the way a free software project should work.

[probonopd]

Two separate issues at hand here:

1. Nautilus user experience being crippled. Not just for AppImages, but for all types of executables.

2. How to "install" (as you like to call it) AppImages in GNOME. Point is, AppImages are meant as "one app = one file" that need no installation (like on the Mac).

Both need to be solved. Many options.

1. Replace GNOME by e.g., XFCE
2. Remove Nautilus by e.g., the ROX file manager (which also handles AppDirs properly)
3. appimaged (although that only solves 2 but not 1)
4. AppImageLauncher (although that only solves 2 but not 1)
5. Something along the lines of (so far untested on the Nautilus version in question)

cat > /tmp/executable.desktop <<\EOF
[Desktop Entry]
Version=1.0
Name=executable
Exec=bash -c "FILE=%f;chmod a+x \\$FILE;exec \\$FILE"
Icon=utilities-terminal
Terminal=false
Type=Application
Categories=Application;
MimeType=application/x-executable;
NoDisplay=true
EOF
sudo desktop-file-install /tmp/executable.desktop
rm /tmp/executable.desktop

sudo update-desktop-database /usr/share/applications/

But best would be:
GNOME fixes Nautilus issue #437

[TheAssassin]

Your script is unfortunately a bad hack. Not really ideal. If there was a dialog, though, something like "ELF launcher", that'd work.

I think desktop-file-install updates the relevant entries in the desktop database by the way.

[Ads20000]

@TheAssassin

But you shouldn't depend on GNOME Software to run AppImages on GNOME.

They're self contained single files, which don't depend on any external tool or app store or whatnot.

Well currently you're depending on GNOME Files to run AppImages on GNOME (by default)? So you're depending on external software either way?

[TheAssassin]

Well currently you're depending on GNOME Files to run AppImages on GNOME (by default)? So you're depending on external software either way?

I don't know what you're referring to, please elaborate.

[probonopd]

@Ads20000 we are not depending on Nautilus (a.k.a. "GNOME Files") to launch AppImages. They can also be launched e.g., from the command line. But the most convenient way is just to double-click them, as you do with a Mac .app or a Windows .exe.

To me personally it seems completely counterproductive to remove this functionality from a file manager. How often have we all double-clicked .exe files in Windows? I mean, removing this from a file manager is like removing the ability to play video from a video player.

But we are getting off-topic here; this discussion should continue where it belongs - in the Nautilus bug report.

[Ads20000]

I don't know what you're referring to, please elaborate.

You want to retain the ability to launch AppImages from GNOME Files, rather than opening/installing (chmod +x) AppImages via (a) GNOME Software (plugin).

You said

What a GNOME Software plugin would have to do is help the user download AppImages. Then, the user can combine this with a desktop integration solution that fits their needs. Heck, GNOME could even ship their own tool for that. But you shouldn't depend on GNOME Software to run AppImages on GNOME.

But by requiring Files double-click support you are 'depending' on GNOME Files to run AppImages on GNOME, just as you would be depending on GNOME Software with this plugin.

But we are getting off-topic here; this discussion should continue where it belongs - in the Nautilus bug report.

I'm responding to @TheAssassin 's point that you don't want to depend on GNOME Software by saying that you're depending on GNOME Files in a similar way to the way in which you'd be depending on GNOME Software. If you launch from Terminal, you're depending on the Terminal...

[TheAssassin]

That's not a dependency. You don't need to call AppImages from any kind of file manager. You can launch them from the CLI as well. This counts as "enhancement" but not as "dependency".

[Ads20000]

So then launching from GNOME Software instead of Files would be an 'enhancement' on CLI use and not a 'dependency'?

[TheAssassin]

@Ads20000 the problem is how GNOME Software would handle AppImage files, and where it'd put them. If you can't find them because they're in some weird system-wide location or are sandboxed and intentionally hidden from the user, then a CLI use is no longer possible. In this case, you'd depend on GNOME Software to run the downloaded files, wouldn't you?

[probonopd]

Also, I'm not sure whether GNOME software is flexible enough to handle, e.g., all the different versions (including historic ones) and different build variants of e.g., the LibreOffice project:
https://www.libreoffice.org/download/appimage/. A GNOME Software plugin would be great, but as something optional/additional, not the only way to get AppImages on GNOME.

---

Looks like we can build plugins now like this:

# Ubuntu 18.04

sudo apt update
sudo apt -y install gnome-software-dev
sudo apt-get -y build-dep gnome-software
wget http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-software/gnome-software_3.28.1.orig.tar.xz
tar xf gnome-software_*.orig.tar.xz
cd gnome-software-*

meson --prefix $PWD/install build/
ninja -C build/ all install

cd contrib/
gcc -shared -o libgs_plugin_example.so gs-plugin-example.c -fPIC  `pkg-config --libs --cflags gnome-software`  -DI_KNOW_THE_GNOME_SOFTWARE_API_IS_SUBJECT_TO_CHANGE 
sudo cp libgs_plugin_example.so `pkg-config gnome-software --variable=plugindir` # installs into the system
cp libgs_plugin_example.so ../install/lib/x86_64-linux-gnu/gs-plugins-11/ # installs into local build
cd -

killall gnome-software
XDG_DATA_DIRS=install/share:$XDG_DATA_DIRS ./install/bin/gnome-software

However, it will still take time until a stable API is provided in the oldest still-supported LTS distribution, at which point it will become feasible to us to (optionally) use. (Unless we make our own AppImage of GS and its plugins, that is.)

[probonopd]

Started dabbling around and writing the beginnings of a GNOME Software plugin for AppImage. Looks like I have more QUESTION comments (marked as such in the code) than anything else ;-) Comments, answers, hints welcome!

https://github.com/probonopd/gs-plugin-appimage

Conceptually, it is not clear to me how GNOME Software is supposed to handle multiple versions of the same app, coming from different packaging systems and being in different channels (stable, nightly,...):

• LibreOffice stable version A (built by Canonical) comes with the distribution
• LibreOffice stable historical major versions A-1,... A-n have been added to the system as AppImages by the user (e.g., a tester who wants to test regressions) (of course these looked all very differently and hence need different screenshots, different description texts as features have evolved over time,...) - the user doesn't want to be bugged about updating them because he does not want them to be updated
• LibreOffice nightly has been added to the system as a Flatpak (it should clearly be recognizable as "nightly")

How can it be ensured that these are still known as "belonging together" but the correct icons, screenshots, feature descriptions, etc. appear for the corresponding versions and LibreOffice 2 doesn't all of a sudden show icons and screenshot of LibreOffice 5?

Also, regarding fetching information about available AppImages:

• What is the easiest way to get the information about installable AppImages from https://appimage.github.io/feed.json into GNOME Software? Is there (another) standard format that would be more suitable than the JSON feed?
• Is it possible to fetch certain information (e.g., the latest version) only once the user opens the product detail page? This is to avoid traffic, as we want to check for the latest version in the second when the user opens the product detail page, and only for those applications the user is really interested in (rather than for all applications) because getting the version information requires us to make costly HTTP requests

Maybe @hughsie can have a look at my (noob) questions. Thank you very much!

[Ads20000]

How can it be ensured that these are still known as "belonging together" but the correct icons, screenshots, feature descriptions, etc. appear for the corresponding versions and LibreOffice 2 doesn't all of a sudden show icons and screenshot of LibreOffice 5?

As far as I understand, the Ubuntu desktop team will be working on fixing these problems once AppStream support is finalized in snappy (which should be soon-ish; I'm guessing 'current cycle' means 2.33 which was meant to be out tomorrow but the beta isn't out yet so I'm guessing it won't be out for around a month or so). Perhaps you could go to irc://irc.freenode.net/ubuntu-desktop and ask them what their thoughts are :)

[Thatoo]

Any news on this very interesting project that would make AppImages even more accessible? It looks like gs-plugin-appimage has stopped.

[probonopd]

As far as I know, no one is working on it.
Personally, I am not using Gnome, Gtk, nor Gnome Software.