X12 [wasRe: Zoom Support]

[Olivier Galibert]

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.