Appimagekit: Feature suggestion for desktop integration

[sudo-give-me-coffee]

In wrapper script

• Add multi language support
• Message more "friendly"

Example

In desktop file:

• Call a "check script" to verify if file exist before run
• Display a message if file is not found and remove the "desktop file"

Something like this:

I can do it, but i need help to verify if text are correctly, because my main language is portuguese and my english is badly

[TheAssassin]

@azubieta and I are working on system-wide dialog solutions for integrating AppImages. Check out https://github.com/TheAssassin/AppImageLauncher (resp. https://github.com/TheAssassin/AppImageLauncher/wiki/Idea) and https://github.com/azubieta/appimage-desktop-integration.

[probonopd]

...and the official solution, the optional appimaged daemon that does desktop integration automatically :-)

[TheAssassin]

@sudo-give-me-coffee I'll be publishing AppImages of AppImageLauncher by tonight. I would appreciate any feedback in my repo. Feel free to subscribe there.

[azubieta]

I'll be publishing an appimage tonight too :)

[sudo-give-me-coffee]

My idea (I forgot to mention) is to run parallel to the main executable exactly equal to:

AppImageKit/desktopintegration

@TheAssassin, @azubieta and @probonopd why not join all? I'm not sure why I did not test them all (I just took a look), but they are not conflicting

@TheAssassin and @azubieta very good

Please see: I'll be publishing my script "mod" by tonight too

sudo-give-me-coffee/desktopintegration

[sudo-give-me-coffee]

Could someone help me by checking if I did not make any grammatical errors, please? In the messages in the photos of the first message? I'm not speak very well english :(

[probonopd]

https://raw.githubusercontent.com/AppImage/AppImageKit/master/desktopintegration is old and not really supported by me anymore. It cannot solve the hassle that the user needs to make the file executable by setting the +x bit first. Instead I recommend the optional appimaged daemon (or in the future possibly things @azubieta and @TheAssassin are currently working on).

[sudo-give-me-coffee]

But they are external tools, if user don't have any of these?

[TheAssassin]

@sudo-give-me-coffee actually @azubieta and I are collaborating on this topic already. However, we started two similar but different projects, and now we decided to develop them until they work properly first before merging them.

The problem with shipping desktop integration in every AppImage is that, aside from being unnecessary bloat, is that then we depend on AppImage maintainers to ship those data. If we provide an _independent_ install-in-system-once solution, we can circumvent those disadvantages.

If you install e.g., AppImageLauncher, your system can be called "AppImage ready" in the future. That's the idea.

[TheAssassin]

An AppImage of AppImageLauncher is now available: https://github.com/TheAssassin/AppImageLauncher/releases/tag/continuous

[simoniz0r]

I personally am not a fan of any idea that takes away from AppImages requiring nothing to work as expected. The user should not have to have anything installed for an AppImage to ask whether or not it should be added to their menu.

[ferdnyc]

The user should not have to have anything installed for an AppImage to ask whether or not it should be added to their menu.

Except that's probably going to be impossible, down the road, because a non-installed, untrusted, foreign binary like an AppImage will be prohibited from mucking with the user's desktop environment (or perhaps from running at all). We're already seeing moves in that direction.

Those sort of restrictions are beyond the AppImage developers' power to control, and having an installed helper daemon at least offers a way to work around it. "A self-contained application package that can bootstrap-install itself" is likely to be redefined as an oxymoron by the desktop environment team(s) / distro(s), no matter how much anyone may want it to be a thing.

[probonopd]

Then someone can always make "our" own desktop. Powered by these ideas.

[TheAssassin]

We're already working with distros on improving AppImage support. One of the most AppImage friendly distributions is Nitrux. Soon, we're going to merge their own tools with AppImageLauncher to improve AppImageLauncher and include it into the standard distribution.

[probonopd]

XFCE and Xubuntu, for example, alre also AppImage friendly.

[TheAssassin]

@probonopd this is still a bit naive, and AppImageLauncher implements a more reliable detection algorithm. Though, this is really nice.

XFCE has been lacking support for desktop actions until recently, though, which we use for desktop integration.

[azubieta]

Desktop integration scripts are no longer recommended as they tend to be a bit fragile and non-precise. Instead users should use one of the desktop integration solutions: appimaged or AppImageLauncher

Closing the issue please reopen if required.

[akontsevich]

I personally am not a fan of any idea that takes away from AppImages requiring nothing to work as expected. The user should not have to have anything installed for an AppImage to ask whether or not it should be added to their menu.

Completely agree!!! All is need to do is to copy .desktop file to ~/.local/share/applications/ with current AppImage location path in Exec= section - that is all for "integration". Why it can't be done on app start?! Guys come on!

Additionally icons are copied into ~/.icons/... - so very simple, and mime-types are not always necessary

[probonopd]

If you do this the "simple" way, then it will collide with tools like appimaged and AppImageLauncher.

How does your simple approach work when the user moves or deletes the AppImage? Who cleans up the extra menu entries?

Be careful not to shoot yourself in the knee with this!

These are all crude hacks. The proper solution is to ask your favorite file manager to incorporate support for AppImages properly.