This was the original thread that discussed issues with the menu (not sequencing).
Originally, I was having trouble with DVM templates not showing up properly in the KDE menus, and originally I had to resort to creating the DVM template under a different name, then rename it to the proper one. If I didn’t do that, it never showed up as anything other than a normal AppVM (one that is not a DVM Template). That of course made it impossible to use the menu to launch a disp1234 type disposable.
THAT problem got solved, but as I tinkered more and more with it it appeared that different “classes” of VMs (and I am for purposes here considering a dvm template to be a different class than an AppVM…I know they’re technically the same under the hood, but from the user standpoint they are very different). I can’t give details right now as I am not on my Qubes system; I will amplify on this later.
[To repeat: For my purposes there are four “classes” of VM, four different cases: TemplateVMs, AppVMs, DVM Templates, and named DVMs. AppVMs and DVM Templates behave differently here.]
Another discovery I made is that calling qvm-sync-appmenus from within salt does absolutely nothing. In a “base” (dom0) run sls file, I can start the VM, run qvm-sync-appmenus, then shut down the VM (all in sequence of course, with requires and the like to ensure they don’t run in the wrong order), and the menu is not altered in the slightest (note: to verify this, make sure the menu is wrong before you start; run it in isolation rather than as part of a bigger sls file, which may have the menus right before even doing this, for some other reason). If I run those steps from the command line in a dom0 terminal, it works; and certainly the applications tab on the settings window works. I can also run the steps from a bash script. So I do. After every VM configure (invoked from a bash script) the bash script then does a start vm, qvm-sync-appmenus, shutdown vm. Yet another reason I have to run salt from bash, because salt won’t do this. I haven’t had to bring up the settings GUI to fix my menus and desktop shortcuts after the fact now, for several months (since I started doing this).
(NB, though: If the GUI tab page refresh is being run for a named dvm, and the disconnect is in the template VM, the GUI does not work; it only goes to the parent template (a DVM Template) for “updates”; it doesn’t go back to the DVM Template’s Template VM.)