Flooded with desktop notifications when moving files

[auwsom]

I installed AppImageD first, interested in the integrating the task launcher. Installed AppImageLauncher also to test it out. Then I found AppIMages can be made to store settings locally by creating .config and .home dirs. I tried moving the files to a new partition with more space and I started getting a slew of desktop notifications saying ""Other AppImage integration daemon running", "Please uninstall appimagelauncher first, then try again" that came from appimaged. Alarmed that this would overfill my logs space and freeze my system, I restarted, only to find them still running. Does this flood really need to happen after simply moving a file?

Then I had to search and search to find out how to actually remove both services because they didn't come up in systemctl status, all while hoping my system didnt freeze. Is this the most clear way to implement the service and allow for troubleshooting? https://github.com/probonopd/go-appimage/issues/126

[probonopd]

appimaged and AppImageLauncher are doing similar things, and they interfere with each other.

You must not have appimaged and AppImageLauncher on the same system. For this reason, appimaged will refuse to run if it finds any remnants of AppImageLauncher on the system.

appimaged and (iirc) AppImageLauncher are run by systemd as per-user processes. So you need to tell the systemd tools that you want to look at per-user processes (I think using systemctl --user ...).

[auwsom]

@probonopd Thanks for the response. I had installed appimaged before AIL. Thanks for the info about it running as user. I downloaded the appimaged.appimage file and AIL moved it into ~/Applications directory, what it looks like it was still causing problems. Having the AppImage file for appimaged seems a little confusing.. isn't it better to run via the command line?

Since I'm trying to integrate the apps manually with dot desktop files, so that I can run the images in Portable Mode, I've been able to untangle most of the mess. Atom still won't run in Portable Mode and I'm not sure why not. I read about the use of binfmt with AIL, that requires restart. Why is such a low level integration necessary? Isn't all it's doing is retrieving dot desktop files and icons from the /tmp mount dir and creating symlinks in the system desktop and file manager location?

I'd still like to use appimaged if it would support portable mode.

[probonopd]

I'd still like to use appimaged if it would support portable mode.

It doesn't specifically need to "support" it. It's each AppImage itself that needs to support it.

Say, you have ~/Downloads/Geany-1.38.0-x86_64.AppImage.

Simply run once ~/Downloads/Geany-1.38.0-x86_64.AppImage --appimage-portable-home and it will create the ~/Downloads/Geany-1.38.0-x86_64.AppImage.home/ automatically for you. (You can also create a directory with that exact name manually and it will be used.)

It will be used by the AppImage no matter how it was launched.

Please let me know if this does not work for you.

---

binfmt with AIL, that requires restart. Why is such a low level integration necessary?

That is off-topic here, Ask the AppImageLauncher project. It is not necessary to run AppImages.

[auwsom]

Hi @probonopd, thanks. That is nice to know that is built in. What I meant was that it appears that Appimaged cannot run and leave the appimages in their current directory (from what I read in the issue below and a search through issues). I ran a command that created config and home dirs for every one of about 10 apps but when I installed Appimaged it broke that. I dont remember seeing a warning it would move them. I would install it again now but am afraid after the trouble either Appimaged or AIL caused. Additionally, if I uninstall, I feel like it should put them back to where I had them.

Do the apps need the config dir too? I have seen some of them using them so I assume so.

So does Appimage not use binfmt or low level causing non-easy uninstallation file systems and attachments? I will lean toward Appimaged if so.

If the could run from where a user puts them it may also solve this user issue below, as that is one of the functions of portable mode. The main file could even be symlinked to different dirs where there were portable home and config directories. https://github.com/probonopd/go-appimage/issues/173