The complexities of keyboard layout switching

by Michael S. Kaplan, published on 2006/07/21 03:16 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/07/21/673569.aspx

It is an interesting idea, and also a difficult one. The list of installed keyboards (which actually means the list of enabled keyboards) is a per user setting on a machine. And, as Chris mentioned, every language can have more than one keyboard attached to it.

So, let's say that I have English and Korean enabled, with multiple input methods on each:

Thankfully, the selection mechanism is smart enough to remember the selection in each language. So that if I

It is smart enough to remember that I switched to that specific IME. This is as good thing.

Now we move to the complicated part -- the fact that actual, specific combination of language and layout is a per thread setting. This has been the design for a long time and it usually leads to two potentially non-intuitive behaviors:

Now that first point is longstanding behavior that is often relied on by people (including me!), and although it is not immediately intuitive it does kind of make sense, especially when one finds oneself e.g. typing a document in a particular language and not expecting that to lead to changes in one's email program....

The secone point is the one that Chris is talking about. Any time one changes the keyboard layout for a language, then isn't it often more likely that you would perhaps expect that switch to be applied to all other UI threads in the session that use this language?

Clearly there are exceptions here (plus there is a legacy expectation that some people may be used to), but that is also why Chris is suggesting some kind of configurable switch. I tend to agree with Chris that the change here is more likely to meet the intuitive expectations of customers, don't you?

This kind of change is complicated for someone to do themselves -- there would need to be a call to SetWindowsHookEx to inject a DLL into every thread to run code to check GetKeyboardLayout -- and if the languages (in the LOWORD) match and the device (in the HIWORD) do not then make a call to ActivateKeyboardLayout to make the switch.

But if you look at the Language Bar and the Text Services Framework, it already has a little something running in every thread, managing this information. So it is in a much better position to architect the kind of cross-thread, cross-process communication that might be required here.

Not an easy change, by any means. But an excellent feature request that is definitely worth considering for a future version of Windows. Good idea, Chris! :-)

If we get to talk about keyboard annoyances: starting with XP (I think) changing the user locale (“Standards and formats”) also adds the matching keyboard.
I know, might be about convenience, and the fact that people changing the “Standards and formats” kind of think is about “language I want to use,” kind of including the keyboard.
It might be convenient for the users, but formatting should have nothing to do with keyboard.

I think the confusion of the poor user is caused by the fact that the keyboard layout is well hidden. It was moved from keyboard (which might not be right technically, but it makes sense for a normal user), and is now buried under the “Language” tab (no indication about keyboard) and under something called “Text services and input languages.” Again, kind of clear for the programmer, but the user wants “keyboard.”

So, “feature request”: let formatting settings to affect formatting (not keyboard) and make clear where the language of the keyboard is set.

Would be nice indeed for casual users. They get frustrated and I haven't found a way to thread my wife yet;)

Another nice feature would be more control on the keyboard shortcut. Choices are limited and they sometimes conflict with other applications & plug-ins.

This design was annoying me just the other day. I was working at home and using remote desktop to my office. I already had a desktop session active from the previous day when I was sitting at the console. My work machine has a UK keyboard.

In the morning I was working from my garden on my laptop. (Yes. I know I'm a smug git!) My laptop has a US keyboard. I switched over to the US keymap when I happened to have my text editor focused, and it worked. I then switched somewhere else and ended up typing at-signs where I wanted quotes. After a while I had them all switched.

Later in the day it got a bit too windy to work in the garden, so I retreated to my home office where I have a UK keyboard again. You can guess how the rest of the story goes.

Of course, I knew about this issue before I started, but I don't encounter it very often since it's only really when Remote Desktop comes into play that you end up typing with the "wrong" keyboard.

For my purposes, I'd be happy just to have an extra button on the language bar called "Change All Windows" which applies whatever is selected across all threads there and then.

I've moaned before about Remote Desktop dealing in scancodes rather than characters, but I accept that it's a architectural limitation. :)

Even better and probably more evil would be not to do it for all windows, but for that physical keyboard (if you used a keyboard shortcut) or all physically attached keyboards at the time (from a menu, etc.)

I've got a US PS2 keyboard and a Japanese USB keyboard. It would be insanely cool to be able to type in the right language just by moving to the other keyboard. Maybe not convenient, but cool.

You don't need to detect what's actually painted on the keys, "just" what HID actually made the input. (It would make even more sense for mice with different DPI properties, or you could even have two identical pointing devices, just with one carrying an implicit setting of much lower sensitivity for pixel-precision work.)

Hi cnettel,

This causes all kinds of other problems like with the input queue and more importantly with the input cache -- what do you do with input that is in progress like via dead keys or IMEs?

Such a deisgn would not only difficult to untangle from the current one, but it would break much of the design of input that is avilable now, from the messages on up....

That's more what I was thinking. You manually tell it what language to use and the system attaches that information to that particular device. And I'm also thinking of it more as "wouldn't that be a nifty piece of magic" rather than an actual suggestion. :)

Occupational hazard -- ideas brought up here get automatic feasibility assessment. :-)

So the actual thought here is to, rather than split input language per thread and then share all devices among them, split it per device AND per thread, and give device its own input queue....

Woohoo! One of my bug reports has made it into a blog post on one of my favourite blogs... so cool!

Thanks Michael - I really appreciate the extra insight and comments you've made here (and very reassuring compared to the feedback in the bug itself).

Chris.

I just got bit by this misbehavior. I switched to the Dvorak keyboard since the last time I tried using Windows, and when my computer ended up in the shop, I ended up sharing an XP box with someone else. I thought I'd just flip the switch whenever it was my turn to use the thing, but I've apparently been spoiled rotten by Mac OS X.

Not only shouldn't assigning different keyboard layouts to every single window be the default, but I'm having a hard time imagining *any* situation where you'd want it to work that way. This is total madness.

And, five years and two versions of Windows later, the problem remains: if I am working with multiple languages in multiple windows, as I often am, then there is no way for me to predict what will happen when I press a key on my keyboard except to squint at a tiny icon down at the corner of the screen that indicates which layout is active for whichever window has the focus. Click into another window? All bets are off.

The only thing that's changed since 2006 is that, so far as I can tell, none of the third-pary programs people have written over the years to fix this bug work any more in Windows 7. Yay Windows.

It still remains too much of a corner case to interest the owners of Cicero or User to or the Window Manager to jump in and fix the issue.

Not sure what programs you're talking about or their methods of action, but I assume none of them were trying to fix it by supported means?