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

[Jan Kiszka]

On 2012-02-27 14:50, Anthony Liguori wrote:
> 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.

Perfect.

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

It might also be something else than a "monitor" that visualizes guest
graphic-like output.

Another effect I just noticed: The scroll position of the monitor
console is not always properly restored when switching from other
consoles. Looks like it can move down, leaving the visible range after
some switches.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux