Allow Keychords for remapping

[darshanCommits]

I was trying to map keys to mimic helix binds i realized you cant use g-g or g-e,
modifier is allowed but not that.

this would also allow for more complex keybinds without hurting the pinky.

[Stoppedpuma]

The current solution for keybinds has to be remade as it can get stuck or drop inputs completely in a few ways. I'm not sure that this will be something easy to set via the UI unless we have a dedicated "escape key" to prevent the input reader from just setting a single key, because of this I'm thinking this might be something only achievable in the config file only? Looking at #408 may interest you on this topic.

@woelper pinging you for your input on the above.

I'll keep this open until woelper has a chance to respond about the actual chord bindings you're requesting, I also think this as some uses such as being able to create acronym keybinds for things like filters if the user desires such as "pt" for palette transfer.

[darshanCommits]

I wasn't aware of the config file. True doing it in ui will complicate it regardless of how it's done internally.

[woelper]

I think these might make sense in a text editor, but I have trouble imagining how you would do these in a way they feel snappy. I want instant feedback when I press fullscreen or other shortcuts. With the keybinds you describe, it sounds like we need to always wait until a second or third key is pressed or am I thinking about this the wrong way?

[Stoppedpuma]

we need to always wait until a second or third key is pressed or am I thinking about this the wrong way?

I think so, I'm pretty sure the user is requesting keys such as how vim works (e.g g+g to go to the top of a file), for most cases I'm a bit confused on this as well unless the user just doesn't like holding any other keys but in some others it would make sense such as being able to quickly bind filters to an acronym style keybind solution. Some examples of this are: i+v for invert filter, a+t for always on top, v+j/k to resize to fit height, v+h/l to fit to width.

These should of course have to be required by the user to setup in the config file, the current keybinds should remain.

One thing which would have to be considered here is a timeout so that if the user doesn't press any keys in x amount of time then the original action is discarded. e.g if a user has several keys added to v like a, b, c, if they have a time out for 5 seconds and they wait that long after pressing v, then none of the a, b, or c keys work unless v is pressed again.

[darshanCommits]

yes, that was my idea. Thank you for expanding upon it.

Since it's not something everyday user would do, it's probably okay to have it in config only.

Speaking of timeout, Escape/ mouse click to cancel out the keypress would be a better idea imo. Timeout will make single key combination complicated if user wish to combine.

eg:
j=next picture
k=prev picture
g-g=first picture
g-e=last picture

Timeout will create artificial delay for single binds like j/k, workaround for that would be to check if there's any keychord associated while parsing.

If this is something you think is a good idea, I'd like to work on this. Although It may take time as I'm not familiar with the codebase.

[Stoppedpuma]

If this is something you think is a good idea, I'd like to work on this. Although It may take time as I'm not familiar with the codebase.

I'm personally in favour of the idea, if you want to give it a shot then go ahead! I can't promise anything as woelper is the one with say here but this feature is completely hidden from the average user. One thing which should be stated before you try any work is that as mentioned in #408 woelper already has a few ideas on how to redo the current keybind solution as it has issues which must be fixed. If you are going to end up implementing this, you'll run into some of these which might make it better to wait until this is addressed on our end unless you want to rewrite this accordingly in your implementation. If this is still something you want to attempt, you should build against #495 as this is where all the work for 0.9.2 has been and master is quite far behind.

Regarding the timeout, it shouldn't delay anything, think of it like an idle timeout. An additional escape key should also be included but I think an idle timeout option would be very useful to prevent against accidents, after all this isn't really a text editor or advanced image editor so things like undo / redo don't really exist in Oculante at the moment and we recently declined a similar request of relevant keybinds for such.