Show Layer-Tap/Mod-Tap information on keys

[BafS]

Show "Layer-Tap" information on the keys, before it was empty, we now see which layer will be enabled on hold and which key will be send on tap.

Instead of the layer logo I was hesitant to add "Hold" to show that this behavior is triggered when it's hold, but it could be done as a future improvement.

Before:

After:

[netlify[bot]]

✅ Deploy Preview for zmk-studio ready!

Name	Link
🔨 Latest commit	4ec09be337f695b51dc20cd879db8c971c5aab56
🔍 Latest deploy log	https://app.netlify.com/projects/zmk-studio/deploys/692f86971b38270007f52932
😎 Deploy Preview	https://deploy-preview-135.preview.zmk.studio
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[nmunnich]

This looks very similar to https://discordapp.com/channels/719497620560543766/722441520741089317/1293320175482966037, which I quite like the look of. If you're able to adjust it to match more closely, that would be great.

Does this work with all hold-taps? If not, it should be extended as such.

[BafS]

Updated the design and made it work with mode-tap too

[BafS]

Added indicators and some fine tuning

[danielsvane]

I agree that it would be nice to see the layer and mod tap info on the keys, but I think we should start out with a simpler visualisation like

This is personal preference though. I feel its simpler to review, and improve over time, when making as few changes as possible.

Also the linting changes you (or your editor) has done, makes it more difficult to review, and should be done in a seperate PR. The actual important changes are confined to 1 or 2 files.

[alvinometric]

Any updates on this?

[BafS]

I wish sorry, I pinged the devs a few times on Discord, I don't know what to do to get it reviewed again/merged. I lost motivation.

[nmunnich]

Last I checked, Pete is planning on doing more with Studio after we bump Zephyr to 4.1.

[BafS]

Is there still hope to help me review/merge this MR?

[nmunnich]

I believe this PR as-is is seen as too specific for the current state of Studio. See https://discord.com/channels/719497620560543766/719909884769992755/1435008086329917521 for a recent discussion we had - I believe that a generic "display both params of behaviour with two params" needs to come first, then figure out how to make that look good, then do edge cases for things like layer-tap.

I do think this PR could be modified to cover the more general case, but I would understand (yet feel saddened if you feel too demotivated to do said work.

[awkannan]

I believe this PR as-is is seen as too specific for the current state of Studio. See https://discord.com/channels/719497620560543766/719909884769992755/1435008086329917521 for a recent discussion we had - I believe that a generic "display both params of behaviour with two params" needs to come first, then figure out how to make that look good, then do edge cases for things like layer-tap.

I do think this PR could be modified to cover the more general case, but I would understand (yet feel saddened if you feel too demotivated to do said work.

So this is basically what @danielsvane suggested above.

If this change would be green lit, I'd be happy to take a stab at it

[petejohanson]

I'd love to see improvements here, yes, that align with the metadata approach so we can have a sane display for any possible parameter combination, with enhanced/imporved display for specific pairs of parameter types.

Important note: The calculation of the second parameter type can depend on the given first parameter value, so the calculation for what that second type is can be non-trivial. We do that right now for the behavior parameter picker here, if you need to see that in action: https://github.com/zmkfirmware/zmk-studio/blob/main/src/behaviors/BehaviorParametersPicker.tsx

[BafS]

Ok, thank you guys for the quick answers, I'll try to update this PR one of those days and make it more simple.

[BafS]

Still a WIP but it's now closer to the behavior param picker

What would be good, I think, is to send the behavior name in the protocol. Currently, we don't have this information, we only have the "display_name" but not the "behavior_name" (see behavior_subsystem.c in the firmware). With this info we could have a design closer to https://nickcoutsos.github.io/keymap-editor/ for instance.

[awkannan]

Since we pretty much have to deal with the protocol we have now, I think using display_name would be a good solution for now. We can consider using the shorter behavior name later.

Maybe something like this:

[BafS]

If we go that route @awkannan I think it would be better to open a separate PR that only change the design. Right now we show this info when we have the cursor "on hover".

I would gladly take care of the implementation, but to avoid back-and-forth it would help to have a specific design/idea/goal in mind before I start.

And thanks for your review! I'll check this soon

[awkannan]

Agreed - I think that should be a separate PR!

[peterjc]

This would close #147 which would be great 😍

[awkannan]

Since #141 was merged, there are some merge conflicts now. But hopefully it's not too bad to fix up!

[BafS]

I still need to work on it, but that's how it currently looks like with the rebase from main