# Qukeys on specific layer but key is transparent

**URL:** https://community.keyboard.io/t/qukeys-on-specific-layer-but-key-is-transparent/6314
**Category:** Programming
**Created:** [April 6, 2023, 4:44am UTC](https://community.keyboard.io/t/qukeys-on-specific-layer-but-key-is-transparent/6314 "2023-04-06T04:44:04Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![Moilleadoir](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/moilleadoir/32/4122_2.png) [@Moilleadoir](https://community.keyboard.io/u/Moilleadoir)
#### Post date: [April 6, 2023, 4:44am UTC](https://community.keyboard.io/t/qukeys-on-specific-layer-but-key-is-transparent/6314/1 "2023-04-06T04:44:04Z")

</div>

A while back I added curly double quote macros as a tapped option on my Alt keys. I also made macros for single quotes, but only added the right one as a held option on ’ since that’s the one I use most.

While editing a document that uses singles a lot I thought I’d add singles in the same place on the Function layer. I thought it would be a simple matter of copying the Qukeys lines and changing the layer & macro, but it didn’t work. Serial monitor showed that the Primary layer macros were still being triggered.

These keys were, of course, transparent in the Function layer layout. Changing them on the Function layer to explicitly reference the Alt keys fixed the issue. I can see the logic here (transparency means you’re still operating on that other layer), but it sure was confusing for a bit.

---

<div class="post-metadata">

### Author: ![merlin](https://yyz1.discourse-cdn.com/flex031/user_avatar/community.keyboard.io/merlin/32/3416_2.png) [@merlin](https://community.keyboard.io/u/merlin)
#### Post date: [April 6, 2023, 5:09am UTC](https://community.keyboard.io/t/qukeys-on-specific-layer-but-key-is-transparent/6314/2 "2023-04-06T05:09:45Z")

</div>

Here’s some more detail on why this happens:

Kaleidoscope stores a mapping of keys to the layers that each key gets its value from. Qukeys uses that layer mapping to decide which `Qukey` to use, if any, when a key toggles on, rather than simply using the top active layer. It could do the opposite, but that would almost certainly be confusing to users a much higher percentage of the time, as their qukeys would inexplicably stop working whenever a mostly-transparent layer was activated.

I see now that the `Qukey` objects are defined in such a way that suggest that they might work in the way you expected, but that is an artifact of the original status of Qukeys as a third-party plugin. If I had been writing it as a core Kaleidoscope plugin from the beginning, I would have used a different structure, and set aside a range in Kaleidoscope-Ranges for a dedicated `Key` type to put in the keymap, with an encoded index into an array of `Qukey` objects instead, and that would have removed the need for both the `KeyAddr` and layer number members when defining the object.
