appimaged: Move in all desktop files at once

[probonopd]

(from AppImage/AppImageKit#577)

Currently we are writing desktop files as soon as we have extracted them to .local/share - this triggers some desktop managers to rebuild the menus after every desktop file, resulting in a major slowdown of the system.
So instead, we should extract them to a temp location and only after we are "done" (as in: we did not process any new AppImages in the last second or so), move them in together at once.

[probonopd]

And then run

update-desktop-database ~/.local/share/applications
gtk-update-icon-cache-3.0  ~/.local/share/icons/hicolor/ -t
gtk-update-icon-cache  ~/.local/share/icons/hicolor/ -t

[probonopd]

I think that parts (or all?) of this logic ("scheduled... for integration") might be implemented in AppImageLauncher. Correct @TheAssassin? If so, could the logic be moved to libappimage so that all libappimage consumers would get to use it?

[azubieta]

@probonopd From my point of view libappimamge already have all the required parts. You can provide a custom $HOME path to deploy the files without editing the environment variable. This feature is used in the tests cases to avoid polluting the developer system.

The schedule feature implies threading which is a very error prone feature and every developer has a different favorite library to do it. My vote goes to keep such feature out of libappimage

[probonopd]

@azubieta can you make it work in appimaged then?

[azubieta]

Sure, but as you suggested it would be nice to have part of this feature on libappimage without the synchronization thing. So the client will be responsible for starting and committing transactions.

[probonopd]

Yes, I thought it would be good to abstract that away in libappimage so that the individual consumers of libappimage don't have to implement any of this. Actually I still think that would be great to have.

The schedule feature implies threading which is a very error prone feature and every developer has a different favorite library to do it.

Exactly because of this I would say let's do it once and in a correct way rather than have every developer fight with this on their own, leading to many (different) bugs.

[probonopd]

So @azubieta how can we get the situation improved?

[probonopd]

What can we do to get this done after all? Instead of duplicating (copying) code from AppImageLauncher, I still think it would be great if libappimage would provide this functionality, so that not each user of libappimage needs to do this on their own.

[azubieta]

libappiamge will receive this feature as part of the solution to this issue: AppImageCommunity/libappimage#28