= Sticky Keys Implementation Proposal =
== Motivation ==
For pie menus it seemed like a good idea to separate clicking and holding down a button. @Psy-fi even implemented this for pies, but only in a hacky and non-reusable way. This lead to the decision, that we need a better implementation that is reusable and tightly integrated by using Blender's event system.
== New Implementation Goals ==
* don't break other events (changes that improve the current event system are allowed/desired) <– **ensure good testing!**
* integration into the event system
* access from operators, basic handling system (C and Python)
* elegant solution
== Proposal ==
**Split `event->val` into `event->val` and `event->clicktype`**
This way, we could separate the basic event values (like `KM_PRESS` and `KM_RELEASE`) and the more advanced ones (`KM_CLICK` and `KM_DBL_CLICK`), which are build out of the basic ones.
**Add clicktype KM_HOLD**
`KM_HOLD` is the needed clicktype for sticky keys. It would be the counterpart of `KM_CLICK`. To determine which of the both we have, we can use a time threshold that can be set through the User Preferences (@Psy-fi used this already in his initial implementation).
So, the Window Manger would go through the following tests:
* got `KM_RELEASE` and time < threshold → send `KM_CLICK`
* got `KM_PRESS` and time > threshold → send `KM_HOLD`
* got `KM_PRESS` after a KM_RELEASE and time < double click time → send `KM_DBL_CLICK`
This is a really simple and reusable approach to get sticky keys to work, plus, it updates the also hacky implemented `KM_CLICK`, all without changing too much of the rest of the event system. All goals can be met.
== Note ==
This proposal grew while I was trying to implement the sticky keys, so I can tell you it is working ;). Further, I have a build ready, using the proposed changes. I'll finish it and submit the patch soon.