Preparing plugins for 1.0.0: Looking for documentation reviewers

Programming
43

Then build on that by adding one plugin (I’d recommend starting with OneShot, and show both how to do it globally and how to do it for individual modifiers).

Hah! Great minds! I just successfully built a sketch with OneShot to use in the tutorial docs, and went searching for a thread on OneShot because I have some questions. It’s weird typing like this, but not chording any more is going to be much easier on my thumbs. :slight_smile:

2 Likes
44

After taking a look, SpaceCadet is actually a superset of DualUse now, as far as I can tell. I made SpaceCadet work so you can apply per-key and global timeouts to the functions, and you can actually map any key to any other key (you aren’t limited to the certain modifiers). Of course, it doesn’t have the layer support, at least from an initial glance, but it may still support that. Personally, I’d rather have the main keymap separate, and then define my overrides like you can do in SpaceCadet, but I know others would have the opposite thought.

The two plugins definitely have a lot of overlapping functionality, but I am not sure if they have the same use case. DualUse looks to be a more powerful plugin in concept, with the keymap integration, though SpaceCadet is currently more extensible, but just initialized differently (you can map any defined key to any other defined key, and have separate per-key timeouts). Effectively, they are the same, but you have more control over end behavior with SpaceCadet. If you want to define your mappings and overrides in the keymap, use the DualUse style, and if you want to have an explicit list of overrides, you can use SpaceCadet. As I said, I prefer the explicit nature of mapping one key to another, so I am going to use SpaceCadet. You can definitely implement the SpaceCadet default Shift/Parens with DualUse if you are willing to change the keymap (and assuming you are using DualUse, you are likely changing the keymap), but you can also likely implement anything you wanted to do in DualUse with SpaceCadet (I am unsure about the layer switching, as I don’t use that, but I assume it’d be possible).

Even though they implement similar functionality, I don’t think it hurts to have both options, and I don’t see a reason that they’d need to be combined. Of course, if it is desired that they be combined, I wouldn’t mind implementing the DualUse keymap logic into SpaceCadet (though I sort of like the DualUse name more, so I’d combine and rename). :grin:

2 Likes
45

Just realised that there was one small, but important difference between DualUse and SpaceCadet: when the secondary action triggers, DualUse did not trigger the first action, while SpaceCadet did. At least, that’s how it worked before @bagels’ changes, which, by the looks of it, changed things, and the primary action is only held when the secondary explicitly says so.

In other words, the subtle difference is no more, yet, both plugins work the way they are supposed to. I do not think merging the functionality is feasible, rebuilding DualUse on top of SpaceCadet seems like a big task for little gain. But if anyone, @bagels or someone else, wants to have a go at it, I’m not going to stand in the way. :slight_smile:

1 Like
46

Has someone tested the example code for the Leader plugin? I’m getting compilation errors.

In file included from C:\Users\droid\AppData\Local\Arduino15\packages\keyboardio\hardware\avr\1.19.0\libraries\Kaleidoscope-Leader\src/Kaleidoscope-Leader.h:21:0,

                 from C:\localUserProfile\droid\Repositories\kb\Model01-Firmware\Model01-Firmware.ino:74:

C:\Users\droid\AppData\Local\Arduino15\packages\keyboardio\hardware\avr\1.19.0\libraries\Kaleidoscope-Leader\src/Kaleidoscope/Leader.h:29:61: error: too many initializers for 'Key'

 #define LEADER_DICT(...) { __VA_ARGS__, {{Key_NoKey}, NULL} }

                                                             ^

C:\localUserProfile\droid\Repositories\kb\Model01-Firmware\Model01-Firmware.ino:506:3: note: in expansion of macro 'LEADER_DICT'

   LEADER_DICT({LEADER_SEQ(LEAD(0), Key_A), leaderA});

   ^

C:\Users\droid\AppData\Local\Arduino15\packages\keyboardio\hardware\avr\1.19.0\libraries\Kaleidoscope-Leader\src/Kaleidoscope/Leader.h:29:61: error: braces around scalar initializer for type 'kaleidoscope::Leader::action_t {aka void (*)(unsigned char)}'

 #define LEADER_DICT(...) { __VA_ARGS__, {{Key_NoKey}, NULL} }

                                                             ^

C:\localUserProfile\droid\Repositories\kb\Model01-Firmware\Model01-Firmware.ino:506:3: note: in expansion of macro 'LEADER_DICT'

   LEADER_DICT({LEADER_SEQ(LEAD(0), Key_A), leaderA});

   ^

Edit: Also, it was a bit confusing to figure out what that “magic number” in “LEAD(0)” was supposed to mean.
It would be nice if the example code actually referred to the examples used to describe the use case of the plugin (I know, it’s not easy to implement since it’s using the Unicode plugin, which doesn’t work without further configuration).

47

We do, in fact, autobuild all of the examples with Travis. Because Leader hadn’t been rebuilt in quite some time, I thought that maybe we’d had some API drift, so I just kicked off a fresh-rebuild on Travis.

It sure seems to build clean to me.

Are you using the Arduino-provided avr-gcc toolchain or something else?

48

That sort of thing is probably best addressed with a PR or an issue on the plugin in question. Notes in forum posts are easy to lose track of.

2 Likes