Update menu modifier images to more accurately reflect the corresponding key that appears on the keyboard

[jscipione]

This ticket details an enhancement to update the menu to make the modifier key images that show on it more accurately resemble the corresponding key on the keyboard. Currently there are 4 images, a "SHFT" image, a "CTL" image, an "ALT" image, and an "OPT" image.

Of these 4 the only one that is not a problem is "ALT" since there is a key with the word "Alt" on it on almost every keyboard I've looked at, Mac keyboards, Windows keyboards, US keyboards, International keyboards, even laptop keyboards.

"CTL" and "SHFT" are pretty good but most keyboards have the words "Ctrl" and "Shift" on them instead. Take a moment to look at your keyboard to verify.

I updated the bitmaps to add an "R" to the CTL bitmap and an "I" to the SHIFT bitmap. This can be seen in the screenshot below:

This screenshot was taken with the modifier keys switched to "Windows/Linux" mode in the keymaps preference app.

The "I" in the SHIFT bitmap costs a couple pixels increasing the bitmaps width from 20 pixels to 22 pixels. The "R" In CTRL increased the width of the bitmap from 16 to 20 pixels.

So far this has just been a minor enhancement. The real problem is the OPT bitmap. What is the option key? It doesn't appear anywhere on the keyboard! Of course the option key refers to the "Windows" key. So I made a bitmap that resembles the Windows key. It can be seen in the screenshot below:

I created this screenshot by switching the command and option keys in the keymap preference application in "Haiku Mode" and then doing a bit of work in the menu to make it show this bitmap instead of the "CTL" bitmap. Of course this is not realistic but the Windows key aka "OPT" shows up in other places.

Now, the Windows Key bitmap in the screenshot above accurately represents the label on the Windows key, but, unfortunately may also violate the Windows trademark so I made a more generic version of the bitmap that should be less legally tenuous:

Personally I like aesthetics of the first bitmap better but I understand that it may create legal problems. I am up to suggestions on how to create a bitmap that is both recognizable as the Windows key and doesn't violate Microsoft's trademark. One thought is to just make a bitmap labeled "WIN" instead. Of course the user would have to know that "WIN" refers to the Windows key, and if they don't, then the label is little better than the original "OPT" label.

Lastly, if you are on a Mac keyboard you don't have a Windows key, instead you have a Command key that has a clover (⌘) symbol on it. This can be seen in the screenshot below.

Luckily the Clover symbol isn't trademarked by Apple AFAIK so it doesn't have the same legal issues surrounding it as the Windows key. If a symbol is undesired the clover could be replaced by a "CMD" bitmap since Mac keyboards also tend to have the word "Command" written on them.

[jscipione]

Updated Shift and Ctrl Menu Bitmaps adding an "I" to "SHFT" and an "R" to "CTL"

[jscipione]

Windows Key Menu Bitmap

[jscipione]

Generic Windows key menu bitmap

[jscipione]

Command key menu bitmap

[axeld]

I don't want to see the windows key in my Haiku windows ;-)

Seriously, though, I think this is a bit overkill - a description of the keys in the user guide is completely enough, and even better, since the keys don't just look the same everywhere. For example, on a German keyboard, shift is generally just an upwards arrow, and control is "Strg", the abbreviation of the translation of "Control" (ie. "Steuerung").

I think the "Ctl" -> "Ctrl", and "Shft" -> "Shift" changes are okay, though.

[biffuz]

AFAIK, the Windows logo is copyrighted. To use on keyboards, makers have to follow MS guidelines. And who wants it, anyway? :) See also ​http://en.wikipedia.org/wiki/Win_key

[Disreali]

Fixing the spelling of the 'Shift' and 'Ctrl' keys is fine, though not needed..

I really do not like the Windows nor clover images and most definitely do not want them in Haiku's menu's. It looks bad and if people really get confused they can look up the key setting in the user guide.

[jscipione]

Replying to Disreali:

I really do not like the Windows nor clover images and most definitely do not want them in Haiku's menu's. It looks bad and...

I agree with you that the Windows image look bad. How about just the words "WIN" and "CMD" instead?

[Disreali]

I understand your reasoning for the change, but not everyone has a "Windows(tm)" keyboard. I have a 'super' key on my current one and a 'penguin key' on another. Personally, I would like to have the command key to remain as is.

[jscipione]

Replying to Disreali:

I understand your reasoning for the change, but not everyone has a "Windows(tm)" keyboard. I have a 'super' key on my current one and a 'penguin key' on another.

Well, I think most people do have a "Windows(tm)" keyboard and we should aim for the common case. You can please some of the people some of time and all that. The 'penguin key' is probably made by a manufacturer who didn't want to pay to get the logo certification from Microsoft or just has a Linux bent. The 'super' key, I have no idea. I guess there really is no ideal solution for this. We could stay with "OPT" I suppose if there really is nothing better.

Personally, I would like to have the command key to remain as is.

Do you mean remain as it is above, i.e. the clover symbol, or remain as it is in the source i.e. "OPT"?

[biffuz]

Replying to jscipione:

We could stay with "OPT" I suppose if there really is nothing better.

OPT was used in place of ALT on old Mac keyboards, that's way it used this name in BeOS. But modern x86 Macs no longer use OPT, only ALT. So, OPT is definitively wrong and misleading - at least until we don't have a working Haiku for PPC Macs :) WIN is better suited and everybody will understand it - including recent Mac owners who have CMD and the clover on that key; slightly older Macs have the Apple logo and the clover. See the picture of my 2006 MacBook compared with the 2008 model: ​http://www.biffuz.it/misc/macbooks.jpg

[jscipione]

Replying to biffuz:

OPT was used in place of ALT on old Mac keyboards, that's way it used this name in BeOS. But modern x86 Macs no longer use OPT, only ALT. So, OPT is definitively wrong and misleading - at least until we don't have a working Haiku for PPC Macs :)

That is exactly the kind of confusion this ticket is trying to address. It is not just wrong and misleading because Mac keyboards don't always have the word "option" written on the key, it is also wrong and misleading because Mac keyboards that do have "option" written on the key don't refer to the "OPT" menu item! That menu item instead refers to the Command key.

To sum up, the "ALT" menu item is great, it matches just about every keyboard, Mac and PC, "OPT" however is bad, confusing and misleading and should be replaced. Now the question is what to replace it with, especially on PC keyboards where there is less consensus as to what is on the key and what it is called, "Windows", "Super", etc.

WIN is better suited and everybody will understand it - including recent Mac owners who have CMD and the clover on that key; slightly older Macs have the Apple logo and the clover.

For PC keyboards I think "WIN" is the best replacement for "OPT" right now. It is understandable, understated, IP unrestricted, not offensive, but I am open to suggestions.

For Mac keyboards I propose showing a clover symbol in the menu like in the screenshot, because it is on every Mac keyboard, new and old, is recognizable, not too ugly or loud, and is IP unrestricted unlike the Windows logo. The Apple symbol is not good for trademark and style reasons and doesn't even appear on newer Mac keyboards so it is right out. However, if the clover symbol is undesired "CMD" is also a good choice. Not quite as universal as the clover symbol but still recognizable.

[anevilyak]

Replying to biffuz:

OPT was used in place of ALT on old Mac keyboards, that's way it used this name in BeOS. But modern x86 Macs no longer use OPT, only ALT. So, OPT is definitively wrong and misleading - at least until we don't have a working Haiku for PPC Macs :)

My 2008 C2D iMac still has an option key on the bundled keyboard, so this is definitely not correct.

[jscipione]

My 2008 C2D iMac still has an option key on the bundled keyboard, so this is definitely not correct.

But the key probably has "alt" written on it as well I assume. I haven't run into one yet that doesn't and I've been looking at all kinds of keyboards on the Internet doing research for this enhancement. Older Mac keyboards (and newer US ones) have both "option" and "alt" written on them. Newer Mac International keyboards have "alt" and the option symbol with the forked lines on them. Point being, they all have "alt" on them, only some have "option".

[bonefish]

Haiku has key roles which can be freely assigned to keys (yes, the key role names originate from the Mac Clone keyboards in the old days (and no, mine didn't have a key labeled "Alt")). The names/icons of those key roles should appear in the menus. Guessing what is actually printed on the corresponding physical key is tedious and won't always work anyway (be that due to keyboard manufacturers renaming keys, localizing the names, or having other great ideas how to make things less consistent). So please let's just stick with the key roles.

FWIW, I agree with the "SHFT" -> "SHIFT" and "CTL" -> "CTRL" renaming, and I guess we should also localize the key role names.

[jscipione]

Replying to bonefish:

Haiku has key roles which can be freely assigned to keys

This is the first I've heard the term key roles. Are you referring to keymaps? Or is there some classes somewhere that define a keyrole that I am unaware of?

(yes, the key role names originate from the Mac Clone keyboards in the old days (and no, mine didn't have a key labeled "Alt")).

Now that you mention Mac clones I have now found a few examples of Mac keyboards that don't have alt written on them, the original Mac keyboard, the Mac keyboard II and PowerComputing Mac clone keyboard all just say "option" at least for the US version. These are all ADB though so the likelihood of someone using them with Haiku are slim to none. T

This page: ​http://support.apple.com/kb/HT2841 shows pictures of modern Apple keyboards in a bunch of localizations and they all have "alt" written on them so I think it is a safe bet.

The names/icons of those key roles should appear in the menus. Guessing what is actually printed on the corresponding physical key is tedious and won't always work anyway (be that due to keyboard manufacturers renaming keys, localizing the names, or having other great ideas how to make things less consistent). So please let's just stick with the key roles.

I am going for the most common case here and trying my best to come up with some bitmaps that work most of the time. But, if there is a key role functionality that I can use to change the bitmap in the menu based on localized variants all the better, I'd love to use that!

[bonefish]

Replying to jscipione:

Replying to bonefish:

Haiku has key roles which can be freely assigned to keys

This is the first I've heard the term key roles. Are you referring to keymaps? Or is there some classes somewhere that define a keyrole that I am unaware of?

I came up with the term key role, which I found fitting for the implemented concept; it probably isn't mentioned in the BeBook. And yes, this is about keymaps. Physical key codes are mapped to "virtual" key codes or, as I would name them in Haiku's case, key roles. E.g. your BView::KeyDown() gets a B_COMMAND_KEY (cf. ​InterfaceDefs.h for the defined modifier codes) regardless of whether the key you pressed on your keyboard is actually labeled "Command" or not.

Unless we want to move to an explicit two-step mapping -- i.e. physical key code -> virtual key code -> key role (*) -- it is not helpful (and even problematic in case of multiple-to-one mapping) to display the actual legends in KeyMap and use them in menus.

[jscipione]

Replying to bonefish:

Physical key codes are mapped to "virtual" key codes or, as I would name them in Haiku's case, key roles. E.g. your BView::KeyDown() gets a B_COMMAND_KEY regardless of whether the key you pressed on your keyboard is actually labeled "Command" or not.

Well, other than making a different keymap for B_OPTION_KEY on Mac keyboards vs. PC keyboard that is exactly what I am doing. I look at the virtual keycode and return a bitmap corresponding to it. However, I don't see how this allows me to localize the bitmap unless I also know the locale. Maybe there is a function in the Locale kit I could call to get that information? Although I suppose the correspondence is not 1:1.

Unless we want to move to an explicit two-step mapping -- i.e. physical key code -> virtual key code -> key role (*) -- it is not helpful (and even problematic in case of multiple-to-one mapping) to display the actual legends in KeyMap and use them in menus.

It might be helpful to have a level where you specify your Locale and Keyboard type, and then build virtual codes on top of that. German -> Mac -> B_COMMAND_KEY vs. German -> PC -> B_COMMAND_KEY. This would eliminate one level of keymap indirection. Right now there are a bunch of (Mac) versions of the keymaps defined in the same locale that could be eliminated. I don't know, maybe that is overkill.

[pulkomandy]

jscipione: if you switch the shortcuts to "linux/windows" mode in Keymap, then command/option wil be reversed. If they were labelled 'alt' and 'control', then you'd have to press 'alt' for the menus labelled 'ctrl', and 'ctrl' for the menus labelled 'alt'... How easy is that ? :)

for the record, old version of BeOS (R3, maybe R4) did show the clover symbol.

Anyway, the idea is you can't really guess what's written on the physical key from the keycode. Some people even swap ctrl with caps lock :). There seem to be some mixup between the menus labels and the keymap preflet, combined with some keyswapping on Apple's side to make their computers useable with pc keyboards. This gets quite messy in the end :)

[jscipione]

Plain text "Win" key bitmap

[jscipione]

Plain text "Cmd" bitmap

[jscipione]

I added some images of some plain text "Win" and "Cmd" key bitmaps that I'd like to present as possibilities to use for the Windows key on a PC keyboard and the Command key on a Mac keyboard. Their plain appearance should be less offensive than the more ostentatious Windows logo bitmap and the clover leaf bitmap. Comments?

[humdinger]

I feel the discussion goes a bit in circles, or I don't get the issue completely...

What Ingo said about the "key roles" is still true, therefore naming the icon to a specific key on popular keyboards doesn't work well. The "OPT" key will always be the "Option" key, regardless if it is mapped to a key with a Windows logo, a penguin, "Super" or (for older keyboards, for example) AltGr which may be called "right ALT".

The shortcut icons should be named after their function, not to a physical key. That is why I have a beef with the "ALT" icon for years. It should be called "CMD". That way CMD+C will always copy to clipboard, never mind if your CMD is mapped to the alt-key, ctrl-key or the menu-key or whatever.

In that way, sticking to "CTL" instead of "CTRL" is better, because moves the function further away from the physical ctrl-key.

The very best solution IMO would be if we can come up with descriptions of the three key functions "COMMAND", "CONTROL", "OPTION" that have no connection to the physical key names.
Maybe name it "RED" (command), "BLU" (control), and "YEL" (option) and sell coloured stickers for people to put on the respective keys. We'd even have a few colours left for future use...

[jscipione]

Replying to humdinger:

I feel the discussion goes a bit in circles, or I don't get the issue completely...

In the case that a menu uses the B_COMMAND_KEY modifier you want to put "CMD" or "RED" in the menu and then have the user go look up what that means in the User Guide and/or put stickers on their keyboard? I find that confusing. The only way that could work is if we controlled the hardware.

The user will probably not look up what "CMD" means in the userguide, nor will they buy colored stickers. Instead they will just become exasperated and file a bug report. :) It is a laudable goal to map the function of the key rather than the name of the key but it will only cause confusion.

The only sane proposal is to try to match up the key on the keyboard with the bitmap in the menu as well as possible. I know that is impossible for everyone, but, we should try to match the most common case.

To do that I propose putting "ALT" in the menu for B_COMMAND_KEY on a PC keyboard and "CMD" in the menu for a Mac keyboard. For B_OPTION_KEY I propose "WIN" on a PC keyboard and "OPT" on a Mac keyboard. For B_CONTROL_KEY I propose "CTRL", for B_SHIFT_KEY I propose "SHIFT".

I still don't see how key roles fits into this. If you switch up your modifier keys in your keymap the bitmap in the menu will be changed accordingly.

[jscipione]

STRG bitmap for those German keymap users out there. This menu option is set by the German keymap, not the language setting. I set the language to German just for effect.

[jscipione]

To bonefish and humdinger. I finally understand what you guys are talking about with regards to key roles. I am sorry that it took me so long to get it.

I am on-board -- key roles are the way to go. I made a mailing list post on dev explaining what I want to do but allow me post the gist of it here too.

Basically I want to set a flag in input_server that chooses between 3 sets of bitmaps. In order of B_CONTROL_KEY, B_OPTION_KEY, B_COMMAND_KEY the bitmap sets are as follows.

PC keyboard: "CTRL", "WIN", "ALT" (The default)
PC keyboard control and command flipped via Keymaps preflet: "ALT", "WIN", "CTRL"
Mac keyboard: "CTRL", "OPT", "CMD".

The menu bitmaps that appear would no longer depend on the keymap, just the flag in input server.

The button to flip the control and command key in Keymap "Switch Shortcut keys to Windows/Linux mode" would no longer alter the keymap, instead it would set the flag in input_server telling it to flip the keys. Why? So that the key flip persists once we support multiple keymaps which apparently is a sorely needed feature for Russian Haiku users at least.

Comments and questions welcome.

[tangobravo]

Another problem is what about other mentions of these keys - eg in the HTML documentation or forum posts etc?

Although I share your frustration that key roles add an indirection that harms usability, there isn't really an alternative when we are an alternative OS that wants to support both Mac/PC hardware.

Right now I'm typing this on OS X on a new MacBook Pro, but using a Microsoft UK PC keyboard plugged in by USB. It annoys me that I can't set independent keymaps for the two keyboards (so the @ is in the right place on the USB one but no longer where it is shown on the mac keyboard); but there is simply no way for the OS to give me a modifier bitmap corresponding to the key I should press for a shortcut, as the same key is marked differently on the two keyboards.

We should of course optimise for the common case, which may well be the bitmaps you suggest for the standard PC keyboard mapping. My main concern is then which convention should be followed for static documentation - key roles would suddenly not be exposed at all top those with the "common case" setup so would cause confusion, but using the WinPC bitmaps directly would be plain wrong for the significant minority with different setups.

[bonefish]

Replying to jscipione:

I am on-board -- key roles are the way to go. I made a mailing list post on dev explaining what I want to do but allow me post the gist of it here too.

Hooray! ;-)

Basically I want to set a flag in input_server that chooses between 3 sets of bitmaps. In order of B_CONTROL_KEY, B_OPTION_KEY, B_COMMAND_KEY the bitmap sets are as follows.

PC keyboard: "CTRL", "WIN", "ALT" (The default)
PC keyboard control and command flipped via Keymaps preflet: "ALT", "WIN", "CTRL"
Mac keyboard: "CTRL", "OPT", "CMD".

Now I'm utterly confused. I thought you agree with the key roles approach. But that would imply labeling the keys on the keyboard in Keymap with "CTRL", "OPT", "CMD" and also use respective shortcut bitmaps.

The menu bitmaps that appear would no longer depend on the keymap, just the flag in input server.

Er, maybe people have different visions of how a key roles based approach would work. To clarify, mine (which I find simple and stringent) would ...

1. switch the legends on the keyboard in Keymap when switching between Mac/Haiku and Windows mode as done already (hrev43228),
2. not switch the shortcut bitmaps *ever*.

Particularly the last point is why they are key roles. CMD is the main shortcut key role. Always. Keymap would visualize the mapping of physical keys to key roles. That might be considered confusing, since the key physically labeled CTRL wouldn't be mapped to the CTRL key role in Windows shortcut mode, but as we already established keyboards with localized legends don't quite match anyway. The "ideal" solution would be to invent names for the key roles that don't clash with actual key labels, but given the obscure kinds of key labels that do already exist (Meta, Super, ...) that's not really practical.

Regarding the Haiku/Mac vs. Windows mode, how/where that is implemented -- i.e. as a change to the keymaps or a flag for the input server -- is really an implementation detail. I suppose a flag would be easier to implement, but I don't care as long as it works correctly.

[jscipione]

Replying to tangobravo:

Another problem is what about other mentions of these keys - eg in the HTML documentation or forum posts etc?

I don't think it is as big a deal as you think it is. And this is a problem already. In fact making the menu bitmaps static only worsens the problem.

Although I share your frustration that key roles add an indirection that harms usability, there isn't really an alternative when we are an alternative OS that wants to support both Mac/PC hardware.

Allow me to disagree. My above proposed solution is exactly that, more or less.

Right now I'm typing this on OS X on a new MacBook Pro, but using a Microsoft UK PC keyboard plugged in by USB. It annoys me that I can't set independent keymaps for the two keyboards (so the @ is in the right place on the USB one but no longer where it is shown on the mac keyboard); but there is simply no way for the OS to give me a modifier bitmap corresponding to the key I should press for a shortcut, as the same key is marked differently on the two keyboards.

I agree that is annoying but that is a different problem. In order to solve that we'd have to change keymaps to work per keyboard. Also, you are going to probably want to have multiple keymaps per keyboard as well. It is certainly a problem that could be solved, but, again, it is a different problem then the one described in this ticket. File a bug report about it.

We should of course optimise for the common case, which may well be the bitmaps you suggest for the standard PC keyboard mapping. My main concern is then which convention should be followed for static documentation - key roles would suddenly not be exposed at all top those with the "common case" setup so would cause confusion, but using the WinPC bitmaps directly would be plain wrong for the significant minority with different setups.

The 3 modes I outlined above represent the 3 most common cases in descending order. PC, PC w/Control and Command flipped, Mac.

Replying to bonefish:

Now I'm utterly confused. I thought you agree with the key roles approach. But that would imply labeling the keys on the keyboard in Keymap with "CTRL", "OPT", "CMD" and also use respective shortcut bitmaps.

We are in agreement that key roles are the best approach, meaning that the bitmap that appears in the menu would not rely on the keymap.

Er, maybe people have different visions of how a key roles based approach would work. To clarify, mine (which I find simple and stringent) would ...

1. switch the legends on the keyboard in Keymap when switching between Mac/Haiku and Windows mode as done already (hrev43228),

You must have meant a different commit because hrev43228 has nothing to do with this.

1. not switch the shortcut bitmaps *ever*.

If you are willing to live with the fact that on a PC keyboard the Windows key corresponds to a menu bitmap that says "OPT" and the Alt key corresponds to a menu that reads "CMD" and you are willing to live with the fact that when you switch the control and command keys via the "Switch shortcuts to Windows/Linux mode" button in Keymap the Control key corresponds to a bitmap that says "CMD" and the Alt key corresponds to a menu item that reads "CTRL" and are willing to live with the fact that on a Mac keyboard the Option key corresponds to a bitmap that says "CMD" and the Command key corresponds to a menu bitmap that reads "OPT" then ok.

I find all that terribly confusing though and I think that the input server could take care of all of it for you without you having to do anything.

Particularly the last point is why they are key roles. CMD is the main shortcut key role. Always. Keymap would visualize the mapping of physical keys to key roles. That might be considered confusing, since the key physically labeled CTRL wouldn't be mapped to the CTRL key role in Windows shortcut mode, but as we already established keyboards with localized legends don't quite match anyway. The "ideal" solution would be to invent names for the key roles that don't clash with actual key labels, but given the obscure kinds of key labels that do already exist (Meta, Super, ...) that's not really practical.

How is that an ideal solution? That is equivalent to saying "this problem is hard, let's ignore it."

Regarding the Haiku/Mac vs. Windows mode, how/where that is implemented -- i.e. as a change to the keymaps or a flag for the input server -- is really an implementation detail. I suppose a flag would be easier to implement, but I don't care as long as it works correctly.

It won't be an implementation detail if we support multiple keymaps because multiple keymaps break the control/command switching feature. However, if we implement this in input server instead, it would no longer have to. And while we are modifying input server to support this feature, we could use this to also change the menu bitmaps too.

[pulkomandy]

1. not switch the shortcut bitmaps *ever*.

If you are willing to live with the fact that on a PC keyboard the Windows key corresponds to a menu bitmap that says "OPT" and the Alt key corresponds to a menu that reads "CMD" and you are willing to live with the fact that when you switch the control and command keys via the "Switch shortcuts to Windows/Linux mode" button in Keymap the Control key corresponds to a bitmap that says "CMD" and the Alt key corresponds to a menu item that reads "CTRL" and are willing to live with the fact that on a Mac keyboard the Option key corresponds to a bitmap that says "CMD" and the Command key corresponds to a menu bitmap that reads "OPT" then ok.

I find all that terribly confusing though and I think that the input server could take care of all of it for you without you having to do anything.

That's what key roles are. The key labelled COMMAND in menus allows to send COMMANDS to the application ; the key labeled CONTROL allows tho send CONTROL characters in terminal, and the key labelled OPT doesn't do anything useful, because it is OPTional. Or you can maybe find a better meaning for this one.

If the labels on your keybaord don't match, fix the keyboard ;) More seriously, this also has to do with muscle memory. This is why we have an optionn :

• people already trained with other OSes will want to use CONTROL as the COMMAND key, as that's what other OS do and they are used to it
• people with BeOS legacy or discovering Haiku will find it beter to use ALT as the COMMAND key, because it is easier to reach on the keyboard.

Once you make a choice about that, you should be able to keep using it everywhere. On macs and on PCs. The labelling on the key doesn't matter.

How is that an ideal solution? That is equivalent to saying "this problem is hard, let's ignore it."

Muscle memory is what matters in the long term. Do you actually look at the keys each time you trigger one of these menu shortcuts ? If so, I think it'd be faster to use the mouse.

It won't be an implementation detail if we support multiple keymaps because multiple keymaps break the control/command switching feature. However, if we implement this in input server instead, it would no longer have to. And while we are modifying input server to support this feature, we could use this to also change the menu bitmaps too.

The input server doesn't know more about menus than the keymap preflet does. The ideas of key roles is that you don't want the labels in the menus to change depending on the keymap, keyboard, whatever. The key role is the meaning of the key, and has no relation with where it is on the keyboard. The mapping of the key is user choice and settable in the keymap preflet. Note that the default setting mostly makes sense, with CTRL being mapped to CONTROL. If you, user, choose to go for something else, assume the consequences.

Also note how it matches what happen for any other key. If you swap P and O in the keymap preflet, they are now out of sync with the markings on your keyboard. You swapped the roles, but you didn't swap the keys themselves.

[stippi]

I understand the purpose of key roles. The problem is that when you use Haiku as a new user, and you open a menu and see what shortcut you could be using instead of your mouse, "CMD" doesn't tell you anything. You'd have to open the Keymap preflet (which you may not expect to exist at all), to see a key labeled "CMD". From my understanding, John's solution is a middle ground that tries to keep this purpose of showing the bitmaps in the menus in the first place. Once you know what key "CMD" is referring to, and that you can even change it, showing it in the menu this way is probably fine. But that means accepting the IMHO quite big usability problem that exists before you know what key "CMD" is referring to. Is this another thing new users are just expected to learn about the platform?

[bonefish]

Replying to jscipione:

Replying to bonefish: We are in agreement that key roles are the best approach, meaning that the bitmap that appears in the menu would not rely on the keymap.

As explained, that is not my interpretation of key roles (at least not the whole story).

1. switch the legends on the keyboard in Keymap when switching between Mac/Haiku and Windows mode as done already (hrev43228),

You must have meant a different commit because hrev43228 has nothing to do with this.

I don't mean a commit, just a revision for reference (in case that the behavior changes in the future and someone reads the comment afterwards, as unlikely as that may seem considering how the comment section of this ticket grows).

1. not switch the shortcut bitmaps *ever*.

If you are willing to live with the fact that on a PC keyboard the Windows key corresponds to a menu bitmap that says "OPT" and the Alt key corresponds to a menu that reads "CMD" and you are willing to live with the fact that when you switch the control and command keys via the "Switch shortcuts to Windows/Linux mode" button in Keymap the Control key corresponds to a bitmap that says "CMD" and the Alt key corresponds to a menu item that reads "CTRL" and are willing to live with the fact that on a Mac keyboard the Option key corresponds to a bitmap that says "CMD" and the Command key corresponds to a menu bitmap that reads "OPT" then ok.

I really can't say what Apple has done to its keyboards. Back in the BeOS days the modifier names on Apple and Mac clone keyboards matched Command, Control, and Option exactly. There was a recent mention of changes to Apple keyboards (maybe even in this ticket) and as I understood it Apple started relabeling Option to Alt. If I misunderstood it and as you say they basically swapped Option and Command, then this demonstrates even more that what you're trying to do is simply not going to work, since 1. it would already be broken for old Mac keyboards and 2. keyboard manufacturers (at least Apple) apparently can change keys on a whim, which doesn't bode well for the future.

I find all that terribly confusing though and I think that the input server could take care of all of it for you without you having to do anything.

It could only do that, if it knew how the keys are labeled on the exact model of the keyboard. Not even considering legends localization and other customization.

How is that an ideal solution? That is equivalent to saying "this problem is hard, let's ignore it."

The problem is not only hard, it's not practically solvable.

Regarding the Haiku/Mac vs. Windows mode, how/where that is implemented -- i.e. as a change to the keymaps or a flag for the input server -- is really an implementation detail. I suppose a flag would be easier to implement, but I don't care as long as it works correctly.

It won't be an implementation detail if we support multiple keymaps because multiple keymaps break the control/command switching feature.

One (i.e. the preflet in which the keymaps between the user wants to switch are specified) would simply have to keep the modifier behavior of all keymaps in sync.

[jscipione]

Replying to bonefish:

I really can't say what Apple has done to its keyboards. [snip] If I misunderstood it and as you say they basically swapped Option and Command, then this demonstrates even more that what you're trying to do is simply not going to work, since 1. it would already be broken for old Mac keyboards and 2. keyboard manufacturers (at least Apple) apparently can change keys on a whim, which doesn't bode well for the future.

The swapped keys happened when Apple switched to USB. It was an issue on BeOS Intel with a USB Mac keyboard as well (No idea about PPC). So that comment is invalid. The keys don't change willy-nilly.

Ignore Mac keyboards for now. Are you willing to deal with the confusion that will result when you change the menu bitmaps for people using PC keyboards?

I find all that terribly confusing though and I think that the input server could take care of all of it for you without you having to do anything.

It could only do that, if it knew how the keys are labeled on the exact model of the keyboard. Not even considering legends localization and other customization.

The bitmap doesn't have to match exactly, just be recognizable as the key to press, be it alt, windows, ctrl, option, or command.

You have to understand, I am advocating the change not for you and me -- we already get it. I am advocating the change for people brand new to Haiku who won't understand what key roles are or what the Keymap preflet does, only what is in the menu and on their keyboard. "Read the User Guide" is a cop-out, we need an intuitive solution, even an imperfect one.

[bonefish]

Replying to jscipione:

Replying to bonefish:

I really can't say what Apple has done to its keyboards. [snip] If I misunderstood it and as you say they basically swapped Option and Command, then this demonstrates even more that what you're trying to do is simply not going to work, since 1. it would already be broken for old Mac keyboards and 2. keyboard manufacturers (at least Apple) apparently can change keys on a whim, which doesn't bode well for the future.

The swapped keys happened when Apple switched to USB. It was an issue on BeOS Intel with a USB Mac keyboard as well (No idea about PPC). So that comment is invalid. The keys don't change willy-nilly.

Good, they shuffle keys only when changing the interface. We should be safe as long as USB prevails.

Anyway, sorry I got side-tracked. To address the Mac part of your original question:

are [you] willing to live with the fact that on a Mac keyboard the Option key corresponds to a bitmap that says "CMD" and the Command key corresponds to a menu bitmap that reads "OPT" then ok.

Huh? Why would we map the keys the wrong way around?

Ignore Mac keyboards for now. Are you willing to deal with the confusion that will result when you change the menu bitmaps for people using PC keyboards?

Absolutely! On Haiku's desktop wallpaper will be written: "When confused about shortcuts call ..." with my cell number. Oh, wait, that was a rhetorical question. I always get confused by those in a discussion.

You have to understand, I am advocating the change not for you and me -- we already get it. I am advocating the change for people brand new to Haiku who won't understand what key roles are or what the Keymap preflet does, only what is in the menu and on their keyboard.

I wonder what users you expect to use Haiku. I'm pretty sure my father never will, but I suspect he doesn't use shortcuts anyway. I expect the potential Haiku user to easily understand the situation. For users coming from MacOS there isn't even anything to understand, since the key roles are named after their keys. Users coming from Windows or Linux will find the Keymap preflet anyway, since they will want to address the "Control key issue".

"Read the User Guide" is a cop-out, we need an intuitive solution, even an imperfect one.

Do we?

Out of curiosity what does MacOS do when you use a non-Mac keyboard and what about Windows with a Mac keyboard? I'd be interested to learn how other systems deal with it. I suspect not at all, which essentially corresponds to declaring the native key names key roles with an (implicit) mapping for the alien keyboard. The Linux solution might be the most interesting. Particularly in tangobravo's case.

[jscipione]

Replying to bonefish:

I expect the potential Haiku user to easily understand the situation. For users coming from MacOS there isn't even anything to understand, since the key roles are named after their keys. Users coming from Windows or Linux will find the Keymap preflet anyway, since they will want to address the "Control key issue".

We have come to an impasse. I don't think there is any way that I will be able to convince you. So, just let's just do it your way.

Out of curiosity what does MacOS do when you use a non-Mac keyboard and what about Windows with a Mac keyboard? I'd be interested to learn how other systems deal with it. I suspect not at all, which essentially corresponds to declaring the native key names key roles with an (implicit) mapping for the alien keyboard. The Linux solution might be the most interesting. Particularly in tangobravo's case.

In Mac OS X and Windows the menu labels don't change based on if you plug in a Mac keyboard on Windows and vice-versa. Then again they also don't support changing the keymap like we do either. Mac OS X does however allow you to switch the functions of Windows and Alt keys (and other modifiers). This was introduced with the Mac Mini to support people from Windows switching the Mac Mini and bringing their PC keyboards. Windows AFAIK does not accommodate Mac keyboards in any way, which is annoying but somewhat understandable.

Like I said, there is no way that I am going to convince you so let's just do it your way. Hopefully users coming from Windows or Linux using a PC keyboard won't be too confused by the crazy Mac keys in the menu.

[axeld]

The small things usually are hard to get right :-)

Whatever solution is chosen, it has to work with different keyboards attached to the system at a time. If you have a Mac keyboard attached to a PC laptop, which symbols are you planning to show?

Since this is about shortcuts, anyway, I don't think there is much wrong with the key roles; it's pretty easy to grasp, and use, without having a look at the Keymap application first. While I wouldn't mind if it all magically worked flawlessly, having to configure this manually is rather awkward, too.

Having said all that, I find the key role approach the most convincing solution so far. Simple, and not over-engineered, and it will work flawlessly in every environment (even when François finishes his Atari and Amiga ports ;-)).

[jscipione]

Replying to axeld:

Whatever solution is chosen, it has to work with different keyboards attached to the system at a time. If you have a Mac keyboard attached to a PC laptop, which symbols are you planning to show?

There is a built in assumption of 1 keyboard being attached right now inherited from BeOS. For instance there is a get_keyboard_id() function in InterfaceDefs.h that gets the PS/2 id of the attached keyboard. I assume that we'd like to extend that to probe multiple keyboards in the (near-)future, including USB keyboards, in a different way, so that we can make per keyboard decisions. I am making a lot of assumptions here but the point is that you would show the bitmaps corresponding to the first keyboard (keyboard 0), which, as I envision it, would be the built-in laptop keyboard.

