Keyboard key names in keymap preflet should reflect actual keyboard

[rq]

The key names in the keyboard shown in keymap preflet currently reflect their function, but not their actual names as printed on keyboard (I'm talking about the PC keyboards). Plus, Cmd and Ctrl shuffle their positions when I change from BeOS to Linux/Windows shortcuts. This shouldn't happen either.

I suggest that those names should actually reflect the usual physical keyboard layout, and not their function.

[rq]

Screenshot of the keys in question

[axeld]

Keymap never shows the actual keys, but always their "function" or in other words, mapping to how it's used in the system. That's what it's all about, changing this for the modifiers in question would only be inconsistent, and would not serve any purpose -- you should know how the keys on your keyboard are labeled, you don't need an application for that.

[rq]

Axel, I really don't see an advantage in current scheme. Abbreviations like CMD, OPT, and CTRL (in this particular meaning) may make sense to you, but not to average users. Heck, I don't even know what CTRL means in Haiku!

The idea is nice though, but perhaps this visualization could be imlemented differently, by using different colors, for example?

Please don't kill this bug, at least not without a proper discussion.

[anevilyak]

There's not really much to discuss here, the reason the keymap applet uses those is, as Axel pointed out, what actual function those keys will perform in Haiku. It makes no sense to say Alt since the keymap could just as easily let me make that key say 'a' or 'b' when hit. The representations they're given now indicate what they'll actually do, and are also the representations used in things like menu items to indicate what key combination to hit as an accelerator shortcut. Putting alt in the keymap instead would completely remove your ability to associate that.

[starsseed]

Some languages needs for special characters and since <ALTgr> is missing, we need to switch keys, as workaround.

IMHO : We'll need to think about improving support for <ALT> / <ALTgr> distinction in the input server for

• keymap consistency
• a correct support for Bépo, Dvorak, French, German, spanish keymap...

=>some stuff for R2 milestone !

[rq]

anevilyak said:

There's not really much to discuss here, the reason the keymap applet uses those is, as Axel pointed out, what actual function those keys will perform in Haiku. It makes no sense to say Alt since the keymap could just as easily let me make that key say 'a' or 'b' when hit.

Well, not really. I just tried to assign letters to some of those keys and the only one that allowed me do it was the unassigned Win key.

The representations they're given now indicate what they'll actually do, and are also the representations used in things like menu items to indicate what key combination to hit as an accelerator shortcut. Putting alt in the keymap would completely remove your ability to associate that.

This is wrong again, because the representations used in menu items change when I switch between Haiku and Win/Lin-like (Ctrl) shortcuts. And they never say CMD, but say either ALT or CTRL instead.

However, I see what you mean, and thanks for the explanation. But I think we should put some more thought into making those functions distinguishable and at the same time not causing an impression that we have no idea which physical keys the user has in which places.

Perhaps we could put some short explanatory text below the image? In that case, we could also distinguish keys by color, e.g. use green instead of CMD (and leave the original printed label greyed out), orange instead of OPT and so on.

starsseed said:

IMHO : We'll need to think about improving support for <ALT> / <ALTgr> distinction in the input server

Agreed. Though currently, it's more mac-like where both OPT keys act like AltGr. By the way, I raised this in #6364. You may want to comment there too.