Re: [Qemu-devel] [PATCH v5] cocoa.m: Add ability for user to specify mouse ungrab key

[Programmingkid]

> On Jan 30, 2018, at 7:18 AM, Gerd Hoffmann <address@hidden> wrote:
> 
> On Fri, Jan 26, 2018 at 04:47:31PM -0500, John Arbuckle wrote:
>> Currently the ungrab keys for the Cocoa and GTK interface are Control-Alt-g.
> 
> SDL is the same now, for consistency.
> 
>> This combination may not be very fun for the user to have to enter, so we
>> now enable the user to specify their own key(s) as the ungrab key(s).
> 
> What about the other hotkeys?
> 
> There is fullscreen.  Ctrl-Alt-F for SDL and GTK.  Cmd-F for cocoa, but
> it works only if the grab is not active.

If has to be that way because the meta (command) key is sent to the guest when 
the mouse grab is in effect. I actually suggest the SDL and GTK interfaces send 
the meta (windows key on PC keyboard) key to the guest when a mouse grab is in 
effect. This way guest operating systems like Mac OS X can use keyboard 
shortcuts. 

> Console select (Ctrl-Alt-<nr>), works for SDL and GTK.  When I read the
> code correctly it should work for cocoa the same way, but it doesn't
> work for me.  Dunno why. 

I know this code was broken in cocoa for a while but I made the patch that 
fixes this problem. Console selection does work correctly using a recent git 
version of QEMU.

> Quit. Ctrl-Alt-Q on gtk.  Cmd-Q on cocoa, again only working without
> keyboard grab.  Nothing on SDL.  Just closing the window to quit works
> on GTK and SDL, both have a switch to turn it off.

I know Command-Q is the standard Macintosh keyboard short for quitting an 
application. With GTK I would imagine it would depend on how the host operating 
system expects applications to be built. I don't think Windows and Linux have a 
standard keyboard shortcut for quitting an application. 

> 
> [ ... list of hotkeys is incomplete, there is more, most of them working
>      in some of the user interfaces only ... ]
> 
> There is the -ctrl-grab switch.  Changes all hotkeys from Ctrl-Alt-<key>
> to Ctrl-<key>.  SDL only.  I want deprecate it.
> 
> There is the -alt-grab switch.  Changes all hotkeys from Ctrl-Alt-<key>
> to Ctrl-Alt-Shift-<key>.  SDL only.  I want deprecate it too.

Sounds like a good idea. It would help to keep things consistent between the 
UI's.

> 
> When touching this mess I want move to something more consistent.
> 
> 
>> Syntax: -ungrab <key-key-key>
> 
> As mentioned earlier: New toplevel switch isn't going to fly.  Should be
> a suboption of -display.

Is this good?:
-display ungrab=<key>... 

<looks further down the email>. 

Ok I see what you want:

-display gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11

-display cocoa,hotkey-modifiers=Command,hotkey-grab=f13,hotkey-fullscreen=f14

I assume hotkey-modifiers is used to set the meta key. Is hotkey-grab the key
used to ungrab the mouse? If it is shouldn't it be called hotkey-ungrab?


> 
>> Example usage:  -ungrab home
>>              -ungrab shift-ctrl
> 
> Modifier-only hotkeys are tricky with gtk (doable, but no support for
> that in the toolkit).
> 
>>              -ungrab ctrl-x
>>              -ungrab pgup-pgdn
> 
> Really?  Two non-modifier keys?
Yes. The ungrab sequence could be a-b-c and still allow these keys to be used 
in the guest.

>  How is that implemented?  Do you queue
> up the pgup keypress, waiting to see whenever pgdn is pressed too, then
> only in case that didn't happen forward the queued pgup key to the guest?

Basically there is a array that acts as a check list. It checks off keys that 
belong to the ungrab sequence as they are detected. Once a non-ungrab key is 
detected, the check list is cleared. If all the ungrab keys are detected the 
ungrab code is executed. This only happens on keyup events. That way if 
Control-ALT were the ungrab keys, sending Control-ALT-Delete to the guest is 
still possible because these are the keys detected on the keyup event. The 
Delete key would have cleared the check list. Daniel Berrange is the one I can 
thank for this idea. He might be able to explain it better than me.

> Making this work properly without unpleasent surprises in corner cases
> doesn't look easy to me.  Needless to say that the gtk toolkit doesn't
> support this either.

I know it sounds hard to implement but it really isn't. It is just knowing 
which pieces fit where. The keyup and keydown events is where most of the 
action takes place.

> I think we should limit ourself to key combinations which have one
> non-modifier key and optionally one or more modifier keys.  That should
> be supportable in all user interfaces we have.  Except curses, modifier
> key handling in unix terminals is a completely different world ...
> 
> When it comes to defining hotkeys I see basically two possible
> ways to do it:
> 
>  (1) Have a fixed (set of) modifier keys for all hot keys,
>      i.e. something like this:
> 
>         -display 
> gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11
> 
>  (2) Allow complete freedom when defining hotkeys, i.e.
> 
>         -display gtk,hotkey-grab=shift+f12,hotkey-fullscreen=ctrl+f11
> 
> Variant (1) provides a simple way to use other modifiers for all
> hotkeys, simliar to the existing -alt-grab switch.  I also expect
> it is easier to implement.

Choice 2 sounds really nice. It does give the user total freedom to customize 
QEMU
as seen fit.

> Another question is whenever we want allow defining different hotkeys
> for the same thing.  So fullscreen could have both F11 (which is a
> common hotkey in various apps, for example firefox) and Ctrl-Alt-F.
> Might be useful, but also makes the implementation more complex.

Assigning two different keyboard shortcuts to the same feature might be 
problematic.
Keeping things to one keyboard shortcut is probably the simple thing to do.

> 
> I think we should clarify those questions before working on patches.

Agreed.

> 
> cheers,
>  Gerd

Thank you for the clarification.