I do not have any macs up and running so I cannot test it in Mac OS X. But my eyes tell me that left Opt has “Alt” printed on it and right Opt has “Alt Gr” printed on it.
The quirk that confuses everybody is that Haiku calls one key Alt and one Opt when they are the same key on macs and one do not exist on PCs.
Keyboards should work as intended. Not as Linux intend, or Windows, but as the manufacturer of the keyboard. That means my Alt Gr on my Thinkpad should access the @-symbol when the 2-key is pressed, because that is printed on the key. Command should issue commands, alt should alternate, shift should shift and control should control. And my wet dream is to be able to compose characters with the Compose key on Sun keyboards. As intended.
And to clarify again, on ISO Apple keyboards the right Opt is also marked as “Alt Gr”.
On which language? I have two Apple ISO keyboards with different languages, none have it. Checked online, none of the keyboard visuals with different languages at the Apple Store seem to have such a thing. ANSI keyboards included.
That AltGr on the keyboard is just typing on a button (for PC users). In the keyboard itself, it’s Right Alt, and only Windows OS interprets it as AltGr and MacOS as Opt.
NO, they’re not, unless you’re using US int keymap, i’m using an azerty keymap-fr they behave differently. you can’t print the accents when you’re holding the left Alt, only with AltGr
For those that don’t understand why some of us are saying “right alt” (on a PC keyboard) is physically the same as “alt gr”, here is a link explaining what is sent from a usb keyboard. https://wiki.osdev.org/USB_Human_Interface_Devices
Notice in the modifier keys status byte, that bit 6 is “right alt”. There is no separate bit for “alt gr”. If your PC keyboard says “alt gr”, it is still bit 6, defined as “right alt” that gets set in the report that is sent to the computer.
It is up to the user to select the keyboard type in the OS.
If your using a keyboard with “alt gr” on the physical key, you can change your keyboard to “English-US” and see that the behavior of “alt gr” is now just like the left Alt key.
Change your keyboard setting to “English-UK” and the behavior will be “alt gr”; the physical key didn’t change, just the behavior.
Hope this helps.
Would you guys please step away from keyboards? You are disturbing my circles
All y’all are most remarkably simultaneously right and wrong on this subject - particularly in regard to Right Alt/AltGr. You are forgetting ISO/IEC 9995-2 according to which ‘bit 6’ key can be interpreted as either Right Alt or AltGr - with both being fully correct, regardless of informal american conventions.
Wow, that really stirred your circles, having you un-lurk after 17 years!
Welcome back?
Anyway, as I wrote before, it’s hard for me to wrap my head around this issue, because my German keyboard behaves exactly as advertised in Haiku (and I suppose in Linux, which I only boot into every other month, usually to be greeted by a gigabyte of updates…).
On-screen-CTRL is keyboard-CTRL, On-screen-ALT is keyboard-ALT, On-screen-OPT is keyboard-WIN-symbol, AltGr works as expected.
If this discussion leads to any changes, I just hope that doesn’t change…
Carry on.
Nobody on this planet has ever called the Win-key OPT, except for Haiku. When will you and the other Haiku developers understand this fact and that it is the cause of the confusion?
This problem has been identified as confusing for decades.
Be has partially addressed this situation by creating a set of neutral names for modifier keys. However, the neutral name scheme derives directly from Be’s PowerPC-only era, which means that the neutral names are more confusing than useful to the majority of Be OS users.
As can be can seen from the reference in The BeOS Bible we inherited the term Opt from BeOS and while it may be confusing it’s our terminology and I’m not sure Hyper or Meta is any better.
To fix the key labels we have to first fix the keyboard type detection, and we’ve punted on that problem like Be did because it’s a difficult problem to solve. Sure we could fix just that one bitmap in the menu, but we won’t because we’re waiting on the real solution, and until we have it, we keep Opt there for the BeOS diehards.
Really, what detection beyond asking the user is really necessary? Linux/Win do not detect, they let the user select a keyboard model. Haiku’s Keymap already lets you select a keyboard model/layout.
If the problem of keyboard detection is intractable…how waiting for a solution to that to fix other things serves anyone?
Abide user settings “now”, add auto-detection in the future, no?
“Don’t let perfect be the enemy of good”, yadda yadda.
What about the fact (if I remember correctly) that the Haiku/BeOS keymap considers the Right Alt for Option and the Right Win for Command, but the Left Alt for Command and the Left Win for Option. Who thinks this kind of confusion is a good solution?
Every Haiku developer seems to be fine with it because no one has shown that they understand the mess. It’s the blind leading the blind.
There is nothing stopping this from being corrected, except knowledge and will from the developers. It will not break any binary compatibility with BeOS.
The extra AltGr key may require changes to the keymap, which is exposed to applications using the get_key_map function. So it would break any apps using that, if not done carefully.
But that is not the only problem.
The issues have been discussed to gr at length here, but, as a summury, here is the impossible list of requirements:
have AltGr and “windows” be handled as two different key roles (easy except BeOS compatibility problems)
have the labels in keymap preferences, documentation, menu shortcuts and on the keyboard all match each other (impossible, but we can have some of them match together, we have to decide which ones)
autodetect the keyboard type to decide if it has an AltGr key or not (probably impossible) and if it has control/win/alt or control/command/option keys (relatively easy for USB keyboards)
allow users to customize their keymap (for example use capslock as a control key, or swap the command and control keys to emulate a mac-style layout on a pc keyboard) (already working, but it sets additional constraints on requirement no 2)
make the whole thing understandable easily both for users and for developers (if the only place we mention a “command” key is in C++ API and everywhere else it is labelled “alt”, and if the C++ API has a “control” key constant that in fact sometimes refers to the “alt” key on the keyboard, that’s not easy for the developers) (possible to fix, requires good documentation about what we do, for both users and developers, and renaming of key roles to avoid confusion)
I don’t think I have seen a proposal that takes into accounts all these things (I think it is not possible) or explicitly mentions which ones it chose to ignore (so that other people can complain that ignoring those is crazy and will make the system unusable).
So, it’s not that the developers don’t understand the problem or don’t want to fix it. We have a set of conflicting requirements, and the “solution” is deciding which of the requirements we must give up so we can solve the other ones. And when that’s the only solution, any change will be strongly rejected by a part of the community. As a result, the easiest (but not the best) course is to not change anything
This is the only thing I am requesting to be fixed, because it is the source of the confusion. Note that I have never argued to match it to what is displayed on the keyboards, because that is impossible. I have only requested that the confusing logical names, the ones used in the documentation etc, to be renamed to something that is not confusing.
NO KEYBOARD IN HISTORY HAS AN ALT KEY PLUS AN OPTION KEY. HOW DIFFICULT IS THAT TO UNDERSTAND? The users do not understand it, for obvious (unless you are a Haiku developer) reasons. As I said, the blind leading the blind.
That is also true for stopping development of Haiku. That is very easy.
Can actual users of the system please state what exactly is the issue.
Is it that you see “Copy ALT+C” in the edit menu and can’t figure out the keys to press? Is it the Tracker add-on shortcuts, e.g. OPT+ALT+T to summon a Terminal that you cannot figure out? Or you read the user guide and see “Hold down OPT while dragging a window by its tab” and you were never able to figure out what could be the OPT key. Assuming you did find the ALT and CTRL keys, how many other keys are candidates?
Or were you taken aback for a second, like with many things you experience when trying a new OS the first time, but figured it out evetually and then managed to remember, “Ah they call the Windows key OPT here. Oh well, I guess the other way around would be weirder, having Microsoft call their key “Haiku”. Life goes on…”?
)