GNOME Bugzilla – Bug 729700
Properties window glitch when resize-guest is disabled
Last modified: 2016-03-31 13:22:00 UTC
Created attachment 276053 [details] Picture of the glitch When I have Fedora in fullscreen mode with resize guest option disabled and switch directly into properties view it looks weird. (see screenshot. It seems to be maximized but shifted) When doing this with resize guest enabled everything is right (properties appear maximized on the screen where the vm was). (I don't know if the dual monitor setup may have to do something with it) Can someone try to reproduce this? Steps to reproduce: 1. Have a VM ready 2. Start boxes unmaximized 3. Start the VM 4. Set "resize guest" to off 5. Fullscreen the VM 6. Go to top with the mouse and click on the settings symbol 7. It may look similar to the appended screenshot I tried to recreate this after restarting boxes and suddenly the edges were rounded and the window was resizeable while I could only make it bigger, not smaller. (It had the same size and position like the one in the screenshot.)
I think the properties page can't be made smaller since without activeting the resize guest option the guest can't be scaled down. The properties window size seems to depend on the size of the running guest.
I can reproduce it here with single monitor. I don't recall why we want to provide an option that can totally mess-up the whole UI and risk making it very unusable.
I think I would enable this resize option by default and dont provide it to the user (makes the UI simpler! Isnt this great?). Turning it off isnt of any good use at least for me.
(In reply to comment #3) > I think I would enable this resize option by default It is! Isn't it? > and dont provide it to the > user (makes the UI simpler! Isnt this great?). Turning it off isnt of any good > use at least for me. Thats what I was saying. I just have this memory of elmarco telling me that there is some case(s) in which this option is needed. Marc-Andre?
(In reply to comment #4) > (In reply to comment #3) > > I think I would enable this resize option by default > > > It is! Isn't it? > > > and dont provide it to the > > user (makes the UI simpler! Isnt this great?). Turning it off isnt of any good > > use at least for me. > > Thats what I was saying. I just have this memory of elmarco telling me that > there is some case(s) in which this option is needed. > > Marc-Andre? Some users want a specific resolutions they configured directly in the guest, and that should not change. Either because they have specific needs (testing, fixed application), or because they arrange their applications and icons and don't want it to be moved around by a mere resize.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I think I would enable this resize option by default > > > > > > It is! Isn't it? > > > > > and dont provide it to the > > > user (makes the UI simpler! Isnt this great?). Turning it off isnt of any good > > > use at least for me. > > > > Thats what I was saying. I just have this memory of elmarco telling me that > > there is some case(s) in which this option is needed. > > > > Marc-Andre? > > Some users want a specific resolutions they configured directly in the guest, > and that should not change. Correct me if I'm wrong but this option doesn't exactly change resolution in the guest but only scales the display to fit the current window size. Since we allow them to put Boxes window (permanently) into a particular size, they can simply adjust the window size to match the guest resolution. Not as best/easy solution as they get by disabling 'resize-guest' but I'd think its a pretty good compromise if we want to avoid the (otherwise hard to fix) issues associated with this option being disabled and also to expose a non-obvious option to users.
(In reply to comment #6) > > Correct me if I'm wrong but this option doesn't exactly change resolution in > the guest but only scales the display to fit the current window size. Since we > allow them to put Boxes window (permanently) into a particular size, they can > simply adjust the window size to match the guest resolution. "resize-guest" does change guest resolution. > > Not as best/easy solution as they get by disabling 'resize-guest' but I'd think > its a pretty good compromise if we want to avoid the (otherwise hard to fix) > issues associated with this option being disabled and also to expose a > non-obvious option to users. what issue?
(In reply to comment #7) > (In reply to comment #6) > > Not as best/easy solution as they get by disabling 'resize-guest' but I'd think > > its a pretty good compromise if we want to avoid the (otherwise hard to fix) > > issues associated with this option being disabled and also to expose a > > non-obvious option to users. > > what issue? This bug for example? :)
(In reply to comment #7) > (In reply to comment #6) > > > > Correct me if I'm wrong but this option doesn't exactly change resolution in > > the guest but only scales the display to fit the current window size. Since we > > allow them to put Boxes window (permanently) into a particular size, they can > > simply adjust the window size to match the guest resolution. > > "resize-guest" does change guest resolution. In that case they can set size of window (rather than guest resolution) as per their needs?
Also we can make it easier by doing something similar to what gnome-terminal does: Overlay current display size when user resizes the window.
(In reply to comment #10) > Also we can make it easier by doing something similar to what gnome-terminal > does: Overlay current display size when user resizes the window. I like this idea. How about snapping at the original size of the running display like mutter does when windows aligning besides each other?
(In reply to comment #11) > (In reply to comment #10) > > Also we can make it easier by doing something similar to what gnome-terminal > > does: Overlay current display size when user resizes the window. > > I like this idea. How about snapping at the original size of the running > display like mutter does when windows aligning besides each other? The display resolution is (ideally) following the window size so there isn't really an 'original size of running display' here. If you mean the size of display before user starts resize operation, that won't give much to user apart from allowing them to easily cancel their resize operation.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Also we can make it easier by doing something similar to what gnome-terminal > > > does: Overlay current display size when user resizes the window. > > > > I like this idea. How about snapping at the original size of the running > > display like mutter does when windows aligning besides each other? > > The display resolution is (ideally) following the window size so there isn't > really an 'original size of running display' here. If you mean the size of > display before user starts resize operation, that won't give much to user apart > from allowing them to easily cancel their resize operation. This ideal case never ocurred on my system IIRC.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > Also we can make it easier by doing something similar to what gnome-terminal > > > > does: Overlay current display size when user resizes the window. > > > > > > I like this idea. How about snapping at the original size of the running > > > display like mutter does when windows aligning besides each other? > > > > The display resolution is (ideally) following the window size so there isn't > > really an 'original size of running display' here. If you mean the size of > > display before user starts resize operation, that won't give much to user apart > > from allowing them to easily cancel their resize operation. > > This ideal case never ocurred on my system IIRC. I works here against Fedora, RHEL, Ubuntu and (assuming you express install them) Windows XP and 7. Why doesn't it work for you? Could you file a bug about that? I wonder if its a disto issue on your machine.
Ok, lets remove 'resize-guest'. I created bug#738760 for the idea in comment#10.
commit: 9e8fee90f2c9a80abb742d2d84754ed46ec49b74 spice-display: Remove 'Resize guest' property Tell SPICE to always try to resize the guest display to allocated size, instead of exposing this internal detail to users. Not only is this property non-obvious to most people, we have had some weird side-effects from people disabling this property in the past. See the bug below for discussion leading to removal of this option.
Hi, so while I appreciate the effort toward minimalism and simplicity, this change just forced me stop using gnome boxes. :-( Other VM management tools don't outright remove these options. Instead they hide them behind advanced menus for the 1% of the time when it's really needed. For one, the spice guest client with Windows 10 guests is buggy and gets nasty and flickering with the auto 'resize guest' property on. No I don't have a workaround to avoid that issue.
(In reply to butternut from comment #17) > Hi, so while I appreciate the effort toward minimalism and simplicity, this > change just forced me stop using gnome boxes. :-( > > Other VM management tools don't outright remove these options. Instead they > hide them behind advanced menus for the 1% of the time when it's really > needed. And what do they do when "Advanced" options view becomes way too overcrowded? Create an button for another layer of advanced option? Keeping in mind that there is always bugs like these and to work around them in this way, they all need some "options", you quickly end up with a cluttered UI. See virt-manager, for a UI that has all the options but isn't exactly an impressive UI. If you really do appreciate miminalism, you'd rather file bugs on the right levels to solve the actual issues rather then ask for options that work around them. Once the actual issues are fixed, that 1% become 0% and we end up with useless UI. > For one, the spice guest client with Windows 10 guests is buggy and gets > nasty and flickering with the auto 'resize guest' property on. No I don't > have a workaround to avoid that issue. I'm guessing you mean spice-guest-agent? How about you uninstall that until that issue is fixed (which I assume you have filed a bug for?).
(In reply to Zeeshan Ali (Khattak) from comment #18) > (In reply to butternut from comment #17) > > Hi, so while I appreciate the effort toward minimalism and simplicity, this > > change just forced me stop using gnome boxes. :-( > > > > Other VM management tools don't outright remove these options. Instead they > > hide them behind advanced menus for the 1% of the time when it's really > > needed. > > And what do they do when "Advanced" options view becomes way too > overcrowded? Create an button for another layer of advanced option? Keeping > in mind that there is always bugs like these and to work around them in this > way, they all need some "options", you quickly end up with a cluttered UI. > See virt-manager, for a UI that has all the options but isn't exactly an > impressive UI. I'm no UI expert, but hiding the clutter away under a single advanced tab/menu won't necessarily detract from usability? > If you really do appreciate miminalism, you'd rather file bugs on the right > levels to solve the actual issues rather then ask for options that work > around them. Once the actual issues are fixed, that 1% become 0% and we end > up with useless UI. Well, actually, I did try look at the distro bug tracker release (before submitting here). Seems Upstream isn't fully supporting Windows 10 yet...: https://bugs.launchpad.net/qemu/+bug/1479717 > > For one, the spice guest client with Windows 10 guests is buggy and gets > > nasty and flickering with the auto 'resize guest' property on. No I don't > > have a workaround to avoid that issue. > > I'm guessing you mean spice-guest-agent? How about you uninstall that until > that issue is fixed (which I assume you have filed a bug for?). Perhaps I misunderstood, but things like cut and paste don't work without the spice agent on the guest, which would be a crippling work around? Anyhow, should someone else stumble upon this, the way to resolve issues for now is to not use gnome boxes, but rather remote-viewer. Also, after a lucky coincidence, flickering seems to have be resolved for me while tweaking something else (OVMF NVRAM for EFI). What I can report: * virt-viewer / remote-viewer, virt-manager and gnome boxes have have stopped flickering * virt-viewer / remote-viewer are now auto-adjusting windows 10 properly to the windows size * gnome boxes is scaling (zooming in and out) the Windows 10 display instead of auto-adjusting the guest resolution ** Unlike the Windows 10 guest, When I test a Linux VM with the spice agent installed, it auto-adjusts the guest resolution * virt-manager is not, it's simply cropping the output So I think something about how Gnome Boxes handles the Windows 10 guest is inferior to the way in which remote viewer does (when EFI is used, which does affect graphics setup). But perhaps wait till spice-agent officially supports Windows 10 with proper drivers, given you may not care for people like me who try their luck with the Windows 8.1 drivers in Windows 10. Exposing the option off zoom versus auto-adjust guest resolution is also risking clutter? Thing is, what happens when I connect to a projector that can only do 800x600 and the app I'm trying to demo is doesn't fit that resolution? Zoom comes in handy in this case. Again, 1% use case I suppose. More detail on the EFI NVRAM issue? Hacking around a debian/ubuntu distro specific libvirt apparmor bug allowed me to use a proper OVMF nvram template to the virtual machine config, and after reconfiguring the VM to use this, the display flickering stopped, so this may be something to do with UEFI simulation and windows 10 on KVM (but given my day job as just a virtualisation user, debugging that or understanding that low level interaction is beyond me). And yes, I did try contribute to the distro and upstream issues I could find related to OVMF NVRAM * https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071 * http://libvirt.org/git/?p=libvirt.git;a=commit;h=91fdcefa7f145c1c39acc8e9a44fbfbf11568e54
(In reply to butternut from comment #19) > (In reply to Zeeshan Ali (Khattak) from comment #18) > > (In reply to butternut from comment #17) > > > Hi, so while I appreciate the effort toward minimalism and simplicity, this > > > change just forced me stop using gnome boxes. :-( > > > > > > Other VM management tools don't outright remove these options. Instead they > > > hide them behind advanced menus for the 1% of the time when it's really > > > needed. > > > > And what do they do when "Advanced" options view becomes way too > > overcrowded? Create an button for another layer of advanced option? Keeping > > in mind that there is always bugs like these and to work around them in this > > way, they all need some "options", you quickly end up with a cluttered UI. > > See virt-manager, for a UI that has all the options but isn't exactly an > > impressive UI. > > I'm no UI expert, Me neither but that's why I don't think I know better than the folks who are: our designers. > but hiding the clutter away under a single advanced > tab/menu won't necessarily detract from usability? If I had a penny each time people suggested that. Here are two issue with this: 1. With such options being hidden behind another view, there will definitely come a time when that hidden view becomes quite cluttered itself. What do you do then? Would add a hidden view inside the hidden view? 2. How do you get to this "Advanced" options without adding a button for it and since most users won't be needing this button, this one button is also adding clutter.