Does some way exist for an AppImage to create temporary a temporary x-scheme-handler?

[2011]

I have read these two issues before I opened this one to try to understand enough to ask the correct question:

https://github.com/AppImage/AppImageKit/issues/458

https://github.com/AppImage/AppImageSpec/issues/22

I don't really have much interest in "system integration" (generally, if I want an application to become part of the system, I would just install it). If I understand, I can't run appimaged, anyway (I don't use systemd), and for some sensitive programs (say crypto wallets, but many other types, as well), I would prefer a more "portable" experience without lasting footprints on the system (for those programs, I keep ~/.config/foo on an encrypted external drive than remains unmounted when not in use), meang no permanent entries in ~/.local/share/applications/mimeapps.list.

1. Does some way exist for an AppImage to create a temporary x-scheme-handler (one that disappears after stopping the AppImage)?

2. If not, does some way exist for an AppImage to add an appropriate mime entry (maybe in AppRun) when executed on a machine without system integration?

[TheAssassin]

There is no such feature at this point. I also don't see much of a point in it. As long as a tool like appimagelauncherd is running on the system, as soon as the AppImage file is gone, the integrated files will be cleaned up. The desktop integration code performs such an integration. You may be able to mimic that from your application code. This is relatively portable already.

If you're concerned about traces, then running applications on your regular desktop is never a good idea. You can never predict the application's behavior and whether it will store data on your system. The only way to work around this is to use some entirely isolated environment like a VM.

[2011]

As long as a tool like appimagelauncherd is running on the system, as soon as the AppImage file is gone, the integrated files will be cleaned up.

If I understand, AppImageLauncher requires systemd.

I don't use systemd

Never wil, either.

If you're concerned about traces, then running applications on your regular desktop is never a good idea.

I can monitor changes to the filesystem, and don't have much concern about stored data (easy to get rid of that). I worry about stored settings (changes to the system - also possible to get rid of, but a lot more work).

The only way to work around this is to use some entirely isolated environment like a VM.

I wouldn't want applications permanently adding mime types, even inside of a VM (possible to avoid, I guess, by running the VM in "discard all changes" mode).

The whole Linux Desktop Environment just doesn't seem set up for true portable apps (Windows actually, with some diligence, handles them more effectively).

Anyway, thanks for your reply.

[TheAssassin]

The whole Linux Desktop Environment just doesn't seem set up for true portable apps (Windows actually, with some diligence, handles them more effectively).

That can be proven wrong by many examples. What makes you think so?

[probonopd]

Well, some of the OpenDesktop XDG specifications are really not ideal for portable applications and make our lives harder than necessary. For example:

• Most Linux desktop environments (exceptions: GNUstep, ROX Filer) don't support application bundles natively (hence, we had to come up with AppImages as a workaround)
• Unlike on other operating systems where resources like icons are embedded inside the application binary itself (e.g., Windows .exe), we need a clumsy workaround to achieve something similar using thumbnailers
• Unlike on other operating systems, many Linux desktop environments assume that there are .desktop files for each application, in order to be able to get proper file associations set up. Which is why we need to use clumsy workarounds

So indeed, I think many desktop environments could become more conducive to portable applications.