The option names in "Modifier Keys" dialog are incorrect

[rq]

I wanted to make my keys somewhat compatible with Windows and Linux, that is:

Alt keys act as Opt Ctrl keys act as Cmd Cmd/Win keys act as Ctrl (since I can't make the same key act as both Ctrl and Cmd)

I found that nice dialog, but figuring out what to change to what in it was quite a challenge, because it seems to assume that keyboards are actually engraved the way BeOS defaults expected them to be, which is, well, never the case. While it would seem perfectly logical for me to see this mapping:

Option -> Option Control -> Command Command -> Control

I ended up with:

Control -> Option Option -> Command Command -> Control

which doesn't make much sense at all. For it to make sense, one has to know that Haiku's Command is actually Alt, and Haiku's Option is actually Command, but only on the left-hand-side, because on the right-hand side Option and Command are reversed for users of AltGr.

I recommend to: 1) make it more obvious which side of mapping is the physical keyboard and which is the keymap used by Haiku. Since that list looks like a table, something like table heading could be used, such as: Function:\tKey: . 2) change button names in drop-downs to reflect the reality: swap names of Command and Option, and rename Option to Alt and perhaps Command to Win (I know I know, Mac users will be unhappy "Win/Cmd" would be an alternative).

[rq]

Rewriting because Trac stripped all my newlines:

I wanted to make my keys somewhat compatible with Windows and Linux, that is:

Alt keys act as Opt
Ctrl keys act as Cmd
Cmd/Win keys act as Ctrl (since I can't make the same key act as both Ctrl and Cmd)

I found that nice dialog, but figuring out what to change to what in it was quite a challenge, because it seems to assume that keyboards are actually engraved the way BeOS defaults expected them to be, which is, well, never the case. While it would seem perfectly logical for me to see this mapping:

Option -> Option
Control -> Command
Command -> Control

I ended up with:

Control -> Option
Option -> Command
Command -> Control

which doesn't make much sense at all. For it to make sense, one has to know that Haiku's Command is actually Alt, and Haiku's Option is actually Command, but only on the left-hand-side, because on the right-hand side Option and Command are reversed for users of AltGr.

I recommend to:
1) make it more obvious which side of mapping is the physical keyboard and which is the keymap used by Haiku. Since that list looks like a table, something like table heading could be used, such as: Function:\tKey: .
2) change button names in drop-downs to reflect the reality: swap names of Command and Option, and rename Option to Alt and perhaps Command to Win (I know I know, Mac users will be unhappy "Win/Cmd" would be an alternative).

[jscipione]

The names in the Modifier keys dialog are correct. They correspond to the role of the key, Control => B_CONTROL_KEY, Option => B_OPTION_KEY, Command => B_COMMAND_KEY which corresponds to the labels on the on-screen keyboard. The Modifier keys window allows you to reassign which keys on your keyboard correspond to which key role on the left and right side simultaneously.

"The right-hand side Option and Command keys are reversed for users of AltGr." The question is why? This makes no sense to me. If simply should not be, left command should be the same as right command, left option should be the same as right option, switching them is quite confusing.

Several of the keymaps are doing this now, and my design for the Modifier keys windows did not take that into account because I didn't know about it. Now I am trying to figure out if I should modify the Modifier keys window to take this anomaly into account or not.

Either way, the Modifier keys dialog box works as intended.

[anevilyak]

Replying to jscipione:

"The right-hand side Option and Command keys are reversed for users of AltGr." The question is why? This makes no sense to me. If simply should not be, left command should be the same as right command, left option should be the same as right option, switching them is quite confusing.

The reason is, on most of those keyboards, the right Alt is labelled Alt Gr and is the one that's used to generated modified key sequences such as accented characters. Since B_COMMAND_KEY does not do this in Haiku, a different function must be assigned to that key in order to serve its intended function.

[jscipione]

Replying to anevilyak:

B_COMMAND_KEY does not do this in Haiku

Exactly.

[rq]

Replying to jscipione:

