Better keyboard handling

[Laurent]

They should only be provided for the letters and numerics, possibly some additional keys, like Esc or the F-Keys. The reason for the need for named identifiers does not apply to the symbol keys, and the programmer is discouraged from using a symbol as a named identifier

So what should I do for keys with punctuation marks, or other symbols? Choose the most "standard" symbol, or define no key code for them?

[Flash]

They should only be provided for the letters and numerics, possibly some additional keys, like Esc or the F-Keys. The reason for the need for named identifiers does not apply to the symbol keys, and the programmer is discouraged from using a symbol as a named identifier

So what should I do for keys with punctuation marks, or other symbols? Choose the most "standard" symbol, or define no key code for them?

As I said, IMO there should be no named key definitions for those keys. There should however be location definitions for them (example with semicolon key).
The reason for the need of named keys is so that keys can be bound according to a named patter (e.g. 't' for target, 'm' for missile, etc.). This reason does not exist for symbolic keys. They are chosen because of their location. If you allowed programmers to do named keybindings on symbolic keys, we would end up with games that have nonsensical key assignments on foreign keyboards. Furthermore, the second problem I mentioned would get much bigger, because there would be even more possible overlap between named and location keybindings.

[Ixrec]

Since I can't find any recent discussions on this with the forum search...

I don't think "named identifiers" can be part of a true solution to international keyboard handling, because any alphanumeric key we're familiar with may not exist on other keyboards, as shown back on page 1 by exploter's Armenian keyboard example:

So even if we wanted to let the programmer bind "missile" to the "m" key or "group 7" to the "7" key, we can't even guarantee there is an m key or a 7 key at all, much less agonize over how to locate it.

To use Flash's terminology: "named keybinding" is simply not possible in general (not even for number keys!), so you need to use "location keybinding" and "named display" for everything.

The only good use for key names is to give developers an easy way of specifying key locations.  In fact, sf::Keyboard already seems to be representing key locations (eg, it has 'A' but no 'a', 'Num1' but no '!').

So in my admittedly uneducated opinion, the best solution is to do the following:
1) add scancodes (which is already happening in 2.2, yay!)
2) add some means of getting a human-readable description of a scancode, ie "named display", since every game with a tutorial or a key bindings menu will need this (and I'm sure you could make something far better than what I've hacked together for my program).  Perhaps a Keyboard::getDescription() method taking a sf::Keyevent or scancode and returning a string.
3) ideally, rename the "code" member of sf::KeyEvent to "location", because that's what it currently is (or at least what it should be going forward); obviously this would have to wait until SFML 3

Regarding the French keyboard number row issue: The value sf::Keyboard::Num1 should represent the physical location that the 1 key is at on a QWERTY keyboard, not the "1" character that may or may not be its default binding on some other keyboard, in which case simply doing if(e.location == sf::Keyboard::Num1) would work just fine.  No extra hassle for the users, and no changes to the public API except renaming that one member someday.


P.S. I'd also like an sf::Joystick::getDescription() someday (the best I can give the user right now is "positive movement along axis 2") though I have no idea how feasible that might be.

[Laurent]

