Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add initial function calls from strings & discard useless keys
- Loading branch information
1 parent
7a9c835
commit ceb6e32
Showing
1 changed file
with
43 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ceb6e32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting keys[] to a string will produce odd results for special keys.
the .key value of backspace is "Backspace", for example.
ceb6e32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It mostly works OK at the moment: the entire key is dropped if it doesn't match something, in one go.
The main problem is that it will stop people binding things to some capital letters (e.g. S for Shift).
The current method has the added bonus that you can type the key out - "B a c k s p a c e".
I'm unsure how much of this should go in Tridactyl, and how much should be in the keyboard API. It might make more sense if the keyboard API sent keycodes?
Otherwise, we could fix this by prepending a special character to any .key with length greater than 1, e.g something in Unicode like 🄰.
ceb6e32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having "Shi" be kept because it could map to "Shift" is clearly bonkers. Prefixing with an untypeable character is OK, but should be done by API consumers, not the API.
Keyboard API will send a shallow copy of the keyboardevent, but
.code
is not appropriate for finding 'Shift' and friends: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/codeWe'll just want to drop all the modifier keys anyway: we don't want users to map Shift or Control on their own, we just want them as modifier keys (which is detected with e.g. keyevent.ctrlKey property).
Arrow keys, backspace, etc. we will want to be mappable.
To think about:
.key
names)?ceb6e32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dumb, but for me a very important question: why don't we want user to map Shift or Control on their own?
I have already come across special use cases (especially when one wants something cross platform), when exactly mapping modifiers was the only or at least the best solution.
ceb6e32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're trying to move discussion to #3
So I'll reply in both places then lock this.
When ctrl+s is pressed, browsers generate a ctrl keydown event, then a keydown event with
.key === 's'
and.ctrlKey === true
, then keyup events for each.If the user was allowed to bind ctrl with no modifier then they would face the surprising situation of Ctrl+s triggering the maps for both Ctrl and Ctrl+s.
This can be solved, but it would complicate the parser significantly by introducing a notion of timeliness.