Since this is about shortcuts, anyway, I don't think there is much wrong with the key roles; it's pretty easy to grasp, and use, without having a look at the Keymap application first. While I wouldn't mind if it all magically worked flawlessly, having to configure this manually is rather awkward, too.

I agree that configuring this manually would be misplaced. It should work as magically as possible with as little explicit configuration as possible.

Having said all that, I find the key role approach the most convincing solution so far. Simple, and not over-engineered, and it will work flawlessly in every environment (even when François finishes his Atari and Amiga ports ;-)).

Well, my concern is that the bitmaps corresponding to the key roles will confuse people with PC keyboards because they won't understand the concept of key roles or that the role of the key is different than the label on the key. This is bound to include a large percentage of users. But, if the vocal minority believes that the key role approach is the best way to go, I am willing to capitulate.

Before this is done though the responsible thing to do is to post a notice on the general mailing list informing the silent majority that this change is going to happen. I consider changing the "ALT" bitmap to "CMD" in the menus to be a pretty big change and I'd hate to blindside people who aren't paying attention to this discussion.

I would also like to alter the "... (Mac)" system keymaps to flip the command and option keys if not already done so that muscle memory is maintained -- meaning the key that is in the same location as Alt (Command), not the key with the same key code as Alt (Option), performs the B_COMMAND_KEY action. In other words I'd like the Option key to perform the B_OPTION_KEY action and the Command key to perform the B_COMMAND_KEY action by default. I hope that is not controversial. Again, I would first inform the silent majority about the change.

[bonefish]

Taking the discussion to the haiku-development list is a good idea. A ticket's comment section isn't really the best place. Also note that we do have a voting procedure that can be invoked by any developer with commit access (though I believe we still haven't managed to describe it on the website or the wiki). It is used very rarely, since mostly discussions are finished with consensus or it becomes obvious that a significant majority of the developers favors one approach.

[jscipione]

key_bitmaps.h

[jscipione]

Curved Windows Key bitmap