Undesirable Behavior of "Modifier if held, normal otherwise"

[digitalentropy]

The current operation of this feature appears to be very clunky.

If, for example, I set the right-shift key to be "Up Arrow" by default but be a "shift" modifier when held, if I am typing quickly and tap shift-W or any other key, it will still register as "Up Arrow". In order to get the modifier key, I have to remember to force a delay in my typing before pressing the next key.

In cases where this feature is enabled, the pressing of such a key in conjunction with any other key should automatically assume the first key's "held"" identity, and not the default one. This is ideal and expected behavior.

In cases where no other key is pressed in conjunction with the modified key, the determination should fall back to using key-press duration, but the duration should be configurable, either on a per-key basis or at the very least for the whole keyboard.

I suspect all of this probably has to do with how the firmware handles NKRO, but without some adjustments, "Modifier if held" is very frustrating to use for most power users, which seem to be the target market for the keyboard.

[digitalentropy]

After some investigation the issue appears to related to Qukeys behavior.

According to https://kaleidoscope.readthedocs.io/en/latest/plugins/Qukeys.html the following variables are useful for changing some of the default behaviors of Qukeys:

.setHoldTimeout(timeout)
.setOverlapThreshold(percentage)

SpaceCadet Emualtion also appears to be of considerable use.

Qukeys appears to be a plugin that offers a great deal of functionality, if the right settings are exposed to the user. Rather than requiring users to hunt down this documentation and functionality, I recommend exposing these variables to the Bazecor interface so that the values can be modified more easily, thus allowing easier fine tuning.

At the moment the only solution appears to be manually recompiling firmware and including the Qukeys.setOverlapThreshold(percentage) function in the main firmware setup() loop.

[digitalentropy]

To clarify my comment regarding SpaceCadet Emualtion, I believe it should be possible to have a switch in Bazecor that reads "Normal key when held, modifier otherwise".

[namitnangia]

After some investigation the issue appears to related to Qukeys behavior.

According to https://kaleidoscope.readthedocs.io/en/latest/plugins/Qukeys.html the following variables are useful for changing some of the default behaviors of Qukeys:

.setHoldTimeout(timeout)

.setOverlapThreshold(percentage)

SpaceCadet Emualtion also appears to be of considerable use.

Qukeys appears to be a plugin that offers a great deal of functionality, if the right settings are exposed to the user. Rather than requiring users to hunt down this documentation and functionality, I recommend exposing these variables to the Bazecor interface so that the values can be modified more easily, thus allowing easier fine tuning.

At the moment the only solution appears to be manually recompiling firmware and including the Qukeys.setOverlapThreshold(percentage) function in the main firmware setup() loop.

https://kaleidoscope.readthedocs.io/en/stable/plugins/Kaleidoscope-Qukeys.html

[namitnangia]

@digitalentropy what value of percentage worked for you?

[namitnangia]

@AlexDygma is exposing value for Qukeys.setOverlapThreshold in the roadmap for Bazecor?

[namitnangia]

To make it work for me, I had to add following to Raise-Firmware.ino's setup() :

// Custom plugin configuration form Qukeys
// https://kaleidoscope.readthedocs.io/en/stable/plugins/Kaleidoscope-Qukeys.html
Qukeys.setOverlapThreshold(30); // defaults to 80
Qukeys.setMinimumPriorInterval(30); // defaults to 75

[AlexDygma]

Hello (@digitalentropy @namitnangia) Dygmates!

Thanks for contributing your hard work! we will add this to the next firmware release so it can be easily changed from the settings panel associated with the raise.

We will try to release our next firmware version as soon as possible!