Move "run app" logic to shared module. about appimageupdate HOT 4 OPEN

Note that just executing a binary produces different results (at least in GNOME) compared to launching an application via its desktop file or via the menu:

• For applications that ship an icon but do not actively set the icon on their main window, the application icon will only show up in the dock if the application was launched via its desktop file or via the menu
• Also, the context menu items in the dock are only available if the application was launched via its desktop file or via the menu

I had written some code that emulates the "proper" way of launching something through its desktop file some time back, AppImage/AppImageKit#174 (comment). This is overkill for appimageupdatetool but we may want to consider this for AppImageUpdate.

Low priority though.

from appimageupdate.

Hm, the problem is that code links to glib, which I could successfully avoid as a dependency so far. First of all, the "run app" code has to be refactored out, however. If we add this behavior, it should probably not be part of libappimageupdate but the standalone applications.

from appimageupdate.

That is true. Ideally this would be invoked by runtime when running an AppImage. And indeed one would need to look deeper than this to understand how to re-create this without additional dependencies such as glib. So indeed probably out of scope here.

from appimageupdate.

@probonopd well we could always make a separate executable with that code.

from appimageupdate.