On Kaleidoscope.use() and .setup()

Strictly speaking, the Kaleidoscope-Leader plugin has a bug. Its README.md says:

Note that we need to use the Leader object before any other that adds or changes key behaviour! Failing to do so may result in unpredictable behaviour.

1 Like

And Qukeys and Kaleidoscope-Papageno have bugs as well because they also like to be .use(...)d first. I don’t see a way to avoid this.

I think such special requirements should be acceptable behavior, and not a bug, as long as they are well documented.

You might be misunderstanding what I meant when I asked that question. I was confused why a lot of examples for plugins listed kaleidoscope.setup() after kaleidoscope.use (list of plugins) where the default firmware lists them the other way around. I didn’t take what @Algernon said to mean that it would be a bug if the order of the list of plugins was important, just that if the order of .setup() and .use() in relation to each other were important, that would be a bug.

Yeah, you are right. I misread that.

Now, that we are speaking about it, why isn’t Kaleidoscope.setup() called automatically by Kaleidoscope.use(...)?

Because Kaleidoscope.use() is optional. We could document that one needs to call either of the two, but it’s a lot easier if we just use both, always. Makes copy & pasting the factory firmware easier too.

We could also teach Kaleidoscope.loop() to check if .setup() was called, and run it once if it hasn’t, but that’d be a bit of an ugly hack for very little gain, in my opinion.

1 Like

Not sure. It would be extremely cheap (1 byte of RAM, few bytes of PROGMEM, few cycles for the noop function calls every loop) and completely backwards compatible.

Kaleidoscope_::setup(void) {
   static bool alreadyCalled = false;
   if(alreadyCalled) { return; }
   alreadyCalled = true;

Kaleidoscope_::loop(void) {

Not saying it is expensive in any sense, my thinking is that this is not needed right now. With loop() calling setup, we’d save one line in the user sketch, a line noone up to this point found either confusing, complicated or anything like it. In return, we add 3 more elsewhere.

It’s a small thing either way, but not something I feel there is a need for. :slight_smile:

And with .use() likely to go away at some point, and us moving towards a more… declarative way of specifying what plugins to use, setup() will end up being a few property settings and Kaleidoscope.setup()… in this setup, I feel it makes more sense to have an explicit call to it. On the other hand, this is just a feeling, or my own aesthetic preference if you like.

1 Like

Every line you spare the user of an interface to write is worth several lines in the interface’s implementation.

Yep, but only up to this point…
I suppose there are many people being confused about a lot of things, but only few of them actually write about it.