Comments (16)
Right, shouldn't be hard to do. Though I'm not sure about "some special character combinations are not consistent across devices", will this help? Or you mean it should switch to charCode
rather than keyCode
?
from keymage.
The main benefit of attaching to keypress
is that it will give developers the entered character, no matter how it was achieved, eg. it doesn't matter if the end user uses DVORAK layout or whatever the input language might be, so it's not hardcoding against keydown input but rather the resulting character. Which in many cases is much more useful.
As an example, I cannot successfully bind to [
or ]
using keymage for whatever reason, even though they should be uniquely identified according to the keyCode tables that I can find, and I get false negatives (wrong values) with a tool like http://keycode.info/ . This is with a Macbook, QUERTY layout with Finnish/Swedish language input, which should by no means be anything particularly exotic.
from keymage.
Additionally, other characters than the ones hardcoded by the keyCode tables could be supported, such as (
, )
, and so on.
from keymage.
Yeah, but with charCode
hotkeys break if you have multiple keyboard layouts. That's the reason for the keyCodes in my code - it works even with Ukrainian keyboard layout.
from keymage.
It may be that I've misunderstood the root cause of this, it's probably not the difference between keydown
vs keypress
, although keypress might handle special characters easier:
https://github.com/PolicyStat/combokeys/blob/master/helpers/characterFromEvent.js
The issue I guess is that the supported characters are hardcoded here https://github.com/piranha/keymage/blob/master/keymage.js#L29-L82 -- and anything outside of that will not work, so I get
Unknown key "(" in keystring "("
Unknown key ")" in keystring ")"
Unknown key "{" in keystring "{"
Unknown key "}" in keystring "}"
Unknown key """ in keystring """
As well as [
and ]
not working probably since I have them in a nonstandard location for the keyboard layout...
from keymage.
Heh, so let's add them maybe? :-) I'm not surprised something could be missing. :)
from keymage.
Well, depending on your goals with the library, something is bound to be missing eventually... Allowing to match an arbitrary character would be more powerful and probably less code in the end.
from keymage.
If there is a way to match an arbitrary character to a keyCode, I'd all for that! But switching to charCode
is something I can't do - because this will break hotkeys for all the non-roman keyboard layouts.
from keymage.
Not sure how to handle this situation, really. I need to think a bit. :)
If you have any ideas except for dropping keyCode
in favor of charCode
completely - I'm very interested. :)
from keymage.
Not 100% sure, but I don't think changing keyCode
to charCode
would be necessary.
The problem currently as I see it is that you're hardcoding which characters to accept in lines https://github.com/piranha/keymage/blob/master/keymage.js#L29-L82 -- from what I can quickly gather from the comboKeys implementation (linked above, as well as https://github.com/avocode/combokeys/blob/master/helpers/special-characters-map.js and https://github.com/avocode/combokeys/blob/master/helpers/special-keys-map.js ) is that you only need to take care of the special characters, the rest already work (with String.fromCharCode
).
Removing this check https://github.com/piranha/keymage/blob/master/keymage.js#L103 and maybe if necessary some changes in dispatch
would probably be enough to match arbitrary characters received from String.fromCharCode
.
from keymage.
I'm sorry being so slow here. :-) So what you propose more or less is:
- store
char
instead ofcode
inparseKeyString
if it's unknown - parse incoming event with
String.fromCharCode(e.keyCode)
- match that after trying to match by
keyCode
Like that? :) Or maybe parsing unknown keys in parseKeyString
with String.charCodeAt
? What do you think about that one?
from keymage.
- store char instead of code in parseKeyString if it's unknown
- parse incoming event with String.fromCharCode(e.keyCode)
- match that after trying to match by keyCode
Based on the combokeys approach I think this should probably work fine.
Or maybe parsing unknown keys in parseKeyString with String.charCodeAt?
This is probably also needed for storing character data instead of the keyCodes (first bullet point above)
With the above, as indicated in the linked combokeys files, it's probably also unnecessary to handle the alphabet characters as a special case, unless that's something that for some reason would be required for non-Roman keyboard layouts (?).
from keymage.
Interesting question: are the keycodes of the keys you're trying to use in the source code at all? You can check keycode at http://keycode.info
from keymage.
The opening and closing square bracket ([
and ]
) match in some cases if I release the keys in the right combination, but I have remapped these. I have the altGr
key combos for all the bracket keys in muscle memory and program on both linux and macs almost daily, so it's in a non-standard location for macs.
Parentheses (()
) don't seem to be there at all AFAICT, since I get the numeric keys even with the shift key pressed. Looking at some tables, these map to keyCode 40 & 41 which are not directly accessible with this layout, it seems.
For me, the comboKeys implementation just works for the keys I needed support for.
from keymage.
I've done some further testing, and have come to the conclusion that it's not possible to get 100% accurate results from keydown
events after all. You can see my test here https://jsbin.com/pemipo/edit?html,js,output -- with the alternative keydown
approach in lines 21-91 in the jsbin javascript source it's very close to getting the correct character, but I've found that the end results are correct for windows/linux keyboard layouts but not macs. keypress
seems to always return the correct character input, even when complicated chording (fe. multiple modifier keys pressed) is tried.
The above test reinforces my original understanding that any printable character should be handled with keypress
, but this might be well outside the intended scope of this library. I have started implementing my own tool that is more focused on keypress
events. This issue and the other one about a target DOM element can be closed if you have no intent of implementing them.
from keymage.
Right, it seems you either can support qwerty + dvorak, or qwerty + йцукен, but not both simultaneously. :( So it's just comes to choice whatever you want to support...
from keymage.
Related Issues (13)
- Does not fully override browser hotkeys HOT 5
- Make bindings for blessed HOT 1
- Add meta HOT 3
- Disable while text field is focused? HOT 5
- Use with specific DOM element, don't attach to window HOT 4
- Can't bind listener for the "Shift" key only HOT 2
- KeyboardEvent.keyCode deprecated HOT 1
- Add a tag HOT 9
- Travis-CI integration HOT 1
- Publish to NPM HOT 12
- Allow to unbind key events HOT 3
- Return prepared unbind()-function from keymage() HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from keymage.