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

Clarification on event.KeyboardEvent attributes behaviour #12

Closed
FractalWire opened this issue Feb 11, 2019 · 2 comments
Closed

Clarification on event.KeyboardEvent attributes behaviour #12

FractalWire opened this issue Feb 11, 2019 · 2 comments
Assignees

Comments

@FractalWire
Copy link

Hey,

I'm currently implementing an input field, and for this I need some clarification on how the event.KeyboardEvent attributes work.
If I'm not mistaken, the value of a key input should be in sym
Which is neat because I can in theory directly do a chr(event.sym) to put it on my input field.

The thing is, it does not work nicely with meta key (shift,altgr,etc.). And instead of having 'A' when I pressshift+a, I get the value for a
First : is this the intended behaviour ?
With a program like xev (on linux), I can get the keysym value as well, and when i press shift+a the value is definitely A, not a

So, I could get around this by manually modifying the value of sym when a modifier key is pressed (that I get with mod attribute) but that would be a lot of work and there are a lot of keyboard layout out there, so the mapping I'd be doing would work for me, but not necessarily for someone with another keyboard layout.

Is there a work around for this or is it outside the scope of tcod ?

Thanks again !

@HexDecimal HexDecimal self-assigned this Feb 11, 2019
@HexDecimal
Copy link
Collaborator

I'm currently implementing an input field

Input fields should use KeyDown events only for special inputs (return, backspace, etc,) and TextInput events for the actual text input itself. The documentation already mentions using TextInput for name entry fields.

@FractalWire
Copy link
Author

Ah, yes.
Completely missed that one.
It looks like it is working fine with TextInput.

Thanks !

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