QubesOS
Improve handling of app menu shortcuts across template upgrades
The problem you're addressing (if any)
I recently switched from fedora-38-xfce to fedora-40-xfce. For whatever reason this change of template caused firefox.desktop not being in the template even though firefox is in the template. In fact, firefox even shows up in the list of "All available applications". So seems that for whatever reason firefox.desktop was renamed to something else. Neither during the switch of the template nor when trying to run the app I was notified. I just waited for firefox and was confused that it did not stark (and the dispVM did shut down automatically right after starting up)
The solution you'd like
On migration of template there should be a warning if an application in the qubes applications menu (not "all applications, but the selected ones) is no longer available and ask what it a) should be substituted by or b) whether the old menu entry is removed or c) should be ignored (like it is done now) or d) whether to abort the switch of template. For multi-switching of templates it should have an "use this for all other switches and report at the end" option such that you do not have to select it for each and every qube.
If the user selects an app in the app menu that does no longer exists, the VM, especially a dispVM should not be run at all (well, if the VM is running already you should surely not shut it down). Obviously, qubes does already detect that the app is no longer available, as it is shown in the applications tab of the qubes settings. Why not tell the user this whent he click such a missing app instead of starting a VM that cannot run the chosen app anyway (and that will immediately shutdown again in the case of dispVM)
The value to a user, and who that user might be
Save time, know what the error is caused by, prevent the error
Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
Applications being listed in the appmenu should never block template upgrades. It doesn't really mean the application is not available. In this case, it changed name:
- https://github.com/QubesOS/qubes-issues/issues/9265
Is your installed template of this version: qubes-template-fedora-40-xfce-4.2.0-202405281929.noarch.rpm ? I believe this version contains the fix. You probably have to sync the appmenus also.
qvm-template info fedora-40-xfce
Yes, the command shows the version you mentioned.
I'd say "A qube should never be run for a tool if you already know that the software you start it for does not exist in the template :D"
And Firefox is only an example here
We've discussed this recently, there there was an interesting idea proposed: introduce few "application equivalence groups". Those would be group of applications with similar purpose or even the same application that just happen to have different name in different templates. And then, when switching templates, for any application that is missing in the new template, check if it's part of some equivalence group. If it is, check if maybe another application from that group is available - if so, replace the missing application with the one that is present.
For the case discussed here, one such groups could be "firefox" which would include:
-
firefox.desktop -
org.mozilla.firefox.desktop -
firefox-esr.desktop
Other groups could be:
- "file manager" - this would automatically switch to appropriate file manager when switching template flavors
- "text editor" - similar to the above
- "terminal emulator" - xfce4-terminal.desktop, gnome-terminal.desktop, konsole.desktop etc
And probably few more.
What is not finalized yet:
- what should happen if multiple alternative applications from the same group are present - my proposal is to take first (which also makes apps order in groups relevant)
- how should those be configured - we discussed about hardcoding the list somewhere in the menu handling code (qvm-appmenus tool?) but that's probably not the smartest idea
