Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editing nested behaviours #232

Open
sebmos opened this issue Jun 14, 2024 · 1 comment
Open

Editing nested behaviours #232

sebmos opened this issue Jun 14, 2024 · 1 comment

Comments

@sebmos
Copy link

sebmos commented Jun 14, 2024

I started using tap-dance and mod-morph behaviours the other day, which has been great for my layout, but also painful to edit. Unsurprisingly, my tap-dance and mod-morph behaviours are only used once on my keymap. Have you considered creating an integrated editing mode for single keys that creates an underlying mod-morph or tap-dance behaviour? (There might be other behaviours that might be useful for, too.)

In other words, I could click on a key, set it to use a mod-morph behaviour, and then configure its parameters. Behaviours that are likely to only apply to a single could be offered alongside configured behaviours.

Aside from the implementation complexity, creating a behaviour like that would be relatively straight-forward. Editing could create some confusion if a behaviour is used on multiple keys. Aside from not allowing editing from the layer view at all (to save yourself the user education problem of "why can I edit this mod-morph behaviour from the layer, but not that other one?"), I see a few potential solutions:

  • Enable editing only for single-key behaviours (and show the existing behaviour selector only for everything else)
  • Enable editing, and edit the behaviour for all keys that use it, i.e. edit the underlying behaviours.
  • Enable editing, but (optionally?) create a duplicate, so the changes only apply to that one key.

I'd be curious to hear your thoughts!

@nickcoutsos
Copy link
Owner

Yeah, I think bringing composition into the binding editor makes sense and would improve the flow a lot. It's very complex, though, as the app becomes responsible for managing behaviors created on the fly which raises all questions about whether these behaviors should be hidden from the UI or how to handle managed behaviors modified/deleted via direct keymap manipulation.

I've have some thoughts about this, but it's a lot of work and not something I can really dedicate any of my focus to right now so no promises about timelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants