refactor key input handling
pm100 opened this issue · 1 comments
[The reason I am raising these feature and api requests is because I am trying to get a large project , gitui, to replace their own textinput widget with TTA. I want
- to make my code simpler
- to make the change as non invasive as possible
- have compelling features
this will make TTA attractive to other developers too (This is a good thing for TTA). I could of course just fork TTA but that seems counter productive]
This change is a big one. I started it on the original select PR but did not explain it so you rejected it - fine.
First the core of TTA should have nothing to do with crossterm, termion, termwiz, or any other key / mouse input. It is fundamentally an API driven widget. Moving all that code to a set of sub crates would simplify TTA code organization and dependencies (you did some of this with the mod input in recent changes).
Input dispatch:
- at the moment the if I want to change key mappings I have to basically copy the whole of TTA input function. This is what I have done in my (as yet to be accepted) PR for gitui, thats a lot of code. It would be simpler if it was table driven and I could make calls to change default entries in the table
- I dont not think having the key table loaded from a file would be a good idea. Thats not transparent enough for the caller. But the calling app can load from a file and call the table edit functions
- maybe have several different starter key tables. You recognize this need with
input_without_shortcuts
I can certainly make a table driven key dispatcher layered on top of the current TTA architecture and make a PR of that, as a sort of demo (like my tick change)
BTW - I highly recommend gitui, fast tui driven git client. Simple and fast