Re: Input Method of Gnome

[Owen Taylor <otaylor redhat com>]

[ CC'd to gtk-i18n-list@redhat.com - which is probably a more
  appropriate, or at least, less noisy, forum ]

NIIBE Yutaka <gniibe@chroot.org> writes:

> Just my thinking for input method of GNOME.
> 
> According to my own experience with GNU Emacs and input method for it,
> I think that it would be good to re-design input method structure for
> Japanese, using CORBA.  With the current situation of GNOME desktop
> environment, we could develop it in the "right" way, rather depending
> on old developped design of X.
> 
> Input method for Japanese usually goes two steps.
> 
> Step 1: Roman translitaration sequence --->  Kana  (we call this translation)
> 	(Using something like automaton)
> 	Mapping is one to one.
> 	One roman sequence corresponds one Kana character most case.
> 
> Step 2: Kana sequence ---> Kanji sequence  (we call this conversion)
> 	Mapping is not one to one.  Some scheme to select the candidates
> 	are needed.
> 	Translating Kana to Kanji, it uses dictionary and some
> 	sort of natural language processing technique.
> 
> To offer consistent environment for desktop, all translation and
> conversion should be done in one place, or it results inconsisitent,
> if each application does it by itself.
> 
> It's like situation for sound output for application.  If each
> application does it by itself on the host it runs, different speaker
> would ring.  To solve the situation, we define one sound output for
> desktop.  Likewise, we define one input method (in other word, one
> translation/conversion engine) for desktop.
> 
> In the design of X, it uses its own way to define the input method and
> the way to communicate with the engine.  IMHO, it's some kind of kluge.

OK, let me first say, I don't like XIM very much. 

 - It is a resource hog. (40-50k of memory for every single
   application that initializes XIM. Plus tons of disk
   access, lots of tiny mallocs, and Purify errors...)

 - It supports too many different input styles, all of
   which are optional for both the application and the
   IM.

    1) RootWindow [ feedback in separate window ]
    2) OffTheSpot [ draws in separate portion of apps window ]
    3) OverTheSpot [ input method fakes in place editing
                     by putting window over apps window ]
    4) OnTheSpot [ application draws everything ]
   
   No sane application is going to implement all 4 of these,
   I think the common thing is to support 1) and 3). [ That's
   what GTK+ does for Entries and Text widgets ]

   But 1) isn't really very nice, and 3) doesn't work well
   when rendering anything other than straight Xlib text
   on top of a solid background. 

   For future versions of GTK+, I'd like to change its
   support to 1) and 4) only, but I don't know how well
   existing IM's support the callbacks necessary to
   handle 4). 

 - It makes multiple separate entities deal with the same
   X windows and X event stream, leading to all sorts
   of race conditions and strange interactions.

But, abandoning XIM would have its difficulties. XIM, for
better or worse, is the X standard, and input methods
have been developed for a number of languages. To
my knowledge:

 - Compose-based IM for western languages (built into Xlib)
 - Thai (built into Xlib)
 - Chinese
 - Japanese
 - Korean

Replacing kinput2 might not be a problem, since you
can just talk to wnn or skk directly, but I don't
think replacing the IM's for other languages would
happen so quickly. 

And people are, or will be, also using GTK+ with 
commercial IMs.
 
> Now having CORBA, why don't we use it for input method!

The big problem here is that if we replaced XIM, we would
be replacing it, not for GNOME, but for GTK+. GTK+ needs 
to be able to access the IM for input into its Entries
and Text widgets. GTK+ cannot depend on CORBA.

If I where designing a replacement IM system for GTK+
(and see above for why I don't think that is necessarily
a good idea) I'd probably go with a shared library
mechanism where GTK+ would load in an appropriate module
to handle the details of an input method. That module
would be free to talk CORBA to a backend server if it
wanted.
 
Regards,
                                        Owen