Hi, I’m currently working on flatpak integration in templates, the only missing piece would be to sync the app menus from the template to dom0. I need some help here 
When install a package in a template, a hook is run to report the new application list to dom0, but I can’t figure how it does that.
For Fedora, it’s done through a DNF hook installed at /usr/lib/python3.X/site-packages/dnf-plugins/qubes-hooks.py in the template, calling /etc/qubes-rpc/qubes.PostInstall → /etc/qubes/post-install.d/10-qubes-core-agent-appmenus.sh → /usr/lib/qubes/qubes-trigger-sync-appmenus.sh
Thank you very much, that’s exactly what I was looking for
Do you happen to know how debian does this?
Sometimes I just copy-and-modify a new desktop file (e.g., I make a copy of firefox.desktop that, instead of running firefox directly, calls a script that runs firefox then shuts down; that way a named disposable behaves a bit more like disp1234.)
When I do that in salt, oftentimes the named disposable that I ultimately create based on the dvm template, based on the template, doesn’t end up with that new desktop file in its menu. And that’s because whatever corresponds to this trigger in debian, doesn’t get called except when doing a real apt install.
I’d like to try to figure out how to manually “trip” that functionality from a salt script when all I do to “install” something is create/copy desktop files and simple scripts.
The first step is that a post-installation trigger for the qubes-core-agent package calls /etc/qubes-rpc/qubes.PostInstall, and from then on it’s the same as for Fedora.
Maybe you could run the qrexec-client-vm command from /usr/lib/qubes/qubes-trigger-sync-appmenus.sh?
It looks like all I need to do is call /usr/lib/qubes/qubes-trigger-sync-appmenus.sh itself…and my shutdown desktop file now appears in Settings: Applications on the left hand side.
I did this hours after constructing the template, by the way, in the template. Which tells me it doesn’t just process one .desktop file, it processes all of them.
Which tells me an even simpler method to take care of this might be to just create the desktop file first before doing any real package installs (which will call this bash script through the trigger mechanism)! [Note, though, that sometimes the desktop file is based off of one of the ones I install, so this could still be necessary.]