Kaleidoscope/libraries/Keyboardio-Macros/src/Keyboardio-Macros.h

#pragma once

#include <KeyboardioFirmware.h>

#include "MacroKeyDefs.h"
#include "MacroSteps.h"

const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState);

class Macros_ : public KeyboardioPlugin {
  public:
    Macros_(void);

    virtual void begin(void) final;

    void play(const macro_t *macro_p);
};

extern Macros_ Macros;
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago			`#pragma once`

Move macros to a separate library Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago			`#include <KeyboardioFirmware.h>`
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago
Implement a way to do simple macros 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> 8 years ago			`#include "MacroKeyDefs.h"`
			`#include "MacroSteps.h"`
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago
Implement a way to do simple macros 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> 8 years ago			`const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState);`
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago
Rework the hook handling 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> 8 years ago			`class Macros_ : public KeyboardioPlugin {`
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago			`public:`
			`Macros_(void);`
Implement a way to do simple macros 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> 8 years ago
Rework the hook handling 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> 8 years ago			`virtual void begin(void) final;`

Implement a way to do simple macros 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> 8 years ago			`void play(const macro_t *macro_p);`
Move all macro handling into separate files Signed-off-by: Gergely Nagy <algernon@madhouse-project.org> 8 years ago			`};`

Rework the hook handling 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> 8 years ago			`extern Macros_ Macros;`