Consider removing dom0 from a VM list in Qubes Manager #1382
Comments
marmarek
added
enhancement
C: manager/widget
P: major
|
I definitely think this is the right direction UX wise- to remove The question then is- where do we put the few actions pertaining to dom0 that makes most sense? My instinct is one of the following:
|
|
I think the second option is better - there are already IMHO too much buttons there. Maybe we should even remove some of them (first candidates: keyboard layout, remove VM)? |
|
definitely agree with removing dom0 from VM list. maybe for the topbar, we should only have listed actions that are global in nature (i.e. no actions that are specific to VMs (except start, pause, stop). users can already right-click on a particular VM or use the VM dropdown for VM-specific actions. I think start, pause, stop are common and administrative enough in nature they could stay. |
Yes. I agree. Both "Keyboard layout" and "remove VM" are low hanging fruits to nuke.
That might be a bit too drastic. I don't think relying on users knowing to "right click" on items is particularly the right approach- especially with new fangled / unusual systems like Qubes. If anything, more explicit "buttons" should be included on each VM item, so that necessary actions are more explicit. However, this starts to get out of hand and needs to be done with the right balance so we don't end up with similar issues like we have. My suggestion for the 3.1 release is that I give some thought to re-thinking the buttons in the current topbar of the VM Manager. Beyond that explore drastic refactoring of the VM Manager in general. I sketched some of these ideas with @rootkovska in DC and she was very keen on the concepts. Losely explained- I'm thinking about splitting them up into different "types" of VM managers (templates, networking, apps). |
|
Michael Carbone:
Yes, because dom0 isn't a VM. |
|
On Tue, Nov 10, 2015 at 07:06:50AM -0800, Brennan Novak wrote:
If we're going to do anything with this for R3.1, it needs to be done
Offtopic: while at it, Qubes Manager needs internals rewrite - it has Best Regards, |
|
On Tue, Nov 10, 2015 at 07:07:41AM -0800, Patrick Schleizer wrote:
Technically it is, just privileged one. But it doesn't mater. Best Regards, |
If feature freeze is two weeks, I don't think I can manage to implement this by then + as well as making headway on the public facing website work that is long overdue. |
|
at minimum all we need is to remove the dom0 listing and put a menu item under System for updating adminVM (assuming the updating dom0 by GUI actually works). And if updating dom0 by GUI doesn't work, have the link open a terminal in dom0 that runs |
|
I think it's still useful to show mem/cpu stats for Dom0. Until we completely rewrite Qubes Manager (which is not gonna happen for 3.1, probably only for 4 when we also migrate to Gnome), I would recommend leaving Dom0 there. Perhaps not allow to select it. Also perhaps rename it as Admin/GUI? Speaking of mem stats: the total sum of all mem allocated to all the VMs (incl. Dom0) does not (usally) equal the total available system memory. We should consider to display also the total amount of DRAM (as well as total used/free) somewhere in the manager as well, perhaps in the status bar? |
well CPU stats from dom0 don't work #1120, so that reduces the usefulness of listing it to the mem stats. which isn't that useful except as a proxy for free memory (whether you can open a new VM or not). for me somewhere around 2000 MB MEM for dom0 means no more opening new VMs due to lack of free memory, but as a user I always have to try anyway since sometimes it works with less free memory and sometimes not. so I would still suggest not having the dom0 listing. if we want to have a free memory listing somewhere that could be helpful, especially if we could communicate a user that they have enough memory to open approximately 2 more qubes or something. |
|
If we removed dom0 (aka 'admin') now, and then introduced gui domain in Qubes 4, then everybody would think it's reintroduction of the dom0 (but this won't be true anymore). Also: since we keep displaying other "service" VMs, such as net, firewall, etc, then I see no reason why treat dom0 specially and hide it? Perhaps better would be to have a (default?) view mode which would be showing only user appVMs, and hide all the service VMs (now including the dom0)? |
|
The main reason for removing dom0 is having totally different actions So I guess the general answer is: do not remove, maybe rename it. Right? Best Regards, |
It's usually bad form to have an item in a list that is grayed
given the idea of splitting up "types" of VMs (networking,
as @marmarek points out "dom0 is having totally different actions
simply renaming |
|
Let's do the dom0->admin rename for now. Lets postpone the discussion on whether to get rid of this from the Manager's list until R4, ok? |
|
On Fri, Nov 13, 2015 at 07:27:59AM -0800, Joanna Rutkowska wrote:
Should it be "admin", "Admin", "AdminVM" or something else? Should the Best Regards, |
|
Since all the (default) domains are currently all lower-case strings, the same should be for the "admin", I think. Also, it's only reasonable for maintaining consistency between the names used in the Manager and qvm-tools. |
|
Hmm, I've done grep 'dom0'. Renaming it internally probably will break
Also having So I think we should either go with only slight change - Qubes Manager Best Regards, |
Yah. Fully agree, just
Ah, makes sense so many things would break with the change. Hrm. |
|
In Qubes Manager, under the Template column, the line for dom0 already says AdminVM. It looks like this:
If you rename
I really don't see how that constitutes a significant improvement. In fact, it strikes me as somewhat redundant, because I already know that it's the AdminVM by just looking at Qubes Manager. Calling it "admin" provides me with zero new information in this case. |
|
Maybe this is what you want instead:
This would be more accurate, since it doesn't make sense to talk about dom0 being based on a template. On a related note, TemplateVMs say "TemplateVM" under the Template column. Again, this is strictly speaking inaccurate, since templates can't be nested. TemplateVMs can't (currently) be based on other TemplateVMs. Hence, this column should say "n/a." In general, there is a bad habit in Qubes Manager of sticking information into a column where it does not belong as a way to convey information to the user which ought to be conveyed in a different way. VM types are conveyed to users in the leftmost column as an icon (with hover text). Therefore, this information should not appear a second time under the Template column, where it makes no sense. If you want to have the text of a VM type instead of just an icon (which would be a good idea), then put it in the appropriate column (the leftmost column for VM type). |
|
I like it there. Please don't take muh dom0s away :-) |
|
When dom0 is removed from QVM list, available updates should to be notified to the user not within QVM but in a system notification/icon in system tray, as is done in vanilla KDE. This icon stays in the sys-tray until the user updates, it is not a momentary notification. This might be something worth implementing for when updates to any templates or dom0 are found by the system. |
|
Run terminal would be great. Just run through a list of konsole and xterm, running the first that is available and a+x. |
|
Given that Qubes Manager has been changed significantly, split into widgets for everyday use and the tool for bigger management tasks, I think this can be closed. |
Instead of generic menu with almost everything grayed-out, now context menu for dom0 has only Global Settings, Logs and update. references QubesOS/qubes-issues#1382 fixes QubesOS/qubes-issues#1165
and others
It's a source of lot of confusion:
The only things applicable for dom0 are:
All other options doesn't apply there. Independently there should be an easier option to access global settings (currently only available through menu).
@bnvk
The text was updated successfully, but these errors were encountered: