Option/Command/Alt Confusion

Development OS
#1

Recently going over the Haiku translations, I’ve noticed that still after 3 years using Haiku regularly, I have still not fully understood what to make of Haiku key labels.

On the Keymap preference panel, the standard layout describes Ctrl as Ctrl, Win/Super/Cmd as Option, and Alt as Command. However, the menu items use the ALT labelling to describe the Command key. Moreover, various strings include ALT string to refer to the Command key. This is utterly confusing. Plus, I am not sure if the menu items are localisable, causing more confusion on keyboard layouts that use different labelling.

Also I have noticed that the Keymap preferences label the Option key as Win/Command key on the modifier selection window, causing additional confusion.

I think we need to ditch the ALT naming scheme completely and go forward only using Haiku-specific naming. Which is:

For Windows themed keyboards:

  • Ctrl for Ctrl
  • Win/Super/Cmd as Option
  • Alt as Command

and we need to tweak all strings in the interface and the user guide to reflect this as such.

For Mac themed keyboards:

  • There is no need for a change here. Since BeOS took inspiration from the Macintosh, this suits us perfectly.

For Windows/Linux users, this will surely create confusion at first, but we ought to treat this as a Haiku-specific quirk that the new users should get used to. Maybe we can introduce our own Haiku-themed keyboard sticker merch, or sticker templates.

However, on current Macintosh keyboards, the Command and Option keys do not act as expected, this even differs on left and right Command/Option keys. This will need fixing.

1 Like
#2

I did not understand the key system at first myself either. There are four key roles: command, option, control and shift. The command key is always used with keyboard shortcuts, and the control key is always used for control characters in Terminal. Option is always used for special characters and other languages plus stack and tile and shift is a modifier.

These key roles never change, they are then assigned to physical keys on your keyboard that can change to different roles so that’s what we display in the menu. By default Alt is assigned to command, meta/super/win/option to option, Ctrl to control, and shift to shift.

If you want to improve the situation, you’re going to have to do it within that system. We’ve long talked about changing what displays in the menus but we haven’t yet come up with a better system than the one we currently have.

1 Like
#3

What is shown in menu doesn’t cause problem, it is always the combination that works for the user. When it comes to docs, Haiku guides are naming these by their role. This is logical since you can map the role to different keys. What you could be changed are of role names because they can exactly match key names. Perhaps adding a leading ‘H-’ to role names in docs would help readers to better differentiate the two things?

#4

The goal is:

  • The keymap shows what the key will do (for example you can select your keyboard ALT key to be the COMMAND key, that is, it will be used for keyboard shortcuts)
  • The menu item shows the physical label of the key you have to press (if you selected ALT to be your COMMAND key, then it will show ALT. But if you switched to “Windows” style shortcuts, your CTRL key is now your COMMAND key, and so the menu will show CTRL).

Since we cannot distribute command/option/control stickers to all users to put on their keyboards, it is impossible to get rid of ALT :frowning: so that’s how we ended up this way.

3 Likes
#5

Note: Not only on Terminal. Those control characters also get sent to the rest of apps. Try it on StyledEdit.

It tends to output “garbage” (or rather “empty spaces”) when you unintentionally hit one of those outside of Terminal, or otherwise do, for me at least, unexpected things:

On StyledEdit. Alt+x, Alt+s, Alt+c, Alt+v (using swapped Ctrl <> Alt), all generate " ", but Alt+a == HOME key, and Alt+d == END key. :face_with_diagonal_mouth:

I guess my brain doesn’t expects non-terminal programs to respond to “control characters”.

I had to remove “^I” from my keymap (among others), because when physically pressing ALT+i, it behaved as “Ctrl+TAB” (even invoking Twicher if I was slow), and that was mildly infuriating (or highly confusing :smiley:).

#6

From what I can see, keeping both what’s printed on keys, and the system variant is bound to create confusion. It would be really easy to let the users know the difference with a better onboarding experience on first boot. A nice visual for PC users would be more than enough.

Regarding the Windows/Linux mode, IMO it really should not be needed. PC users are the majority, but there is no Windows mode in macOS. Instead of teaching the Haiku way, we compromise.

macOS uses key symbols instead of names in menus. Maybe we can use macOS symbols if there are no copyright problems, at this point they are well known to people (at least to tech-savvy people, that would try Haiku in the first place).

#7

Displaying the same in the system as is printed on the keys is impossible since keyboards can have different labeling.

There are key terminology that is well established that should be used. For the three keys in question those are Control (CTRL), Super (Windows/Command etc) and Alternative/Option (ALT/OPT). I have argued that Haiku should use this terminology.

Haiku confuses the users by calling one key ALT and another OPT, keys that do not exist together as separate keys on keyboards. The user guide claims this has “historical reasons, because the BeOS was inspired somewhat by MacOS”. Unless you interpret the word “somewhat” very freely (wrong), this is not true. Apple keyboards and therefor Mac OS never had a separate ALT and OPT key. They have an Option key that is also marked as ALT. It is the same physical key. The key that Haiku calls Menu is the Super key.

TLDR: Rename the keys to Control, Alternative or Option and Super and the confusion should clear up.

1 Like
#8

As described in my post above, this statement is not true. Just look at an Apple keyboard:

apple-control-keys
apple-control-keys1198×551 31.9 KB

ALT and OPT is the same physical key. Haiku treats this as if they are two different physical keys, which do not exist on any keyboard. This is the cause of the confusion. It has nothing to do with the Control key. Swapping the mapping to “Windows/Linux mode” solves nothing since it is not the problem.

#9

I didn’t say the opposite. My first post indicates that we should name the keys in the order of Control, Option, Command; and let every GUI string and menu shortcut reflect that. Just like a Mac keyboard.

#10

The only place where we have to keep the “system” variant (that is, what the key will actually do) is in the keymap preferences, and in the documentation because we can’t know there what type of keyboard is used and what settings are used. Everything else should use “what’s written on the physical keys on the keyboard”. For now we assume a standard PC keyboard.

But there is a lot more confusion than that:

  • Apple keyboards use different labels. We should detect them (based on the USB vendor and product ID) and change the labels in the menus
  • On european keyboards, there is an additional Alt Gr key. Currently this is mapped to OPTION (the same as the left “Windows” key) and the right “Windows” key is mapped to COMMAND. As long as this situation persists, nothing we do will make any sense. The solution here is to introduce a separate AltGr key role separate from OPTION. Then we can have both “windows” key be OPTION keys, left alt be COMMAND, and right alt be ALTGR.
    -Even if we fix this, users are free to swap keys as much as they want in Keymap preferences. For example, some users like to have the “caps lock” key used as either a CONTROL or COMMAND key. But we may accept that this is a “you know what you’re doing” case.

The alternative is to completely ignore what’s written in the keys, and use the key role names (CONTROL, OPTION and COMMAND) everywhere. From the developer point of view, this is mcuch simpler. We don’t have to worry if the user has switched the shortcuts to “windows” mode, if they have a Mac keyboard, etc. It’s always COMMAND for menu shortcuts. But then users are confused because they can’t find that key on their keyboard. Maybe that’s, after all, a smaller amount of confusion than the current thing, and we should do that?

#11

I totally forgot about AltGr, and it scares me to add it into this spaghetti of an equation.

FWIW, I totally advocate for using the Control, Option, Command route. I’d assume every user will be confused by Haiku at first, I was, but it got over quickly. Mac users are also confused at first, but they learn it. We just need to convey the users that we name keys this way, we don’t distinguish AltGr as a separate key, and that’s all. Let’s also sell keyboard sticker merch for the fans.

Also Mac is not the niche it was twenty years ago. Macs are very popular among both tech-savvy and parents; which seem to me like potential Haiku users a lot.

The only addition to this layout maybe can be the Menu key, which opens the context menu on some PC keyboards. I don’t see it interfering with the above proposal.

#12

Yes, I didn’t mention the menu key because its role is MENU and its label is also a menu. So, no problem to solve there at least!

1 Like
#13

Just rename the logical modifier keys to Control, Option (or Alternative) and Command (or Super) and leave everything else to the future. This eliminates the confusion.

#14

Adding to that… Note that basically all of South America also use keyboards with Alt Gr, with the “Spanish”, “Latin American”, and Brazil’s “ABNT2” keyboards, or even by switching to “US-international” on Windows when the device has a US-only keyboard (common on imported laptops).

https://en.wikipedia.org/wiki/AltGr_key, for those curious about it.

That’s my experience too, no amount of fiddling on the Keymaps preflet feel right due to the lack of distinct Alt Gr key.

Who we need to bribe to tackle this one? :stuck_out_tongue_winking_eye: (I recall seeing some proposed patchsets in the past about it, and plenty of discussions too, but none seem to have landed. Oh well).

Still extremely niche in my part of the world at least (Argentina). Poor-countries problems, I guess :smiley:

#15

We assume a PC keyboard with Alt key on it. We can’t do better than this unless we can detect what keyboard you are using. No major operating system including macOS, Windows or Linux have the ability to do this either. This goes for Mac keyboards, and German keyboards with their Strg key, the AltGr key and a whole host of other issues. So if you want to solve the confusion you’ll have to tackle that problem first.

#16

You can just ask the user which type of keyboard they have?

AFAIK, on Linux or Windows, you not only specify the keymap layout, but also the type of keyboard (defaulting to “PC 104/105 keys international”, for example).

Heck… even Haiku’s Keymap preflet lets me select “Generic 105-key International” on its Layout menu. Isn’t that enough?

#17

Alternatively, since detecting the keyboard is an intractably hard problem, we could ask the user what their keyboard type is in the FirstBootPrompt: PC ASNI keyboard, Mac ANSI keyboard, PC International keyboard, Mac International keyboard, JIS, etc. and then we could swap the modifiers and setup the menus using the value of that setting. We already kind of do this by asking for the keymap, but that doesn’t give us all the information we need.

#18

Seems to me it should also (could already?) use the Layout the user has selected on the Keymap preflet.

#19

Sort of yes, we could, but we’d have to fix up the keymaps to add Mac variants (where we haven’t already done so). You could get it all to work by being clever with the key maps, and we have gotten clever with the keymaps plenty already, but I’d rather we create a new keyboard type setting to simplify things, and then we could clean up the keymaps. The keyboard type is slightly different from the keyboard layout in that we don’t care so much about whether you have a numpad or if you have a big enter key or not, only PC, Mac, AltGr, and some international keyboard types, e.g. JIS (Japanese).

#20

Even if the keyboard was detectable, it would only solve parts of the problem. For example the documentation is independent of what keyboard is used and must be independent of keyboard layout. That is why I propose logical modifier keys, that can be freely mapped to physical keys.