GNOME Bugzilla – Bug 678463
hard to differentiate running/non-runnig b&w boxes in the overview
Last modified: 2016-03-31 13:57:40 UTC
If a box only displays black and white content (locked gnome screen, tty console, ...), it's very hard to tell if it's running or not.
The issue also happens when a box doesn't have a thumbnail, we can't know if it's running or not in such cases.
similarly, you could also say it's hard to differentiate a local VM and a remote display. For those cases, we don't really have a way to know if the VM is running, or taking screenshots may not be possible (although we could improve this situation a little)
It doesn't help that all my VMs only show black lock screen so *all* thumbnails look the same...
The last patch in bug 678455 helps a bit on dark screens.
I would recommend some sort of icon overlayed on top of machines indicating the state of the machine.
Created attachment 243650 [details] [review] machine: Property to indicate under construction status Currently this is only true for libvirt machines that are under installation.
Created attachment 243651 [details] [review] machine: Indicate to user if machine is shutdown This is useful for differentiating between shutoff machines and machines that are simply showing all/mostly black screen (think idle screen/screensaver).
Created attachment 243652 [details] [review] machine: Indicate to user if machine is shutdown This is useful for differentiating between shutoff machines and machines that are simply showing all/mostly black screen (think idle screen/screensaver).
Review of attachment 243652 [details] [review]: I don't understand why machines under construction are special cased here?
Review of attachment 243652 [details] [review]: Because Boxes is responsible for its state. When machine shutsdown, its actually a reboot and only lasts a fraction of a second. It wouldn't really be worth special casing it but we show 'Installing..' in the info and we'll need to complicate the code a bit to ensure we don't touch that part of the info. I think this info being a simple string is a bit of recipe for disaster and I was hoping to improve that sometimes soon. What I had in mind was a kinda of a stack/queue where info messages are pushed to, UI shows the last N (1?) messages in separate lines and message pushing code then can remove its info message when appropriate and UI is automatically updated.
Review of attachment 243652 [details] [review]: Is it bad if we just show "shut down" for a brief period of time, and then set the label back to "installing" right when it reboots? This special casing looks hackish :( ::: src/machine.vala @@ +69,3 @@ pixbuf = draw_vm (orig_pixbuf, SCREENSHOT_WIDTH, SCREENSHOT_HEIGHT); + + if (info == _("Shutoff")) Can't this be "if (!under_construction)" as well?
(In reply to comment #5) > I would recommend some sort of icon overlayed on top of machines indicating the > state of the machine. Any reason this is not what your patches are doing?
Review of attachment 243652 [details] [review]: It not bad but more wrong. Its not really a shutdown from users POV but rather a reboot and even that user needs not be caring about. ::: src/machine.vala @@ +69,3 @@ pixbuf = draw_vm (orig_pixbuf, SCREENSHOT_WIDTH, SCREENSHOT_HEIGHT); + + if (info == _("Shutoff")) we don't need to care about that in here. Also, if info was set to 'Shutoff', vm couldn't have been under construction.
(In reply to comment #12) > (In reply to comment #5) > > I would recommend some sort of icon overlayed on top of machines indicating the > > state of the machine. > > Any reason this is not what your patches are doing? I'll need our designers help in making/getting an icon and to decide if that is what we want to do.
It would be nice to avoid overlays, maybe just doing a box-shadow and a border would be enough — https://raw.github.com/gnome-design-team/gnome-mockups/master/boxes/boxes-active-box-dropshadow-border.png /* pseudocss */ .running.thumbnail { box-shadow: 0 1px 2px rgba(0,0,0,0.5); border: 1px solid white; }
Isn't this already solved with bug#683067 ? *** This bug has been marked as a duplicate of bug 683067 ***