Re: Thoughts and questions about input

[Shahbaz A Chaudhary <chaudhar engin umich edu>]

First of all I am not familiar with teh technical details of this project
but am interested as a user and a developer who will eventually make use
of this functionality.  Having said that...

I am currently using widnows 2000 which come with an english default.  I
included Urdu as well and now when I need to switch between teh two I use
a key combination of "alt+left_shift."

I think it is important to be able to switch between the modes since,
especially in casual urdu writings, a large percentage of urdu text is
bound to contain english words.  If a user needs to use a mouse (which
means take their hand off the keyboard and disrupt their train of thought
(and train of typing) ) then it will be an obvious hassle.

Now switching between multilingual typing modes is different from
switching between overall gui translation.  By that I mean an Urdu user
may be using english version of X-windows, but just need the ability to
type a few lines in Urdu--which is when we need quick and simple mode
switching.  If the user wants his/her whole gnome environment to switch
from displaying menus etc. in english to urdu, then I don't see a great
need for quick changes (but then again I don't think Pango needs to worry
about this anyway).

Shahbaz C.
chaudhar@umich.edu


On 12 Mar 2000, Owen Taylor wrote:

> 
> [ 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
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> To unsubscribe: mail gtk-i18n-list-request@redhat.com with "unsubscribe"
> as the Subject.
> 
>