Appimagekit: Desktop integration again

[akontsevich]

The was multiple discussions on #appimage IRC channel and here: https://github.com/AppImage/AppImageKit/issues/715#issuecomment-710082960. While I think all is need to do for integration is to copy .desktop file to ~/.local/share/applications/ with current AppImage location path in Exec= section on AppImage start. Additionally icons are copied into ~/.icons/... - so very simple, and mime-types are not always necessary.

The good idea is user should not have to have anything installed for an AppImage to ask whether or not it should be added to their menu! We won't ship additional applications with our AppImage like appimaged and AppImageLauncher. And AppImage should work (and even better - integrate: show icon and put int apps menu) everywhere.

Could we add to recipe option to do this automatically not asking user, @azubieta? Or some appimage switch: --integrate?

[azubieta]

@akontsevich libappimage already has all the code to properly create the desktop file, icon and mimetypes. An option to implement this feature would be to create an statically linked tool that could be shipped as part of the AppImages.

[akontsevich]

@akontsevich libappimage already has all the code to properly create the desktop file, icon and mimetypes. An option to implement this feature would be to create an statically linked tool that could be shipped as part of the AppImages.

Cool! I see libappimage is only 280 KB in size so think it could work fine for this. Hard to incorporate into appimage-builder, @azubieta?

[azubieta]

I guess that it may fit better as part of AppRun. AppRun is already deployed by appimage-builder.

[akontsevich]

I guess that it may fit better as part of AppRun. AppRun is already deployed by appimage-builder.

@azubieta whatever works! :wink: While AppRun is used by appimage-builder. Any chance to incorporate it there? Thanks!

[probonopd]

The issue is that when libappimage is inside an AppImage, we cannot change the behavior of the desktop integration for the already-made AppImages. So I would be very careful about doing something like that.

[TheAssassin]

Yeah, it's a bad idea. And there's also the bloat argument.

[azubieta]

What if we made a 'appimage-self-management-tool' that could be shipped with every AppImage. This tool could be capable of performing the system integration, update and other task that we may need.

At runtime this tool will check if a newer version of it is available in the system. If true, the tool will run instead that version otherwise it will upgrade the system binary and run. This will ensure that the latest version is always present in the system. The tool may also perform a self update.

[probonopd]

Better have this logic outside of each AppImage, so that it can be updated.

Even __much__ better, have desktop environments treat AppImages as first-class citizens in the first place, without the need for any desktop integration workarounds on our sides. As in: File managers that natively understand and handle AppImages properly.

We should redirect users to ask for this at the desktop environment projects.

[azubieta]

I agreed that the best solution for this feature is to be implemented as part of the file managers.

But I fear that we have an egg - chicken issue here, where desktop doesn't adopt AppImage because it doesn't have enough traction and AppImage doesn't gain enough traction because their cannot be integrate without extra tools into the desktop.

[Ramblurr]

Previously I've manually created desktop files. I see some mention in old threads of appimaged, but that tool seems deprecated now.

As a user of software that is distributed with AppImage, how do I integrate the image into my desktop in 2021?

[TheAssassin]

https://docs.appimage.org/user-guide/run-appimages.html#integrating-appimages-into-the-desktop

[probonopd]

I see some mention in old threads of appimaged, but that tool seems deprecated now.

Updated the documentation to point at its new implementation:
https://github.com/probonopd/go-appimage/releases