Desktop integration could be better documented or less frictionful

[kortschak]

See discussion at prusa3d/PrusaSlicer#1431 for background.

In the past AppImage applications would ask whether they should insert themselves into the appropriate desktop files. This behaviour is apparently now deprecated, or at least least not recommended. This is unfortunate.

The two solutions that are proposed to be used in the AppImage documentation are to use appimaged or AppImageLauncher. This adds an additional layer of friction for using AppImage, neither of these programs appear to exist as packages in ubuntu, debian, mint or arch main line repositories, and so for users wanting to install only a single or few AppImage applications need to go through essentially non-amortizable work to make desktop integration work.

Given that a significant proportion of users are likely to want desktop integration, the documentation for the approach should probably be more prominent.

I also have to say that the automatic registration of AppImages by appimaged in directories like $HOME/Downloads and [any mounted partition]/Applications is troubling.

It seems to me that having the option for a single AppImage application to manage its own desktop registration, explicitly, as was done previously, would be a benefit. Of course this should not prevent people from using the solutions above.

cc @probonopd

[probonopd]

Thanks for your detailed feedback @kortschak. We are making AppImage for "mere mortals", users who do not necessarily want to be "system administrators", but want to use a Linux system similar to how they would use a Mac. Feedback from "real life" users like you is thus very important to us.

Given that a significant proportion of users are likely to want desktop integration, the documentation for the approach should probably be more prominent.

What exactly would you like to see, e.g., on which web page should be stated what?

neither of these programs appear to exist as packages in ubuntu, debian, mint or arch main line repositories

We are distributing our software in AppImage format, so that AppImage users never need to use the package manger (nor root rights, which they might not have, e.g., on enterprise or lab machines). We think this is more consistent.

for users wanting to install only a single or few AppImage applications need to go through essentially non-amortizable work to make desktop integration work

I am currrently working on an experimental appimaged implementation that will, when double-clicked for the first time, automatically set up itself as a systemd service, with no further installation or interaction from the user. I hope it will be out of the "experimental" phase soon.

I also have to say that the automatic registration of AppImages by appimaged (...) is troubling.

Why do you think this? What would you like to see instead? I am trying to achieve the same user experience as the Mac, where every app "just works" without a distinction between "installed/integrated" and other applications. There, the system "magically" knows every application on the system, without the user even having to notice.

Here I am showing it in a video: https://www.youtube.com/watch?v=0sRYL9IzkRQ

It seems to me that having the option for a single AppImage application to manage its own desktop registration, explicitly, as was done previously, would be a benefit.

Would having a small tool that would integrate/unintegrate a single AppImage work for you?

But then again, why not make it more seamless like shown here? https://www.youtube.com/watch?v=L00UjifUEfE

[kortschak]

What exactly would you like to see, e.g., on which web page should be stated what?

At the moment it's indexed, but having it in the introduction preamble in https://docs.appimage.org/user-guide/index.html would be helpful.

We are distributing our software in AppImage format, so that AppImage users never need to use the package manger (nor root rights, which they might not have, e.g., on enterprise or lab machines). We think this is more consistent.

It may be more consistent, but it's an additional point of friction; when I want to add something to my system I reach first for apt (or yum or pacman), so having to do another thing, and remember where it went and what managed it (if anything) is a pain. Particularly if it is just so I can install one piece of software as is the case in the original issue that prompted this.

I am currrently working on an experimental appimaged implementation that will, when double-clicked for the first time, automatically set up itself as a systemd service, with no further installation or interaction from the user. I hope it will be out of the "experimental" phase soon.

This, with the capacity to remove it easily would be ideal, and functionally what existed before as far as the user is concerned.

Why do you think this?

Autoregistration from removable drives and ~/Downloads just seems like a disaster waiting to happen.

What would you like to see instead?

At the very least, not including Applications from any mountable device and ~/Downloads. But preferably, asking on set up whether these autoregistration locations should be used.

I am trying to achieve the same user experience as the Mac, where every app "just works" without a distinction between "installed/integrated" and other applications. There, the system "magically" knows every application on the system, without the user even having to notice.

Magic has always frightened me. I don't use MacOS because of the "helpfulness" that they force on users.

Would having a small tool that would integrate/unintegrate a single AppImage work for you?

Not if it is an additional thing that needs to be installed. If it were embedded in the AppImage itself, then sure.

The issue is that you are assuming an amortisation over time that does not exist when only a single AppImage application is used.

[probonopd]

At the moment it's indexed, but having it in the introduction preamble in https://docs.appimage.org/user-guide/index.html would be helpful.

Would you consider sending a pull request? Our docs live on GitHub, too :-)

My objective with the project is to create a user experience similar to Macintosh System software around 1984. Nothing ever had to be "installed". Just drag-and-drop, double-click.

[kortschak]

My objective with the project is to create a user experience similar to Macintosh System software around 1984. Nothing ever had to be "installed". Just drag-and-drop, double-click.

But to achieve that, I now need to install additional software (rather than just allowing a first run to place a file in the desktop registry), and software that has behaviours that make me feel uncomfortable.

I guess I'll be running AppImage applications from the command line in perpetuity.

[edent]

I'm confused! I've downloaded an AppImage file. How do I run it from the GUI? Every other app appears in the Gnome menu. I can either find it in the hierarchy, or open up the search bar to run it.

I've made it executable, and I can double-click to run it. But that's not the same as having it integrated with the rest of my desktop environment.

Was any user research or testing done by the AppImage project? I'd love to understand if I'm outside the general usecase.

[TheAssassin]

@edent please check out https://github.com/TheAssassin/AppImageLauncher, which provides an easy way to integrate and manage AppImages from the UI.

[probonopd]

@edent https://discourse.appimage.org/t/how-to-run-an-appimage/80

[edent]

Thanks. What's the difference between @TheAssassin's Launcher and @probonopd's daemon? Which is better? Or, I suppose, why do I have to choose between the two?

[TheAssassin]

They follow different approaches. AppImageLauncher provides its own UX. It's highly integrated in the system, taking care of AppImages and making them the first-class citizens they should be. Built in upgrades, a launch assistant and many more features. You can also configure it to suit your needs. It's been built by an every day Linux user for other every day Linux users.

appimaged in contrary is much more simple, doesn't permit any configuration and is more of a "I integrate any AppImage I can find on your system automatically" solution. It is supposed to be somewhat "OS X < 2010" like. That makes it special.

[bubnikv]

Frankly I believe neither AppImageLauncher nor appimaged are available on stock Ubuntu 18 or 20 and neither of us PrusaSlicer developers would install these daemons voluntarily. I believe most of our Linux users thus don't have PrusaSlicer integrated into their desktop for whatever reason. I personally don't like another daemon sweeping the file system regularly, but I suppose our users usually have no knowledge of the desktop integration daemon existence.

I find it sensible to have a command somewhere in the Configuration menu and the installation wizard of our application to perform desktop integration manually. For a C/C++ application, a static library as a github project would be nice, which would 1) Detect whether any desktop integration daemon is running and if not, 2) Check whether the application is desktop integrated and if not, 3) Perform desktop integration, possibly installing multiple desktop integration files, see also https://github.com/AppImage/AppImageKit/issues/25

I would let the user application to wrap the common functionality provided by the library by their custom GUI. For scripted applications, the two functions may be provided by calling the AppImageKit binary with some special parameter.

[probonopd]

Thanks @bubnikv.

What you are describing is what we had a long bash script for in the past. It did exactly 1., 2., 3. before launching the main payload executable. But we are no longer recommending it anymore since there are so many options for desktop integration these days, including non-daemon versions.

Should you decide to implement something like it, then please do at least checks like these.

[bubnikv]

Thanks, we will look into it.

[probonopd]

@kortschak do you have better ideas?

[kortschak]

Better is difficult to quantify. I have my opinions, but I've expressed them previously in this thread.

[almereyda]

Unfortunately, the daemonless AppImageLauncher seems to be deprecated, since no new commits appear there, and go-appimage is communicated somewhere hidden as the state-of-the-art appimaged. I personally needed to find the comment https://github.com/AppImage/AppImageKit/issues/1079#issuecomment-757127133 somewhere deep in the closed issues to find out about the newer, better implementation.

To second the comment by the OP @kortschak

I also have to say that the automatic registration of AppImages by appimaged in directories like $HOME/Downloads and [any mounted partition]/Applications is troubling.

This also feels very strange to me, especially when looking at the log of the unit and finding every file system operation in my home directory in there. This is a spill of private and eventually sensitive information. Secondly, it makes me really uncomfortable that the user (sic!) daemon is trying to access my system mounts, which fails with permission denied:

`$ journalctl --user -b -1 -u appimaged.service | grep permission | grep 'lstat|ERROR'`

``` Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /var/lib/NetworkManager/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /root/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /boot/efi/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /boot/grub/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /var/lib/NetworkManager/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /var/lib/NetworkManager/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /var/lib/NetworkManager/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /root/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /root/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /boot/efi/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: ERROR watchDirectoriesReally: open /boot/grub/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /boot/grub/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /boot/efi/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /boot/efi/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /boot/grub/Applications: permission denied Aug 31 01:52:51 ganglion appimaged[1993004]: 2021/08/31 01:52:51 lstat /root/Applications: permission denied ```

