Re: Input Method of Gnome

[NIIBE Yutaka <gniibe chroot org>]

Ulrich Drepper writes:
 > What are the benefits over the current scheme?  The applications using
 > the new service must in any way we changed to use the CORBA
 > mechanisms.  So this is not different from changing them to use XIM.
 > I would even say it is more difficult since the XIM methods embed
 > easily in existing X code.
[...]
 > But I really fail to see the major win you are hoping for.  Could
 > you elaborate this?

I should make the point clear.  The last mail was not good
explanation.  Sorry.  

Yes, the XIM scheme is for consistency in desktop.  It offers
consistent input method for desktop.

Let me explain more.  Here, you don't need to know about Japanese.
Please think about the translation/conversion as something like spell
check or words selection.

XIM comes with two scheme, frontend model or backend model.  

In the frontend model, XIM server stands in front of the application
and does input processing.  As it (almost) doesn't require any
help/change in the application, it works well somewhat.  This is the
way current GTK+ widgets works for Japanese. (I guess.  Please correct
me if I'm wrong. ) Note that in the process of input keystrokes, it is
not the application but the XIM server which displays window for Roman
sequence input or Kanji selection.

Frontend model:
     USER   ----> { XIM Server } ----> { Application }
		   Translation/
		   Conversion/
		   Selection...
       [Input Window ]
           <======    

OTOH, in backend model, the application control everything.  It is the
application which catchs the input event, sends the string to XIM
server.  It also displays the window when needed.

Backend model:
     USER  ----> { Application }  <---->  { XIM Server }
					   Translation/
	 [Input Window ]		   Conversion/
	     <======    		   Selection...

While frontend model works with least changes of the application (in
many cases no change at all), it is a kind of kluge, as the
application generally has context.  Tipical example is mode of VI.  VI
has mode.  Command mode and input mode.  HJKL does left, down, up, and
left in command mode, while it's just string input in input mode.
While we are at command mode, Kanji is not expected, but XIM server
doesn't know about the mode of VI.  Such is very annoying, assumed it
is input mode and type phrase with Kanji selecting the candidates, but
it happend to be command mode and lost all inputs.  (Yes, we could
define some control from the application in frontend model to resolve
such situations, but it means change of the application.)

Backend model works best (by definition :-) as the application does
everygthing.  However, it requires (possibly) many changes in the
application.  While XIM offers backend model, in fact, there's no
application which uses XIM with backend model, AFIAK.  The reason seems
that it's no use to use XIM server in that case, but it's natural to
use conversion server directly.

			*	*	*

Here are my points: I think that backend model is the right way.  It
would be good if GNOME comes with backend model for Japanese Input.
To do so, we need to change the widgets to call the service, but XIM
is useless for this, as it offers additional layer which results
inefficiency.  Instead, we should think about CORBA.

Also, I think that it's good opportunity for conversion servers to
define their service in CORBA.

With CORBA service for conversion, change text widget, entry widget
with backend model.  It's best way, I believe.

In other words, I believe that the right way for Japanese input is
reached by generalizing "editing" in text widget.  Like calling
"spellcheck" service from the widget, call "conversion" service from
the widget.

Well, I need more consideration.  I know.  Above is just idea.

P.S.:
Currently, I use input method called "EGG" in GNU Emacs, it's backend model.
Emacs communicates conversion server by itself.
-- 
Niibe Yutaka