Sticky Keys Implementation Proposal #41867

New Issue

Julian Eisel · 2014-09-19T00:23:49+02:00

Julian Eisel commented

2014-09-19 00:23:49 +02:00

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).

Conclusion

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.

# 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). ## Conclusion 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.

Julian Eisel commented

2014-09-19 00:23:49 +02:00

Changed status to: 'Open'

Julian Eisel self-assigned this 2014-09-19 00:23:49 +02:00

Julian Eisel commented

2014-09-19 00:23:49 +02:00

Added subscribers: @JulianEisel, @Psy-Fi, @Ton, @liquidape

Ton Roosendaal commented

2014-09-19 10:24:35 +02:00

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.

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.

Julian Eisel commented

2014-09-19 15:35:04 +02:00

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 #40587, 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 senton 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!

* **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 #40587, 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!

Antonis Ryakiotakis commented

2014-09-19 16:07:57 +02:00

@JulianEisel 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 @JulianEisel'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.

@JulianEisel 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 @JulianEisel'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.

Keen Foong commented

2014-11-21 02:24:33 +01:00

Added subscriber: @kfoong

Julian Eisel commented

2015-04-04 14:06:20 +02:00

Committed 53a3850a8a

Committed 53a3850a8a

Julian Eisel commented

2015-04-04 14:06:28 +02:00

Changed status from 'Open' to: 'Archived'

Julian Eisel closed this issue

2015-04-04 14:06:28 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Sticky Keys Implementation Proposal #41867

Sticky Keys Implementation Proposal

Motivation

New Implementation Goals

Proposal

Conclusion

Note