Displaying transparent keys functionality

[necsoiu]

Is your feature request related to a problem? Please describe.

We don't know what a transparent key does.

Describe the solution you'd like

It would be very useful to display the function of a transparent key, for example with a faded color and/or a different color.

Describe alternatives you've considered

An interesting implementation idea is the one used by the Oryx configurator.

https://ergodox-ez.com/pages/oryx

[Rom1deTroyes]

Well, transparent key are... Transparent (!), so it becomes the first key under it. You can't know if a layer is active or not, so you can't display a faded key for above the second layer :

• If you are on layer 0, a transparent key will do nothing
• if you are on layer 1, a transparent key will be the key of layer 0
• if you are on layer 2, a transparent key will take the key of layer 1 if layer 1 is active, and fallback on layer 0 if layer 1 is inactive, or transparent.
• if you are on layer 3, a transparent key will take the key of layer 2 if layer 2 is active, or the key of layer 1 if layer one is active and if layer 2 is not active or layer 2 have a transparent key, and fallback on layer 0 if layer 1 is inactive, or transparent.
• ...
• if you are on layer 9, a transparent (sorry, I don't want to try !)

If you want to know what a specific key does, you can look at the stack on the right : Here, what does be printed on my key depend of the context : do I write with azerty, steno or bépo ? even the base key can't be guessed :thinking:

[necsoiu]

Ok. So my suggestion was to improve the display of transparent keys

• If you are on layer 0, a transparent key will be showing
• if you are on layer 1, a transparent key will display the level 0 key with a faded color and/or a different color.
• if you are on layer 2, a transparent key will show with a faded color the key of layer 1 if layer 1 is active
• etc.

Looking at the stack on the right will show you the functionality of a single key. My suggestion will allow you to display the functionality for all the transparent keys of a layer. Please see the screenshot above.

This is very useful when you use many layers (and sometimes different keyboards) and forgot where are some keys on a certain layer. Implementing my suggestion will allow a much faster memory refresh than the individual selection of each key.

Besides, I think that the implementation of this solution should not be very complicated.

[algernon]

The problem with displaying bindings on a lower layer like Onyx does is that in quite a few common cases, it is simply wrong, and the displayed key will not be the one that's actually bound. Let me describe a few scenarios!

First of all, unlike in QMK, layers in Kaleidoscope are not index-ordered, but activation-ordered. So if you have a transparent key on layer 1, that doesn't mean it will be looked up from layer 0: if you activated layer 2 first, then layer 1, then the transparent key on layer 1 will be looked up from layer 2. If that key is also transparent, then it will be looked up from layer 0.

Second, even if we go by index, there's no reliable way to tell which layer a key is going to be looked up from, without asking the keyboard which layers are active. There's a possibility to have alternative base layers, for example: a QWERTY layer at 0, Dvorak at 1, and other layers above. A transparent key on layer 2 will only be looked up from layer 1 (Dvorak) when that layer is active.

Thus, without consulting the keyboard to know the currently active layers, there's no reliable way to show what a key is mapped to on a different layer. This is why we show only the current layer, and the mappings of the current key on other layers. It is technically possible to let the keyboard notify Chrysalis on layer change, and then show the mappings reliably, but that's a fairly complex operation, and would need a whole lot of changes on the Chrysalis side, as we currently depend on a request-response protocol, and data arriving from the keyboard without a request being sent is not handled well with the current Chrysalis architecture.

I agree, it would be very useful to have this feature, but it's sadly far more complicated to implement properly than one would first think.

[necsoiu]

Thank you algernon. I'm to blame because I was somewhat superficial when I assumed it would be easy to implement. And I think in this situation there are other features that should have much more priority. However, I think it would be useful to keep this in mind for the time being when the others will be resolved. You are doing a very, very good job.

[algernon]

Yeah, it is definitely something to keep in mind, as if/when we can implement this in a reliable way, that'd be very nice indeed.