Thoughts and questions about input

[Owen Taylor <otaylor redhat com>]

[ Warning: long, disorganized message follows. What I'm
  really asking is: "In the ideal world, how would input
  work in GTK+?". Feel free to send ideas, even if they
  are not related to the textg below. ] 


Over the weekend I got somewhere with putting Pango into GTK+ - 
after creating a few labels with mixed Korean, Hebrew, etc in
them, the natural next thought was GtkEntry and input.


Looking at the big picture for input, scripts can roughly be
classified into three groups:
  
 - Modified Roman layouts.
 - Completely separate keyboard layouts (Russian, Arabic, Hebrew)
 - Full input methods (Chinese, Japanese) with preedit strings,
   status windows, etc.

There are a few twists on these types. For instance, Thai is basically
just a separate keyboard layout, but there are prohibited combinations,
so there is a need for a simple input method to validate the input.

While the main thrust of Pango is to allow people to work in their own
languages, I think that full multi-lingual input is a compelling
feature that we need to support. (Nobody would design a system that just
allowed entering Chinese, and not English. Why should Arabic + Chinese
be any different?). But I don't have a clear picture of how this
should look to the user.


I can think of a number of ways of switching languages:

 - via keyboard hotkey. (This is most suitable for toggling between
   two languages). 

 - via right-click menu on the input field. 

 - via system setting. (This could be in a control-panel, or in
   a shortcut applet of some sort.)


In many cases, the expected behavior is that changes to the
language setting are global. In X right now, when you switch between
Russian and English keyboard layouts, this is not much different than
Caps Lock - the user sees it as a property of the keyboard. In
general, I think having a per-application language setting would be
confusing to the user, and having a per-input-field language setting,
worse.

In the cases where depending on Xkb is an option (basically everything
but full input methods), this is pretty easy to accomplish, since it
IS a global setting. In most circumstances, GTK+ can just wait for
keysyms, and interpret them. (The one exception is using a single
caret for bidirectional languages, in which case, one needs to know
the current keyboard direction.)

But the same is not really the case when input methods come into the
picture. For XIM, the choice of the input method is basically under
the control of the application.  (It is based on the locale setting
when the input method is opened.) While an application can switch
input methods on the fly, it isn't going to propagate globally.

We could put a "INPUT_LANG" property on the root window. GTK+
programs would watch that, and when it changes close the current
input method and open a new one. However, that possibly is going beyond
the realm of a toolkit's proper scope.


I'd appreciate people's thoughts and experience in the matter; some
questions I have:

 - How does switching input language appear to the user on other operating
   systems that support it? (I believe both the Macintosh and Windows 2000
   have support for this.)

 - Is it important (or even good?) to make the language setting appear
   to be global?

 - Should the keyboard state ever change by something other than
   a user action? (From what I've seen of Macintosh docs, if you
   are using Arabic, then clicking in a segment of Arabic or 
   English will switch the keyboard state to match the new segment.)

 - Is supporting a single caret important for bidirectional
   languages? (As mentioned above, things becomes somewhat easier
   if you only support dual carets.) 

   [ A dual caret (used on the Macintosh and in Java) means that 
     if you are sitting on a directional boundary, then two carets
     are visible, distinguished by shape or color. One caret indicates
     where a RTL character will appear if typed, the other caret indicates
     where a LTR character will appear if typed. ]

Thanks,

                                        Owen