Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#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)

in reply to:  description ; comment:1 by bonefish, 14 years ago

Resolution: invalid
Status: newclosed

Replying to rq:

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.

That's totally intended. The keymap shows the mapping (i.e. function) of the keys.

  • terminal applications begin expecting different shortcuts, e.g., Alt+C instead of Ctrl+C for quiting. That's very inconvenient for terminal users.

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.

  • 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).

Er, potentially, Haiku is not OS X, nor does it even run VMware Fusion.

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.

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.

in reply to:  1 comment:2 by axeld, 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.

Note: See TracTickets for help on using tickets.