Implementing AppImage desktop integration

[syntactic-spice]

Hi, I'm implementing desktop integration for AppImages. Currently they are copied to ~/Applications, but unlike macOS, an additional step is required on Linux before desktop environments, launchers, etc. see them. On the surface it's pretty simple - just extract the embedded *.desktop file (which contains launch command and other metadata) into ~/.local/share/applications. But there are several edge cases that need to be considered, so I thought I should open a discussion.

If you'd like me to start a PR with my current implementation and discuss there instead, let me know. Here are my questions:

Imagine we are trying to install ~/Applications/Foo.AppImage and ~/.local/share/applications/com.foo.desktop

1. Should we rename/version/namespace the desktop file?
   We could put them in a homebrew/ subdir, or prepend the name with homebrew-. Most existing AppImage managers rename it in some way. But according to the spec the file name matters. I did extensive testing and if it doesn't match the app's internal ID, it breaks some things. So I think we should keep the name where possible.

2. What if the file already exists?
   If both the target AppImage and its desktop file exist, then the answer is obvious, fail unless --force or --adopt.
   But what if com.foo.desktop exists and doesn't point to ~/Applications/Foo.AppImage? This could happen if two packages have the same desktop file name, or the user manually downloaded ~/Downloads/Foo.AppImage, ran it, and it self-installed the file. Is it reasonable then to fall back to a rename with a warning, even without --force, so as not to break the existing app's integration? We can ask them to reinstall -f to overwrite if they wish.

3. What if the user changes the file before an upgrade?
   The user might want to add custom parameters or env vars, etc. Do we just overwrite on package upgrade? Do some sort of merge? Ask the user?

4. There is another way that avoids most of these issues
   Brew already has its own .linuxbrew/share/applications and some packages like btop link their desktop files there, but they are currently unused on Linux. To use it, we would have to ask the user to add to their session's $XDG_DATA_DIR or just create ~/.config/environment.d/homebrew.conf. We can't handle it at brew shellenv level since it needs to reach the graphical session. If we do this, we can have complete ownership of all *.desktop files. The user can still override them by copying them to ~/.local/share/applications and editing them. We will still have to deal with potential duplicate names across packages.
   The caveat is that this only works if the shell inherits systemd --user environment. So may not work for some setups.

My current implementation writes to the regular dir, but I think 4 would be the more conservative change. We are only ever adding a single file to ~/.config/environment.d. I have tested that approach on Noctalia/Niri and Gnome on Ubuntu. On setups where it doesn't work, the behavior remains the same as present (no desktop integration). So let me know what you think.

[SMillerDev]

If you'd like me to start a PR with my current implementation and discuss there instead, let me know.

For most of the questions that'll be a much better option.

into ~/.local/share/applications

I think it should follow the XDG settings, not blindly write to this location

if it doesn't match the app's internal ID, it breaks some things.

How do we make sure it follows the apps internal ID?

If both the target AppImage and its desktop file exist, then the answer is obvious, fail unless --force or --adopt.
But what if com.foo.desktop exists and doesn't point to ~/Applications/Foo.AppImage?

I think in any case it should fail unless you force it. It doesn't really matter what the content is.

Do we just overwrite on package upgrade?

Yes

some packages like btop link their desktop files there

btop is not a cask though, it's a formula. I think there might be value in bringing symlinks for desktop files in formulae, but that's a separate discussion.

[syntactic-spice]

Thank you. I did mean XDG_DATA_HOME, with a default path as is convention.

How do we make sure it follows the apps internal ID?

It's supposed to be the original file name that's embedded in the root of the AppImage. AppImage managers (Gear Lever, etc.) rename it to track ownership of the file for uninstalls/updates and to avoid name conflicts between apps. I scanned the ~250 AppImage casks available right now, and the only ones with name conflicts were versions of the same app, like nightly vs stable. So I think we should be fine there. And I am tracking ownership via a symlink from the cask directory.

For most of the questions that'll be a much better option.

Great, I will start a PR.

[itsTurnip]

Copy into ~/.local/share/applications is something that was already suggested to merge but rejected. There should be a better solution.

See PR#23674

[itsTurnip]

I've reviewed your message once again.

I'm not a homebrew contributor (yet) but option 4 in your list seems to be the best for me. Yes it may be not convenient in some users' setup, but, you know, this is Linux - there much of choices over there and it's impossible to cover all of them.

I would like to see your PR. Thank you for your work.

[syntactic-spice]

Hi, that PR was closed by the author themselves. I would argue the "we don't write to user home" point is moot now, as the AppImage install process was changed recently to directly write them to ~/Applications. Homebrew also writes fonts to ~/.local/share/fonts on Linux. I will start a PR and see where it goes.