On 2012-02-27 14:33, Anthony Liguori wrote:
That all keyboard inputs are grabbed when the mouse is in the window and
you don't need to press ctrl-alt-g explicitly. And the reverse should
happen when the mouse reaches the window border. Just like under SDL,
give it a try.
Right, this was intentional. I think it's weird that a window would steal input
when the mouse moves over it breaking desktop accelerators like alt tab. If
you've ever alt-tab cycled through windows when QEMU is running, if you're
unlucky enough to have the mouse where a QEMU window may be, the QEMU instance
will steal input and prevent alt-tab from working anymore.
This would be a usability regression. It is very unhandy to switch
between grabbed and ungrabbed, specifically for alt-tab, when working
with guests vs. host windows. Look e.g. at how rdeskop works in this
regard. That's why I introduced this feature to QEMU, and I would not
want to see it die again with the introduction of GTK.
- window not resizable (except in broken full-screen mode)
That's intentional.
And a mistake IMHO. Definitely for the text consoles, but one can also
argue about the guest graphic console. I think Stefano once introduced
this for some Xen use case, maybe he can comment on it.
If we added resize, I wouldn't want to scale-to-size. I find this behavior to
be more trouble than it's worth. I'd want to render the VGA screen with a black
border only scaling based on the zoom settings.
OK for aspect-ratio-correct scaling of the guest view from my POV. And
if there is a use case for the old behavior, we could still add a switch
to the menu for selecting the scaling mode.
BTW, "VGA" is the wrong term for the graphic console. Maybe there is the
real front-end name available somewhere and could be used instead.
Any suggestions? Display? Graphics?
Or were you thinking something like Cirrus VGA?
VGA is (mostly) x86. Also, we may once have multiple guest screens,
maybe even multiple types of them. So picking up some telling front-end
name would likely scale best.