Yep, it’s for that. I’m not happy how the default layer selection is presented, but wasn’t able to come up with anything better yet.
It’s… not that much work. Duly noted (#76), I completely forgot about DualUse keys.
Thank you for taking it for a spin and providing feedback! <3
I added an issue for outputting the key maps as C code.
The modifier chekboxes are not active for me. I assume you must know that but just in case…
The bottom right plus control doesn’t fit my conception of how it’s commonly used in design language. I thought it would probably add a new layer before I clicked it.
I don’t see a way to add layers yet. Again, I assume you already realize that but that would seem like another key feature.
Yep, that’s a known limitation. I disabled them instead of letting them be enabled but doing nothing. (#63)
Mhm. What do you think would be a better place to put the speed dial? Or rather, what would be the best way to make the same-ish functionality available that’s less surprising?
Adding layers is… not the most intuitive at the moment. There’s limited amount of space on the keyboard’s EEPROM, and we pre-allocate slices of it for various purposes, at compile-time. So there’s no way to extend the number of layers, you only have as many as you configured (3+5 with the factory firmware; 3 read-only in PROGMEM, 5 additional ones in EEPROM). Thus, an “Add Layer” button doesn’t fit this model.
The way you “add” layers is choose one that’s past the read-only PROGMEM layers, and set it up as if it were your default, replacing the built-in ones. Then you set it as the default. (We’ll provide a copy layer functionality later on, to make this task easier).
I suppose this should be better explained, and a help button, or help screen would go a long way.
If we can come up with a way that allows the built-in, read-only keymap to be able to switch to an EEPROM layer, and make that configurable, that will open up a few new possibilities.
I just tagged another release of Chrysalis, 0.1.0, the first one I’d consider “alpha”. Functionality-wise not much have changed since 0.0.6, but a lot of polishing was done, lots of small stability and UI improvements were made to make the experience of using it much less scary. I’ve tested it on Linux, Windows 10 and OSX, and every functionality worked on all three platforms, a big improvement over 0.0.6 already.
I realize it’s the holidays, so taking it for a spin is the last thing on people’s minds, but I wanted to have something nice under the virtual tree, so:
Happy Holidays!
I just released another Chrysalis pre-release, version 0.3.0 this time (there was a 0.2.0, with many improvements, but wasn’t announced here). It’s a release where I was seriously contemplating branding it beta instead of alpha. A lot of polish went into this, as can be seen from the release notes:
If you can take it for a spin, and report any issues, that would be amazing. I’ve had a few people test previous builds, and the feedback we received was invaluable, and made it possible to polish the design much better than I would’ve been able to on my own.
There are binary builds available for Linux (Ubuntu 18.04+), Windows (10+), and OSX. I’ve tested all, and they all work (except for flashing ErgoDox or Atreus under OSX - that’s something I’ll fix in an upcoming 0.3.1 release).
Chrysalis 0.3.2 pre-release is now available:
It contains quite a lot of bug fixes and polishing since 0.3.0. Flashing the ErgoDox and Atreus under OSX and Windows now works too.
Really impressive work. Can you describe the conditions in which a layer is determined to be read only? I noticed Chrysalis smartly was able to load my existing layer settings but showed them as “RO”.
One small note, looks like Tilda shows up as “<” in the key description
When they are in PROGMEM, they are read-only. Any layer you create in your sketch, that appear in the KEYMAP(...) block are going to be read-only, because they’re in flash memory, which cannot be written to, except during re-flashing. To have editable layers, you need the EEPROM-Keymap plugin.
We hope to improve the experience in the very near future, and make it so you won’t have to see or deal with read-only layers unless you unhide them with a knob in the settings menu. Chrysalis will do some magic behind the scenes to make this possible.
The keymap currently shows US QWERTY labels. If you have your OS set to a different language, that’s not reflected in Chrysalis yet.
Thanks Algernon.
I guess then I’d be looking for a basic way to migrate all my current settings stored in PROGMEM into Chrysalis, since Chrysalis has successfully read through my existing layers. If I have to bite the bullet, to do the conversion myself and manually set each key again in Chrysalis after setting Chrysalis’s firmware back to factory layout, just let me know.
My OS is set to US and I only read/write English. I have fn+Q mapped to shift+backtick, which should show a Tilda but instead shows <. (I have backtick key set to Tab, and fn+backtick set to backtick)
With Chrysalis 0.3.3, you have to copy each PROGMEM layer, and adjust the layer switching keys after. With the upcoming 0.4.0 version (due sometime in February), Chrysalis will do a lot more automatically: you won’t need to copy layers, nor adjust layer keys. All you will have to do is apply your own customisations. If you flash a firmware with your customisations applied and plugins required by Chrysalis, then you won’t even need to do anything, until you want to change something: then start Chrysalis, do the change, save.
Oops! Found the bug, thank you. This will be fixed in the next Chrysalis release.
@algernon, quick question. I’m trying to use Chrysalis 0.4.0 to configure “space cadet”, inasmuch as I want the shift keys to be ( and ) if just tapped. I can map a key to “enable” space cadet itself, but I don’t really want that - I just want to “manually” create the equivalent function by using the GUI. I got very excited when I saw the toggle “Modifier when held, normal key otherwise”, but it seems that enabling this toggle repurposes the existing check boxes, which is a problem for ( and ) because they have to be defined as shift-9. Am I missing something?
With the current GUI + experimental firmware pair, the most straightforward way to use SpaceCadet is to have a dedicated “enable” key. SpaceCadet is disabled by default, because people found it surprising when it was enabled. I suppose we could make the enable/disable state storable in EEPROM, and then you could just flip it on in Chrysalis and be done. If you can file an issue about that, that’d be great.
Until then, an enable key is required, I’m afraid.
Got it - but isn’t there a slightly broader “issue” (or design limitation) arising from the re-purposing of the modifier key checkboxes when the “modifier when held” toggle is enabled? For a newbie, isn’t SpaceCadet just a name for a very selective implementation of what you’ve faciliatated with a more generic and useful capability (which is explicitly shown in the layout editor)? I appreciate the efficient use of real-estate, but I’m not sure how intuitive it is, and it restricts the capability to keys that don’t require a modifier themselves, which would be fine with the exception of shifted keys for which there is no dedicated key code (like the “(“ and “)”. In an ideal world, when I activate the toggle, an additional set of modifier checkboxes would appear. This would obviate the need for SpaceCadet itself, which I think would be a useful simplification.
The reason for the repurposing is that there’s a technical limitation: each key on the keymap is stored on two bytes, so we have a limited number of possible combinations. We can support dual-use keys with this model, but we can’t support things that’d be a shifted key on tap, and a modifier on hold (aka, SpaceCadet shift), because we run out of bits. That’s why SpaceCadet is a separate plugin, and why some of the plugins aren’t easily configurable via Chrysalis.
By the way, we’re working on redesigning the key selector to be more intuitive, and sooner or later, we’ll write documentation too, explaining the limitations as well.
Aah. Sorry. I now recall reading that somewhere. Thanks for taking the time to explain again.
I see in chrysalis that there is a way to run a macro. Can you remind me how I can edit the macros through chrysalis? If it helps, my macros are simply typing a static set of strings, eg press key and get “abcdef” every time.
There isn’t yet. Chrysalis allows you to set up macro keys, but right now, those macros must be written in code. There will come a time - soon enough - when you will be able to edit macros from within Chrysalis, but it can’t do it yet.
Gotcha, I have the macro code that I wrote via the .ino file. Can I put that somewhere?
If it’s in the ino, and you compiled & flashed it, you should be able to assign it to a key, yes. (Did I understand the question? I’m lacking coffee and sleep, so my English parser is not very reliable at the moment.)