New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

have DispVMs inherit launcher shortcuts like other TemplateBasedVMs #1339

Closed
adrelanos opened this Issue Oct 16, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@adrelanos
Member

adrelanos commented Oct 16, 2015

Currently as of Qubes R3:

  • Qubes Launcher (blue/green 'Q') -> DisposableVM misses the 'add more shortcuts' button.
  • Qubes Launcher (blue/green 'Q') -> DisposableVM lists only Firefox by default. Nothing else.

Proposal:
I suggest to change this, make the DispVM Qubes Launcher menu work like the menu for other TemplateBasedVMs.

Use cases:

  • There are various applications that one might use in an amnesic manner (in future thanks to #904). For example: if one created a DispVM based on whonix-ws, it would show the same shortcuts as a whonix-ws template based AppVM. Then the menu would not show Firefox, but for example Tor Browser and XChat. And starting up such an torified XChat whonix-ws template based DispVM would be done thing Qubes Launcher.
  • For a Debian based DispVM it would be nice to start either Firefox or Chromium using Qubes Launcher. Not being limited to launching Firefox.
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 16, 2015

Member

Good idea. But technically not easy, because DispVMs are started totally
different from other VMs (at least from dom0). This will improve in
R4.0, not sure if possible to do it also in R3.1...

So setting milestone R4.0 for now.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Member

marmarek commented Oct 16, 2015

Good idea. But technically not easy, because DispVMs are started totally
different from other VMs (at least from dom0). This will improve in
R4.0, not sure if possible to do it also in R3.1...

So setting milestone R4.0 for now.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 23, 2017

Member

This is done. When an AppVM being a template for DispVM (template_for_dispvms=True) have additionally feature appmenus-dispvm set (qvm-features vmname appmenus-dispvm 1), its menu directory will be named Disposable: vmname (instead of Domain: vmname) and entries there launch new DispVM with that application (same as "DispVM: Firefox" entry in Qubes 3.x).

Member

marmarek commented Oct 23, 2017

This is done. When an AppVM being a template for DispVM (template_for_dispvms=True) have additionally feature appmenus-dispvm set (qvm-features vmname appmenus-dispvm 1), its menu directory will be named Disposable: vmname (instead of Domain: vmname) and entries there launch new DispVM with that application (same as "DispVM: Firefox" entry in Qubes 3.x).

@marmarek marmarek closed this Oct 23, 2017

@maertsen

This comment has been minimized.

Show comment
Hide comment
@maertsen

maertsen Dec 15, 2017

For the release-notes: an additional qvm-sync-appmenus --regenerate-only vmname is needed after setting the feature before the change actually appears in the menu.

For the release-notes: an additional qvm-sync-appmenus --regenerate-only vmname is needed after setting the feature before the change actually appears in the menu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment