Opened 14 years ago

Last modified 4 years ago

#6362 assigned enhancement

Keyboard key names in keymap preflet should reflect actual keyboard

Reported by: rq Owned by: nobody
Priority: normal Milestone: R1.1
Component: Preferences/Keymap Version: R1/alpha2
Keywords: input-server Cc: starsseed@…
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (1)

haiku keyboard.PNG (17.9 KB ) - added by rq 14 years ago.
Screenshot of the keys in question

Download all attachments as: .zip

Change History (9)

by rq, 14 years ago

Attachment: haiku keyboard.PNG added

Screenshot of the keys in question

comment:1 by axeld, 14 years ago

Resolution: invalid
Status: newclosed

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.

comment:2 by rq, 14 years ago

Resolution: invalid
Status: closedreopened

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.

comment:3 by anevilyak, 14 years ago

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.

comment:4 by starsseed, 14 years ago

Keywords: input-server added
Type: bugenhancement

Some languages needs support 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 !

Last edited 14 years ago by starsseed (previous) (diff)

comment:5 by starsseed, 14 years ago

Cc: starsseed@… added

comment:6 by rq, 14 years ago

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.

comment:7 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: reopenedassigned

comment:8 by pulkomandy, 4 years ago

Milestone: R1R1.1
Note: See TracTickets for help on using tickets.