#6365 closed bug (invalid)
Switching keyboard shortcut accelerator key should not remap keys
Reported by: | rq | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Preferences/Keymap | Version: | R1/alpha2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Switching keyboard shortcut accelerator key should not remap keys, but should actually only switch shortcuts instead (if possible). The problems with remapping are:
- the keyboard shown in Keyboard Layout preflet swaps keys (cf #6362), and that's not intuitive, because at the same time key names change in the menu.
- terminal applications begin expecting different shortcuts, e.g., Alt+C instead of Ctrl+C for quiting. That's very inconvenient for terminal users.
- potentially, other applications will also suffer. For example, I had a great inconvenience when I swapped Cmd and Ctrl in OS X's preferences, and vmWare Fusion began treating Cmd as Ctrl and vice-versa (thus I had to use Cmd-shortcuts in Windows running in vmWare until I updated it to a version that allowed me to remap shortcuts).
Generally, I think an application should always be able to know which exactly physical key was pressed if it needs it. I suspect that simply swapping keys deeply in the OS, like we seem to be doing here, is sort of limiting.
Change History (2)
follow-up: 2 comment:1 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Replying to bonefish:
Generally, I think an application should always be able to know which exactly physical key was pressed if it needs it. I suspect that simply swapping keys deeply in the OS, like we seem to be doing here, is sort of limiting.
I don't see why.
Even more, if the application really wants to know, it can -- every key event does not only contain the system mapping, but also the physical key.
Replying to rq:
That's totally intended. The keymap shows the mapping (i.e. function) of the keys.
That is only inconvenient for people used to an OS using the Control key as shortcut modifier and inconsequent terminal program implementations. It is obviously impossible to use Control as shortcut key and as control key in the terminal at the same time, so these terminal programs invent alternative shortcuts for functions that have otherwise system-wide common shortcuts. Great solution!
Haiku's solution is consistent: If you use Alt as Command key (which is the default), the Control key is mapped to Control and acts like that in the terminal (just as on the Mac or on Amiga (at least back in the olden days)). Setting the Control key as the shortcut modifier, switches the Control and Alt key mapping transparently to all applications, which is exactly what is intended. Otherwise all applications that use the Control function for something would have to handle clashes, which is simply stupid.
Er, potentially, Haiku is not OS X, nor does it even run VMware Fusion.
I don't see why.
The thing that needs to be added to Haiku is a fully featured shortcut management and a respective API. That would give the user total control over shortcuts and would also allow reconfiguration to the stupid setups of other OS that some users want to punish themselves with.