Define optional additional system integration data/code

[kossebau]

Some Linux workspaces/desktop systems have hooks for integration with the system besides application launcher system or process metadata like for windows of an application (already in current spec) or custom MIME type registration (#22).
Those hooks might not be only by data, but also by code. The latter as in-process as well as out-of-process extensions of the system.

The extensions are often closely coupled with a given version of an application software (due to used private API of internal application libraries or used private format of application specific data). So shipping the system integration extensions bundled with the actual application lowers the risk for users of running into incompatible combinations of application and integration extensions.

The additional extensions are often also desktop/workspace-specific, where either no cross-desktop/workspace freedesktop.org or other specification has been established, or where extensions are highly dependant on the unique capabilities of a desktop/workspace product line.

For an improved experience with AppImage-based applications it would be interesting to extend the AppImage specification to allow bundling also of solution-specific system integration extensions

Some Challenges

Conflicting extensions with multiple (AppImage) versions of the same application

Possibly needs to be fixed by having a system where only one version of the AppImages can be the currently integrated one. Might also be a fix for the similar challenge with the custom MIME type registration (which icon version is used for files with that MIME type and which AppImage as handler).
Additionally the same application might also be installed in a version from non-AppImages (e.g. distribution packages), that needs to be handled as well somehow.

Who deploys solution-specific system extensions

To deploy an integration extension which is only usable with a given workspace/desktop system solution, needs special knowledge about that system.
One solution might be to have the AppImage itself do that, as the creator knows what specific extensions they added and for which systems. That though comes both with the disadvantage of code duplication as well as having to trust the code of the AppImage not to do bad things on deploying the system extensions. And then it completely will miss to do any clean-up if an AppImage is simply deleted.
Another solution is to extend the AppImage system integration tools (like appimaged) to learn about specific desktop/workspace solutions, to recognize any specific system integration extensions in an AppImage and to do the needed things for deployment/undeployment. This creates a dependency on the given AppImage system integration tool, which might not yet know about less popular workspace/desktop solutions. The abilities of the tool need to be communicated to the user in some way, so they have a chance to learn why some integration might not be happening for them on their system, while it happens for others, and ideally with pointer to a solution how to fix this for them.

Platform variants & version dependencies might be needed

Given that workspace/desktop specific integration extensions are done against a richer API which also tends to be less stable over time (stable vs. feature progress), the compile-once-run-everywhere approach of AppImage might not work that well with such extensions.
One approach might be to allow multiple variants of the same extension in one AppImage, tagged with version & platform dependencies. Needs more thinking.

Examples for additional system hooks

• global search plugins (e.g. Plasma's KRunner)
• applets/gadgets/widgets for quick access to app managed data
• indexer plugins (e.g. for tracker or Plasma's Baloo) for custom MIME types
• file thumbnailing plugins for custom MIME types

Example for an application with solution-specific system integration extensions

The IDE KDevelop provides the following extensions, where a "session" is an application instance profile with a set of projects loaded and specific settings:

• KRunner plugin to directly launch existing KDevelop sessions or get their window activated if already running
• Plasma widget to see a list of existing KDevelop sessions to quickly launch them or get their window activated

[probonopd]

What should happen if the user has, say, 10 different versions of KDevelop AppImages, including a stable and continuous ones?

[kossebau]

What should happen if the user has, say, 10 different versions of KDevelop AppImages, including a stable and continuous ones?

That' a challenge I tried to give initial mention with the subsection "What should happen if the user has, say, 10 different versions of KDevelop AppImages, including a stable and continuous ones?"

The most rigid or simple approach would be to have the appimage integration tool to only do the integration for one version (with the user having the option to switch which one is the integrated).

Though then there is also the challenge of people having the same application installed from the normal distribution packages or by other non-AppImage options. That needs to be catched as well (extended the subsection for that now). Related use-case would be people doing (preview) testing of unreleased versions, e.g. for bug fixes or betas of feature releases.

I have not yet thought more about this, ideally we would first have some user stories/use cases collected for the cases where people do make use of parallel installations, so we can derive what people/users would expect, need or want. Would a wiki page on github be a good place to do such user story collection related to parallel-version installations match your workflow?

[shoogle]

I think this covers most use-cases:

• Users have a preferred version of an app (e.g. Firefox)
• They might also have an older/newer version that offers something that the preferred version doesn't
  • e.g. a missing feature, more stability, more compatibility, etc. (e.g. Firefox LTS)
• They might have an unstable development version for testing (e.g. Firefox Nightly)
• They might have different apps that serve the same purpose as the first (e.g. Chrome)

Desired outcomes:

1. The user wants to install the app so it appears in menus. They also want it to be the default program for the task at hand (e.g. Firefox).
2. The user wants to install the app and have it appear in menus, but they don't want it to be the default program (e.g. Chrome and Firefox LTS).
3. The does not want to install the app at all; they merely want to click the AppImage and see if it runs (e.g. nightly builds).

AppImage can fulfill (2) by copying files to the relevant locations in ~/.local/share, and (3) by providing an option to not do that. I don't think AppImage can fulfill (1) on its own.

Desktop Environments can (and do) provide mechanisms for allowing the user to pick a default application for a particular task. All AppImage can do is advertise the services that each app offers and then allow the user to pick the default through their DE.

Similarly, for terminal applications there is an existing mechanism to choose defaults (e.g. by creating aliases or modifying ${PATH}). It would be nice if applications could advertise that, for example, MuseScore-3.0.1-x86_64.AppImage would like to use the alias mscore on the command line, but users should be free to use that alias for a different applications if they prefer.

[probonopd]

Is this already sufficiently solved by Snappy and/or Flatpak? Just asking so that we don't re-invent the wheel.

[shoogle]

I believe it has in most cases, and I agree we don't want to create our own private solution if there is already a standard. In fact, that is what I was trying to get at with my comment really. All applications can do is advertise the services they provide (or choose not to advertise). Applications cannot force the desktop environment, and ultimately the user, to make use of those services, and nor should they!

So if desktop environments offer some kind of hook, applications must communicate their ability to "get hooked", but it is up to the desktop environment to decide what to do when multiple applications have this ability, not us.