Allow combinations of modifiers as modifier when held, normal key otherwise

[EFLS]

I'm using Chrysalis to configure my Keyboardio Atreus which just arrived, and am really enjoying the experience so far. My prefered config (which I use on my Ergodox) makes heavy use of the 'Modifier when held, normal key otherwise' feature.

One thing Chrysalis seems to be lacking, is a way to use this feature with a combination of modifier keys. I can select Ctrl, Alt, Shift & Gui individually, but not combined to act as modifier when held, but normal otherwise.

For my specific use-case, I'm trying to get a key to act as Hyper when held (i.e., Ctrl+Alt+Shft+Gui) but as space otherwise.

Am I missing something? Can this be considered as a feature request?

Thanks EFLS

[EFLS]

I'm learning a bit more about Chrysalis & Kaleidoscope -- and now I'm thinking that this is probably available in the Kaleidoscope firmware directly, but not yet in Chrysalis. I might have to learn how to flash the firmware directly.

[ksheng]

I have this exact use case (need to overload a key with Hyper), and while I could implement it in firmware, it would be the only key that needs to be done that way. Would be great to see this in Chrysalis.

[gedankenexperimenter]

It's possible to add this feature, of course. The downside is that it would use a relatively large number of the Key values available to plugins ((2^4-1)*256). It would also add a little bit of complexity to Qukeys, though probably not enough to be concerned about. It would also be desirable to insert these new values for DualUse keys consecutively with the existing ones, which would presumably create a backwards-compatibility issue with existing stored values.

[ksheng]

I see, so there are some technical challenges to the implementation. What if you only special-cased Hyper and Meh? It could reduce the amount of space used, but still add that complexity, so it's not a perfect solution.

[gedankenexperimenter]

I think before we get to the technical challenges (which aren't so much "challenging" as they are "inconvenient"), there's the matter of whether or not those changes are (generally) desirable. After all, there is already a way to add those key definitions to a Kaleidoscope sketch.

If the AVR chips used in many of the boards supported by Kaleidoscope weren't already so close to their limits in RAM, PROGMEM, and especially EEPROM capacity, it would be easier to say that the best solution would be to move the Qukey definitions into EEPROM, and add the ability to configure them to Chrysalis. But there is a pretty big grab-bag of constraints, and it's not obvious what the right choices are.

What if you only special-cased Hyper and Meh? It could reduce the amount of space used, but still add that complexity, so it's not a perfect solution.

Good question. I would not want to do this, because it doesn't just add the complexity of the more general system, but arguably adds more complexity to the logic, and makes the upgrade path even worse. I wouldn't go so far as to say that I think it would be wrong to do it, but I do think it would be a poor choice. As the author of the Qukeys plugin, I will claim a certain amount of expertise in this area, but I feel I should also point out that I am very comfortable building a custom firmware that would solve this problem with existing tools, and I know that there are plenty of people who don't have the same level of comfort, and by no means do I want to silence dissenting opinions. I think providing more general Qukeys functionality to users via Chrysalis is a great idea, but that focusing strictly on modifier combos is perhaps too narrow. For that matter, focusing on Qukeys definitions alone is probably also too narrow, as this could be part of a more general architecture for plugin configuration stored in EEPROM (or equivalent storage). If we do restrict the topic to just Qukeys modifier combos, we should perhaps add the right alt key, as well. Currently, we don't even support that via Chrysalis, and I would think that would be of more general interest.

[Historical note: The reason that some Qukeys definitions are available in Chrysalis, but many are not is because Qukeys was originally a third-party plugin that replace the original DualUse Kaleidoscope core plugin, and took over the DualUse key handling as a drop-in replacement. It's those more limited DualUse keys that are available in Chrysalis, because they pack the info for both the primary and alternate Key values into one 16-bit keymap entry. My dream system would use neither existing mechanism, but instead give Qukeys a single, much smaller index-based range, with its primary and alternate values stored in a PROGMEM array, which Chrysalis could write by compiling and flashing a custom firmware.]

[obra]

In -general-, we're interested in making as much functionality as possible available from within Chrysalis.

[ksheng]

That all makes sense. I seconded this as a quality-of-life improvement, but it does sound like there are constraints in the system that I didn't have context on.

I'll go ahead with implementing it in a custom sketch for now and keep an eye out for when something better comes along.

[macintacos]

I was super excited to mess with the Model 100 after finally receiving it, and it kinda bummed me out that something like this wasn't possible when I started configuring it - something that has been in QMK ever since I got into this hobby (something like 5+ years ago at this point).

Are there any plans to get this into Chrysalis?

[algernon]

It is available in Kaleidoscope, the firmware that powers the Model100, so if you're willing to compile your own firmware, you can use it.

As explained above, exposing it in Chrysalis is non-trivial, because unlike Oryx and most other keyboard configurators, Chrysalis does not compile firmware to flash, but uploads non-executable data for the firmware to use as configuration.

[macintacos]

@algernon thanks for pointing to Kaleidoscope, I'll take a look. I don't think this will be an acceptable workaround for a pretty big portion of the Model 100's audience though, so I'm hoping that this could be bumped in priority.

[gedankenexperimenter]

To make this available from Chrysalis, the best option would be to make full-fledged Qukeys definable in and readable from EEPROM. It would solve not only this problem, but would also provide a way for the primary key value (what you get on a "tap") to be something other than an unmodified Keyboard key. I think this would be great, but it's outside my area of expertise.

[algernon]

I have a pretty good idea how this could be accomplished, kinda modeled after DynamicMacros and DynamicTapDance, most likely. I hope to get there sooner rather than later, but there are higher prio tasks in Chrysalis at the moment.

If anyone wants to have a go at it, I'm happy to provide some hints and ideas, both for the Kaleidoscope and the Chrysalis parts of it.

[benfrain]

Would really like to see this added. Is there any kind of ETA currently? Don't have a Model 100 yet but this would be a blocker to ordering it, as like OP, I use Hyper on Home Row Mods in both ZMK and QMK.

[obra]

Is there any kind of ETA currently?

I'd love to see it happen, but it's nowhere near the top of our priority list. If someone was interested in hacking on it, I'd be glad to provide pointers.