Re: Thoughts and questions about input

[Owen Taylor <otaylor redhat com>]

"Adam Sleight" <adams@linearcorp.com> writes:

> status windows?  I'm only familiar with Japanese.  I hate when you have to look
> at a small window to change kanji at the bottom of your screen and after
> choosing it, it inserts it into whatever application.  I believe that is what
> Netscape 4.72 on Windows currently offers.  IE5 has Japanese input capability
> but only within IE5..(possibly Outlook too just guessing). When forced to use a
> status window it is easy to lose concentration.  It's better to change whatever
> Korean, Chinese, Japanese directly where the user is inputting text rather than
> off to the side somewhere.

"status windows" are a separate thing fom "preedit windows". A status
window would be a window that would indicate that you are composing
input currently, and the exact mode you are in. (For instance, if you
switched into a mode to enter characters by numerical code, the status
window would reflect that.) Status windows can also be used for doing
things like displaying possible candidates for a particular conversion

There are various styles of handling preedit strings:

 1) On-the-spot: the preedit string is displayed at the eventual 
                 insertion location
 2) Over-the-spot: the preedit string is displayed in a separate
                   subwindow over the insertion location. (This 
                   is typically done in such a way to provide
                   a simulation of 1)
 3) Off-the-spot: the preedit string is displayed in a separate
                  area of the toplevel window. 
 4) Root-window: the preedit string string is displayed in 
                 a separate window.

GTK+ currently supports 2) and 4). For 1.4, I want to move this
to supporting 1) and 4), since 2) does not look good unless you
are sticking very close to the way Xlib renders things.

The root-window input style would only be used for IM's that
didn't support on-the-spot input, or in case an app didn't
support it. (The standard GTK+ widgets will support on-the-spot
input, and it won't be hard to add to applications, but it will
still be more a bit more work to support than the root-window 
input style.)

> > > 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.
> 
> You can have tons of combinations...say for example someone choose Japanese
> input method.  You can could input with a Japanese layout keyboard but I doubt
> many people do it that way anymore.  Instead they just input romaji
> (a,i,u,e,o,ka,ki,ku,ka,ko) rather than just "ka" as a single key.  Perhaps
> allowing them to set a default as to when they change into a language of input
> as to which keyboard layout would be nice.

I see this as mostly a matter of configuration of the input method.
Once an input method is in use, it is up to it whether it looks for roman
keysymbols or hiragana keysymbols.

> > > 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. 
> 
> I light this option best.  In the control-panel they can choose which languages
> that they wish to have available for switching and in the right-click icon at
> the bottom they can choose amongst those 2 or 3 or however many they prefer.

Yes, this is basically what I would imagine. (Though hotkey switching
is clearly necessary too.) 

The somewhat confusing thing when trying to accomodate both languages
like Japanese and languages like Russian, is that, while for Russian
you are either in "English" mode, or "Russian" mode, for Japanese, the
choice is a bit different - you are either inputting through the input
method or not inputting through the input method. So while a Russian
user wants a hotkey to switch their keyboard between English and
Russian, the Japanese user's hotkey keeps them set for Japanese, but
activates and deactivates the input method.

> > >  - 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.
> 
> yes it would be confusing...as far as one app having menus in a certain language
> and saving them as default.  I think it's all Chinese or no Chinese and a
> restart of X should be necessary..most likely.  Otherwise too many fonts would
> have to be loaded?  I'm not sure actually how it works but it wouldn't be all
> that inconvenient.
> 
> However, the user should be able to switch on the fly into their chosen input
> method in any application.  In Japanese the HOTKEY is ATL-~ (squiggly character)
> which toggles between English-Japanese. I think F7 is katakana and F8 is
> hiragana (could be wrong). Would DnD be supported possibly.  Say if a user
> inputted Japanese in gEdit and wanted to copy over to Gimp or Eye of Gnome
> whatever..that would be cool.  Let's say the gEdit app had Japanese Input
> selected and you dragged it over to Gimp which didn't have Japanese Input
> selected..but would all GTK+ apps be able to at least read Japanese fonts and
> not be able to manipulate them ...only of course if Japanese input method was
> chosen.

This will certainly work with Pango. I already have samples running
locally of GTK+ programs with some labels mixing, say, Korean and
French. The same will work for entries and text widgets soon. Of course,
applications will need some modification to load and save multi-lingual
text correctly, but I don't think this will be that much of a burden.
(Using Unicode makes this a lot simpler than it would be if we were,
say, trying to do the same thing with iso-2022.) 
 
> > > 
> > > 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.
> 
> If it propagated globally then have a quick HOTKEY to revert back would seem
> necessary.  I doubt most people will be switching back and forth between more
> than two langauges, maybe three...at least 95% or so.  

Certainly the case. I suspect the figure is more like 99%. But those 1%
of user's are the ones who really care about this stuff. So I'd
to set up things to work for them as well.

> > > 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.)
> 
> Win98 English...with IE5 Japanese Input support...their is an icon..lower right
> En and when switched to Japanese it appears Ja. Then you have choices (small
> toolbar) of input method..Hiragana (use spacebar to select kanji), Katakana,
> English, Half-size Katakana, Half-size Hiragana.
> 
> Under Win98 Japanese edition you can install Photoshop English edition and input
> Kanji into Photoshop and render graphics, etc. with Kanji. This would be nice to
> be able to do the same under Gimp.  Gimp having English menus with various input
> methods for various languages and have it render in whatever character set.
> 
> > > 
> > >  - Is it important (or even good?) to make the language setting appear
> > >    to be global?
> 
> global...well it probably wouldn't be hard to do.  File, Save As, New,
> Open..once they are translated it can reflect across all applications.  It may
> look corny if some menu items were left untranslated though.  I think having the
> users choose (translate known menu items into so-and-so language) could be an
> optition.  Abiword for example, Korean...they would probably want all menu items
> to be translated over though.  Many people throughout the world know no Enlglish
> whatsoever...so any English would be scary.
> 
> Having some sort of defineable parameters like .po offers would be the best bet
> and leave it up to the individual translators for each application to translate
> the uncommon menu items.  Perhaps within each app it would show a menu list of
> the languages that it has been completely translated into.  Thus, if it was
> partially translated they'd know what to expect.

When I said here "language setting", I meant input language setting.
As I mentioned in another mail, I don't think switching the language
of translations on the fly is all that interesting or doable.  I think
a simple global setting that requires logging out and logging back in
is pretty sufficient here.

The infrastructure for translating programs (but not switching on the
fly) is already pretty well advanced now, so that's one thing that,
luckily we don't have to worry about now. (Yes, gettext does have
deficiencies, but I'd consider this area to be pretty much a "solved
problem".)

> > > 
> > >  - 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.)
> 
> Win98 English does this with Japanese Input.  For example. Right now I'm typing
> in IE5 webmail in English.  Another window I have Yahoo Japan open and selected
> Japanese Input Method.  As I flip between them it changes.  However, I chose
> Japanese input method.  It should never switch automatically unless the user has
> choosen that input method for that window or app.  Just because I open a
> document in that has some English and a little Japanese....it shouldn't
> automatically switch to that Japanese language unless that was the input method

OK, a good data point.

Regards,
                                              Owen