After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678463 - hard to differentiate running/non-runnig b&w boxes in the overview
hard to differentiate running/non-runnig b&w boxes in the overview
Status: RESOLVED DUPLICATE of bug 683067
Product: gnome-boxes
Classification: Applications
Component: general
3.5.x (unsupported)
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks: 696727
 
 
Reported: 2012-06-20 10:27 UTC by Christophe Fergeau
Modified: 2016-03-31 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
machine: Property to indicate under construction status (1.34 KB, patch)
2013-05-09 00:17 UTC, Zeeshan Ali
none Details | Review
machine: Indicate to user if machine is shutdown (1.51 KB, patch)
2013-05-09 00:17 UTC, Zeeshan Ali
none Details | Review
machine: Indicate to user if machine is shutdown (1.49 KB, patch)
2013-05-09 00:21 UTC, Zeeshan Ali
none Details | Review

Description Christophe Fergeau 2012-06-20 10:27:19 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.
Comment 1 Christophe Fergeau 2012-06-20 12:49:33 UTC
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.
Comment 2 Marc-Andre Lureau 2012-06-20 12:55:30 UTC
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)
Comment 3 Alexander Larsson 2012-06-21 19:15:32 UTC
It doesn't help that all my VMs only show black lock screen so *all* thumbnails look the same...
Comment 4 Alexander Larsson 2012-06-29 07:24:59 UTC
The last patch in bug 678455 helps a bit on dark screens.
Comment 5 Zeeshan Ali 2012-07-03 16:52:33 UTC
I would recommend some sort of icon overlayed on top of machines indicating the state of the machine.
Comment 6 Zeeshan Ali 2013-05-09 00:17:22 UTC
Created attachment 243650 [details] [review]
machine: Property to indicate under construction status

Currently this is only true for libvirt machines that are under
installation.
Comment 7 Zeeshan Ali 2013-05-09 00:17:30 UTC
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).
Comment 8 Zeeshan Ali 2013-05-09 00:21:21 UTC
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).
Comment 9 Christophe Fergeau 2013-05-16 12:56:00 UTC
Review of attachment 243652 [details] [review]:

I don't understand why machines under construction are special cased here?
Comment 10 Zeeshan Ali 2013-05-16 14:50:38 UTC
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.
Comment 11 Christophe Fergeau 2013-05-21 10:10:24 UTC
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?
Comment 12 Christophe Fergeau 2013-05-21 10:10:55 UTC
(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?
Comment 13 Zeeshan Ali 2013-05-21 13:15:10 UTC
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.
Comment 14 Zeeshan Ali 2013-05-21 13:16:52 UTC
(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.
Comment 15 Jakub Steiner 2014-03-05 13:42:54 UTC
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;
}
Comment 16 Zeeshan Ali 2014-07-16 13:45:00 UTC
Isn't this already solved with bug#683067 ?

*** This bug has been marked as a duplicate of bug 683067 ***