Thoughts and questions about input
[ 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
- 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,
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. ]
To unsubscribe: mail firstname.lastname@example.org with "unsubscribe"
as the Subject.
[ This mail was originally sent to email@example.com ]
[ and was forwarded to this list automatically. Big5 characters are ]
[ also converted to GB at the same time, Please note that there may ]
[ be errors during the conversion as this is not done by a human! ]