We need to guard the `k` argument, place it within parens, to make sure it is
treated as a single argument, even if it expands to something that would be
ambigous. This is required, because most - if not all - keys are defined as a
list casted to `Key`, which the pre-processor would misinterpret without the
extra parens.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to create custom shortcuts, that do not interfere with system
ones, an old trick is to use many modifiers. To make this easier, Ctrl+Shift+Alt
is commonly abbreviated as "Meh", while Ctrl+Shift+Alt+GUI is often called
"Hyper". To support this, we offer the `Key_Meh` and `Key_Hyper` aliases, along
with `MEH(k)` and `HYPER(k)` to go with them.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We should be using a different variant of the `default_layer()` method to query
the default layer instead of abusing 0xff as a special valie.
Fixes#522.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Add `REDIAL` to `kaleidoscope::ranges`, so the plugin can define `Key_Redial`
itself, and won't need `Redial.key` to be set in the user sketch either. This is
a breaking change, but one that's easy to upgrade to, hence no effort was made
to make it at least partially backwards-compatible.
Fixes#519.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When selecting a new default layer via Focus, we should be moving there too,
because there may be no other way to switch to the new layer, and having to
reboot the keyboard for changes to take effect is not our desired behaviour.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When sending `Key`s, there's no need for an extra separator, because
`send(key.raw)` will send one anyway. Not sending one results in 10 bytes less
PROGMEM used, and plenty of bytes less spent over the wire.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When we use `lookup()`, we're looking up from the cache, not from the active
layer. If the cache gets updated later than we're called, we won't notice. So do
an explicit lookup.
Fixes#507.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Due to the plugin needing a key coordinate -> geometric space mapping, it
depends on the keyboard used. As such, restrict it to the Keyboard.io Model01,
for which the mapping was set up.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the rainbow colors are great, some may want to restrict the colors to a
single hue. For this purpose, the `ripple_hue` property was introduced. It
defaults to `Wavepool.rainbow_hue` (a special value that tells the plugin to use
multiple hues).
Inspired by @bjc's ToyKeeper/Kaleidoscope-LED-Wavepool#8.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based largely on ToyKeeper/Kaleidoscope-LED-Wavepool#8, this smooths out the hue
transitions, so that the ripple is a nice rainbow, without oddly flashing colors
while cycling through the effect.
Thanks @bjc for the change!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Methods that originate from the `kaleidoscope::Hardware` base class need not be
documented every time they're being overridden. That leads to duplication, and
higher chance of documentation going stale. As such, remove such cases, and rely
on the base class having plenty of documentation instead.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Since all implementations of detachFromHost/attachToHost are the same for all
our current keyboards, move it to the base class as a default.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is basically the old Kaleidoscope-Hardware plugin pulled in, and made into
a base class. The purpose is documentation (#167) mostly. The base class has
default implementations for all methods (most do nothing), and can be overridden
by derived classes. Since the hardware object is always going to be called
through `KeyboardHardware`, which has the exact type of the hardware, we do not
need to use virtual functions. The derived class will just shadow the default
implementations.
All hardware plugins were updated to use this (directly or indirectly). The
resulting compiled binary is the same, but we were able to remove a few
boilerplate lines from here and there.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Apparently, the shellcheck on Travis does not like comments after a disable
command, while the one I used locally didn't have a problem with it. Lets make
the one on Travis happy.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When calling avr-size, we want to expand ${AVR_SIZE_FLAGS}, not pass it as a
single argument, hence, we do not need to - and do not want to! - quote it.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In general, we want method names to be verbs, because they convey actions. The
`Layer.on()`, `Layer.off()`, etc family of functions weren't like that. It
wasn't immediately obvious that they turn layers on and off.
Furthermore, `Layer.next()` and `Layer.previous()` were even more confusing,
because one could easily think they implied moving to the selected layers, while
in practice, they just activated them.
All of these have new names, that better describe what they do. The old names
are still present, but emit a deprecation warning.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In the original `KeyboardioFirmware`, this was used to store the default keymap
index in EEPROM. When we removed the EEPROM storage, it was meant to be used by
sketches to set a default layer (the minimum layer one can switch to), which was
not nearly as useful. Even worse, the behaviour was complicated to reason about,
and it wasn't used anyway.
For these reasons, it is now deprecated, and will eventually be removed.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The examples were recently reorganized, but the documentation was not updated,
so some of them were pointing to dangling, obsolete places. This updates them
all to point to the correct locations.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As the name implies, this makes it possible to set all leds to the same color
depending on which layer is the topmost active one.
Fixes#492.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The ATMega32u4 chip Splitography does not have the JTAG interface disabled in
fuses, so we must do so from the firmware. Otherwise PIN_F4 - PIN_F7 would not
be usable for I/O.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Florian Fleissner
Gergely Nagy
Jesse Vincent
Gergely Nagy
Brian Almeida
Brian Almeida