How to propose changes to Kaleidoscope's internals or design

Programming Kaleidoscope Internals
1

Browsing through the KS code, I found a bunch of places where I think, things might be improved in terms of performance, usability (definition of sketches & plugins), maintainability etc.
In some places, the implementations are not … how to put it … using C++ to full capacity.

Although I am very much aware that everything works great, I have and probably other experienced C++ devs and KS users also have some ideas about how to polish parts of the code to make a great tool even greater. I could provide a lot of code samples with explanations but am hesitating with pull requests as I do not want to waste too much time on this in case my proposals are rejected.

I am talking rather about long term changes that might even affect the plugin programming interfaces, than small modifications. And of course this is just about ideas. I know how delicate this topic is between devs.

So the question is, where and how to discuss next generation KS? Here or on github or via direct contact? This question is mostly directed to @jesse and @algernon.

1 Like
2

For specific changes that are not backward incompatible, github pull requests are ideal. If it’s something you think might be contentious, starting a thread here or opening a GitHub issue is not wrong.

I am not an experienced C++ developer and I know there are many things about Kaleidoscope that can be done better.

There are certainly places where “using all of C++” is not going to be the right thing for us. Similarly, what makes a lot of sense for enterprise systems doesn’t always make sense for embedded systems. And there will be cases where doing things the “right” way for C++ is in conflict with “doing things the Arduino way”

One way to think about how to structure your proposals is through the lens of the code style guide: https://github.com/keyboardio/Kaleidoscope/blob/master/doc/CODING_STYLE.md

It is very much a work in progress. Initially adopted from Google’s C++ style guide, we’ve done some work to start to make it more appropriate for our use case, which is very different than Google’s. At the same time, we’ve done some work to try to start bringing our code up to match the style guide. But we’re not there yet.

The very rough guide for how I think about priorities for the code is here:

One aspect of the project goals is that it be newbie friendly. That means that some things that make sense to an experienced C++ dev might not be ideal. If there’s a good reason for something, then we should document it clearly, both in terms of what’s going on, how it works and why we do it that way.

Another thing is, of course, efficiency of the compiled code. On that tiny little microcontroller, individual instructions sometimes make a big difference in performance or space efficiency. Adding a layer of indirection that isn’t compiled out, is often a straight-up showstopper.

http://www.atmel.com/images/doc8453.pdf is an interesting read. There’s some stuff that…seems counterintuitive.

So, with that context, start making proposals. Possible, start with simpler, more obvious things. That’ll help you get a sense of which kind of crazy @algernon and I are and should help you figure out how to target future proposals or, possibly, make you decide that we don’t “get it” :wink:

-jesse

5 Likes
3

Thank you for summarizing your design targets.

The changes I was having in mind would certainly not violate the constraints stated. Rather the opposite, they might get us closer to actually meeting them.
And I was not talking about philosophic, whats-the-smarter-implementation-stuff, but performance, usability and maintainability.

I see the KS community is rapidly growing and I dare to predict a great future for keyboardio, considering how professional, congenial and unique you have done so far. But that’s exactly why I think that some issues concerning the plugin interface might better be straightened up before there’s a million of plugins around. KS has certainly come to stay.

You will receive my proposals soon. :gift:

I know, me being part of this forum is the ultimate stress test for the benevolence of the dictator.
So far, you’ve done quite well. :+1:

5 Likes
4

Just one comment, @noseglasses: Using “KS” as an abbreviation for Kaleidoscope is a little bit confusing, because I’ve so often seen it as shorthand for “KickStarter”…

5 Likes
5

@merlin - That’s taken me a bit, each time too. (I’ll update the topic title)

6

I spent a couple years as the Pumpking for Perl 5. You’ve been friendly, considerate and reasonable, even when I told you I didn’t like technology you proposed and that I had no good reason for my dislike. So far, this is a pretty light stress test :wink: (Please don’t try harder just to break me.)

8 Likes
7

Thanks for the clarification. What would be a good abbreviation? Typing Kaleidoscope (currently only on my smartphone) is quite tedious.

What about Kscope, KSP, KP? Lets start a topic…

1 Like
8

“the firmeware” ? :slight_smile:

1 Like
9

That’s … only slightly shorter. :wink:

10

Well, here’s one that’s just two “characters”: How about :crystal_ball::telescope:?

3 Likes
11

Alas, there’s no emoji for “kaleidoscope”…

12

There is one for :butterfly: though! And that’s kinda close.

3 Likes
13

That would serve as a replacement for keyboardio.

Btw., is there already a Kaleidoscope logo?

14

@Simon-Claudius has it in his work queue, but he’s doing work on Chrysalis first. :slight_smile:

2 Likes
15

Here’s the pull request.

1 Like