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


Chris was thinking about how keyboard layouts work on Windows, and suggested:

Windows allows a user to set up multiple keyboards within an input language, and switch between them either by a keyboard shortcut or by clicking an icon on the taskbar. However, when the keyboard layout is changed, the change is only applied to the current window.

This behaviour is extremely confusing to users, as the characters that appear as they type then vary from window to window. By default, using the keyboard shortcut or clicking the taskbar icon to select another keyboard, the new keyboard should be used in all windows.

If it is necessary to keep the old behaviour, this should be done via a (non-default) check-box on the "Language Bar" tab of the "Text Services and Input Languages" applet.

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:

If I look at the Language Bar, I have the option of choosing the language:

and then also the keyboard layout under the language once it is selected:

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.

Yuck.

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! :-)

 

This post brought to you by ђ (U+0452, a.k.a. CYRILLIC SMALL LETTER DJE)


# Mihai on 21 Jul 2006 5:38 AM:

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.

# John Ingres on 21 Jul 2006 7:14 AM:

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.

# Ben Cooke on 21 Jul 2006 11:33 AM:

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

# josh on 22 Jul 2006 2:32 AM:

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.

# Michael S. Kaplan on 22 Jul 2006 3:42 AM:

Hi Josh,

That one would actually be much harder, given the lack of any good standards related to detection of the hardware's language....

# cnettel on 22 Jul 2006 9:26 AM:

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

# Michael S. Kaplan on 22 Jul 2006 1:32 PM:

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

# josh on 23 Jul 2006 4:30 AM:

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

# Michael S. Kaplan on 23 Jul 2006 7:48 AM:

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

# Chris on 26 Jul 2006 11:02 AM:

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.

Nick Fagerlund on 27 Mar 2008 4:43 AM:

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.

YayWindows on 30 Jun 2011 5:26 PM:

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.

Michael S. Kaplan on 30 Jun 2011 6:07 PM:

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?


go to newer or older post, or back to index or month or day