$ journalctl --user -b -1 -u appimaged.service | grep permission | grep 'lstat|ERROR' | awk '{ print $9 }' | tr -d : | sort -u
/boot/efi/Applications
/boot/grub/Applications
/root/Applications
/var/lib/NetworkManager/Applications

Is this particular behaviour eventually worth an independent issue?

[bubnikv]

At the end of the day, we implemented desktop integration into PrusaSlicer as part of the "Install wizard" process. This also allows our users to switch between PrusaSlicer versions, to keep just one integrated into desktop and to be able to re-register one or the other PrusaSlicer version with desktop.

Maybe a C++ library could be written helping with desktop integration with little dependencies (just boost::filesystem?)

BTW the manual desktop integration works on Crosstini (Linux on Chromebooks), so PrusaSlicer pops up in the chrome os app launcher.

[probonopd]

Thanks for letting us know @bubnikv, doing this in the install wizard is probably a smart way to do it, as long as it is optional.

Maybe a C++ library could be written helping with desktop integration with little dependencies (just boost::filesystem?)

Could your code serve as a starting point?

[azubieta]

Maybe a C++ library could be written helping with desktop integration with little dependencies (just boost::filesystem?)

This is precisely what libappimage is for, you may take a look at it on https://github.com/AppImage/libappimage/

[bubnikv]

@azubieta

This is precisely what libappimage is for, you may take a look at it on https://github.com/AppImage/libappimage/

Cool. How come we did not stumble over it?

[maverick74]

@probonopd What's the state of this issue?

What I truly expect from an appimage is something in the lines of:

(I just installed some fresh Linux distro...)

1. I download an appimage
2. Click on it
3. And that's it: software is up and running

in the background and without any intervention the App starts to appear on the applications menu.

To remove it: just right click the app on the menu and choose "uninstall"

If there is an update for the app there should be some visual alert over the app icon. Right clicking on it, there should be an option to update it.

(an option somewhere to configure the update behavior would be great - choosing between "manual update" or "always auto-update")

That's my 2cents about what I expect from appimages

[probonopd]

Hello @maverick74, you are missing one step:

I download an appimage Make it executable Click on it And that's it: software is up and running

You need to set the executable bit.

Source: https://discourse.appimage.org/t/how-to-run-an-appimage/80

To remove it: just right click the app on the menu and choose "uninstall"

AppImages do not need to be installed, hence to "uninstall" them you simply delete them. Done!

If there is an update for the app there should be some visual alert over the app icon. Right clicking on it, there should be an option to update it.

To update an AppImage, you need to run AppImageUpdate and select the AppImage to be updated.

If you would like AppImages to be better integrated into your desktop environment and file manager (which I understand), then please do open feature requests with the project that makes your desktop environment and file manager. We just define the AppImage format and make some tools available. The desktop environments and file managers would need to support AppImage more natively for a truly "native" experience.

[maverick74]

Hi.

I understand what you say, but I probably didn't explain myself well enough (English is not my native language).

That's what I expect... I understand they do not need to get installed, but what I mean was that it would be good to have then showing up in "start" menu and be able to remove them from there.

Same thing for the update part!

Regarding the "make it executable", the system should recognize it and run it without that need (ok... Maybe the 1st time it could ask for it).

Now... When you say that desktop environments should support it more natively... If I go start boring KDE guys about this, what do they have to do to get this kind of integration (menu integration, remove from menu, update app from right click)?

Is including appimaged enough?

[probonopd]

appimaged is a workaround. It is better to have native support in the desktop environment and file manager.

[bubnikv]

appimaged is a workaround. It is better to have native support in the desktop environment and file manager.

AFAIK appimaged is not being promoted by common distros to be installed by default and native support in the desktop environment and file manager does not exist.

We at PrusaSlicer implemented desktop integration directly into PrusaSlicer, however if PrusaSlicer AppImage is just deleted, it has no chance to deinstall from desktop.

On Sun, Jun 5, 2022 at 4:24 PM probonopd @.***> wrote:

appimaged is a workaround. It is better to have native support in the desktop environment and file manager.

— Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/1036#issuecomment-1146814216, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI7CZ6LRKHK3J6GO4K3VNS2CNANCNFSM4LRD2WNA . You are receiving this because you were mentioned.Message ID: @.***>

[maverick74]

KDE Plasma, from what i can see in Neon, actually works very well. When we download the app and click on it, it warns it will run the software as an executable and ask if it is this we want. After that first warning Plasma marks it as executable automatically. (i might have made some system alterations that i don't remember any more... can anyone confirm it works like this out of the box?)

Anyway this is something really nice!

Now, what misses is the inclusion on the menu and the option to update the app.

[maverick74]

@probonopd Is go-appimage also just a workaround?

(I ask this because I truly believe this won't take fly until DE have someone doing the integration job for them... Something they can easily include and know it will just work... But then again: maybe that's just me XP )