> On Feb 1, 2018, at 7:16 AM, BALATON Zoltan <bala...@eik.bme.hu> 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.
