With this redesign, we introduce a new way to create plugins, which is easier to
extend with new hook points, provides a better interface, uses less memory, less
program space, and is a tiny bit faster too.
It all begins with `kaleidoscope::Plugin` being the base class, which provides
the hook methods plugins can implement. Plugins should be declared with
`KALEIDOSCOPE_INIT_PLUGINS` instead of `Kaleidoscope.use()`. Behind this macro
is a bit of magic (see the in-code documentation) that allows us to unroll the
hook method calls, avoid vtables, and so on. It creates an override for
`kaleidoscope::Hooks::*` methods, each of which will call the respective methods
of each initialized plugin.
With the new API come new names: all of the methods plugins can implement
received new, more descriptive names that all follow a similar pattern.
The old (dubbed V1) API still remains in place, although deprecated. One can
turn it off by setting the `KALEIDOSCOPE_ENABLE_V1_PLUGIN_API` define to zero,
while compiling the firmware.
This work is based on #276, written by @noseglasses. @obra and @algernon did
some cleaning up and applied a little naming treatment.
Signed-off-by: noseglasses <shinynoseglasses@gmail.com>
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This can be used to see the effect of changes on the core firmware alone,
without any plugins or the like.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We are moving towards including the Adaptor from the Hardware library, so we
need not pull them in from user sketches (or from core).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
At some point, we want to remove the default include, so start including the
extra library in the examples.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This macro allows the definition of the LayerCount variable and the
keymaps[] array together. It shouldn't break old sketches, but this is
probably not all that's necessary; LayerCount still doesn't get
initialized outside the macro.
This file is meant to be included in sketch files in order to make
data available to Kaleidoscope functions. In particular, the size of
the keymaps[] array (i.e. the number of defined layers), which is
needed in order to prevent reading uninitialized memory past the end
of that array due to Key_KeymapNext_Momentary.
This took some trial and error to figure out, but once I determined
that the example sketches were being built, I made this change to keep
the build working. Hopefully this will satisfy Travis-CI.
If we want to allow plugins to implement EEPROM storage, it is best if we don't
do anything with EEPROM in the core firmware. As such, remove the
`Layer.defaultLayer` call from `Kaleidoscope.setup`.
With that gone, the `keymap_count` argument is obsolete, so drop it from
`Kaleidoscope.setup()` - but we keep an temporary `setup()` with the old arity,
so that plugins can be updated at a slower pace.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of just switching to a layer, make it a macro. The macro will toggle the
layer and the LED effect.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Moves the LED control code, along with the built-in effects into the
Keyboardio-LEDControl plugin.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This function registers the layer handler, move it up, before Keyboardio.use, so
it will have a chance to run before the other handlers.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make keymaps look nicer, easier to read, introduce the `___` and `XXX`
aliases. The former is an alias to `Key_Transparent`, the latter to `Key_NoKey`.
The `genetare_keymaps.pl` tool was updated to support these, too, with the
additional functionality, that all strings that are made up entirely of
underscore or Xes, and are two or more characters long, will be treated as
`___`/`XXX`, respectively. This makes it possible to space keys in a nicer way
in the source layout files.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having a primary and a temporary layer, store the state of at
most 32 layers in a bitfield. These can be individually turned on and
off, and key lookup starts from the top, and goes downwards until the
default layer to find a non-transparent key.
This allows one to reuse a partially transparent layer: set the default,
and the transparent parts will be reused. The numpad layer was updated
accordingly.
Having an interface to the layer switching things also makes it easier
to build other behaviour on top of these.
As part of the rework, layer handling was moved to a separate file, and into its
own, full-blown handler. Furthermore, we now use a single bit for all keymap
events.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We can't register hooks from constructors, because there is no guaranteed order
in which the objects will be created. So it may well happen that the Keyboardio
object gets created later, and zeroes out everything. Or it gets created first,
and registers the default handler as the first one, making all the others
pointless.
Instead, we create a KeyboardioPlugin class, that has a `begin` method. This is
responsible for setting up the hooks and whatnot. To make things simpler (for
some values of simple), a `Keyboardio.use` method is introduced, which, when
given a NULL-terminated list of plugin object pointers, will call the begin
method of each.
All LED effects and other plugins that used to register a static object now use
an extern, and had their initialization moved to the `begin` method.
The end result is not the nicest thing, but it works. We can try figuring out
something nicer later.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The main thing here is `Macros_::play`, which takes a list of bytes from
PROGMEM, and plays a macro. The array is always a command, followed by
arguments, and the size of the argument depends on the command: key presses and
releases take a 16-bit argument, and the event is injected into the event
handler flow. Waiting and interval change take a 8-bit time. Helpers are
provided to make it a little bit easier to construct a macro.
Of course, the `macroAction` method may do any other side effects, and is not
restricted to returning a sequence of commands.
Fixes#5.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of hardcoding the macro actions into the core firmware, use a
`macroAction` function that is marked weak. This makes it possible to override
the function from Sketches, and implement the handlers there.
While there, also made sure that the `macroAction` is always called, with
`keyState` argument appropriately set. With this, macro actions can trigger on
keyup, or while held, or anytime the implementor wants, not just on keypress.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Because the animation saves if it has been run, it may do so during
factory testing. But running it every time is annoying, too. So as per
@obra's request, the code for the animation is kept, but removed from
the default sketch.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When one adds or removes a layer from a keymap, the keymap size has to
be adjusted in the call to `Keyboardio.setup()`. This is easy to forget,
so as a helper, introduce `KEYMAP_SIZE`, a macro that automatically
computes the size at compile time.
This way, one does not need to remember to update the size anywhere.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
noseglasses
Gergely Nagy
Michael Richters
Jesse Vincent
Gergely Nagy
Craig Disselkoen
Gergely Nagy
Jesse Vincent