Consider to unify 4 tools into one about appimaged HOT 38 OPEN

from appimaged.

AppImageLauncher doesn't intercept calls to AppImages solely with binfmt-misc, but also the MIME type. It adds an update and remove desktop action to the desktop files. It ships with tools for this purpose, and doesn't depend on external tools (which need to have any specific filename). You can't break this functionality, like you can with appimaged, when the tool goes away.
Firejail support is planned (see TheAssassin/AppImageLauncher#32).

appimage-desktop-integration relies on the MIME type, and doesn't intercept calls. It has a different focus, it's more about "do you want to make this executable" instead of "do you want to integrate this AppImage in your system".

It should be noted that appimaged isn't scalable, and, compared to the other solutions, slows down the system e.g., during boot, and generates a lot of I/O operations (mainly read).

from appimaged.

The three are mutually exclusive (in the sense that no one ever will want to use all three), right?

from appimaged.

I think using them all together is pointless, though. But they're compatible. You could switch from appimaged to AppImageLauncher and vice versa. Brought to you by libappimage.

from appimaged.

These are two questions:

• Would anyone want to use all three together on the same machine, as of today?
• Can the three tools be merged (possibly by using runtime configuration options)?

from appimaged.

Why would you want to merge them? AppImageLauncher and appimaged work so differently. AppImageLauncher focuses on user control, not on automagic integration. There is no real point in merging appimaged and AppImageLauncher.

Using them together doesn't make much sense to me either. The update and removal tools AppImageLauncher provides are not compatible with what appimaged does. And AppImageLauncher is run only on behalf of a user action.

I don't see any point in merging them. Why don't you explain why you think it would be possible and make sense to merge any of them?

from appimaged.

In AppImage-Desktop-Integration ( ADI now on ), automatic integration is used along with the single app user control. So it's a merge between both approach. The rationale behind it is: I have several of apps in my system, the ones that I use every day are in $HOME/Applications and they are integrated in the system. The ones that I rarely use are somewhere else.

This allows automatic and unattended integration and removal of apps by means of the Applications directory. At the appimaged style, which keeps the idea making dead simple to integrate or remove an application in the system.

Also consider the AppImageLauncher is launcher functionalities useful, in the case of we would like to use Appimages from a CLI (where mime-types handlers are not used). Or to integrate/remove some applications that for some reason the user didn't want to have with the rest (by example in a Applications folder).

About the merge, we could provide from a single code base the three workflows:

• full $HOME folder monitoring
• only $HOME/Applications monitoring
• first run assistant (AppImageLauncher)
• update menu entry
• remove integration menu entry (which to be honest looks a bit awkward alongside with the delete menu entry)

from appimaged.

Why would you want to merge them?

AppImage is supposed to be simple, and having 3 tools doing kinda similar things (integrate AppImages into the desktop) is confusing - even me...

from appimaged.

AppImageLauncher keeps things simple from a user perspective. Much more simple than appimaged. Less magic, more control, and more visible actions. The user interface is kept really simple and understandable, but it has a lot of functionality in it.

from appimaged.

If simplicity means that the user have to do lees stuff to use a newly acquired application I must vote for appimaged (and it's magic which is totally transparent for the user). Once the application is download you can go and launch it from your menu or from the file.

IMHO The hard point about AppImageLauncher is control, the user can decide what is being integrated and what is not.

from appimaged.

Simplicity is more than just "count of mouse clicks". Simplicity involves the user experience, especially how understandable it is for the user. Nobody really understands appimaged. It does monitor only a set of predefined directories (which the user doesn't necessarily know), and doesn't work for applications on the entire system. If I'd plug in a USB drive with a set of AppImages, AppImages on then couldn't be run by the user if they weren't executable. And the user might not even want these to be integrated, not even for a minute.

Also, if AppImageLauncher crashes, the user will notice immediately, and can report the issue. If a daemon ever crashes, a user needs to spend time on investigating this when they want to launch an AppImage that they expect to be integrated.

Also AppImageLauncher is not prone to common daemon bugs like memleaks. It just runs during the launch, and then terminates. This is quite understandable. It works similar to a runtime.

from appimaged.

Actually end user doesn't want to understand anything about adding or removing applications from their systems. They just want to have an application or not.
The only thing that they should know: applications are stored at $HOME/Applications (or wherever you like)
Also it's true that there would be some applications that you are only testing and you don't want to integrate.
If the deamon crashes Apport (or something alike) will let you know to report the error.

Memleaks it's not a valid argument, it just says that we are not good C/C++ programmers.

from appimaged.

Nobody really understands appimaged.

Then we need to fix it or replace it by something better. Just piling up additional alternatives is not gonna help the cause. Can any of the other two solutions integrate (and make executable, if needed) AppImages prior to them being run at least once?

from appimaged.

Memleaks it's not a valid argument, it just says that we are not good C/C++ programmers.

It's just an example. There's many reasons a daemon could fail. And therefore you need to manage it. Claiming you're a good programmer so you may not produce a bug is quite arrogant, we all produce bugs from time to time.

If you're interested in integrating your tool into AppImageLauncher, we could talk about the following model:
We implement the daemon you have written in AppImageLauncher based on your code but using my integration code (in order to provide a consistent experience). We should write at least a systemd user config like appimaged.
The workflow is as follows: if a user launches an AppImage that is not in ~/Applications, AppImageLauncher will ask about the integration.
If a user moves an AppImage into ~/Applications themselves, the AppImage is automatically integrated. If it is removed, it is "un"-integrated. (We don't need to have the daemon do that even, actually, due to TryExec being a thing).
The user can optionally choose to disable the daemon by disabling it via systemd.

Would that be acceptable for you? We would have the "best of both worlds", combining the daemon and launcher approaches.

from appimaged.

Claiming you're a good programmer so you may not produce a bug is quite arrogant, we all produce bugs from time to time.

It wasn't my intention to show of that I don't have bugs in my code. I just want to say that bugs must be fixed as soon as possible instead of assuming that is fine living whit some of them.

from appimaged.

About merging, I agreed about creating systemd and upstart configurations for the daemon along with the auto-start entry (as backward compatibility, it's already done so it will not mean any extra effort). The TryExec indeed hides the entry but when the menu cache is updated, there will be a time in which the entry is shown but the file will not exist.

About using binfmt as hocking method on the integration assistant. the binfmt hook provides an interpreter for AppImage files so every time you call exec on one of those it will be triggered instead. As the AppImage are already binary files that can be executed there is no need of such interpreter. Also AppImageLauncher and "appimage-desktop-integration-first-run" are binfmt Graphical Applications that will be used in a Graphical Desktop Environment where mime-types are well known and supported everywhere. Therefore a mime-type handler is a lot less complex and also does the job of handling non-runnable AppImage files. If the file has already execution permissions there is no need for us to stand in the way.

About the functionalities of finding collisions and adding the menu entries for update and remove applications. They are excellent as they are.

About the overall merge I think that the appimage-desktop-integration has a better structure to accept the new changes. Because components are more decoupled and sorted. Already has a configuration to generate multiple runnables (daemon and launcher) and the launcher application GUI already has the views for checking the appimage file integrity and signature (only the views because signature checking is not complete yet).

from appimaged.

@azubieta you don't seem to understand the point of AppImageLauncher. AppImageLauncher is more than a simple "make it executable" application. It's supposed to ask the user whether to integrate AppImages on every run. And by taking control of the AppImage execution, one can improve the experience a lot. For example, suppressing the old-style desktop integration dialog isn't possible in 100% of all cases without binfmt_misc support. That's the core difference between our tools. AppImageLauncher might gain more functionality in the future that requires such a form of control about the application instance life cycle. There is nothing that could replace this form of control to implement the current set of features.

What I am looking for at the moment is a way to execute AppImages directly bypassing binfmt_misc in some way, e.g., by calling ld-linux.so.2 directly. Unfortunately I couldn't find a method that works so far, as the magic bytes in the AppImage runtime seem to violate the ELF specification in a way that makes ld-linux.so.2 refuse to execute it.

Regarding the structure: your application is a little more class-based than mine is. This might be due to me not being very used to Qt, and also because I prefer a more "functional" approach as long as encapsulation or inheritance isn't needed. I could only "decouple" my code more if I'd split up the shared module I have. But other than that, there is no real need for classes, or for a separate source file for every single functionality that is shared, following the KISS principle.

from appimaged.

@TheAssassin I know it's much more than "make it executable". I already test it, read the code and you even have explained to me several times.

What seems wrong to me is to try intercepting every call of an AppImage file like an interpreter would do (let's call it interceptor to not create misunderstandings). Once the user have granted executable permissions there is no need for us to stay in the execution way. An AppImage is "a self-sufficient application in a single file", there is no room for interceptors or pseudo-interpreters in that statement. I fear that, as you said, new features were implemented making the fact of having this application in the system mandatory to execute properly some kind of AppImages. Would you mind to mention some example future features that will require or be improved by having this solution approach?

I use classes (and OOP in general) not just because I'm used to Qt nor because I like them. Actually encapsulation implies a better "separation of concerns" by keeping the not only the functions but also the data they handle together. Also reduce the scope of the code forcing us to be less messy with the result of a more malleable solution. By pushing our code to be more modular we will reduce tremendously the amount of comments required as the entities name will do that job (if we name them well). Also the side effects of our changes will be reduced as they will stay inside the module scope. Finally higher modularity allows more granular testing giving us peace of mind in every release and the confidence to change stuff without fearing that we could break something else.

The same applies to files, they will expose the architecture of the solution. By example: in my project I could put all the "core" classes in a single "core.cpp" file as functions and the whole module structure will be hidden.

You can use classes and don't violate KISS, there are no fake inheritance trees or forced design patterns in the solution. Just simple classes that provide a simple set of related functionalities and share some common data.

To summarize, in this case I use OOP and a very decoupled file structure to:

• have more malleable modules
• reduce side-effects
• expose the solution architecture
• improve readability (using entities name as documentation)
• ease testing

NOTE: Suppression of the old stile desktop integration could be achieved by setting an environment variable.

from appimaged.

I fear that, as you said, new features were implemented making the fact of having this application in the system mandatory to execute properly some kind of AppImages.

Would you like to explain why you think there will be AppImages that won't run without AppImageLauncher? I already explained very often that AppImageLauncher is an enhancement. AppImages don't depend on it to run. Not at all. The opposite applies. AppImages can run fine without it.

What AppImageLauncher does, however, is that it can control some aspects of how the AppImage is launched. Setting the $DESKTOPINTEGRATION environment variable is a good example. Only by intercepting the calls to AppImages, this variable can be set reliably. There is no other way to do so reliably. Users can unset a system wide set $DESKTOPINTEGRATION variable. And if they do so, they break the system AppImageLauncher uses, as the old desktop integration isn't compatible with the libappimage one.

I don't see how there's an issue in intercepting calls at all by the way. If a desktop environment would do so in order to improve their AppImage support, would you mind? Why can't a third party app do so?

As said before, I don't like to ship with my own runtime to run AppImages. What I would rather like to do is edit the environment and then forward the call. That's the only real issue that needs to be solved.

from appimaged.

My fear is founded on that binfmt, as you said, give us a great power. You know the phrase "with a great power comes a great responsibility"? I just don't want to have responsibility of watching that what I'm doing will not break the applications run-time.

I'm calling on the KISS principle here, if a mime-type handler allows you to do intercept opening attempts on AppImage files in desktop environments why taking it to the CLI where there is no need to do anything for an AppImage to work as expected.

About your ISSUE did you tried loading the file as a regular shared lib and calling "main" ?

About the reliability of the environments variable. Yes the user can unset them, as they can also unset the binfmt entry. Does the fact that an user can break a system makes it unreliable ? If the answer is yes, then all GNU/Linux distributions are unreliable. I think your are exaggerating a bit on this topic. A lot of solid applications relies on environment variables starting from the initrd to the whole desktop environment.

from appimaged.

as they can also unset the binfmt entry.

The actual user can't alter these entries. You need to become root. And as root, you can create a lot of damage. So, actions as root user don't count really. If you're just a simple user, you can still call unset DESKTOPINTEGRATION in your shell, but you can't escape binfmt_misc support.

Considering your second argument regarding the MIME type, no, that's not quite true. As soon as the file is executable, you can't control its execution any more. That's why I implemented support for these use cases via binfmt_misc.

I will try to hack around using with dlopen().

from appimaged.

Escape binfmt_misc support is harder I know, but the thing is that you don't need it. Using an environment variable is good enough. If a regular user unset an environment variable they will do it on purpose, there is an unset command they have to run.

Would you please tell me why would you like to control an AppImage that was already set as executable by the user ? And what will you do with it besides of actually executing it ?

from appimaged.

Another reason to make use of binfmt_misc: TheAssassin/AppImageLauncher#42

from appimaged.

From the discussion in the ticket it looks like this is not a simple question. Maybe we should schedule a time at which we can have a conf call/jit.si session? May be easier. I'd like to understand all of the a) requirements b) potential solutions to arrive at something that is really simple for our users. Having 3 tools that superficially(!) seem to do the same thing is not ,-)

from appimaged.

@probonopd we're working on this topic already behind the scenes (i.e., not on GitHub, but IRC etc.). We'll post an update soon.

from appimaged.

I would add another point.
Could we have in non installed mode?

Namely I ran it, it runs in the background with all integrations applied.
But it is not installed or becomes permanent part of the system.
It is only work when initiated by user (For instance, it doesn't run automatically on restarts).

from appimaged.

...and to add one, https://github.com/CalebQ42/LinuxPA

from appimaged.

@probonopd ,
I'm not sure one must combine all.
Letting different approaches develop on their own means anyone can choose.

In my opinion the missing tool (Which will have some features of each still missing).
I will try describing it:

1. Has the ability to work with no installation (Better be AppImage on its own).
2. Runs only on demand (Namely it is not a background daemon with extra privileges, it is a regular program with System Tray icon).
3. Scans User Defined single location (By default the folder it resides at). Scan period should be user adjustable.
4. Here we have 2 approaches:
   • Application Menu of its own similar to PortableMenu.
   • Ability to integrate applications (And remove applications which were deleted) into the system menu.
5. Ability to register MIME for applications (User level, not system).
6. By default works in Portable Mode (Namely creates .home and .config folders per AppImage automatically).

In the long run with a data base of AppImage applications we can allow updating of AppImage as well.

from appimaged.

One difference between the tools is that appimaged runs as a daemon in the background, whereas other tools avoid this. A discussion at Discourse triggered by @RoyiAvital brought up the idea that we could turn appimaged into a non-daemon that does not run in the background, and have something else invoke it when needed. This "something" could either be a MIME type, or binfmt, or systemd Path Units (which uses inotify under the hood).

The beauty of this would be that we could decouple what the system integration tool does from how it is invoked, making for a more flexible system than we currently have.

wdyt?

from appimaged.

Has the ability to work with no installation

appimaged can do that. If you are fine with launching it manually, you can start and stop it like any other program, and for this it needs no installation.

it is not a background daemon with extra privileges, it is a regular program with System Tray icon

It has no extra privileges. In fact, it does what you describe but it doesn't have a tray icon (I don't like these).

Runs only on demand

What do you mean by "demand"? The user launching it whenever he has downloaded an AppImage? Or the system somehow (how?) invoking it when it "sees" a new AppImage?

Scans User Defined single location (By default the folder it resides at).

Currently we are scanning the locations listed in the README.md, but I like your suggestion that it should also scan the location at which it itself resides. Opened #7 for it.

Scan period should be user adjustable.

Why that? Currently it gets notified about changes by the kernel using the efficient inotify system.

In the long run with a data base of AppImage applications we can allow updating of AppImage as well.

This is out of scope here, but check https://appimage.github.io/apps/ and the various app centers and tools that use its data, e.g., https://github.com/opendesktop/opendesktop-app and https://github.com/nomad-desktop/nx-software-center (these are available as AppImages themselves, too).

from appimaged.

Has the ability to work with no installation

appimaged can do that. If you are fine with launching it manually, you can start and stop it like any other program, and for this it needs no installation.

How do I run it without making it run automatically on system restarts?
As currently the installation guide shows how to register it into "Run on System Startup".
How can I stop it if it has no System Tray icon?

Runs only on demand

What do you mean by "demand"? The user launching it whenever he has downloaded an AppImage? Or the system somehow (how?) invoking it when it "sees" a new AppImage?

No, I meant only when user starts it.
Just like a regular application.
Damon is a frightening concept for new users in Linux.
I want it to be application in the background.

So it seems what I miss is the following features:

1. User controlled ability (Per Application) to register on System Menu.
2. User controlled ability (Per Application) to register MIME.
3. User controlled ability (Per Application) to mark it as Executable.
4. User controlled ability (Per Application) to run using Sand Boxing (With AppImage which wasn't marked as executable only being run within Sand Box).
5. User controlled ability to select the directories to scan (I don't want all of those).
6. Use Portable Mode - namely it will create .home and .config. for the AppImage it finds automatically.
7. System tray to have easy access to those settings.

from appimaged.

The problem with appimaged is that it is too quiet about what it does. I can already imagine explaining to my mother and grandmother for the 10th time how and why they can download AppImage files and be able to execute them right away. Even a notification saying "Application is now available" would help to connect the action of downloading to the automatic integration into the system.

But still, people who want to run applications manually will feel that the app is fighting them - especially in the use-cases where users want to run multiple versions side by side, having them integrated automatically makes it bad UX. Also, appimaged is rigid and not easily configurable, and relies on the user using the Terminal, which a lot of non-Tech-savvy users will look as too high a hurdle.

But, on the other hand, I don't think a centralized application for AppImages would be the best - except maybe if attached to the DE's software (ie. a plugin for GNOME Software like there are for Snap and Flatpak applications). AppImageLauncher may be best here wrt user experience, although I see some tweaks for UX improvement (will create an issue there).

All in all, I think the best solution wrt fragmentation is to have a blessed tool that has a balanced set of features and provides good experience out of the box. This will allow users to effortlessly use AppImages, and also application developers to trust AppImage being the solid foundation it is. This way, other developers can make their own projects if they want to, but first-time users can just follow a simple guide.

So, I believe the Launcher should be made the official integration companion (effectively replacing the current way which is to have publishers* opt into the "integrate with desktop" prompt), using a MIME handler to either show the user the integration prompt, or directly launch the application (by checking if the file is executable, for example). Other projects could include plugins to software centers (I saw one project on GitLab integrating the AppImage repository to GNOME Software).

from appimaged.

Just Copy & Paste the @PortableApps model into Linux.
That's all needed.

from appimaged.

How do I run it without making it run automatically on system restarts?

appimaged is supposed to always run in the background as a system process.

How can I stop it if it has no System Tray icon?

You don't. Why would you ever want to? Users install appimaged (or get it pre-installed as part of their distribution) and don't even have to realize that it exists. They should definitely not have to think about it or fiddle around with it. It is supposed to "Just work", like the many other background services that are running all the time on any Linux desktop machine.

from appimaged.

Even a notification saying "Application is now available" would help to connect the action of downloading to the automatic integration into the system.

I don't quite understand why one would need a notification. The point is that "it just works".

But still, people who want to run applications manually will feel that the app is fighting them - especially in the use-cases where users want to run multiple versions side by side, having them integrated automatically makes it bad UX.

Indeed, this is a tricky one. Mainly because the Linux way of integrating applications into the system was not really built for having many versions of the same application available at the same time. What should we do? Only integrate the latest version?

Also, appimaged is rigid and not easily configurable

It is meant to be not configurable at all. Configurability is the root cause of complexity, whereas we are aiming for a simple user experience that is the exact same for everyone.

relies on the user using the Terminal

Where does appimaged rely on the Terminal? It is meant to be launched by systemd, and all you need to do is install the deb.

All in all, I think the best solution wrt fragmentation is to have a blessed tool that has a balanced set of features and provides good experience out of the box.

Yes, we are thinking about this in the AppImage project, but it turns out that different users and contributors have greatly different ideas on how the user experience should be, making it difficult to design a solution that works for everyone.

So, I believe the Launcher should be made the official integration companion (effectively replacing the current way which is to have publishers* opt into the "integrate with desktop" prompt)

What do you mean by "the Launcher"?

We recommend that AppImages do not attempt to do system integration, but leave this job to tools like the optional appimaged daemon, or the third-party AppImageLauncher, or one day a great unified tool.

Other projects could include plugins to software centers (I saw one project on GitLab integrating the AppImage repository to GNOME Software).

Exactly. We want to encourage an ecosystem of independent projects to emerge around the AppImage format, and not do everything ourselves as the AppImage project. (Some time ago I started to write a GNOME Software plugin, but it is available for someone to take over because I was not interested in it enough to finish it.)

from appimaged.

I don't quite understand why one would need a notification. The point is that "it just works".

It doesn't matter that it "Just Works" if the user doesn't see what's happening. It's like in movies where a character suddenly moves from one location to the next without anything suggesting they moved. If the user manually installs appimaged they understand the use-case of the application and has hopefully read a bit about what it does. But in the case where the system is pre-configured or configured by someone else (like me configuring my parents' computer), the user will not easily connect "downloading an AppImage" with "The application is installed". The idea of showing a notification when performing the integration step was as an example of feedback to the user, the idea being the system shouldn't feel like it's performing magic tricks but are simply being a useful assistant to their tasks.

Indeed, this is a tricky one. Mainly because the Linux way of integrating applications into the system was not really built for having many versions of the same application available at the same time. What should we do? Only integrate the latest version?

This is where I think the idea of a daemon breaks down and where mapping a user action (like double-clicking on the AppImage file) seems better. I don't think a lot of "regular" users want multiple versions of the same application, but it is a clearly stated advantage of the AppImage spec, therefore, it should be maintained as a first-class feature.

It is meant to be not configurable at all. Configurability is the root cause of complexity, whereas we are aiming for a simple user experience that is the exact same for everyone.

Ridigity != complexity. I do agree that with every configurable setting we expand the space of all possible configurations, but you can have the most complex software and not a single option to tweak. Simple configuration options like where to put integrated AppImage and which folders to check - even if hidden in dconf or as environment variables. Simple users would use the app as-is, while people who want to configure their system to their liking exactly could choose which folders are tracked allowing them to place extra versions of an application somewhere that makes sense for them but know isn't tracked, for example.

But I do agree that configuration should be sparse and put there only where it makes sense.

[wrt to having a blessed tool], we are thinking about this in the AppImage project, but it turns out that different users and contributors have greatly different ideas on how the user experience should be, making it difficult to design a solution that works for everyone.

Indeed it's the bane of designing a product. I'm not saying we have to please everyone, and I'm not saying that nothing else should be made available. By having an official tool we can introduce new users without friction to AppImage and leave to other projects to build what they think is missing from the ecosystem.
For example in Python, pipenv has come to be the blessed package/project manager, however, there is space left for other tools (like poetry) which aim to do things differently.

A balance should definitely be struck here; there are two extremes to avoid in terms of the ecosystem. On the one hand, you have macOS which is closed for pretty much everything - in order to do anything you have to pass through official means and projects. On the other hand, you have Linux and its fragmented ecosystem because nothing being official means everything is equal parts official.

I believe this should be the minimal set of official projects:

• appimage/Specification, where AppImage is defined as what it is
• appimage/libappimage, C API for manipulating AppImages
• appimage/AppImageKit, the reference implementation (an example of blessed project, by the way)
• appimage/DesktopIntegration, the official project integrating to desktop

Related projects should be left to third-parties, maybe with a section on the AppImage website referencing them. Things like other integration projects, software center plugins, analyzers, etc. On the other hand, maybe bindings for other languages of the C API could also be officialized (something like python-libappimage which would help third-parties).

What do you mean by "the Launcher"?

I meant https://github.com/TheAssassin/AppImageLauncher/ which I think should be the base for the official desktop integration tool (instead of appimaged).

We recommend that AppImages do not attempt to do system integration, but leave this job to tools like the optional appimaged daemon, or the third-party AppImageLauncher, or one day a great unified tool.

I didn't know that, and it makes sense. I've always seen this attempt at desktop integration being more of a hack or a band-aid than something long-term.

Exactly. We want to encourage an ecosystem of independent projects to emerge around the AppImage format, and not do everything ourselves as the AppImage project. (Some time ago I started to write a GNOME Software plugin, but it is available for someone to take over because I was not interested in it enough to finish it.)

That's the project I had stumbled upon! I tried working on it but I'm not versed in CMake - and the libappimage-dev package on Ubuntu doesn't provide a pkg-config entry for some reason which means I can't easily remake the build configuration with Meson - but I haven't put much energy into it yet.

I guess I can try to take up the project, see if I can push it forward a bit.

from appimaged.

This is where I think the idea of a daemon breaks down and where mapping a user action (like double-clicking on the AppImage file) seems better.

Definitely - double-clicking the application icon in the file manager has been the traditional way to launch applications on the Mac forever, and is in my opinion still the most explicit (you always know exactly what it is you are launching, and where it resides). The "new" UX trend of having a launcher somewhat breaks with the "direct manipulation" principle and makes it harder for users to understand what it actually is that they are launching.

So - you raise a very valid concern here. I'm just not sure how the ideal resolution would look, apart from simply not using the launcher at all.

people who want to configure their system to their liking exactly could choose which folders are tracked

Somehow the Mac doesn't seem to need this, and is still working "as intended". To replicate that experience is my design goal. The user should not even know that something is being "tracked" at all - it should just work everywhere. Granted, we are not there yet. But I think we should strive for the user experience outlined in #30, i.e. learn from the Mac how things are done conceptually.

I believe this should be the minimal set of official projects:
appimage/Specification, where AppImage is defined as what it is

https://github.com/AppImage/AppImageSpec

appimage/libappimage, C API for manipulating AppImages

https://github.com/AppImage/libappimage (needs a better README.md)

appimage/AppImageKit, the reference implementation (an example of blessed project, by the way)

https://github.com/AppImage/AppImageKit (this is the main AppImage GitHub project, the one that has the stars; it contains the tools to turn AppDirs into AppImages)

appimage/DesktopIntegration, the official project integrating to desktop

https://github.com/AppImage/appimaged (currently under discussion whether AppImageLauncher can be changed so that it more or less {also} does what appimaged does, at which point the two might be merged)

Related projects should be left to third-parties, maybe with a section on the AppImage website referencing them. Things like other integration projects, software center plugins, analyzers, etc.

Agree. This is pretty much the conclusion that the main AppImage developers have reached over the past weeks as well.

On the other hand, maybe bindings for other languages of the C API could also be officialized (something like python-libappimage which would help third-parties).

Funnily, the first versions of AppImageKit were written in Python but then we moved to C (in my effort to have tools that have less runtime dependencies and are more generally accepted), and later libappimage was factored out and moved to C++ (because the contributors working on it deemed C++ more powerful and leading to better quality code). Having additional bindings would be good to have but we are currently also considering to expose functionality over dbus, which would make it easy to access functionality from any language.

That's the project I had stumbled upon! I tried working on it but I'm not versed in CMake

@TheAssassin is our CMake wizard in residence. Maybe he can help

the libappimage-dev package on Ubuntu doesn't provide a pkg-config entry for some reason which means I can't easily remake the build configuration with Meson

That's the beauty of build pipelines: Looking at https://gitlab.com/probono/gs-plugin-appimage/pipelines/23555988 I can see that my build succeeded 10 months ago, using 1e4f51fbc5ed940901824ffcd5beb52a67b8ed63.

I guess I can try to take up the project, see if I can push it forward a bit.

That would be great. 👍 Be sure to hang out in #AppImage on irc.freenode.net as well, where all the main devs are. Welcome to AppImage!

from appimaged.

double-clicking the application icon in the file manager has been the traditional way to launch applications on the Mac forever, and is in my opinion still the most explicit (you always know exactly what it is you are launching, and where it resides). The "new" UX trend of having a launcher somewhat breaks with the "direct manipulation" principle and makes it harder for users to understand what it actually is that they are launching.

The AppImage format is inherently portable, therefore anything that relies on "file stability" (files not easily able to be moved) will need some extra work to feel right. With snaps and flatpaks, since the application is downloaded and installed from a central place, system integration is easy - however with AppImage a lot of care needs to be given as to the behavior of system integration.

Be sure to hang out in #AppImage on irc.freenode.net as well, where all the main devs are. Welcome to AppImage!

Once I know where I've put my IRC client (or its AppImage ;) ) and when once I'll have dusted it off...

from appimaged.