Keymap Modifiers Menu with Mac Modifiers Option

[jscipione]

This ticket provides an enhancement to the Keymap preference application that changes the "Switch Shortcuts to Windows/Linux Mode" button to a "Set modifier keys" drop down menu. This menu has 4 options:

• Haiku modifiers (default)
• Windows/Linux modifiers (swaps control and command)
• Mac modifiers (swaps command and option).
• Custom (only shows up if you manually manipulate the keymap)

This is what the menu looks like normally:

The new option here is Mac modifiers. This menu item will switch the command and option keys on your keyboard which is a useful thing to do if you are using a Mac keyboard on Haiku (as I am) because the relative positions of the buttons are physically reversed from those on a PC keyboard. This could also be modified in a keymap file but this is a more user friendly way to take care of the problem. Also if you are using a Mac keymap (that switches the command and option keys for you) then the menu will automatically be set to "Mac modifiers" for you. You then have the option to choose "Haiku modifiers" if you want to reverse them again.

This is what the menu looks like when you manually manipulate the keymap in some custom way (in this case I swapped the left control and caps lock keys):

A "custom" option is added to the menu and it is selected. If you choose one of the other options the keymap application does its best to place the modifiers in the mode you asked for, although with a custom keymap some manual manipulation may be required. In this case the keymap application doesn't put the caps lock key back to its original location. However, you can drag and drop the key back to its default location. The rest of the modifiers are in their correct position and even the left control key is hidden under the caps lock key in the correct position.

The patch below also makes another minor change. It modifies the Deadkeys menu to be a BMenu instead of a BPopupMenu. The only difference between the two in this case is that the menu pops up below the mouse cursor instead of right under it like this:

[jscipione]

Keymap Modifiers Menu

[jscipione]

Keymap Modifiers Menu custom

[jscipione]

Keymap Deadkeys Menu

[jscipione]

Same thing but as the other image but I forgot to include the extension in the description

[jscipione]

Same thing but as the other image but I forgot to include the extension in the description

[jscipione]

Same thing but as the other image but I forgot to include the extension in the description

[jscipione]

Replaces the "Switch Shortcuts to Windows/Linux" button with a drop down that switches between Haiku modifiers, Windows/Linux modifiers, and Mac modifiers.

[axeld]

IIRC Mac keyboards are different from normal keyboards, and therefore usually have their own keymap to deal with them. And this keymap should already take care of having the command/option/alt key where they belong on the Mac. I think this change would make changing the keys unnecessarily complicated.

BTW, there is really no need to put a screenshot for everything in here. In this particular case, I find all screenshots pretty much superfluous.

[axeld]

Ideally, with keyboards connected through USB (which I think Mac keyboards always are), Haiku would detect the keyboard on its own, anyway, and could default to a Mac keymap in this case.

[jscipione]

Replying to axeld:

IIRC Mac keyboards are different from normal keyboards, and therefore usually have their own keymap to deal with them. And this keymap should already take care of having the command/option/alt key where they belong on the Mac. I think this change would make changing the keys unnecessarily complicated.

Mac keyboards are a bit different from PC keyboards, yes, but they are mostly the same. The only major differences are the modifier keys the numeric keypad is laid out a bit differently. In an ideal world I agree with you that a Mac keyboard would be automatically detected and have the appropriate keymap assigned to it. However, the drop-down added in this ticket is to aid the user when this ideal case does not occur. For example there is no (Mac) keymap file currently for my locale (US). And if the keymap does get automatically get detected and applied for the user then the drop down will have "Mac modifiers" selected. So in addition the user is given feedback.

BTW, there is really no need to put a screenshot for everything in here. In this particular case, I find all screenshots pretty much superfluous.

Sorry, I put screenshots in only to try to aid understanding. I was worried that people wouldn't "see" the feature from the description alone. I still think it is hard to "see" the feature even with the screenshots. You have to apply the patch and try it out to really see how it works. But, I agree that the screenshots are a bit gregarious especially because they are wider than the normal page size. I will tone down the screenshots in the future.

[jscipione]

The other day I was reading the following article: ​http://arstechnica.com/hardware/news/2011/09/ultrabook-intels-300-million-plan-to-beat-apple-at-its-own-game.ars

The article on Ars Technica by Peter Bright is about a guy who won't use a Mac laptop because he prefers the UK keymap found on PCs (BS 4822) to the one on the Mac UK keyboard. He includes some nice screenshots highlighting the differences between the 2 keyboards in the article. This is a perfect example of when someone would want to use the PC UK layout on a Mac keyboard rather than the Mac UK layout, but, would also want to flip the command and option modifier keys, thus invoking the functionality presented in this ticket.

Besides, flipping between Haiku mode and Windows/Linux mode makes no sense on a Mac keyboard, it becomes a ternary choice rather than a binary one.

[jscipione]

This patch changes "Set modifier keys" to "Select modifier keys". Since I can't reliably return you to a known state if you have custom keymaps set I simply disable the other menu options in this case. So you can switch between Haiku mode, Win/LInux mode, and Mac mode freely, but if you do something custom you are on your own.

[axeld]

No, this doesn't make any sense. What we should do is to have a Mac-mode identifier in a keymap that makes the switch button disappear -- it's just a convenience button, anyway, you can easily change the roles with the panel as well, so we don't need to accommodate every rare use case out there.

[jscipione]

Replying to axeld:

No, this doesn't make any sense. What we should do is to have a Mac-mode identifier in a keymap that makes the switch button disappear

Or better yet just automatically detect that you have a Mac keyboard plugged in, switch the modifiers and hide the button. But without the drop-down there would be no user feedback as to what had happened nor any easy way to undo the changes. Is that acceptable?

