A general question: What do you consider the top 5 plugins or macros currently available, and why?
For me, OneShot is far & away number one. I guess my two through four would be, in no particular order Macros, MouseKeys, Unicode, DualUse er, SpaceCadet.
-
OneShot, because it allows me to use modifiers and layer keys without chording, which in turn makes it so much more practical to move them to the thumb arc. For me, this is essential. I can work without the rest, but withoutOneShot, Iām useless. -
Leader, because it gives me access to actions triggered by a sequence of keys. -
TapDance, because it allows me to bind many functions to the same key, without having to use any other key to augment it. -
Focus, because through it, I can customize my keyboard without reflashing. -
Unicode&Syster, because inputtingšis so much easier asLEAD Syster mouse SPACEthan entering - and remembering! - hex codes.
MouseKeys and Macros come close to top 5 too.
Thanks for these replies. So many macros to try, so little time!
I donāt have a top 5 yet, still setting up but Iām using the Heatmap plugin for the bling bling 
and the Macro recorder which is quite fancy
cheers
I really like DualUse. I got PageDown mapped to LeftGui when held and PageDown when tapped. That works wonders, since I donāt need a windows button very often.
I also use it on my right alt key. When tapped it is AltGr (which works with WinCompose). When held it sends LeftAlt (regular alt modifier).
How do you do that? Is there a way other than using Chrysalis?
It has a small - though not too sophisticated - command-line tool as well, written in Python:
https://github.com/keyboardio/Kaleidoscope-Focus/blob/master/extras/kaleidoscope-focus.py
I use that for most things, and a small tool built on top of it to change my colormap:
https://github.com/algernon/Model01-sketch/blob/master/tools/colormap/apply
Mind you, I do not fiddle with my EEPROM contents anymore.
Qukeys is my undisputed number one. Macros would have to be number two, and I keep playing with MouseKeys so I suppose thatād be the third. OneShot Iāve used on and off so that would have to be up there too. Iād be reaching for a fifth.
Prior to Keyboardio Iād used sticky keys for 5 or 6 years and would never have envisaged ditching it but now I have.
Iāve mapped the home row keys to Super, Alt, Shift, and Ctrl both sides and I find chording practically effortless now, which is why I was able to stop using sticky keys (with its occasional annoyances).
Iāve tried to incorporate OneShot (which is essentially an extension to and more configurable version of sticky keys) a few times now but Iāve had difficulty getting it and Qukeys to play well together. But itās something I keep coming back to because itās too powerful and attractive a concept to not find a use for.
Iām very happy to hear that someone is successfully using home-row qukey modifiers, since that was the original goal.
If youāre willing to describe the compatibility problem(s) in detail, the best thing to do is open a GitHub issue for keyboardio/Kaleidoscope-Qukeys. The forum is good, too, of course, if you prefer that or donāt have a GitHub account.
Thank you, Michael! And like I say, Qukeys is a great plugin!
I would absolutely be willing to describe the issue and when I do Iāll try to so on GitHub, but Iāll hang fire on that for now as Iām encountering a bigger issue with my Keyboardio setup that Iām struggling to make sense of, namely that of repeated keystrokes. The issue is much wider than any use of Qukeys and OneShot as Iām still encountering it even when I revert to the original sketch. Some of the macros I have have also started firing twice - again even with the original sketch (but for the added macro definition, of course).
Anyway, for now I want to wrestle a little further with understanding whatās going on, even if only to be better able to describe the issue on the forum or on GitHub. Iām also hoping that should I get to the bottom of it, the problems with Qukeys and OneShot may also clear up because Iām sure I had it working perfectly one time, albeit for only a couple of days.
*edit - and sorry for the slight diversion of the thread, guys!
It could be that, and Iāll keep it in mind but I donāt think this is the issue. Also, Iāve had the Keyboardio three months now, and Iād not had this particular issue until this last week.
Iām still investigating this and there does seem to be other issues. One issue does (I think indirectly) concern Qukeys, and this is that the Qukeys toggle macro has completely stopped working despite being perfectly fine for months. Another macro definition that I mentioned above had stopped working but I managed to get that working again; itās just a tmux prefix macro: D(LeftControl), T(B), U(LeftControl). But according to xev this would register twice. So after changing it to: D(LeftControl), D(B) it works again. Of course, xev registers nothing for the Qukeys toggle macro, but that is precisely what one would expect anyway. Does any reason leap out at you as to why the behaviour of the macro plugin may have changed recently? Iām using the most recently updated repositories on an Arch Linux system.
If youāve updated to the master branch of all the repositories, it may be a problem with the new plugin hook system. Iām not one of the two or three people who has the arcane knowledge required to debug that part of Kaleidoscope, so Iāll direct you to @algernon.
Just to provide some closure to my ramblings about compatibility issues between Qukeys and OneShot: Iāve resolved things to the point I can happily say - no more problems!
Iād hitherto only ever used the command line when compiling the firmware, and indeed when using the Arduino IDE instead (and so not using repositories that incorporate the new plugin hook system), the non-working macros worked again. Other behaviour, which was never consistent, like repeated keystrokes and OneShot keys not āshootingā (when they really should have) also resolved themselves.
A OneShot modifier on a Qukey was also becoming āstickyā a lot too even when Iād set the double_tap_sticky property to false - but this was due to my having set the Qukey property of setReleaseDelay to something > 0. Even so, I suppose the modifier still shouldnāt be locking, but in any case, I didnāt need to mess with setReleaseDelay in the first place as my typing style doesnāt really warrant it.
That -sounds- like you might have been ending up with a different compiler when using the commandline builds.