The names in the Modifier keys dialog are correct. They correspond to the role of the key, Control => B_CONTROL_KEY, Option => B_OPTION_KEY, Command => B_COMMAND_KEY which corresponds to the labels on the on-screen keyboard. The Modifier keys window allows you to reassign which keys on your keyboard correspond to which key role on the left and right side simultaneously.

This makes sense, but only for the "assigned function" side. The other side (hardware keys) is NOT labeled BeOS way, and I would expect it that when I assign say Option function to the Option key, it's Alt keys that are affected, not the Win-keys, which act as Function by default for some reasons I can never agree with, but that's a subject for another issue. I would also prefer the physical keys to be called the way they are usually labelled on the keyboard (that is Alt instead of Option, and perhaps Win instead of Command).

"The right-hand side Option and Command keys are reversed for users of AltGr." The question is why? This makes no sense to me. If simply should not be, left command should be the same as right command, left option should be the same as right option, switching them is quite confusing.

Several of the keymaps are doing this now, and my design for the Modifier keys windows did not take that into account because I didn't know about it.

I personally like that, although others may disagree.

Now I am trying to figure out if I should modify the Modifier keys window to take this anomaly into account or not.

Either way, the Modifier keys dialog box works as intended.

Please try to understand my position too. If it took me a few minutes of trial and error to figure out what changes what. I doubt that was intended. MI believe my report is still valid. I'm not asking you to change the key names used in Haiku, but ONLY those that correspond to a physical keyboard.

[jscipione]

Replying to rq:

Please try to understand my position too. If it took me a few minutes of trial and error to figure out what changes what. I doubt that was intended. MI believe my report is still valid. I'm not asking you to change the key names used in Haiku, but ONLY those that correspond to a physical keyboard.

Ahh, but with internationalization and different keyboards it is impossible to say what label appears on each key on your keyboard.

[rq]

Replying to jscipione:

Ahh, but with internationalization and different keyboards it is impossible to say what label appears on each key on your keyboard.

Aren't they localizable? If not, they should be. ;)

[jscipione]

Should now be finally fixed in hrev43956

[rq]

John, the dialog now looks great and is indeed much more usable, thanks!

May I suggest a further improvement? I think it would make more sense to swap the columns and turn Key Roles instead of Keys into dropdowns. This would prevent assignment conflicts (where two roles are assigned to same keys), yet would allow to assign same role for more than one key, if anyone for any reason would ever want that (you could still issue a warning if the user would try to save such settings, but it would be a warning, not an error).

[jscipione]

Replying to rq:

May I suggest a further improvement? I think it would make more sense to swap the columns and turn Key Roles instead of Keys into dropdowns. This would prevent assignment conflicts (where two roles are assigned to same keys), yet would allow to assign same role for more than one key, if anyone for any reason would ever want that (you could still issue a warning if the user would try to save such settings, but it would be a warning, not an error).

I originally wanted to have the Key column on the left and the Key Roles column on the right (reverse of now) but I couldn't get that to work. That being said, the current behavior seems logical to me.

The Keyboard Layouts assume that each key is defined exactly 1 time, so one set of Shift keys, one set of Control keys, one set of Option keys, one set of Command keys. While you could repeat a set of keys and it would work as far as pushing the keys goes, it wouldn't display correctly in Keymap. Given that and also that defining a key role more than once purposely would be rare it isn't worth it to allow you to do this from the Modifier Keys dialog.

However, the reason I took Caps Lock out from the dialog was exactly that, if you defined Caps Lock as Ctrl for instance the Caps Lock key wouldn't show up in the display as Control assuming you also had control defined.

Perhaps someday I'll allow you to map Caps Lock to control (or another modifier) in the regular dialog instead, and also update the Keyboard Layout so that the display shows correctly. At that point not only do you have a custom keymap, you also have a custom keyboard layout. So, before that could work I would have to support having a custom keyboard layout and checking a "Custom" option in the Layout menu.

However, AltGr is a much more important feature to implement so I'll be focusing on that next.

[jscipione]

Fixed in hrev43956