qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Programmingkid
Subject: Re: [Qemu-devel] [PATCH v5] cocoa.m: Add ability for user to specify mouse ungrab key
Date: Thu, 1 Feb 2018 08:11:55 -0500

> On Feb 1, 2018, at 7:16 AM, BALATON Zoltan <address@hidden> wrote:
> 
> On Wed, 31 Jan 2018, Programmingkid wrote:
>>>> 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.
>>> 
>>> Hmm, ok.
>>> 
>>> Doing the same for gtk would basically imply to not use any toolkit
>>> support for hotkeys ...
>>> 
>>> It'll also become more difficuilt if we use that for multiple hotkeys.
>>> 
>>> But possibly we can share the code across all UIs, now that keycodemapdb
>>> is used by qemu.  So first translate the keycode from the UI toolkit to
>>> a QKeyCode, then feed that into shared hotkey detection code.
>> 
>> Sounds like a good idea. I will be more than happy to help. My cocoa code
>> uses sets to implement keeping track of key presses. A set is a collection 
>> of data
>> that only allows for unique values. So no two items in a set can be the same
>> value. My patch uses cocoa's NSSet so the shared code would probably not be
>> able to use it. I don't currently know of an implementation of a set that is
>> in C and available for us to use, so we may have to implement it ourselves.
> 
> I think we already depend on glib so maybe you could find something useful 
> for this here:
> 
> https://developer.gnome.org/glib/stable/glib-data-types.html
> 
> Regards,
> BALATON Zoltan

Thanks BALATON for the help, but I didn't see anything that was a good fit for 
the patch.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]