Custom names layers

[algernon]

The firmware does not save custom names given to macros, tap-dance, or leader keys, nor layer names. Yet, those are all interesting and useful information. Since we want to support saving a layout, and importing them too, we could also allow the user to name the layers, and give custom names to any of the keys on the board. Custom names would be displayed on the keymap instead of the normal label.

One restriction I'd add, is that this would only affect the primaryLabel; extraLabel would still come from DisplayTransformer. At least, for keys. For layers, there should be no such restrictions.

[hnrklssn]

Is it out of scope for this issue to also have the language setting act as a big custom key name import? Of course with the user defined key names overriding. Currently it is quite confusing to configure a non-US layout where the OS remaps the scancodes to another symbol than the one assumed by Chrysalis. Should I file a separate i18n issue?

[obra]

That's a separate problem that we don't yet have a good answer for. And I don't -think- that it should be tied to the display language for the UI. But please do open a ticket about it, because we do need to get there. ᐧ

…

On Tue, Jan 22, 2019 at 10:21 AM Henrik ***@***.***> wrote: Is it out of scope for this issue to also have the language setting act as a big custom key name import? Of course with the user defined key names overriding. Currently it is quite confusing to configure a non-US layout where the OS remaps the scancodes to another symbol than the one assumed by Chrysalis. Should I file a separate i18n issue? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACxaNzPWPuOrENL99_TUlJLuTaWMmWJks5vF1a5gaJpZM4XBL5O> .

[algernon]

Mistakenly closed, the @chrysalis-api merge confused GitHub.

[algernon]

I was thinking about this the other day, and I think I have a solution that'd work nicely: a CustomNames plugin on the Kaleidoscope side, which we could use to store custom names for keys or layers, in eeprom or in progmem. Chrysalis would simply query the names, and use those instead of the built-in ones.

For storage in EEPROM, I'd use the following format: 4 bits for the type of name, 4 bits for the number of names (N). Then we have N index->name mappings, where the index size depends on the type, and names are NULL terminated. Initially, we'd have two types: layer & key names. For layers, the index is 1 byte, for keys, its two bytes. If we need to have more than 16 names of the same type stored, we can store multiple series of the same type. The serialization ends when the number of names is 0.

So, for example, to have a custom name for layer #0 and #1, and a custom name for Dynamic Macro #0, we'd encode it as:

<00000002b> <0> "QWERTY\0" <1> "FUN\0"
<00010001b> <53596> "Greet\0"
<0>

For PROGMEM, it's a bit tougher, doing this kind of encoding at compile-time is more difficult. I'm not sure what the best approach would be there.

Maybe if we separated type and length... that'd allow 255 custom names per type, should be a plenty, even if we disallow multiple series of the same type (but we could have multiple series anyway). But maybe I can fit the bit fiddling into a macro. We'll see.

In any case, to keep up with the spirit of storing keymap and keyboard settings on the keyboard, I'd store the custom names there, too, rather than somewhere on the Chrysalis side.

[algernon]

Going to split this in two, because they will be implemented separately: custom layer names (this issue), and custom key labels.

[cobblepot1]

I just wanted to encourage continued work on this issue. I'm trying Miryoku on the Atreus, and it has 6 layers, and it's really hard to remember the main purpose of each layer without custom layer names such as Mouse, Function, Numbers, etc. This is true both for mapping the keys initially and for having the layer names on the layout cards I want to print for reference to learn the layout.

[algernon]

The Chrysalis side of this is pretty much complete. We just need to figure out how to approach the firmware-side, and we're good to go. It's coming soon™!

[cobblepot1]

Honestly, I would love it if you just released the Chrysalis part and stored the information in a file on the computer while working on a solution to store it in firmware also. I bet most people are like me and do their keyboard configuration on one main computer, so for those people having the info in a way that can be viewed in Chrysalis and printed out solves 98% of the issue. Storing the custom names for the layers in firmware is nice also but doesn't seem as necessary. Just IMHO.

[algernon]

This is now available in the latest snapshot build, and will be part of the next Chrysalis release.