I have added a section about mapping of logical moderator keys to physical keys.
Note that the mapping below is only a suggestion and open for discussion. I have no horse in this race. What is important to me is that the usage of logical shortcuts are standardized in order to avoid interference with applications, and make it more intuitive for the user.
PHYSICAL KEY MAPPING
The logical OPT, CTRL and ALT must be mapped to physical keyboard keys, or key combinations where suitable keys are missing, such as IBM Model M that only have Ctrl and Alt keys.
For "PC" keyboard with a "Win" key, OPT should be mapped to "Win", CTRL should be mapped to Ctrl and ALT to Alt.
For keyboards without a suitable OPT alternative, an alternative key sequence must be used. [Suggestions? Could CTRL CTRL work as OPT? That would be CTRL CTRL CTRL for OPT CTRL]
Apple keyboards should map OPT to Command, CTRL to Ctrl and ALT to the Option key.
That is a valid point. Since a lot of commands could be used to launch applications, even 3rd party once, the OPT key should be reserved to be defined system wide and not by any application.
Examples could be OPT SPACE that is excellent to be used to launch QuickLaunch or similar application, OPT F to open Find etc. That would mean that CTRL F would have to be mapped to an applications Find, which differs from OPT Z/X/C/V etc. That is not intuitive. Both options have their respective drawbacks.
Iâm not sure why you map Opt to Command and Alt to Option on Mac keyboards. I use a Windows gaming keyboard on a MacBook Pro and I map the Alt on that keyboard to Command and then the Windows key is Opt. This matches the layout of the built-in keyboard on the laptop and works really well for me. On a normal Haiku keyboard layout which is more Mac-like I think it makes sense to map things that way. Of course probably not many people using Haiku use a Mac keyboard layout.
It is only suggestions, which I clearly have stated. The suggestion is based on Apples intended usage of their keyboards, where the keys are labeled âctrlâ, âaltâ and âcmdâ respectively (see image below). Feel free to discuss how you and others want them mapped. As I said; I have no horse in that race.
What is important is to standardize the usage of the logical modifiers. Haiku currently has no such standardization, or guideline at all. As Haiku stands today, it is impossible to add a single shortcut to the system without risking breaking applications. That is what I am trying to fix with this, and at the same time make it more intuitive and easier to use.
Personally, I feel that after 25 years of using BeOS/Haiku Iâm very used to our âtraditionalâ keymappings. If we can make everything completely configurable, Iâm all for it. The same for easier shortcuts for S&T (the scope of this thread), if that is possible.
But changing OPT for CMD (= ALT) to be more like a Mac, or mixing âsystem shortcutsâ (OPT) with 'app shortcuts (CMD) doesnât make sense to me.
Then weâll change that. I see no problem in that. I have only followed what is labeled on the keyboards. As I have said; I have no horse in this race.
EDIT: What does âchange OPT for CMD meanâ? Those are two logical modifiers. The physical layout differs between a âPCâ keyboard and an Apple keyboard. On an Apple keyboard, the Alt key is where the âWinâ key is on a âPCâ keyboard, and vice-versa.
Are you suggesting that keyboard combinations using both OPT and CTRL should be non-valid?
My reasoning behind the ârulesâ is that any shortcut using the OPT key is a system reserved one, and any shortcut without the OPT key is reserved for applications. That is the only rule.
All other rules are which keys should be preferred. To me that makes sense.
Currently Haiku has no rules. That makes no sense at all.
We need to think more about this. See my comment above.
There are two solutions to this problem, both with its respective drawbacks.
On the plus side with my suggestion is that we only need to reserve key mappings using the OPT key. All other keys are free to be used by the application. The downside is that system functions and some application functions (such as cut, paste, undo/redo, find etc) use the system key, not the application reserved key.
The down side of using an alternative key, like ALT is that we have a problem with consistency if we do not reserve some standard keys.
Both solutions have its positive and negatives. Input is appreciated.
EDIT:
So the alternative solution may be to reserve OPT for system use, ALT (without OPT OR CTRL) for âstandardizedâ application commands (copy, cut, paste, undo/redo, find, help, print etc) and let the applications freely use the CTRL modifier.
That behavior is unchanged in my proposal. Users may remap their logical modifiers depending on what keyboard they use or their own individual preference.
Iâve thought about your input and came up with this alternative. What do you think about it?
MODIFIER KEY RULES
The OPT modifier is reserved for system defined shortcuts and is its primary modifier. Applications may not use the OPT modifier, and system defined shortcuts must use the OPT modifier.
OPT F -> Opens the Find system application.
The CTRL modifier is the primary modifier for application defined shortcuts. It can be freely assigned by the application.
CTRL R -> Reload in WebPositive.
The ALT modifier when used without OPT or CTRL is reserved for common shortcuts that should be consistent thruout the system.
ALT Z -> Undo.
ALT S -> Save.
ALT SHIFT S -> Save as...
ALT F -> Invokes the application's find function.
Because without doing it, we cannot unify commonly used shortcuts. Itâs about consistency. We do not want half the applications use CTRL Z/X/C/V/S and the other half ALT Z/X/C/V/S. Thatâs my reasoning behind it.
I donât know if this is the best way of doing it, so input is greatly appreciated.
Application decide use common shortcuts or not. Application canât handle common shortcuts if it not aware of it and do not implement it. Application private shortcuts is extension of common shortcuts. If extension is handled externally to application logic, it is system shortcut, not application.
OK, so just because some of this thread is hurting my brain, yaâllâre saying:
I only ask because I was under the notion that Ctrl (Control) and Alt/Option were ALWAYS Ctrl and Alt, and the only outlier was Logo / Command. Historically, whereas on PC keyboards, the â/Logo key was shoved between the Ctrl and Alt when it was introduced, the Closed Apple/Ctrl key was cloned, shoving the â„Option/Alt and Open Apple/âCommand keys to the right on Mac keyboards. From my understanding, the BeBox just used an AT/PC layout keyboard, so where does this weirdness come from?
Yeah, itâs confusing. Itâs easier to just think of the logical modifier functions (CTRL, ALT, and OPT, which by the way do not make sense since OPT do not exist on a âPCâ keyboard and ALT and OPT are the same key on Apple keyboards) and what they should do. What keys those are physically mapped to is just a matter of taste.
I just want to make some guidelines for it that is easy to understand, remember and creates consistency, both for users and developers. I am thinking about it and I have another alternative that I would like to present.
For completeness (and to add some confusion): on keyboard layouts where there is an altgr key, the mapping is different for the left and rigot sides of the keyboard currently. This is why we donât use the names written on the keys.
So basically, the layout is currently:
If you use a keymap with AltGr:
Control - Option/AltGr - Command - Space - Option/AltGr - Command - Control
If you use a keymap without AltGr (pretty much only US QWERTY?):
Control - Option - Command - Space - Command - Option - Control
Thefe are the default. But some people want the command key on the left, so that it behaves similarly to Windows and Linux. In this case the mapping is:
With AltGr:
Command - Option/AltGr - Control - Space - Option/AltGr - Control - Command
Without AltGr:
Command - Option - Control - Space - Control - Option - Command
In most case, the key usage likely does not match the label on the physical key. And with AltGr keymaps, keys with the same label do different things, while keys with different labels do the same thing.
Ideally we could change the way we handle AltGr and handle it really as a separate key (as it should be) and not as an option key. I think there is some work towards that in a not-yet-merged patch on Gerrit
Command
I think this needs more clearing up than just the shortcuts part. I mentioned all the modifier keys in my initial proposal and I would like to address some of that again, because there have been a lot of misunderstandings in this thread, which to me indicates even stronger that change is needed.
Alt and Alt Gr are not the same key. Alt is an alternative key, or options key. Its intention is to be used to type in shortcuts. Alt Gr is a modifier to type in alternative graphics, iow characters. Alt Gr should not be used for shortcuts.
There should be no difference between left and right modifiers when inputting shortcuts. When one hand do not reach a modifier and a key, an alternative to using two hands is to use the modifier closer to the key. For example L is to far away from the left modifiers, but very close to the right modifiers.
Left and right modifiers should be separate if the applications wish to use them for other things than shortcuts. I mentioned the examples of VirtualBox and IBM terminal keyboards using the right Ctrl as a special key. Another example is pinball-type games using left and right Ctrl as flipper controls.
I think I will suggest renaming what I call logical modifiers that I have taken from Haikuâs documentation, CTRL, ALT and OPT since on Apple keyboards they do not make sense. More logical would be CTRL, ALT and maybe SUP (for super). The problem as mentioned earlier is that ALT and OPT are the same key on Apple keyboards.
Yes, of course, our current situation with regard to AltGr makes no sense and this should be fixed. This is a hack we inherited from BeOS because they designed their keyboard system on keyboards without a âWindowsâ key (pre-1995) and then badly adapted it to the new keyboards.
I just think this situation helps understanding why we currently use key names (control/option/command) that donât match the label on the keys - in the current situation itâs just not possible. An attempt to change the key naming without first fixing this will just result in more confusion for us AltGr users
As far as I know in the UI and in the code we use the names âcontrolâ, âoptionâ and âcommandâ. But it seems the userguide team decided to use âcontrolâ, âoptionâ and âaltâ. Indeed that doesnât help making sense of things
If we fix the AltGr thing, we could have the UI show the actual key labels (matching the keyboard). But we canât do that in the userguide.
