Current world status allowed me to finally upgrade my layout by manually merging my custom layout with the latest kalaidoscope edition.
I have one problem though, that I can’t figure out how to fix.
I use the OneShot plugin and I keep getting my modifers stuck in sticky, which leads to all kinds of disruptions in my workflow.
In my previous layout I could disable stickyness with a flag, but now it is a method call. I RTFM, but it still doesn’t work for me.
Also I tried to enable the ActiveModColorEffect plugin, but that doesn’t seems to kick in either, so now I am suspecting that maybe I have made some foundational merge error.
I would be grateful if somebody could take a look at my sketch and tell me if you see the problem.
I managed to solve it, but I am not sure what I did.
I fiddled around and tried out Topsy. But didn’t have space for that, so I got rid of QuKeys.
Maybe that solved it…?
One thing that is getting on my nerves is that I no longer trust the dev environment.
I can make a change and flash the keyboard with no errors and then sometimes I don’t see the change.
I can revert to a previous version and start over, but it is very annoying not to know which code is running.
I haven’t had time to think this through completely, but when you had Qukeys active, it was near the end of
KALEIDOSCOPE_INIT_PLUGINS(), after OneShot. This is not recommended, because Qukeys needs to delay key events, and sometimes changes their
Key values. Because of that, putting it after other plugins that have already processed those events doesn’t work. You might want to try the version before you removed Qukeys in favour of TopsyTurvy, but with Qukeys initialized as the first plugin in the processing order instead of nearly the last.
I think you are very likely right about QuKeys having to be configured right.
But now that it works and I found that I no longer need dualuse in my layout, I must admit that the motivation to go back is slim
I actually tried removing qukeys earlier, but that did nothing - but that was also before I realized that the dev environment is broken.
Do you have any idea why I can sometimes flash, but the firmware doesn’t reflect my change?
When I got the problem I can revert in git - flash again, test ok, make the simple change again, flash and then I see the change in the layout. But when I keep working, it happens again …
You are using EEPROMKeymap, that’s probably why. EEPROMKeymap - by default - overrides the built-in keymap. If you don’t plan to change the layout with Chrysalis or a similar tool, you can just drop EEPROMKeymap. Mind you, that will alter the EEPROM layout, so you may need to redo your colormaps.
You should place
ActiveModColorEffect last, or at least after all other LED plugins, so it can override them for the mod keys. If it’s too early, the active LED mode may very well revert the highlight
ActiveModColorEffect would make.
This sounds like a bug. Can you open an issue on GitHub about it, please?
Thanks for the tips on EEPROMKeymap. I will try disabling that.
For the other things with ActiveModColorEffect and stickyness. I think that just happended because I couldn’t tell which code was running in the keyboard! So I tried all kinds of things, but didn’t notice that flashing didn’t work. Isn’t that a bug?
I did the same thing, about a week ago, and had the same problem. Here’s the solution I found; I haven’t applied it to Shift (yet!). I’ve got this snippet within
setup(), just after the call to