Unless there are other comments, I think the blog post is almost ready to go. Updated the preview:
News - Whonix Forum
The only thing I would like to sort out before posting it are my above questions since otherwise it would contradict.
Yes. Steps have been included which successfully create entries to the XFCE4 menu in Qubes 3.2.
if XFCE4 menu was replaced by “desktop shortcut”, it would be ready to go.
Careful here lest users ignore the warning in the wiki. Ancestor VM if called from dom0; Calling VM if spawned from domU. This is actually a weakness of current implementation.
Looks good!
A couple conservative wording changes:
The major benefit of this approach is that the Whonix-Workstation DisposableVM can be created in order to host a single application – usually the Tor Browser – without any risk that a compromise of the browser will effect any of your other VMs.
“without any risk” > “mitigating the risk”
Critically, a Tor Browser exploit will not effect (poison) later instances of the Tor Browser running in a subsequent DisposableVM session, because the DisposableVM is always started in a clean state.
“effect” > “affect”
“in a clean state” > “in its original state”
Thanks entr0py. Agree with your changes. My old English teacher will kill me if they saw effect and affect mixed up again 
@Patrick, I was referring to steps for changes to the Qubes menu as ‘working’ i.e. Qubes Blue/Gray Button -> DisposableVM -> (new) Tor Browser entry
That is, replacing the instance of ‘Firefox’ from the DispVM menu with Tor Browser instead.
Sorry, I didn’t get around to trying the the menulibre entry as I had promised earlier. So that is still ‘untested’, unless you have it working. I’d still like to try those untested steps sometime over the next week, so that ‘untested’ can be removed from the wiki entry.
But please go ahead and put up your blog post if you are happy with everything else.
“effect” still needed to be changed to “affect” in that blog post 
Anyway, I have tested Option#1 of generating a non-customized DisposableVM-Template which works.
So, you can remove the “untested” tag from the wiki here:
Option #1: Use a non-customized DisposableVM-Template. (untested) This template will use a stock image based on whonix-ws and will not preserve any changes that are made to it.
Re: “Adding shortcuts to applications menus”, which is also untested in Qubes 3.2, I have followed the steps up to this point:
Once the .desktop files have been created, they need to be added to your Applications menu. Use a text editor to edit the following file.
kwrite ~/.config/menus/xfce-applications.menu
Note: There is NO xfce-applications.menu entry anywhere in the template. I have searched using find and ls to no avail. Using kwrite as above just creates a new (empty) file.
Surely Marek knows where this (.menu file) is stored for dispVM template in the Qubes architecture? After all, the entry for the original DispVM menu can be edited to replace Firefox with the Tor Browser entry instead via Alt F3 in dom0.
So where is it? Adding the additional .desktop entries should be simple enough. Maybe he can give us some pointers.
I have not attempted the menulibre option, as I don’t want to bork my menu as per other people’s recent experiences.
You mean dom0 right?
This is the reference I used for instructions: howto:customize-menu [Xfce Wiki]
Things to try:
sudo find / -name *.menuecho $XDG_CONFIG_HOME/etc/xdg/menus/xfce-applications.menu~/.config/menus for customizationFixed.
Done.
If you get comfortable with git (and virtual consoles, was not even required for me), you can easily rewind any changes by non-root applications such as menulibre that are only writing into the home folder.
All in dom0 /home/user.
Seems like some .desktop file is required in .local/share/applications. Example:
.local/share/applications/qubes-dispvm-firefox.desktop
And qubes-dispvm-firefox.desktop is referenced in:
.config/menus/xfce-applications.menu
I guess these are the files to edit by emulating how its done with the two above files. A word of caution: I managed to loose my system settings Qubes start menu entry by just adding a new desktop file to .local/share/applications/.
What if you cp /etc/xdg/menus/xfce-applications.menu ~/.config/menus/ first?
That restored my system settings Qubes start menu entry.
/etc/xdg/menus/xfce-applications.menu mentions DefaultMergeDirs. That may be a lead for investigation. DefaultMergeDirs to me implies it may be possible to extend the start menu without having to directly edit ~/.config/menus/xfce-applications.menu (by editing some other file).
XFCE follows the freedesktop standard. The DefaultDirs are explained here: Desktop Menu Specification. These Dirs specifiy locations to look for .menu (MergeDir), .directory (DirectoryDir), and .desktop (AppDir) files.
I decided to stop being an idiot and went to look for the Qubes .menu file. From this: qubes-desktop-linux-xfce4/garcon/garcon-0.2.0-qubes-menus.patch at release3.2 · QubesOS/qubes-desktop-linux-xfce4 · GitHub, it looks like Qubes is pulling in .menu files from some applications.d directory. Best guess for location would be one of $XDG_DATA_DIRS, so maybe /usr/local/share/applications.d/. That must be where each VM has its own .menu file. If you can locate the DispVM-like.menu, then it should just be a matter of adding custom .desktop to the <Include> section.
Thanks to both of you. I’ll play around with this and see if I can work it out.
How timely… if anyone is looking to become an expert in Qubes appmenus… https://groups.google.com/d/msg/qubes-devel/nR_VRLX6FPc/JDoWwKkBDgAJ
We should test these Qubes instructions for DispVM customization and then replace the existing (untested) instructions we have for DispVM menu customization.
I presume everything is the same as below, except references for usr/share/applications is replaced by ~/.local/share/applications for Disp Whonix-Workstation VMs (?)
Adding arbitrary programs to Disposable VM Application Menu
For added convenience, arbitrary programs can be added to the Application Menu of the Disposable VM. In order to do that arbitrary.desktop file has to be created in /usr/share/applications in Dom0. That file will point to the desired program. Use following template when creating a .desktop file:
[Desktop Entry]
Version=1.0
Type=Application
Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
Icon=dispvm-red
Terminal=false
Name=DispVM: Arbitrary Name
GenericName=DispVM: Arbitrary Generic Name
StartupNotify=false
Categories=Network;X-Qubes-VM;
Next, the /etc/xdg/menus/applications-merged/qubes-dispvm.menu file has to be modified so that it points to our newly-created .desktop file.
Add arbitrary.desktop line to the block. The modified file should look like this:
qubes-dispvm-firefox.desktop qubes-dispvm-xterm.desktop arbitrary.desktop
After saving the changes our program should appear under the Disposable VM Applications menu.
For Qubes R4 there have been quite some changes that need catching up:
Things are “starting” to get confusing 
inheritance (on create) persistence (on poweroff)
TemplateVM n/a everything
TemplateBasedVM /etc/skel/ to /home/ /rw/ (includes /home/ and bind-dirs)
DispVM /home/ nothing
Conceptually, dispVM is now more flexible/convenient than before but potentially less anonymous since they are based on templateBasedVM and not templateVM - meaning there are more opportunities to configure them badly.
Potential tickets:
/etc/skel/ instead of /home/user
sys-whonix-dispVM;sys-whonix; disable update proxy in sys-whonix//cc @marmarek Please have a look the post above mine.
It’s a nice table! @entr0py Perhaps add DispVM template or is it the same as TemplateBasedVM?
Could you please add the table to Whonix or Qubes wiki? (The latter would be better since it specific to Qubes, not Whonix. However having this table anywhere for reference would help a lot.)
Questions:
When trying to start a DispVM for the first time, it actually starts the DispVM template such as whonix-ws-dvm. After shut down, using the very same shortcut to start the DispVM, it starts an actual DispVM starting Disp[...]. The user may be confusing the DispVM template for the actual DispVM since there is no graphical explanation what is happening. Is that right? If so, shall we open a usability bug?
How to start the DispVM Template (such as whonix-ws-dvm) for a second or subsequent time?
It’s maybe not ideal to introduce sys-whonix-dispVM as UpdateVM. That would hopefully only be an intermediary solution if anything. (As per this)
Could a whonix-ws based DispVM act as UpdateVM? Does that even require development on the Whonix side? (UpdateVM might work out of the box? Qubes updates proxy likely not?)
Hm. Good question. Still trying to wrap my head around it.
Related:
Based on that, what about the following implementation?
tb-updater-first-boot.service in TemplateVM. (Already implemented.)tb-updater-first-boot.service in DispVM Template. How could being run inside DispVM Template be detected from within the first-boot-home-population script? @marmarek/var/cache/tb-binary to user home. (Already implemented.) → That would result in whonix-ws-dvm based DispVMs inheriting upgraded versions of Tor Browser if the tb-updater package in whonix-ws TemplateVM gets upgraded. That would spare the user from having to run tb-updater inside whonix-ws-dvm, which really wouldn’t be great to require (one VM more to update, one more complication).
Awesome, in Qubes R4, we can have a whonix-ws based disposable AppVM acting as UpdateVM as @marmarek pointed out. Sounds not too difficult, but I haven’t tried it yet.