Handle multiple (and no) desktop files better?

[TC01]

Right now, it seems that AppImageAssistant just selects the first *.desktop file in an app directory, even if there are multiple.

(apt-appdir's app directories, at the very least, can suffer from this problem. And the tool I wrote this afternoon that uses Mock has the same problem... if not worse, because usually more dependencies get pulled in).

Is it possible to handle this better? I would think that some combination of the below might be reasonable:

1. defaulting to $APP.desktop in the event of multiple files.
2. prompting the user/accepting a command line switch for "name of desktop file".
3. prompting the user/accepting a command line switch for the name/binary name (and defaulting to some template icon).

I'd be willing to contribute some code to make this better, but I figured I'd ask first. :)

[probonopd]

You are correct about the problem. The question is whether you want to resolve this at AppDir creation time or at runtime. I opted for the first, but I could see reasons to go for the second.

Why did I go for the first?

• To make the AppDir format super simple
• To always have one starting point inside an AppImage - double-clicking on an AppImage should start the main app rather than do nothing visible
• To allow 3rd parties to ,e.g., write a daemon that scans a directory for AppImages, and extract just the desktop files from them with good performance (see appimaged http://portablelinuxapps.org/packages/deb/appimaged/ for an early sample implementation of this - I am sure this could be done way better today - contributions in this area are highly welcome!)
• To have the AppDir creator decide what is the "main app" rather than have the user to figure it out

What I could imagine:

• Still have the main .desktop file in the root of the AppDir be the default entry point
• Additionally, have a command line switch to choose another one
• Possibly write a very small GTK app that asks the user to pick an app (for apps where there is no clear "one" entry point)
• Add a desktop.manifest file in the root directory that defines which other desktop files, if any, should be considered for selection by the user, and should be used for system integration by 3rd party tools

Basically similar to what you suggest but keep in mind it has to keep working without the command line, and 3rd party tools (like daemons for system integration) need a way to find out what is the main app and, ideally, what should happen to the other .desktop files).

What do you think?

[TC01]

I like your proposal, although I was actually suggesting it be resolved at AppImage creation, not runtime-- because currently AppImageKit chokes under the following conditions:

1. An application has multiple *.desktop files, only one of which as an Icon defined.
2. The .desktop file that gets picked by default does not have an Icon (and other information defined).
3. AppImageKit loads the first desktop file, but it's not a valid entry point, and throws an error.

This happened to me when trying to build kate, which ships with a lot of (generated?) desktop files; for instance, katebacktracebrowserplugin.desktop.

This is fixable by deleting the spurious files, but it'd be nice if there was some automation in AppImageKit that could do this to pick the default entry point.

Though I guess the desktop.manifest would cover this case? As you could specify "these are invalid, do not use".

Or maybe AppDirectoryKit does/will give the choice of "select default app.desktop" file and this is just something that apt-appdir doesn't do?

[probonopd]

Yes, asking the user at creation time is sensible. Right now the correct desktop file has to be placed in the root directory of the AppDir manually, but I would welcome a more comfortable solution.

[probonopd]

Could be considered for appimagetool, pull requests welcome!