On Thu, Dec 18, 2008 at 06:02:33PM +0100, Nicolas Mailhot wrote: > Layout and language are closely related. Basically for a globalized > user that types in multiple languages, you have two situations : > 1. If his current layout is sufficient for the other language, he will > perform a language shift but keep the layout > 2. Otherwise he will perform a simultaneous language+layout shift > > So both are dynamic properties that have similar change triggers and > will probably be controlled by the same desktop bit of code (and > similarly most apps which will want the status of one of them will > also want the status of the other)
I'm a globalized user that types in 4 languages or so. I have one common layout for all of them, which is a US qwerty with Multi_key and Kanji keys added. In my experience language choice for input is never at the whole desktop level but at the window or even more often logical subwindow level (file in xemacs, tab in firefox for wikis...). I expect such a language change to stay fixed in the logical subwindow context I do it in. I don't want a "switch to english" in my grant proposal edition window acts on the mail writing I'm doing with the french colleagues I'm communicating with about it. OTOH, if I was doing layout switches, I suspect I'd hate having it change with the focus. Keyboard layout is semantically linked with the keyboard, so moving the mouse (focus-follow-mouse) and possibly clicking in a window has nothing to do with the keyboard, so shouldn't change the layout (except if what you click on is a change kb layout icon/button obviously). I really think that in terms of mental model, layout changes and input language changes usually don't have the same scope, and the X server and X protocol are at the wrong level for the language changes but at the correct level for keyboard layout changes (under client-side control obviously). OG. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg