As a former QMK user, I do owe it gratitude for getting me started in making my own keymaps. However after migrating to Kaleidoscope this does seem like a better system generally. This is my attempt to flex the merits of Kaleidoscope over those of QMK for hand coded key-maps. I don’t have knowledge to discuss graphical tools like Chrysalis where I understand Keyboardio has an even greater advantage.
QMK encourages you to start by forking their repo: thereby downloading a massive directory of stuff just to build your own keymap. This also exposes you to the horrors of git. I managed to get out of sync and eventually overwrite my own keymaps whilst trying to rebase everything.
I confess that Kaleidoscope and its use of Arduino did not seem intuitive when all I had known was QMK. At first I did not see why one would want to use Arduino’s austere looking IDE instead of choosing any text editor or IDE under QMK. But once used to it, this approach seems much more logical. Instead of getting into a pickle with Git, the IDE quietly keeps the tools for building key-maps up to date in the background. Arduino’s self contained environment made a lot more sense after my own misadventures! In fact, when Arduino have made it their business to provide easy to use tools for building firmware and flashing microcontrollers, why use anything else?
QMK does have its advantages stemming from being an industry standard of course. It supports almost all keyboards and I think bugs are fixed faster there due to currently having more developers. Before the advent of Chords on Kaleidoscope - which is now better than the QMK system - there was MagicCombo which was hopeless for most purposes. So QMK used to be the only choice if you wanted to add key combos. Ironically I need MagicCombo for something now, so hopefully both plugins will be developed going forward.
So if like me you have used both, what are your thoughts on QMK? I’d love to hear from QMK die-hards also. Hopefully this thread will inspire some people who are used to developing in QMK to come over to Kaleidoscope. Maybe by articulating a good set of arguments in its favour we can encourage more manufacturers to add Kaleidoscope support to their boards?
I’ll give you that QMK’s git repo is a bear; I personally think they should separate each keyboard out into a submodule. As far as your lost code goes, I was able to find this and this in github’s repos; hopefully one of those is what you’re missing.
As far as how the code is designed, though, QMK makes a lot of intuitive sense to me: there is a hook for just about every phase of the keyboard polling process, and if you want to do something special anywhere, all you need to do is write the appropriate hook function. In addition the truly voluminous documentation is supplemented by all the example code that’s in the repo: you can find an example of almost any hook you want to write.
I never got to the bottom of how Kaleidoscope is organized; I found it impenetrable. I managed to port my macros over from QMK, but that was pretty much a monkey-see monkey-do operation – coding macros is the one thing that is described in (barely) enough detail for me to be able to make that work.
The one bit of code I had in QMK that I really wanted to port was CAPS LOCK BLINK: as a programmer, I use caps lock not infrequently, but I wanted a very noticeable reminder when it’s on, and I was able to get my entire keyboard’s lights to blink in QMK – impossible not to notice.
It wasn’t even very tricky.
In Kaleidoscope, it looks like there’s a beforeEachCyle event which is likely where an event handler to check the blink timeout would go (like housekeeping_task_user in QMK). How to implement a timer, though, I never figured out. Timers are certainly things one might be expected to use in keyboard firmware, and they are documented in QMK.
Maybe after I’ve written more general code for a bunch of arduino devices-- which is one of the things I’m hoping to get to eventually-- I will be able to fill in the gaps in Kaleidoscope’s documentation and implement the feature I want.
I don’t know if I’m a QMK die-hard – I haven’t messed with keyboard firmware in quite some time – but my experience is, I was able to get QMK to do 100% of what I wanted it to do; and Kaleidoscope only 50%. So QMK won for me.
Interesting. My experience is exactly the opposite. I had a lot of trouble getting qmk run the way I wanted it (never tried own plugins or anything like that though), main issue was the updates - always get the whole repo was a bit annoying. And let alone finding the right place to put your custom code. It was not very intuitive for me.
Kaleidoscope was easy to use from the beginning, not much boilerplate stuff to do, Arduino, klick some icons and you’re good to go. That was / is way easier than with QMK imho.
when it comes to the archtitecture and code - i did not dive too deep into QMK to really have an opinion about it, but I find Kaleidoscope better to understand for my part. But I agree - Documentation needs to be improved in order to really make it work for more people.
For me, it’s not so much the code (I’m a software developer) it’s the tool chain. QMK uses a fairly stock build process. I’ve never really got to grips with Arduino. I’m aware that you can build from the command line but I believe the Arduino dependency is still there.
I am also a software developer. arduino comes with the cli tools needed. It’s basically just setting a environment variable to kaleidoscope and call „make flash“
Now, that is. It used to be a bit more complex with the model 01.
I love that the „sketch“ is more or less self sufficient, you can put it to github or wherever. Like that.
It is understandable for those used to coding to be familiar with github and have a preference of IDEs that QMK might seem natural. For many of us, programming one’s own keymap will be the only time we have to encounter “real” programming. This is where Arduino IDE earned my trust - making microcontrollers easy to handle is its raison d’etre. Of course people like me who fall between the stools of “total noob” who never leaves the safe space of Crysalis, and the “serious programmer” who is used to handling all the tools of building firmware are probably in the minority.
I think in the wider scene, even for those who have heard of it, Kaleidoscope might be seen more akin to proprietary customisation software that major manufacturers issue with their products, rthan equivalent to open firmware platforms like QMK, ZMK et. al. That is the reason for this thread with its bombastic title: to encourage us make the case of Kaleidoscope as a viable option in its own right.