Better keyboard handling

[Veltas]

I think he's saying "the number keys on a French keyboard should be interpreted like the numbers on normal keyboards, despite them not actually typing numbers when you hit them without modifiers".

[Lo-X]

I think if a strategy game maps unmodified key to a hotkey it always wants the same id the number key on non-french keyboards would give. Then you could still use that hotkey only and the game switches to only select the group and if you press shift it would add to selection.

I'm reading this again and again, but, although it looks ok, I fail to understand it

In a game like Warcraft 3, where '1', '2' '3', ... are mapped to unit control, french keyboard works well (I mean, no need for shift).

From a game developper point of view, we shouldn't return the modified key but the standard key and check if the modifier is pressed. Yes it's a check we have to do but it also allow more flexible things (I think).

Plus, if I understand it well, if we return interpreted keys, there will be a difference between 'a' and 'A' (upper/lower case). In a game, I want my 'a' or capslock+'a' key to do the same, but 'Shift'+'A' to be mapped to any other action I want to.

[Laurent]

In a game like Warcraft 3, where '1', '2' '3', ... are mapped to unit control, french keyboard works well (I mean, no need for shift).

From a game developper point of view, we shouldn't return the modified key but the standard key and check if the modifier is pressed

But how do you know that '1' is pressed on a french keyboard if SFML returns the unmodified key ('&') ? Even if you know that the 'shift' key is pressed, but that won't give you the corresponding modified key ('1').

If we only return the unmodified key, there's no way to know that '1' is pressed on a french keyboard. So we must either change the "default" symbol for some keys (like SDL does), or return all the possible symbols of the pressed key.

Plus, if I understand it well, if we return interpreted keys, there will be a difference between 'a' and 'A' (upper/lower case).

APIs that return interpreted keys usually don't differenciate between upper case and lower case letters. There's only one Key::A constant.

[Lo-X]

But how do you know that '1' is pressed on a french keyboard if SFML returns the unmodified key ('&') ? Even if you know that the 'shift' key is pressed, but that won't give you the corresponding modified key ('1').

If we only return the unmodified key, there's no way to know that '1' is pressed on a french keyboard. So we must either change the "default" symbol for some keys (like SDL does), or return all the possible symbols of the pressed key.

That's what I wanted to say : we should return '1' instead of '&' on french keyboard (or any other keyboard in that case). What I meant in "standard" was "the same for anyone whenever possible".
I don't know how it's coded in any library, so I don't know if it's hard to do.
I just think, what about special keys (symbols, etc..) ? Is there a way to standardise them ? The more I think about it, the more it becomes tricky.

I agree with Nexus to looking at this from a game point of view. Also I know this is not a video game lib. Plus, it's true that hotkeys kinda solve the problem, but it's not always implemented. [I'm going nut here :p ] If I had to chose one of the three models you gave in the first post, I would chose the SDL one.

APIs that return interpreted keys usually don't differenciate between upper case and lower case letters. There's only one Key::A constant.

So that's perfect

[eXpl0it3r]

It seems like I know nothing about foreign keyboards (see here), so I guess one can work on top of a few different layouts.

[Tank]

Let's see what we mostly need in games:

• A value of ANY type (e.g. for mappings keys to actions; could be the scan code)
• A name for that key (the actual character or a descriptive name like "Shift") (e.g. for showing the user which key he pressed)
• A key mapping/type in case it's a special character (tab, control, shift, alt etc.) which is available across different keyboard layouts (smallest subset).

Point 1 is to support any type of keyboard and key. It doesn't matter which key it is. Because point 1 does not give any information about the key itself, there needs to be a descriptive name, or in case of a printable character the character itself. Point 3 gives information about key presses of a pre-defined subset of generally available keys (unprintable keys mostly), so that key combinations can be implemented (Ctrl+A etc.). It could be an enum containing these values for example: PrintableKey, Control, Shift, Tab, ...

Such an event structure allows me to use any key I want, get a name for it for using it visually and interpret keys that are available across all keyboards, e.g. for key combinations.

[Laurent]

Such an event structure allows me to use any key I want, get a name for it for using it visually and interpret keys that are available across all keyboards, e.g. for key combinations.

It still doesn't solve the number keys issue, does it?

[Tank]

I think it does. On your keyboard, the key's name would be "&", on my keyboard it'd be "1". The scan code is completely irrelevant. The key mapping as well, because it's a printable character/no special key.

[Laurent]

So what do you write in your code to refer to that key, so that it works with any layout?

[Tank]

There's no general solution, because it depends on the layout (just like languages/localization).

What you can do however is providing good defaults, either depending on the target system including language (a French installation will probably use a AZERTY-compatible keyboard) and keyboard type (to be honest I don't know if there's a good way of detecting the active keyboard layout on all systems SFML supports).

So in the end it'll be something like this:

keys["de"][Action::JUMP] = "1";
keys["fr"][Action::JUMP] = "&";

[wintertime]

One more try.
The point is to separate your thinking of the different involved things:
1. key on the keyboard (example is key second row at 4th column)
2. the labels on it (american (3, #, nothing) or german (3, §, ³) or french (", 3, #))
3. the character it would produce in combination with formerly pressed dead keys and currently pressed modifier keys (if no modifier is pressed its in many layouts '3' and on some '"')

1. Would be prefered for many games so they dont need to do some guesswork on backwards-translate what the library forward-translated, because they would test a constant of KEY_ROW2_COLUMN4 or KEY_COLUMN4_ROW2 (or for "convenience" a library may call it KEY_3 if its believed by its creator it would apply to the majority of layouts even though it may mean something else on some layouts). The constants may have much in common with the scan code, but there are quirks.
2. It may in some ways be wanted by a game to know what label to print on screen when the key gets pressed, but it gets ambiguous with the many layouts, though it may be convenient in some situations to get KEY_LABELED_3 event always when any key is pressed that includes that label if its primary, secondary or third class. For example a game shows a list labeled 1 to 10 and wants to know when some key with such a label gets pressed (but for that the text-event may be reused instead as an inferior alternative). I'm not sure but this may be got from the VK_ constants in Windows or other things on other OS.
3. Would be the domain of the character text input event, not the key event. And here you would like to get UTF-32 codes.

[Laurent]

Scancodes are great when key bindings are configured by the user itself. But if you want to provide a fixed binding programmatically (sf::Key::Num1 => "select first weapon"), this is still not possible with what you said. Even text events wouldn't help, since they would produce '&' on french keyboards. The only solution to this problem is to somehow provide all the symbols of the key, or force '1' to be the default even if it would normally require a modifier in order to be outputed.

[Tank]

Laurent:
If you replied to my post, then no, the only solution is to provide a set of default values for each layout.

[Laurent]

I was replying to wintertime (sorry it was not clear). Your previous post was explicit enough about the lack of simple solution to this problem

[zsbzsb]

The only solution to this problem is to somehow provide all the symbols of the key

I don't see how that is possible considering the symbols on the physical keys changes depending on the keyboard. For example you have a '&' and a '1' on your first number key, yet on my US layout I have '1' and '!' together on my first key.