Its utility is very limited now that `macroAction()` only gets called when a
Macros key toggles on or off, and it uses a symbol that breaks an abstraction
barrier (a local variable of the `macroAction()` function).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This makes it unnecessary to include `Arduino.h` (or `stdint.h`, or some other
header that includes it) before including Kaleidoscope-Ranges.h.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
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>
This allows plugins to override the current LED mode just before the LED sync is
done (i.e. after the mode sets the LED colors, but before those changes are
pushed to the hardware.)
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This class should help plugins that implement `onKeyswitchEvent()` to ensure
that they won't process the same event more than once.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
There's no need to trigger a keyboard HID report after processing a layer
change, so stop processing before calling `prepareKeyboardReport()` if
`event.key` is a layer change `Key`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The new version of the layer change `Key` handler is more consistent with the
other `KeyEvent` handling functions, and properly checks for a second layer
shift key being held when releasing the first one.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This defines four new event handlers for plugins to use with the forthcoming
redesigned main event loop:
- `onKeyEvent(KeyEvent &event)`
- `onPhysicalKeyEvent(KeyEvent &event)`
- `beforeReportingState(const KeyEvent &event)`
- `onAddToReport(Key key)`
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This allows it to return correct `KeyEvent` values when used by plugins that
need to track that information for delaying events.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The `KeyEvent` type will encapsulate all of the data that will be passed to the
new generation of event handler functions.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
With a non-zero default for tap-repeat, the timing of events changed, causing
this testcase to fail.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This is not complete, but it does test the two basic cases of a double-tap and a
tap-then-hold (to produce a single primary key value hold in output) on all
three types of qukeys (Generic, DualUse, SpaceCadet).
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This change gives Qukeys the ability to repeat a primary keycode by
tapping the key, then immediately pressing and holding it. While doing
this, the extra release and press of the key are suppressed, so it
looks to the host just like a simple press-and-hold event, which is
particularly nice for users of macOS apps that use Cocoa, where
holding letter keys is the "standard" way of accessing accented
characters.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
The new items have been added to the end of the list (before `SAFE_START`),
where they belong.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Michael Richters