In its current incarnation, Qukeys are configured outside the keymap, with a separate declaration, so (for example) the keymap entry might look like this:
Key_A
…and the qukey constructor is in a separate place:
Qukey(QWERTY, 2, 1, Key_LeftShift);
@algernon had the idea that we could use the DualUse declarations in the keymap as Qukeys, which would work, but would be more limited than the separate definition:
SFT_T(A)
I’m thinking of trying to put this in the keymap:
QK(Key_A, Key_LeftShift)
…or some abbreviated equivalent:
QK(A, LShift)
…where QK() is a macro that expands to some function call, such as:
#define QK(pri, alt) defineQukey(pri, alt)
That function would be defined earlier, like so:
Key defineQukey(Key pri, Key alt) {
static byte i = 0;
// create the entry in an external array
qukeys[i] = Qukey(pri, alt);
// mark the keymap entry as a qukey, with an indexed offset
return (Key){ .raw = ranges::QK_FIRST + i++ };
}
Then I’m back to the problem of getting the size of the array correct in its declaration, but right now I’m just wondering if this is feasible. I wouldn’t use a static variable in the function, of course; that index would end up being the size of the array, so it would be a class variable instead, but I hope that conveys the idea.
It’s like the DualUse declarations in the keymap, but would allow for the full range of possible Key values for both the primary and alternate Keys. I’m interested in the question of whether or not this idea is feasible (I’d be surprised if I tried this example and it worked), setting aside the issue of getting the size of the static qukeys[] array correct for the moment. I’m not convinced that this is a good solution to the problem (I’m pretty skeptical, myself) — I just want to know what’s possible at this point.
