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 SPACE
than 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.