search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.78k stars 563 forks source link

Write plugin for Gnome Software #58

Open probonopd opened 8 years ago

probonopd commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

https://github.com/GNOME/gnome-software/commit/82b15e9a34dc1cbce7da24e0771a9c7a259ff15d "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 https://github.com/probonopd/AppImageKit/issues/48

hughsie commented 8 years ago

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 commented 8 years ago

Thanks @hughsie. If you have a spare minute or two, I'd appreciate your thoughts on https://github.com/probonopd/AppImageKit/issues/48#issuecomment-228614440

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

probonopd commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

hughsie commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

Yes, very much so.

Ads20000 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

TheAssassin commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

TheAssassin commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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,...):

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:

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

Ads20000 commented 6 years ago

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 commented 2 years ago

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

probonopd commented 2 years ago

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