Got it. We are on the same page then.
It is already done in most places.
It is command key. Alt is implementation detail. Haiku have no enough finances to manufacture its own keyboards so most popular Windows keyboards are used. There are no Cmd on Windows keyboard.
1 Like
There are no Cmd on Windows keyboard.
Command key on Windows it is called WIN key, on Linux it is Super or OS key.
No. It is the same scancode by occasion, but meaning is completely different. Linux basically mimic and use Windows keyboard and shortcuts (Ctrl as shortcut key).
1 Like
Scancode is that what matters, and it is says that they are the same key with different names.
Chose one.
Text to reach the minimum of 12 characters.
AltGr is not! same as Alt left!
AltGr is differerent!
Overall I donât know if this discussion is being very productive. It happens to be the case that BeOS tried to satisfy everyone by generally emulating both Mac keybindings when Alt is Cmd, and Windows/Linux when Ctrl is Cmd. Haiku obviously inherits that choice. It isnât totally perfect but also I think saying it is terrible isnât correct either.
We have Haiku developers and users who prefer the Alt layout (myself, X512, probably many more) and then some who like Ctrl (waddlespash and again more, I havenât taken a poll.)
But blowing it up to come up with some new scheme that seems more consistent will just make everyone unhappy. Overall people have a huge amount of muscle memory for keyboard bindings and shortcuts, and our best bet is to emulate other systems as well as we can and then make unique Haiku choices where it makes sense. Overall I think that has been done pretty well. Iâd suggest making small incremental improvements over trying to completely redo everything.
8 Likes
What you and @X512 do not understand is that I have not suggested to change the layout. I have only suggested to name the key to the same thing that is printed on it.
This will be my last comment about this. Those that have not understood this by now may never do so.
OS donât know what is printed on keyboard and actually multiple variants exist.
I will say a long time ago I realized we do have some issues with shortcut keys where they really need to understand the keyboard layout. For example on a standard US layout the plus key (+) is above equal (=) and requires using Shift. If an application defines a shortcut key for Cmd-+ for zooming in for example, it wonât work, because the shortcut handling code checks for each modifier so really this shortcut has to be Cmd-Shift-= on this keyboard layout. Other operating systems seem to handle this okay, so obviously it can be done, but I think it can only work if the shortcut handling code âknowsâ that + and Shift-= are the same.
How does this relate to the current discussion? If we add understanding of the keyboard layout to the shortcut handling code then maybe the proper key could be used in the menu rendering, in those cases where it is currently wrong. Though I think those cases are really only for Mac keyboards? Unless of course someone has remapped their keys.
I guess the main issue we have with this thread is that the Cmd key not matching the keyboard is pretty rare, isnât it, since most people use standard Windows layout with Haiku?
Question to everybody.
To me it sounds like the consensus is to keep the keyboard layout (in regards to Ctrl, âWinâ and Alt) on PC keyboards as is.
But how do users that use an Apple or similar layout (Ctrl, Alt, Command) want the keys mapped?
-
Map them the same way as âPCâ keyboards are physically placed.
This would mean that to copy something, on a âPCâ keyboard you would press ALT C but on an Apple-like keyboard you would press COMMAND C.
-
Map them the same way as they are labeled.
This would mean that to copy something, on a âPCâ keyboard you would press ALT C but on an Apple-like keyboard you would also press ALT (key labeled Option) C.
Free AltGr thats all I want!
It is used for Typographic use!
Edit: For German use!
In Haiku Opt key can work as Alt (no 3th level in the keymap) or as AltGr (if there is 3th level in the keymap). Sorry English people but other languages needs 3th level in theirs keymap. I dont like eider, but my native and many other languages have more then 26 letters. So, how to we remedy this.
We map the keys as they are intended. That is in my proposal.
I prefer this variant because key with Cmd label should be used as command key if available. If not, Alt is used as command key.
1 Like
There is PC and Mac and some other styles for âas they are intendedâ. Haiku seams choosing Mac style, so be it: ctrl opt cmd, no alt no altgr no win no super no os keys.
In my proposal I have stated that any key should work as intended. That includes Alt (which is the same as Appleâs Opt), Alt Gr, Compose etc. Command, âWinâ, âMetaâ are commonly named Super after the Space-cadet keyboard.
In this regard Haikuâs use of ALT makes sense, since Control historically was meant for sending control signals. Since only terminal clients sends control signals, Control can be used as a meta key outside of terminal clients.
The only thing I will exclude, because nothing will stop it from being implemented in the future, is client-side programmable keys (not to be confused with macro keys that are keyboard-side programmable and should be supported by default).
I propose the following basic scheme:
Control key: application shortcuts.
Optional key: used with printable characters, 3th level for the keymap (Opt + Shift for 4th level). For keymaps with only 2 levels Optional key can be used for as user defined shortcuts. And for users with 3th level keymap this user shortcuts can work with CMD+OPT (and this also for 2 level keymaps another additional option). OPT+nonPrintableCharacter can be used for switching between apps and workspaces.
Command key: for OS/GUI shortcuts.
In keymap preferences those keys can be swapped for everyone needs.
Well, ist seems everyone is confused and a lot of people reply without reading the thread. You had been warned that discussing this on the mailing list would be a better idea. AnywaysâŚ
- The API has âcontrolâ, âoptionâ, and âcommandâ keys. We can even see from the ordering of the constant values that option was added a bit later.
- The meaning of these constants is clear: control for control sequences (in terminal), command for shortcuts in menu. Option is currently used both for the 3rd layer of keymaps which need that, and some window management shortcuts.
On the API side: probably it would be a good idea to separate B_OPTION_KEY and B_ALTGR_KEY. That is the only change needed. The meaning of these constants is otherwise well defined and well understood. There is a change on Gerrit (not reviewed yet or not finished) to fix this
The constants do not map, at all, to the physical labels on the keys, for multiple reasons:
- The lack of a distinction between altgr and option means the key labelled altgr and one of the two labelled with a windows logo are option keys, while the right windows and left alt keys are command keys. As long as this is the case, it isnât really possible to have asingle key label for each key type, at least for users with an altgr key (pretty much everyone since our default âus internationalâ keymap has altgr and so do most european layouts)
- The user can flip the âcontrolâ and âoptionâ keys to have something closer to windows/linux (menu shortcuts on the leftmost key)
- Also, the user can do whatever they want by simply dragging and dropping keys around. Some like to use caps lock as a control or command key, for example.
On the user interface side:
- The intent was to have the labels in the menus always match the physical labels on the keys. Currently they display âaltâ or âcontrolâ depending on which you selected as a command key in keymap preferences. They ignore the mismatch on the right side of the keyboard caused by altgr, and they also ignore keyboards that have different physical labels.
- On the other hand, the keymap preferences use the key âmeaningâ (control/option/command) to show which key is assigned to what. This makes sense in the context of the app (you map keys to their functions), but with the names control/option/command not being used elsewhere in the gui, this is not very clear for users
Our options are:
- Give up on trying to have labels on menus match the keyboard. Use âCMDâ all the time and let the user discover and remember what key that is. Simpler for developers, maybe not so great for users.
- Make our code to show the correct label work better: introduce a separate identifier for altgr to avoid having two differently-labelled keys both act as command keys. Add extra icons for the different keys (there is a change on gerrit to do this already, although I think these are bitmaps, and it would be more flexible to use vector/string drawing). Add a way to somehow detect keyboards key labels (mainly detect keyboards manufactured by Apple or known to be designed for Apple machines thanks to their vid/pid. This would never work perfectly so it would need to be configurable in keymap preferences by manually selecting the right labels, in case the autodetection gets it wrong. Also, I donât know what to do with the keymap app in this case. It would not be possible to visualize which key is the âcommandâ key by just its label, if the label is consistant with other parts of the ui it would be âaltâ or âctrlâ.
Userguide:
No problem here. The userguide will document the UI as it is, and will be adjusted if the UI changes.
Conclusion: the current ui is an imherfect solution to a complicated problem. A perfect solution probably isnât reachable. But improvements are possible in several places.
3 Likes