If I clone a template that has both menu-items and default-menu-items set as features (qvm-features) the clone will have menu-items set to the original’s default-menu-items. (This is the same thing that happens if you create an AppVM based on that template…in that case it’s useful behavior.)
For example, take template-a whose menu-items are xterm and start-qube, but whose default menu items are xterm, file manager, start-qube and firefox. The reason you might want to set things up this way is because you don’t want to have a menu entry for firefox on your template. You shouldn’t ever want to run firefox on a template. (When you create an AppVm based on template-a, default-menu-items becomes the AppVM’s menu-items, so the AppVM now has firefox in its menu, which is exactly what we want.)
The problem is, when you make a clone of template-a to template-b, the menu-items for template-b is treated the same way; it gets set to to template-a’s default-menu-items. So now you can run firefox on template-b through the menu, and you couldn’t do so on template-a. So the two templates are not identical. I don’t think this is right, I think qvm-clone should set the new template’s menu-items and default-menu-items to be exactly the same as the source template.
NOTE: If template-a does not have ‘default-menu-items’ set, then menu-items gets copied to the clone as one would expect. It’s only when default-menu-items is set in the source, that there is an issue.
@SteveC If you write the issue description here (minimal steps to reproduce, affected versions, etc. I let you figure out what should go in there) I can open the issue.
Once opened, you can track any issue without an account.
OK: Qubes version, 4.1 is what Qubes Global Settings shows. No sub-sub-version number is shown, but I keep my system updated.
I have no idea what other versions are affected but I wouldn’t be surprised if this has been going on a long time.
Find (or create) a template whose menu-items and default-menu-items are different. default-menu-items cannot be empty. Check using qvm-features.
Clone it with qvm-clone <existing template> <new template>
Run qvm-features on the new qube to show that both menu-items and default-menu-items are set to whatever the original qube had for default-menu-items.
Note: If default-menu-items is empty/unset the clone operation correctly copies the menu-items (which is probably why no one ever noticed this before).
Note: Whoever works this please ensure there isn’t a similar problem for AppVMs (both dispvm templates and ‘normal’ AppVMs) and for named disposables.
Thanks for the reporting this bug. I wasn’t aware of menu-items and default-menu-items, so your explanation and example use case were educational for me. Out of curiosity, how do you actually use these? For example, how would a user actually implement the example you described?
I’ve just now converted my salt scripts to use them properly. I didn’t figure out until recently what default-menu-items was actually for.
I now ensure, when I clone a template, that its “menu items” is set to what I want to see in the KDE (or xfce) menus for the template. Generally a terminal, start-qube and the like. This feature is what actually governs what shows in the menu. I do NOT put any sort of user apps (like firefox, keepass, libreoffice, etc.) in this feature since I don’t want to be running them in the template. Ideally I will never run the template at all (except for updates, and that’s automated).
I set up default-menu-items (in the template) to be the list of things I want to see in the AppVM’s menu. For example, I will list firefox here if it’s present.
When I create the AppVM from the template, the system does the same thing it does for the clones–except that this time, it’s appropriate. It makes the AppVM’s menu-items look like the template’s default-menu-items. Done; I don’t have to explicitly set menu-items in the AppVM any more!
It’s a LOT more complex when the AppVM is a disposable template; I won’t go into that here, but I started a guide on menuing and I will add to it.
I discovered this bug when I realized my templates were getting messed up somehow, I eventually realized their menu-items features were being altered when they were cloned. My workaround was to define two new features, tmpl-menu and appvm-menu, and set those to what menu-items and default-menu-items should be. When the template is cloned, those get copied faithfully when cloned and my script or salt state file can then fix the “real” menu-items and default-menu-items immediately after the cloning, putting it back the way it should be.
My question was actually much more simplistic: What steps would a Qubes user take in order to achieve this result?
For example, I see that I can go into the Applications tab of my template’s settings and add/remove application shortcuts, but won’t doing that just change bothmenu-items and default-menu-items? What’s the step where I get to make menu-items and default-menu-items different from each other? Is it only a Salt thing?
In the Applications tab, it will change only menu-items.
To change menu-items or default-menu-items, you have two tools: qvm-features or qvm-appmenus.
To read the values:
[user@dom0 ~]$ qvm-appmenus xx --get-whitelist
xterm.desktop
[user@dom0 ~]$ qvm-appmenus xx --get-default-whitelist
org.gnome.Terminal.desktop
org.gnome.Nautilus.desktop
firefox.desktop
[user@dom0 ~]$ qvm-features xx menu-items
xterm.desktop
[user@dom0 ~]$ qvm-features xx default-menu-items
org.gnome.Terminal.desktop org.gnome.Nautilus.desktop firefox.desktop
To set the values:
The values must be the file name as it is in /usr/share/applications.
(You can also see the file name by overing your mouse over the app in the Applications tab)
e.g. xterm.desktop or org.keepassxc.KeePassXC.desktop
For qvm-appmenus, there are --set-whitelist PATH and --set-default-whitelist PATH (use ‘-’ to read from stdin).
e.g. echo xterm firefox appxx | qvm-appmenus xx --set-default-whitelist -
For qvm-features, just add the values after the feature name.
e.g. qvm-features xx default-menu-items 'xterm firefox appxx'
More info with the manual pages man qvm-features and man qvm-appmenus
Or the shorter qvm-features -h and qvm-appmenus -h
I can see from the issue that it has been addressed.
In reading the source code out of context, though, it’s not clear whether the fix will also affect the way creating an AppVM based off a template will work (in other words, does the fix ONLY apply to cloning?).
In the case of creating an AppVM based on a template, you actually DO want the default-menu-items of the template to become the menu-items of the AppVM.
Also it looks as if, if the original has no menu-items set but does have a default-menu-items set, then the copy of default-menu-items to menu-items will still happen in the clone. If so, that’s not proper for a cloning–the idea behind which is to create an identical copy–and one shouldn’t try to fix a deficiency in the original in the process.
I suppose when the next update goes out I will have to check to see how it behaves in both cases–it’s hard to be sure when reading a fragment of code out of context.
