Plan on making a Gnome Software plugin but...

[PHPJosh]

As the title states i plan on working on an Gnome Software plugin maybe in few weeks after i get my first ISO out of cinchOS but think we may need to implement Appstream some how into the kit. been looking at the source for Gnome Software and it seems it heavily depends on it to work properly.

I will start taking a look at it in my spare time up until i get my first ISO out but any Ideas in this area would be helpful :)

[probonopd]

AppStream is also recommended by the AppImage spec. The AppStream developer is aware of AppImage and has recently added support for it to the <bundle> tag.

For the big picture, please read Thoughts on an infrastructure for distributing Linux application bundles .

Looking forward to your plugin.

[PHPJosh]

hmm so we will need to extract the Appdata out the AppImage and install it.. i will take a look at the desktop intergration and AppImage montior once i get done wrapping up on my first ISO as got about another week or so before i am done with that as still got quite a bit of packages to compile HAHA.

but from looking at the Gnome Software code the plugin will have to contain two parts. One to implement to Appstream parts of it then the second part for the actual sources for the AppImages which will probably use your bintray sources first and later on I also plan on adding a App section to the soon to be Website for cinchOS that will be curated and it will be able to pull from that source also. I will also make it simple to add more to it.

then the other thing is I don't have a clue how to actually contribute to Gnome atm which i am reading in to now as once its done i for sure want to try to push it upstream as it will benefit everyone if it does. til then though will host a fork for it at https://github.com/cinchOS/gnome-software/

[PHPJosh]

add about an extra week here as I have decided for the reasons of stability and some other issues with Arch (Packages being broken from get go when it comes to compiling them and other such issues, Rolling releases are Bad IMO) I am swapping to an Debian/Ubuntu Base and building from there. Not sure why i just didn't do this from start lol. other than i was using Arch when i got the Idea to build cinchOS rofl will post a status update once i get done swapping over which with it being Debian/Ubuntu should not take long

[probonopd]

This blog post by @hughsie outlines the GNOME Software (GS) plugin for Flatpak: https://blogs.gnome.org/hughsie/2016/07/05/flatpak-and-gnome-software/

I wanted to write a little about how Flatpak apps are treated differently to packages in GNOME Software.

Let me go through this in detail because I suppose many of the concepts could be used in a very similar way to handle AppImages. Comments welcome!

We’ve now got two plugins in master, one called flatpak-user and another called flatpak-system.

Maybe we need appimage-user and appimage-system then, too.

Per-user applications that are specific to just a single user account are an amazingly useful concept, as most developers found using tools like jhbuild.

...and AppImage ;-)

We default to installing software at the moment for all users, but there is actually a org.gnome.software.install-bundles-system-wide dconf key that can be used to reverse this on specific systems.

Then we should respect this key, too. AppImages are bundles just like Flatpak.

We go to great lengths to interoperate with the flatpak command line tool, so if you install the nightly GTK3 build of GIMP per-user you can install the normal version system-wide and they both show in the installed and updates panel without conflicting.

There is no AppImage command line tool for installing. One simply downloads an AppImage, makes it executable, and is done with it. But to handle things like desktop integration, there is an optional appimaged daemon. This is what the GS plugin could communicate with.

We’ve also got file notifications set up so GNOME Software shows the correct application state straight away if you add a remote or install a flatpak app on the command line.

How does this work? appimaged could notify GS in the same way.

At the moment we show both packages and flatpaks in the search results, but when we suggest apps on the overview page we automatically prefer the flatpak version if both are available. In Ubuntu, snappy results are sorted above package results unconditionally

I tend to agree in that upstream-provided bundles are usually newer, and hence, preferred.

The same app is really shown twice in the search results. Why not show one search result, and on the product detail page show the different available versions and package/bundle formats? What if I have the system-provided package, a Flatpak, a Snap, a stable AppImage and two nightly AppImages of the same app? Is it then shown six times in the search results?

GNOME Software also supports single-file flatpak bundles like gimp.flatpak – just double click and you’re good to install.

Now this is very similar to AppImage. Just that if you double-click an AppImage, the app is launched rather than "good to install".

These files are somewhat like a package in that all the required files are included and you can install without internet access.

Exactly like AppImage, which adds the benefit that the file does not have to be installed but can simply be run.

These bundles can also install a remote (ie a reference to a flatpak repository) too, which allows them to be kept up to date. Such per-application remotes are only used for the specific application and not the others potentially in the same tree (for the curious, this is called a “noenumerate” remote).

For AppImage, we have update information embedded into the AppImage, which does the same thing. It is also only used for the specific application. Although an application author might have different channels like "releases", "nightlies", and so on, which would be embedded in the AppImages distributed through the respective channels.

Each of these files contains all the metadata we need in AppStream format, with translations, icons and all the things you expect from a modern software center. It’s a shame snappy decided not to use AppStream and AppData for application metadata, as this kind of extra data really makes the UI really beautiful.

AppImage does, it's recommended as per its spec.

I've also posted thoughts on an infrastructure for distributing Linux application bundles at length (tl;dr: A system to distribute Linux application bundles and exchange metadata about them is needed, and this writeup ponders on how to create the infrastructure needed for that).

Just like the CLI, gnome-software can update flatpaks safely live (even when the application is running)

AppImageUpdate does that too. But I think you still need to restart the application to benefit from the updated version, right? AppImageUpdate uses the appimageupdate command line tool (which is actually a shell script around zsync-curl). So we could probably invoke that from within GS and use the GUI provided by GS to signal the updates rather than the AppImageUpdate GUI.

While we are at it, I would also like to see this:

we do a little bit extra compared to the CLI and download the data we need to do the update when the session is idle and on suitable unmetered network access

How does this work? Does that mean it downloads the update before I even told the system to do so? Gosh do I hate that... eating away my precious RAM on a Live ISO system... (all I ever use are Live ISOs booted with SystemImageKit. Fully image based OSes without installation - OS can be upgraded or exchanged in under a minute).

[PHPJosh]

hmm this is a really informative read. I am almost done swapping over to Ubuntu Base and should have an ISOs out soon as it super simple to make a Remix ISOs on Ubuntu .. this all the initial ISOs will be Remixed ISOs at first just so i can get them out quicly and people can start seeing just how a Distro built around appimages will work with them being upfront and center focus and not just an after thought.

so as soon as I start getting ISOs out i plan on starting the Gnome software plugin. but seems I going to have to Update GTK+ for my distro as seems from reading some the new changes in the Plugin system only will work on 3.22 +

[probonopd]

As noted before, a special distribution is not needed... But of course you can do one if you like...

[probonopd]

@PHPJosh still interested in this?

[PHPJosh]

yes I am as I am back to working on things as took a break for awhile as was frustrated with the fact some people didn't realize I am not making my distro for us Power Users or everyday users of Linux but new people. the people who come to Linux and get frustrated with it because in their eyes it doesn't "just work" like windows or macOS. well past few days I have gotten confirmation there is a need for something like my idea so I have been reinvigorated to continue work on it. have to change things though as alot of software updates have changed stuff the past 10 or so months

[AsciiWolf]

Any news?

[probonopd]

@AsciiWolf we are still looking for a volunteer who would like to work on this. Is it you?

[AsciiWolf]

Sorry, I am not skilled in C. :-/

[probonopd]

@PHPJosh like to join us in working on https://github.com/probonopd/gs-plugin-appimage?

[azubieta]

closing as duplicated of #58