Implement a more intuitive Qubes Manager

[bnvk]

While the current Qubes VM Manager works alright, there are a handful of bugs and it is not nearly as intuitive as it could be. Additionally, there are configuration settings that are missing from it and others that are a bit technical and overwhelming. Lastly, there are new big ideas like Recipes and installing apps that aren't taken into account at all.

UX Ideas / New Features

• Splits up VMs into App Qube, Networking, Devices, Templates, Standalones
• Choose applications to run by default on starting a Qube
• Dropdown to choose Open URLs in [Qube Name]
• Explain Power State of a Qube like Running, Paused, Dying, Crashed
• Intuitive options to install software packages into Qube or Templates
• Integration of Recipes that use the salt configuration Design and create salt formulas distribution method #1939
• Opportunistically offer links to Docs / explainer content Improve introduction to Qubes in installer #1774
• Last started / run
• Make "updating" VM action simple / less steps (restart)

Require Modifications to API

• Add Icon field instead of all VMs having a lock icon Add field for VM Icon #1873
• Add Description field so instead of anon-whonix there is also Anonymous Web Browsing Allow users to add free-form text to qubes (for descriptions, notes, comments, remarks, reminders, etc.) #899
• Add available_disk_space for resizing of qubes sizes Create dom0 API to detect global disk space available #2016

Considerations & Issues

• UpdateVM system defaults should only list NetVMs and ProxyVMs UpdateVM system defaults should only list NetVMs and ProxyVMs #1831
• run suspend / resume scripts also on VM pause / resume Remove "pause VM" button from Qubes Manager #1855
• Already assigned devices should not be listed as "available" under VM Settings > Devices of other VMs Already assigned devices should not be listed as "available" under VM Settings > Devices of other VMs #1838
• stop using abbreviations for whonix templates Stop using abbreviations for Whonix templates #1778
• change default proxy-vm: sys-whonix -> system-tor change default proxy-vm: sys-whonix -> system-tor #1777
• stop using abbreviations for default vm names stop using abbreviations for default vm names #1776
• change default appvm name: anon-whonix -> anonymous-browsing change default appvm name: anon-whonix -> anonymous-browsing #1775

...there is probably loads more things and will update accordingly 😄

[marmarek]

Added ticket reference to the VM description idea.

[Jeeppler]

@bnvk the issue #899 is quite important for me. I have many many VM's and I would like to have a VM description similar to what VirtualBox offers. I created some simple GUI mock-up under: https://groups.google.com/d/msg/qubes-devel/t32l-0BjlLs/w3Rir4LhAAAJ . If I can help you in any way or work together with you on issue #899 please let me know.

Note: VM description means for me a text box not a descriptive VM title.

[bnvk]

@Jeeppler thanks for the input and mocksup. I hadn't given much thought to Last started value, but I definitely see your point. I will try to work that into the new UI. I'm not that familiar with the VirtualBox UI, but I would be happy to checkout screenshots if you could take some describing what you mean.

I wonder if adding a user facing "group" value to VMs, such as Web Browsing or Work whereby a user would see all their web browsing related VMs (anonymous, social accounts, banking, etc...) would help. Not sure if this is ideal, but I wanted to jot the idea down!

[Jeeppler]

@bnvk VirtualBox provides a description box like shown here: https://software.grok.lsu.edu/image/19970.gif and https://programmaticponderings.files.wordpress.com/2013/04/view-of-oracle-vm-virtualbox-manager-for-windows.png , but it is not perfect and I was already designing my own idea as mock up. I would like to see the Last started value since this could be a good indicator for the question: Do I really need this machine?

I think furthermore that markdown support in the VM description would be nice. Maybe not full markdown support, but lists, code, bold text, italic text and heading support would be nice.

[Jeeppler]

"I wonder if adding a user facing "group" value to VMs, such as Web Browsing or Work whereby a user would see all their web browsing related VMs (anonymous, social accounts, banking, etc...) would help." I completely agree with you. This would be a nice idea. I would use the "groups" for filtering and define that:

• each VM can be part of 0 to N groups

for example:

• python-dev is part of: "Python", "Programming", "Development", "Work"
• zololo is part of: "Python", "Programming", "Development", "Work", "Customer", "Project"

[mfc]

not seeing in the list:

• know network state from first level of Network Manager

the user should not have to go to VM Settings of a particular VM to know if the VM is non-networked, going through sys-whonix, sys-firewall, etc.

I guess "grouping" VMs would be a potential workaround, if you create groups based on their networking state. But then they are not being based on user domain.

please ignore, hadn't adequately explored the existing Qubes Manager > View menu...

[andrewdavidwong]

User suggestions for improvements to the current Qubes Manager:

https://groups.google.com/d/msgid/qubes-users/57384F52.40907%40gmail.com

[bnvk]

