Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/27/2012 07:42 AM, Jan Kiszka wrote:
> 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.

I'll add a "Grab on Hover" menu item to enable the behavior.  It's a good excuse 
to look at gconf to store GUI preferences too.

>>>>> - 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.

Okay, I'll look into it.

>>> 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.

Display 0?

I think Monitor would be more natural but obviously that would conflict with the 
human monitor.

Regards,

Anthony Liguori

> Jan
>