SetActiveLayers: support layer mask

[rgoulter]

No description provided.

[rgoulter]

Hmm.

I think in order to get the "desktop keys" that I have, this would require "conditional layers" in addition to this "set layers (with mask)" functionality. -- Which then means each layered key is that much larger. (Albeit, this would be less of a problem with "sparse layered key").

Hmm.
I guess for the "desktop keys" (e.g. workspace left/right, for Linux/macOS/Windows), what I was thinking of was "activatable"? where "desktop" would activate all the desktop layers, but this 'activatable' would restrict it to one at a time? -- I think "conditional keys" sounds a broader solution.

[rgoulter]

RE: Conditional Layers.

It's tempting to think about abstractions like a full-on Kirei-style "key expression". -- I think with careful design, that might be an interesting abstraction to try, but I'm not sure it's a good fit for smart keymap. (For example, in my mind: smart keymap keeps each key system separate (layered doesn't know about tap hold, etc.; whereas, querying would either depend on a common central system or, involve some kind of way to refer to state of other system?).
-- But on the other hand, what's possible and what's practical/useful are different for keymaps.

Conditional layers are a generalisation of tri-layer.

My motivating use case is 'desktop keys'; keys which behave differently depending on condition/context.

I recall some keyboards even have external DIP switches. Smart-keymap wouldn't really support these external conditions.

Perhaps what I want is: keymap has some kind of config registry. Each config register supports 32 bits (say). Perhaps at Keymap scope. (System-specific 'registers' can be implemented as contexts). So, this condition key would behave differently depending on how the register is set; like layers, it could support variants, but would have keys to manipulate the registers directly.

(Again, though: having a key that's similar to layers but not layers... smart-keymap smells like it has some redundancy in its key systems).

[rgoulter]

Ah.

Another thought:
This "case key"/"condition key" that I want for "desktop keys" ~could likely borrow from the same layer system. But the obvious blocker is: right now adding a layer adds to the size of every layered Key, since it's all in the same "layer space". There's one "layer space", and all layered keys are activated with the same layer state.

If could have e.g. the "layers" layer state, "desktop" layer state, then the layered keys could borrow from this.

May-be also in miryoku style keymaps: the left hand layers are practically separate from the right hand layers. ("fallthrough"/"transparent" is practically the same as "not affected by that layer state"). -- Though I suspect this gets tricky: e.g. if there are base layers (qwerty, dvorak, ...), then it's not as simple as "left hand layer state, right hand layer state".

Hmm.
Perhaps simpler to think of "layer space" as "subset of layers". Ah. So rather than [Key], if instead it's { LayerSet, [Key] } then for a bit of additional overhead (computation and storage), layers can be stored more compactly. -- That way, having "Win layer", "macOS layer", "Linux layer" would only involve the overhead of may be having a larger layerset. (Presumably a bitset).

-- In which case, then having "Set Active Layers" have a layerset mask makes sense. And perhaps it makes sense for other operations to operate using a layerset, too. For "desktop keys", these could be just implemented in keymap-ncl-to-json as additional layers.