[axeld]

A Mac keyboard isn't just about switching the modifiers. You would need to have a "* (Mac)" equivalent of your keymap, and that one might be automatically selected (which takes care of the any mapping changes).

The these keymaps, the button could be hidden, as it's pretty much useless (although I could imagine a bug report "hey, this button is sometimes not visible"). Using separate keymaps, the user feedback would be quite sufficient.

[jscipione]

Replying to axeld:

A Mac keyboard isn't just about switching the modifiers. You would need to have a "* (Mac)" equivalent of your keymap, and that one might be automatically selected (which takes care of the any mapping changes).

Bullshit, the "* (Mac)" keymaps are a hack and should be removed. Creating a special "* Mac" variation for each keymap is redundant. Instead, we should detect whether or not you are using a Mac keyboard, and if so, make the appropriate adjustments. We can detect whether or not you are using a Mac keyboard by probing the USB devices and look for a device with vendor ID 0x05ac (Apple, Inc.) and device ID 0x0201-0x02ff (keyboards).

When a Mac keyboard is detected the unmodified B_COMMMAND and B_OPTION codes are reversed (B_LEFT_OPTION = 0x5d, B_LEFT_COMMAND = 0x66, B_RIGHT_OPTION = 0x5f, B_RIGHT_COMMAND = 0x67), the numeric keypad equals key code (0x6a) is mapped, and the upper F keys (F13-F19) are mapped. All other keys use the same keycodes as a PC keyboard. We may also want to apply the same hack that Virtual Box uses to map F14 to Print Screen.

The Menu key, not present on a Mac keyboard would need to be simulated. However, this is already needed for 101-key keyboards anyway and I am pretty sure that BeOS 5 provided a solution for this that we should simply copy.

The these keymaps, the button could be hidden, as it's pretty much useless (although I could imagine a bug report "hey, this button is sometimes not visible"). Using separate keymaps, the user feedback would be quite sufficient.

If the above solution were to be implemented then the Switch Modifiers button would indeed become superfluous and could be hidden. The button is a hack to placate Windows users after all. The patches on this ticket would also be rendered useless.

[jscipione]

Sorry for the swear, after re-reading I think we are mostly in agreement. I was just upset by the suggestion that the "* (Mac)" keymaps are a good solution to the problem of detecting Mac keyboard differences.

[axeld]

Replying to jscipione:

Replying to axeld:

A Mac keyboard isn't just about switching the modifiers. You would need to have a "* (Mac)" equivalent of your keymap, and that one might be automatically selected (which takes care of the any mapping changes).

Bullshit, the "* (Mac)" keymaps are a hack and should be removed.

Nope, I'm afraid you are on the wrong track here...

[...] All other keys use the same keycodes as a PC keyboard.

... while that is true, that doesn't affect the keymap at all. The Apple keymap layout is often different from a regular one, and needs a "* (Mac)" keymap alternative. Just to give you a simple example: the '@' symbol is (IIRC) Alt-l on a German Mac, but AltGr-Q on a regular keymap. And that's just one difference out of many. Finding the backslash on a German Mac keyboard is a challenge.

While the standard US keymap might be automatically translated into a Mac keyboard keymap, that's likely to actually be the exception rather than the rule. And if that's the case (which we would need to verify, though), then it's not worth to do that IMO, but one should rather automatically choose the Mac keymap alternatives.

BTW your apology about the tone is appreciated.

If the above solution were to be implemented then the Switch Modifiers button would indeed become superfluous and could be hidden. The button is a hack to placate Windows users after all. The patches on this ticket would also be rendered useless.

Yeah, sorry for that, but I guess it's for the better ;-) It's not just for Windows users, but also for Linux users, though. Or probably pretty much any other OS on a PC, for that matter; Windows just happen to be the most common one.

[jscipione]

Replying to axeld:

... while that is true, that doesn't affect the keymap at all. The Apple keymap layout is often different from a regular one, and needs a "* (Mac)" keymap alternative. Just to give you a simple example: the '@' symbol is (IIRC) Alt-l on a German Mac, but AltGr-Q on a regular keymap. And that's just one difference out of many. Finding the backslash on a German Mac keyboard is a challenge.

I might have been a bit hasty in saying that all the "* (Mac)" keymaps should be removed outright. I'll concede that you do need a "* (Mac)" keymap file to detail the special differences between a PC keyboard and Mac keyboard in some locales. But, you should not need a special "* (Mac)" keymap just get the differences that are common to all Mac keyboards vs. PC keyboards. That should be "baked in".

While the standard US keymap might be automatically translated into a Mac keyboard keymap, that's likely to actually be the exception rather than the rule. And if that's the case (which we would need to verify, though), then it's not worth to do that IMO, but one should rather automatically choose the Mac keymap alternatives.

If the common Mac differences are "baked in" then you only need a "* (Mac)" keymap version for keyboards that have yet more differences like you mentioned above. Out of the 60 or so non-Mac keymap files that exist right now, how many need a "* (Mac)" equivalent? I'd guess around 20 of them. A 66% reduction in the number of keymap files seems worth it to me. Even if it is only a 20% reduction it is still worth it IMHO.

BTW your apology about the tone is appreciated.

I lost my head there for a second. I realize that you are only trying to help.

If the above solution were to be implemented... The patches on this ticket would also be rendered useless.

Yeah, sorry for that, but I guess it's for the better ;-)

The code is useful to me anyway even if it is not generally applicable. I've come to realize that adding a hack to a hack is not a great solution to this problem anyway, it must be fixed on a more fundamental level.

It's not just for Windows users, but also for Linux users.

well KDE/Gnome users anyway...

[jscipione]

Sadly, the patches on this ticket were not meant to be.