@andrewdavidwong thanks! Added that to my list + had already been working that exact thing into new Qubes Manager :)

[bnvk]

@john-david-r-smith @dumbl3d0re @Jeeppler thank you for your feedback and suggestions. Great stuff in there @andrewdavidwong thanks for pulling in stuff from the mailing lists.

I made progress towards this issue, however, as of last week I am not officially working on it any longer as per @marmarek feedback / decision. Reasoning being: I am not a competent / fastest enough Python + Gtk developer (yet) and Qubes does not have the budget to hire additional engineers.

All the code I created exists in this repo and is signed with this key. I don't have wireframes or design comps (I was instructed to go straight to code) of what I was aiming for, so I will explain a bit:

An intuitive window that feels closer to a file system (as opposed to a list of VMs) that is categorized by qube type (AppVM, NetVM, TemplateVM, etc...). There is a secondary bar relevant to selected qube type (App Qube --> Attach Microphone) that are relevant to the current selected qube type. The biggest missing aspect is "qube state" (Running, Halted, etc...) as there were a few discussions / issues that would affect how this should be implemented best, IMHO see #1015 #1788 #1873

Doubling-clicking on a qube icon in the manager (pictured above) would open the following window:

This window contains common qube type specific actions () and is similar to the "Basic" tab in the current VM Manager. This view was not meant to fully configure a qube, as those actions would happen via the multi-tabbed Advanced window:

The other high level "sections" of the Qubes Manager are common, but discreetly different things, a user may interact with (Recipes, Backups, Global Settings) of which I implemented the later.

Most of these interfaces are still quite rough visually and have no integration with the actual Qubes dom0 API because the fedora-20 is not compatible with Glade (the Gtk GUI app) and fedora-23 not available for dom0 when I started. There is a rough start towards Recipes #1939 interface here:

In my repo is a list of ToDo Items that @marmarek and I outlined as per this current implementation.

At present I am unsure of how the team wants to move forward, and who will keep working through these issues. Given my primary skillset being a designer who's most competent at web engineering, but is now moderately familiar with Gtk, Glade, and Python, the few directions I see this going are:

1. I do not touch any of the code (python or Glade) while the core team finds someone else handle that. In which case, I can provide feedback & ideas via sketches and UI compositions
2. I only work within Glade to add elements and polish how things look (margins, fonts, icons, etc...)
3. I still do a bit of python as well as Glade, but is subject to review

All that said, since working on this will no longer be part of my paid salary, I am unsure how much time I will be able to commit to this, but I can try to help. I was very excited about where this is going and would love to see it implemented.

[Jeeppler]

@marmarek Why was he instructed to start directly with the coding part?

[marmarek]

The intention was to have UI mockup in glade (not necessary functional) to not need to rewrite it later. In theory shouldn't involve much python coding and indeed those windows done such a way doesn't involve much.

[Jeeppler]

@marmarek what is the idea for the future?

[marmarek]

We're looking for GTK developer to work on this task - there will be an announcement about this on ML.

[andrewdavidwong]

More user feedback in this thread regarding Qubes Manager (some users don't want it to change):
https://groups.google.com/d/topic/qubes-users/x2RR1udsQlY/discussion

[andrewdavidwong]

Suggested feature: The ability to hide system-manged (i.e., RPM) TemplateVMs. More generally, the ability to hide any user-defined VMs.

[andrewdavidwong]

Suggested feature:

Is it possible to add links of every VM that show at "start" menu also
to Qubes Manager at the right click menu as sub-menu of some parameter?
Right click on VM -> Menu -> Select "Apps" -> and get list of all
applications and possibility to start them from there?

[andrewdavidwong]

@evadogstar wrote:

Suggestion:
Qubes Manager UX - Add possibility to sort meny items up and down.
It's useful in big list to keep some most used application at the top.
https://i.imgur.com/gctZoJl.png

[Jeeppler]

While switching to Xcfe as default desktop environment the Qubes Manager will be split and integrated in the XCFE start menu. So, is there any reason to keep this issue open?

[andrewdavidwong]

@Jeeppler:

While switching to Xcfe as default desktop environment the Qubes Manager will be split and integrated in the XCFE start menu. So, is there any reason to keep this issue open?

Good question. As far as I know, we're still looking for a GNOME developer to implement a new Qubes Manager. Since, as you point out, the Qubes Manager's functions are to be decomposed into separate widgets in R4.0, I can only assume that the job of the GNOME developer will be to code the new decomposed widget system.

Even so, you're probably right that these two issues are probably now effectively duplicates.

CC: @rootkovska, @marmarek

[marmarek]

Yes, this is a duplicate now

[marmarta]

Tagging @ninavizz

[andrewdavidwong]

@evadogstar:

Now all tickets about Qubes manager closes? :(

What do you mean? This issue was closed as a duplicate 3.5 years ago.