This example sketch is now a fairly good demonstration of the power and
simplicity of the new KeyEvent handlers, and an example of a custom plugin
written directly in the sketch file.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Unintended modifiers are becoming an increasingly big problem among users of
Qukeys. This change adds yet another configuration option to prevent this from
happening while users are typing fast. It introduces a new requirement to make a
qukey eligible to become a qukey; a minimum amount of time that must pass
between the keypress event for a non-modifier key and the subsequent keypress
event of the qukey.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Previously, we used index-ordering for layers, meaning, we looked keys up based
on the index of active layers. This turned out to be confusing, and in many
cases, limiting, since we couldn't easily shift to a lower layer from a higher
one. As such, index-ordering required careful planning of one's layers, and a
deeper understanding of the system.
This patch switches us to activation-ordering: the layer subsystem now keeps
track of the order in which layers are activated, and uses that order to look
keys up, instead of the index of layers. This makes it easier to understand how
the system works, and allows us to shift to lower layers too.
It does require a bit more resources, since we can't just store a bitmap of
active layers, but need 32 bytes to store the order. We still keep the bitmap,
to make `Layer.isActive()` fast: looking up a bit in the bitmap is more
efficient than walking the active layer array, and this function is often used
in cases where speed matters.
As a side effect of the switch, a number of methods were deprecated, and similar
ones with more appropriate names were introduced. See the updated `UPGRADING.md`
document for more details.
Plugins that used the deprecated methods were updated to use the new ones.
Fixes#857.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This change makes Qukeys require a certain minimum amount of time for a
key to be held before it is eligible to get its alternate (i.e. modifier)
value. This should help faster typists avoid unintended modifiers in the
output.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The biggest problem here is that Qukeys was listed last. It doesn't
matter whether it comes before or after things like Focus, but it
really needs to handle events before other keystroke-handling plugins
like OneShot, TapDance, Macros, et cetera.
I also moved SpaceCadet up, since it does similar key value
resolution, and MousKeys down, because it never changes the value of a
key event.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
While `using namespace` certainly has its downsides, in these cases, the scope
is local to a single file, and makes the code _much_ more readable, offsetting
any downsides the directive otherwise has. As such, lets tell cpplint to ignore
these.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
On the `Upper` layer, we used to have a macro that moved us back to the QWERTY
layer. It was made before we had `MoveToLayer` available. Now that we do have
it, lets use that instead of the macro.
We still keep the macro around, for the sake of compatibility, so that if anyone
who has the old macro in EEPROM, but updates the firmware, will have the key
working still.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
On the `Upper` layer we have a key that takes us back to the QWERTY layer. That
key appeared as `M(QWERTY)` on the keymap, while `QWERTY` was the layer name,
and `LAYER_QWERTY` was supposed to be the macro name. In the macro itself, we
used `Layer.move(LAYER_QWERTY)` - the macro name instead of the layer name.
In practice, this didn't matter, because both ended up resolving to `0`, but the
code did not reflect intention, and was confusing for anyone trying to
understand what's going on.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This reverts commit c917acb8a1, because that
introduced breaking changes, and we want to address the problem in a different
way instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This introduces a new plugin - `FlashHelper` - to aid with firmware-assisted
flashing. During the flashing process, this plugin can temporarily disable the
`Prog` key.
Addresses the firmware part of keyboardio/Chrysalis#509.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Previously tapping the fn key in the upper layer had no effect; now it
returns it to the base layer.
This also removes the RESET macro, which also had no effect. At this
time the Classic Atreus running Kaleidoscope must use the hardware
reset since both the firmware-based reset button and `make flash` are
ineffective.
Signed-off-by: Phil Hagelberg <phil@hagelb.org>
The new `.setBrightness()` and `.getBrightness()` methods control the brightness
of the LEDs, by dispatching them to the LED drivers. We dispatch to the drivers
so that nothing else needs to be aware of brightness control. Plugins will
always set the unadjusted colors, and anything and anyone who reads colors, will
also get the unadjusted values.
Pushing the adjustment down to the driver level makes everything smooth, and
since we do gamma correction there anyway, it makes sense to do brightness
adjustment at the same place, too.
Fixes#775.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Jesse Vincent
Florian Bruhin
Michael Richters
Gergely Nagy
Gergely Nagy
Jacob Hurwitz
Phil Hagelberg