Thanks for your feedback, it is very important with SFML 2.2 approaching (even if it won't include the final solution)

I'd also like an sf::Joystick::getDescription() someday (the best I can give the user right now is "positive movement along axis 2")

A description for what? Axes? They are already clearly identified (X, Y, POV, etc.).

[Ixrec]

I mean strings like "left trigger pressed" or "right analog stick up" for an Xbox controller, etc.  Analogous to how Keyboard::getDescription(sf::Keyboard::Num1) might return "1" for my keyboard and "&" for yours.  But that's another subject, a much lower priority, and (I assume) a much harder feature to implement.

[Laurent]

Indeed, I don't even think it is possible to implement.

Let's go back to the original topic

[Senzaki]

Well, if someone needs scancodes before SFML 2.2 comes out, I implemented their support because I needed them in my project. See this pull request for more details. The way scancodes are translated to "SFML scancodes" is exactly the same as in SDL. (Note : I don't expect it to be directly integrated in SFML, but at least it could give ideas for a better implementation.)

[Flash]

Since I can't find any recent discussions on this with the forum search...

I don't think "named identifiers" can be part of a true solution to international keyboard handling, because any alphanumeric key we're familiar with may not exist on other keyboards, as shown back on page 1 by exploter's Armenian keyboard example:

So even if we wanted to let the programmer bind "missile" to the "m" key or "group 7" to the "7" key, we can't even guarantee there is an m key or a 7 key at all, much less agonize over how to locate it.

To use Flash's terminology: "named keybinding" is simply not possible in general (not even for number keys!), so you need to use "location keybinding" and "named display" for everything.

That is correct, and I have to admit that was a stupid oversight on my part.
However, I already stated that it should be made absolutely clear that if the developer uses named keybindings, he should also offer the possibility to customize keys. So people with a non-latin keyboard would have to customize keys.
Therefore, I still think named keybindings make sense. If you don't allow named keybindings, you only increase the number of people who have to customize.
With named keybindings => everybody without a latin keyboard needs to reassign keys.
Without named keybindgs => everybody without a qwerty keyboard needs to reassign keys.

[Ixrec]

I agree in the sense that I think key locations should be referred to by their QWERTY names (is there any other sensible way to do it?), which implies we'd get named binding support "for free" on QWERTY keyboards.  I see no reason to restrict this implicit support, though it'd be nice if the property was eventually renamed "location" as I suggested so that developers are more likely to realize that any named bindings they use won't work on other keyboards.

I'm a little more skeptical on the idea of supporting named keybinding across all latin keyboards, because this would probably force SFML to answer tricky questions like "is A equal to a?" and "is á equal to a?", or require the programmer to provide equivalence classes for each character.  Not to mention there's always the possibility the a/á/whatever key conflicts with a location binding (I think you said earlier that this is negligible, but it's still nonzero).  And there's even weirder cases: if I ask for the "i" key on a Turkish keyboard, which one do I get?  Dotted i or dotless i?  (you may say obviously the dotted one, but what if I asked for the "I" key instead? should I then get the dotless i key?).  And that's just the complications I can think of off the top of my head.

To sum up: I think named bindings for all latin keyboards would be nice, but I'm not sure it's possible without embedding a lot of extremely arbitrary and fragile rules into SFML.  Putting those rules into an extension might be a good idea though (maybe some extra methods in thor::ActionMap?).

EDIT: It's possible Windows virtual key codes already attempt to do this, so maybe SFML is already inheriting from Windows' built-in arbitrary rules.  No idea about Mac and Linux.  If all three do have something similar, I would be in favor of exposing it in SFML (in addition to scan codes and locations).


P.S. I'm not sure about the claim that necessarily more people "need" to rebind all their keys if developers don't do named keybinding, but that probably depends heavily on the genre.  For the stuff I play (platformers, puzzle games, action games) I find the locations of the keys is infinitely more important than the letters that happen to be on them (eg, WASD have nothing to do with up/left/down/right, and no one minds).  I assume in strategy or simulation games where you have far more keys, there's more benefit to named binding.  Are those the use cases you're thinking of?

[Flash]

To sum up: I think named bindings for all latin keyboards would be nice, but I'm not sure it's possible without embedding a lot of extremely arbitrary and fragile rules into SFML.  Putting those rules into an extension might be a good idea though (maybe some extra methods in thor::ActionMap?).

EDIT: It's possible Windows virtual key codes already attempt to do this, so maybe SFML is already inheriting from Windows' built-in arbitrary rules.  No idea about Mac and Linux.  If all three do have something similar, I would be in favor of exposing it in SFML (in addition to scan codes and locations).

I agree. I wrote about named identifiers:
The operating systems keyboard event should provide those. If they need to be converted to location identifiers (most likely for asynchronous key handling), this should also be done by the operating system (but I don't know if it's possible).
So just to clarify: If it is not possible to do it via the operating system, I wouldn't propose to implement it in SFML. That would indeed induce a lot of headache.

P.S. I'm not sure about the claim that necessarily more people "need" to rebind all their keys if developers don't do named keybinding, but that probably depends heavily on the genre.  For the stuff I play (platformers, puzzle games, action games) I find the locations of the keys is infinitely more important than the letters that happen to be on them (eg, WASD have nothing to do with up/left/down/right, and no one minds).  I assume in strategy or simulation games where you have far more keys, there's more benefit to named binding.  Are those the use cases you're thinking of?

Yes, it is heavily depending on the genre. For a platformer the location is indeed the most important aspect.
Flight & Space sims are the most notorious ones in the other direction. There are games that have two or three function on every key (in combination with CTRL and ALT), and those are usually selected according to their name in order to ease memorization. Here's the example of X-Wing Alliance, which is an arbitrary mix of named and location binding.

[Ixrec]

Flight & Space sims are the most notorious ones in the other direction. There are games that have two or three function on every key (in combination with CTRL and ALT), and those are usually selected according to their name in order to ease memorization. Here's the example of X-Wing Alliance, which is an arbitrary mix of named and location binding.

Thanks for the link.

After looking up tons of keyboard layouts I've come to the conclusion that named bindings for just the letters A-Z are completely safe across all keyboards, assuming the only other bindings used are QWERTY-location bindings for numbers, puncutation and control keys (ie no non-English letters), and assuming those named A-Z bindings fall back to location bindings on systems where the keys do not exist (which SO told me Windows does).

So, since you said that game uses a mix of named and location, do you happen to know if all of its number/punctuation mark bindings are location-based?  And what most other games like this do?

Here's some of the conflicts I found that might occur if someone used named binding for punctuation and/or numbers:

• On the "KazWin" keyboard, . and , are the same key
• On the Serbian keyboard, ; and , are the same key
• On Russian keyboards, 4 and ; are the same key
• On Russian (Typewriter) keyboards, 6 and , are the same key
• On most Central/South American keyboards, Q and @ are the same key
• I'm fairly sure I saw a keyboard whose number row had 1,2,3,4,6, but none of 5,7,8,9,0.  I can't remember which one this was now.

[Flash]

Thanks for the link.

After looking up tons of keyboard layouts I've come to the conclusion that named bindings for just the letters A-Z are completely safe across all keyboards, assuming the only other bindings used are QWERTY-location bindings for numbers, puncutation and control keys (ie no non-English letters), and assuming those named A-Z bindings fall back to location bindings on systems where the keys do not exist (which SO told me Windows does).

I don't think this is correct. As I wrote in my first post in this topic, French AZERTY keyboard have the letter M in the position of the semicolon on a QWERTY keyboard.

So, since you said that game uses a mix of named and location, do you happen to know if all of its number/punctuation mark bindings are location-based?  And what most other games like this do?

I did not express myself very well here. What I meant is that it is clear by the design of the shortcuts to be a mix of name and location. As I said, I don't know any game that actually implements this correctly. All the games I know implement either location keybinding, which makes shortcuts hard to memorize or named keybinding, which is even worse, and forces you to press key combinations for what was intended to be a simple keystroke on some keyboards. I don't know by heart what XWA does, but it does allow re-assignment, so it could be dealt with.

Here's some of the conflicts I found that might occur if someone used named binding for punctuation and/or numbers:

• On the "KazWin" keyboard, . and , are the same key
• On the Serbian keyboard, ; and , are the same key
• On Russian keyboards, 4 and ; are the same key
• On Russian (Typewriter) keyboards, 6 and , are the same key
• On most Central/South American keyboards, Q and @ are the same key
• I'm fairly sure I saw a keyboard whose number row had 1,2,3,4,6, but none of 5,7,8,9,0.  I can't remember which one this was now.

I also said that for this reason I would not suggest including named keybindings for anything beyond alphabet and numbers. There is no reason for their existence (you cannot easily memorize the keystroke, because a punctuation mark is not the beginning of a word), and it only leads to conflicts.
So apart from the last one (which seems really strange to me), those shouldn't be a problem. The only conflict I see thus far is the M / ; conflict, if M is bound by name and ; by location.

[Ixrec]

I don't think this is correct. As I wrote in my first post in this topic, French AZERTY keyboard have the letter M in the position of the semicolon on a QWERTY keyboard.

Damn, missed that one.


Well it seems like we agree on everything that matters anyway.  Maybe future tutorials on keyboard handling should have a big warning about not using named bindings unless you also provide rebinding.

Should we try to make some concrete proposals for how SFML should implement/expose this stuff?  My first thought is simply giving the key event "scancode", "location" and "vkey" properties.

[Flash]

Should we try to make some concrete proposals for how SFML should implement/expose this stuff?  My first thought is simply giving the key event "scancode", "location" and "vkey" properties.

I don't know, I had the impression that Laurent likes to think about those things by himself.
If he wants us to, we can try to make some proposals.

[Nexus]

We always appreciate ideas, that's why Laurent opened this thread

However I don't know how much of the functionality you're currently discussing will make it into SFML 2.2 -- the plan is to release it rather soon, and to add basic scancode support. In a first version, this might entail only unnamed integers that can be used for comparison (key rebinding). This way, we have enough time to discuss all the advantages and drawbacks of different naming possibilites, experiment with them and test them thoroughly, and we don't have to implement a last-minute solution that will soon prove as not ideal.