Layer-switching confusion

The stack would be ‘stackier’ if we could drop layers into it in any order. But the ability to pull a layer out by name from any position (not just the top) is worth keeping, to avoid accumulations of leftovers from poking out around the edges of those topmost layers. Both of these operations could be handled with some complications to the cache-builder.

I’ve tried and tried to think of something else we operate the way Kaleidoscope layering currently works: layers can be in or out of the stack, but only at a fixed position. The only one I can think of is multiplane animation cameras (the technology that made Disney’s Snow White and the Seven Dwarfs revolutionary). Art is drawn for a certain distance from the lens, so that the angular size of the image on it will be coherent with the other depth cues (focal plane and depth of field, overlapping, parallax, vertical position, haze) and the size of the object it portrays. But compositing a cartoon image is not very much like compositing a board of input controls.

(And actually, for the camera you can draw a series of frames that move an object from one depth to another; you just have to cancel out each change in real distance-to-lens with a careful jump in image size, and eventually you can take it from being overlapped to overlapping or vice versa. So Kaleidoscope is more strictly ordered even than multiplane cameras, and with less justification for it from the nature of its task.)

With n layers in fixed order, technically there are 2^n possible composites, but to a human user it hardly matters which small fragment of which unused group of keys peeks out from some deeply buried layer.

I suspect it’s very hard to design a layer that usefully uses transparency on about half the keys. Exposing most of a thematically coherent key cluster (“theme”) from a lower layer is usually much less useful than exposing all of it, designing it to retain utility relative to every higher layer that may nip off one portion or another of it is mind-boggling, and ensuring that the higher layer does expose it entirely is just another packing problem, little different from just putting it in that higher layer in the first place. It’s more flexible only in that several themes on lower layers could share a footprint, if they usefully go together with the upper one and not much with each other. So I believe there’s ecological pressure for layers to be either mostly transparent or mostly opaque.

And that means the highest active mostly-opaque layer dominates the composite (unless numerous higher mostly-transparent layers are very, very well coordinated – but again, that isn’t much different from coalescing them into an opaque layer of their own). Even if we are quite optimistic about the possibility of a second or occasionally even third mostly-transparent layer making a meaningful contribution to the composite, fixed order still means there are about (n choose 2) meaningfully different places to go.

Free order means you don’t have to get multiple themes exposed at the same time, as long as you can bring one to top easily. So the pressure toward mostly-opaque layers is reduced, and the design of mostly-transparent layers requires solving fewer simultaneous packing problems too.

1 Like

@eritain This is 100% a deficiency in the current implementation. https://github.com/keyboardio/Kaleidoscope/pull/867 aims to address it. Right now, the only blocker to it getting merged is testing. I’d really like to see some automated tests, but user reports that the new code works well would probably be enough to tip me over the edge into merging it

2 Likes

On the M01, I didn’t really need multiple layers, simply because there are more keys on the M01 and at most I mainly used the palm keys to temporarily shift to another layer for nav, media controls, misc keys, etc.

On the atreus, you have to use layer if you want to access numbers, punctuation, spacing, nav, modifiers, etc.

I’m trying to understand the difference between lock to layer vs move to layer. The shift to layer requires me to hold down the key to access layer-x. Where move to layer allows me to access that layer without holding down the move to layer key.

On a different note, I didn’t think I’d ever like any other kb as much as the M01, and I may not but I’m really liking the atreus. I backed one on faith that J and K put out marvelous things and ended up immediately getting a second one once I got to touch a real one.

Can we get an atreus 2 that has backlit keys?

Wasn’t sure where to put this or start a new thread but this thread seemed closest.

Oh, I just had a thought. atreus 3 can have morphing keys, the keycap itself is blank but the led below it will project the key corresponding to whatever layer you’ve activated… I know magic, may be too sci fi for some people. Dream big.

Mike R answered this question here:

@rloic already provided a link to the sketch, but I’ll answer your other question.

No, LockLayer() and MoveToLayer() are not equivalent. LockLayer(N) toggles the state of layer N when pressed, activating or deactivating that layer, but leaving all other layers unaffected. MoveToLayer(N) unconditionally activates layer N , and also deactivates all other layers (except the base layer).

The distinction matters because the layer stack is index-ordered. Layer N+1 is always above (and when active, its non-transparent keys will be masking) Layer N , regardless of the order in which they were activated. So, if both layers 2 and 3 are active, pressing LockLayer(2) will deactivate layer 2 , but would only affect the mapping of keys that are transparent on layer 3 . Pressing LockLayer(2) again would re-activate layer 2 , but layer 3 will still be the top layer. Pressing MoveToLayer(2) , however, will also deactivate layer 3 , and will result in layer 2 being active regardless of its previous status.

3 Likes