Why is KeyboardioScanner separate from Kaleidoscope-Hardware-Model01?

question

(Michael Richters) #1

I’ve been continuing to pull the threads that I find in the code, and I’m starting to wonder why the KeyboardioScanner repository is separate from the Kaleidoscope-Hardware-Model01 repository, rather than being a part of it. @algernon, can you explain it to me?


(Gergely Nagy) #2

Because it can be used separately, as in by a different keyboard. Perhaps its name is not the best, as it suggests it is tied to the Keyboardio, while it is not. It implements a particular way to do scanning and other things, but can be re-used by other hardware plugins, too.

(Raise currently uses a fork, but we could easily merge the two and support both keyboards. I’ll get there, eventually.)


(Michael Richters) #3

Thanks for the answer. I guess that makes sense, though it does make it difficult to follow code in Kaleidoscope-Hardware-Model01, because some of its data structures are defined in a different repository.

Does KeyboardioScanner require the same hardware for the key scanners that are used in the Model01? I’m still not sure where the code for those resides.


(Jesse) #4

no. it just requires the same protocol.

It’s not uncommon for code that uses an API to require a library that exports the API. arguably, we should have methods to keep the data structures private.


(Michael Richters) #5

I started by (re-)examining Kaleidoscope-Hardware-Model01, and noticing that it did not, on its own, provide the whole API offered by Kaleidoscope-Hardware. It wasn’t the KeyboardioScanner API that I was looking at.

I haven’t worked out the details yet, but it seems to me that it would make more sense to use the same mechanism for making a module swappable in both this case and on the HID side, which seems to be going in a very different direction.


(Jesse) #6

That’s a reasonable point, but a different thread :wink:

There may be C++ reasons it’s not plausible, but i’m not sure either way at this point. It’d be nice to have consistent patterns.