Show/hide hotkey uses raw keyboard keys, ignores keyboard layout

By w...@wisq.net on October 15, 2011 16:10 (imported from Google Code)

---

The iTerm show/hide key does not respect keyboard layouts. When set, it attaches to a raw keyboard key — even though it appears to attach to a translated (mapped) key in the current layout. This causes problems when switching between keyboard layouts, or if using a device that remaps keyboards at the hardware level (even if I'm pressing the same logical key).

Steps to reproduce:

1. In System Preferences, select a keyboard layout — let's say Dvorak.
2. Set your iTerm show/hide key to some key — let's use command-(key next to tab).
3. iTerm will display the key you chose in the current keyboard layout. Using the above examples, it would now show "⌘'" (command-apostrophe).
4. Change keyboard layouts — let's go back to Qwerty.
5. Bring up the iTerm preferences. Notice that it still displays the key you chose.
6. Attempt to bring up iTerm using the displayed (logical) key. With the above examples, that would be command-apostrophe (key next to enter) in Qwerty. (Nothing happens.)
7. Attempt to bring up iTerm using the same keyboard (physical) key you set it up with. With the above examples, that would be command-(key next to tab), i.e. command-Q. (It works.)
8. Set your iTerm show/hide key to the same physical key. Notice how the displayed logical key changes, even though you're not actually changing the physical show/hide key. With the above examples, it would now display "⌘Q" instead of "⌘'", but nothing has really changed.

(FYI: "a" and "m" are the same in Dvorak and Qwerty, so if you want to test with different keys, don't use those two.)

Given that the iTerm preferences say that my key is set to <X>, I would expect that pressing the logical key <X>, in any layout, would be the trigger key. Instead, it really means "the physical key that maps to logical key <X> when your keyboard layout is set to the same layout as when you set this setting". Not entirely intuitive. :)

Running iTerm2 1.0.0.20110909 on OSX 10.6.8 Snow Leopard.

The full, long story:

I use Dvorak as my main keyboard layout. Usually, I run with a normal keyboard (e.g. the built-in Macbook keyboard) with Dvorak as my software keyboard layout (in System Preferences) — let's call this "software remapped".

Sometimes, I use a hardware device that remaps Qwerty to Dvorak at the hardware level. I type in Dvorak, but the computer sees me typing the same letters in Qwerty instead, and I set my software keyboard layout to Qwerty — call this "hardware remapped".

(This is useful for games, which often also bind to raw keyboard keys. Or for pair programming, where we want two USB keyboards, one in each layout. Or for attaching to a KVM switch that includes a hardware remapper. All of which are common scenarios for me.)

In software remapped mode, my global iTerm show/hide key is command-apostrophe (⌘'), where apostrophe is the key next to "tab". This works fine so long as I continue to use software-remapped mode.

If I switch to Qwerty (with no remapping), the keyboard layout changes, but the iTerm activation key remains the same. It's now command-Q (key next to tab), which shadows the existing Mac "quit" key. However, iTerm still shows it as "⌘'", ignoring the fact that it's really "⌘Q" now.

If I then enable hardware remapping, the raw keyboard keys change, meaning that I now have to actually enter command-Q in Dvorak rather than command-apostrophe. (That's like pressing command-X on Qwerty.)

Obviously, this makes it rather difficult to switch between the two remapping methods as needed, even though I'm essentially pressing the same key (command-apostrophe) at all times.

(You can probably imagine the looks I get when I tell my pair programmer that they should bring up the terminal using command-Q.)

I don't know if binding to a raw keyboard key is a fundamental limitation of being able to have a global show/hide key, but it's certainly confusing behaviour. Also, I'm guessing some users may prefer that the key not change based on keyboard layout, so if this is "fixed", it should probably be a toggle option.

---

com.googlecode.iterm2.plist

Comment 1 by gnach... on November 03, 2011 05:36

---

I researched this and it looks like the only APIs that could do this (to translate a keycode to a character) were deprecated with Carbon and can't be used in 64-bit apps. HIToolbox offered the APIs, but it's no longer available and its replacement can't do this.

Comment 2 by Denis.Bile... on July 20, 2012 08:52

---

I think I have a similar problem. My MacBook keyboard generates this event:

KeyPress event keycode 18 (keysym 0x60, grave)

and my USB keyboard generates this event:

KeyPress event keycode 58 (keysym 0x60, grave)

Thus pressing the key on macbook causes iTerm to appear and pressing the key on the USB keyboard causes the grace accent character to be printed.

---

Perhaps the solution for this is to make iTerm2 supports setting more than one key for hotkey?

This would solve my problem, I'd simply bind both keys as hotkey.

Milestone changed to Future Release

Milestone changed to Feature Complete 3.1

We should keep a separate binding per input source. The relevant APIs are described in these questions:

http://stackoverflow.com/questions/781777/cocoa-learn-currently-selected-keyboard-layout-input-language

http://stackoverflow.com/questions/31969341/get-keyboardlayout-id-for-a-keyboard-layout-tisinputsourceref

Fixed in commit 1ce14c65.

Status changed to closed