Here is what i know:
- Menus read the .desktop files.
- My menu is Rof
Following is what i did to figure out this problem. Maybe it helps some new to linux users with their problem solving. If you are only interested in the solution and not the path to it, feel free to skip to the end.
I have located the .desktop files by utilizing
sudo find -iname "*.desktop" | less in the root dir of dom0.
The list was long, but i was able to visually spot locations where many .dekstop files are located.
The one promising location i was able to quickly detect was
Taking a look at the entries that are problematic to us: dvms.
Here is the content of
home/$USER/.local/share/qubes-appmenus/whonix-ws-16-dvm/apps/ by issuing
ls -1 on that location.
So one can see, that there are duplicate entries for:
I highly suspect the
dispvm is for the dispvms and the
vm is for the dvm-template.
The content of those files look like this:
Name=whonix-ws-16-dvm: Tor Browser Downloader (AnonDist)
GenericName=whonix-ws-16-dvm: Download Tor Browser
Comment=Download Tor Browser (AnonDist)
X-Qubes-NonDispvmExec=qvm-run -q -a --service -- whonix-ws-16-dvm qubes.StartApp+anondist-torbrowser_update
Exec=qvm-run -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+anondist-torbrowser_update
This leaves us with a few options. I would prefer to not see them at all, so i would delete all
vm entries in the folders of my dvms. A less destructive approach would be to rename them from
$NAME.desktop.old. This didn’t do the trick for me.
I can think of three possibilities:
- Rofi caches the menu entries
- Rofi reads all files in the location regardless of file type
- I am at the wrong place
So i changed the icon of tor browser to the icon of systemcheck for the dvm entry without success.
I suspect that i may be in the wrong place so i searched for a specific .desktop file with
sudo find / -name "org.qubes-os.dispvm.whonix-ws-16-dvm.janondisttorbrowser.desktop"
There are the following placed that file exists:
/home/$USER/dom0-home/... This is an old dom0-home from an backup.
/home/$USER/home-restore... Don’t know what this is, but seems like something backupish
/home/$USER/.local/share/qubes-appmenus This is where i tried
/home/$USER/.local/.gnome/apps/... Don’t know what that is, but i don’t use gnome
/home/$USER/.local/share/applications Looks the most promising now.
For testing i changed the icon of my dvm torbrowser by commenting out the line and adding the one from the system settings .desktop:
Name=whonix-ws-16-dvm: Tor Browser (AnonDist)
GenericName=whonix-ws-16-dvm: Privacy Browser
Comment=Start Tor Browser (AnonDist)
X-Qubes-NonDispvmExec=qvm-run -q -a --service -- whonix-ws-16-dvm qubes.StartApp+janondisttorbrowser
Exec=qvm-run -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+janondisttorbrowser
I can see the new icon in my menu now, so i am definitively in the right place and there is no caching.
So i reverted the change and moved the dvm .desktop to .desktop.old.
The duplicate menu entry is gone now
To see if this change would be persistent i run go to the qube manager gui and click “refresh applications”.
This does not revert my changes, nor does running
What does revert the change, is if i remove the entry in the settings, save, add it again, save.
Taking another look at the .desktop file i see other possibilities than deleting or renaming, that may be more persistent:
- Changing the icon
- Setting another name
I tried removing any references to the word “whonix” of the desktop but kept the Exec lines. I can still find the entry when searching for whonix.
To remove the duplicate menu item for the dispvm-templates from your menu, rename the
/home/$USER/.local/share/applications/org.qubes-os.vm.$QUBE_NAME.$APPLICATION.desktop to the same name +
This will remove the entry that launches the application in the template of your disposable, so only the actual disposable menu entries remain.
To launch the application in the template, you need to launch it via command line. Or revert the change.
This is my preferred solution, maybe changing the icon in this file is better suited to your use case.
May break stuff for you, for me it does not.
May be a sub optimal solution.
May not be persistent.