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

Numpad Dot not in documentation. #1596

Closed
JonathanILevi opened this issue Jul 2, 2019 · 6 comments
Closed

Numpad Dot not in documentation. #1596

JonathanILevi opened this issue Jul 2, 2019 · 6 comments

Comments

@JonathanILevi
Copy link

The documentation does not have a key code for the numberpad dot. Is this intentional? It comes up as Unknown when it is pressed. The same is true for the numlock and capslock key although this kinda makes sense.

Shouldn't there be a NumpadDot key code?

@minirop
Copy link

minirop commented Jul 2, 2019

I think NumpadDot is not a good name because it's not a dot, but a decimal separator (which is a comma in French for instance). Also, should SFML convert it depending of the locale? (like word/libreoffice do)

@JonathanILevi
Copy link
Author

Whether SFML should convert is another issue.

What would be a better name? NumpadDecimal?

@MyrddinE
Copy link

MyrddinE commented Oct 9, 2019

The code for getting keyboard events only has 101 entries; since modern keyboards usually have 106 keys or more this is not the only key affected. This should be resolved, both for simple convenience and for better accessibility for international and disabled users, who tend to be more likely to use uncommon keys.

@MyrddinE
Copy link

MyrddinE commented Oct 9, 2019

Duplicate of #7

@oznogon
Copy link

oznogon commented Jan 28, 2020

I'd argue for Decimal. For comparison, the MinGW/Wine DInput headers use Decimal, and SFML already (coincidentally?) aligns with those headers in naming numpad math keys Add, Subtract, Multiply, and Divide (and not NumpadAdd, NumpadSubtract, etc.).

@eXpl0it3r
Copy link
Member

Scancodes will provide a lot more keys and keyboard layout independent. After the scancode implementation I'd be willing to look into expanding the existing sf::Keyboard::Key enum.

For now, I'll close this issue and point to the on going Solution Design and open PR #1235

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants