Page MenuHome

Sticky Keys Implementation Proposal
Closed, ArchivedPublic


Sticky Keys Implementation Proposal


For pie menus it seemed like a good idea to separate clicking and holding down a button. @Antony Riakiotakis (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


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 (@Antony Riakiotakis (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.


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.



Event Timeline

Two things;

  • The sticky key event has been accepted as a good option for configuring and personalization. I do not think it is a good idea to make it a piemenu default, and certainly not to present it as if holding keys for a shortcut will show tool options. (The latter is in interesting concept but very hard to make consistent).
  • How would KM_PRESS work then, after a fixed delay? I would prefer it to keep working immediate, so the double click or sticky tests have to be done exceptionally somehow... that was the reason for the current (clumsy) double click code.

Having key presses never work, but only as key releases is not desirable. Also think of tablets and mouse, touchpads, etc.

  • At the first:
    • Remember, that this isn't just about adding stickies for pies, it's more a system wide integration, for that we're trying to find a good way to implement. However, talking about pies, I think we could add a checkbox "Sticky Keys" to the pie menu section which might be a good compromise. But this is something to discuss in T40587, once we have a good implementation of sticky keys ready. About presenting as if holding keys shows tool options: You're right there, we shouldn't create this illusion. For now, stickies would only be visible to the user with pies. All the other use cases are more in the backend (like better drag & drop handling, value ladders, etc.). So I don't think we would create much confusion there.
  • At the second:
    • I assume you meant KM_CLICK instead of KM_PRESS? I had a look at how KM_CLICK currently works: It is sent on release not press! I guess that wasn't intended? Even though, this might not be the way it should work, I think it's fine this way, since for one thing, most apps, today, use release to execute an action and for another, if I understand correctly how KM_CLICK *should* work, it should only be sent on the first key-down event, to make things not conflict with KM_PRESS (which is sent as long as the key is pressed). But Blender's event handling is quite intelligent there, and ignores repeating KM_PRESS events. This Leads to the conclusion that KM_CLICK is/was needless (remember, KM_CLICK == KM_RELEASE). Of course you can correct me if I'm wrong ;). So with this said, using and changing 'KM_CLICK', is not a big deal here IMHO.
    • Tablets, touchpads, etc. shouldn't be a problem, too, since they handle finger/pen/... clicks exactly like like a normal mouse in this case (AFAIK).

Thanks a lot @Ton Roosendaal (ton)!

@Julian Eisel (Severin) the problem with KM_CLICK is that it's really a mouse specific event to solve double clicking. So system should work as intended here.

Apart from that I think that if one wanted to configure a pair of operators for sticky interaction he would have to specifically change the operators to use KM_CLICK and KM_HOLD, so I don't think this would be really such a big deal. KM_PRESS will work as before. If user wants to assign an operator to KM_PRESS it will of course override KM_CLICK since it will get handled first.

Even if we designed this to use a macro/sticky operator system, it would still need to be configured and make sure no collisions with operators using the same key would occur, so I think @Julian Eisel (Severin)'s design here is superior.

Modifier keys won't work with keys registered for KM_HOLD style interaction, but the same is true for operators that use the same key as the modifier already - actually might be doable to solve if modifier + key is done before time threshold expires but this is more ninja territory here.

Julian Eisel (Severin) closed this task as Archived.Apr 4 2015, 2:06 PM