Re: Input Method of Gnome

[Hilary Cheng <hilarycheng usa net>]

Maybe I am wrong. Pls correct what I am wrong :p

IMO, I think FrontEnd model is much better. Since All those existing
applications ONLY need a small change. They need to change to support unicode
character input and conversion from Unicode back to user's favourite character
set / user's favourite character set to Unicode. As I know, X Applications are
using Event Driven Model. Any Keyboard event will throw to Applications. Then
Application will do anything that they like to do. If we want to support Input
Method of International Language, we can do it in this way.

Case 1: We want to Type Some NON-ENGLISH Characters ( Chinese / Japanaese, etc.)

Keyboard Event --> XIM --> XIM Generate a Character Event --> XServer -->
Applications

Case 2: We want to Type Some ENGLISH Characters / Some Special Keystoke (Arrow /
Function Key)
Keyboard Event --> XServer --> Applications

In Case 1, If the user want to type some NON-ENGLISH Characters Set, they just
simply TURN ON Input Method ( Like M$ Windows ), choose their favourite input
method. and then XIM will send the characters that users typed to the
application rather than sending a group of keystokes.

In Case 2, If the user want type some ENGLISH Characters set / Keystoke, it is
similiar to the Current XServer. We just send all those keystoke event into
Application. Application will handle as a keystoke event rather a character
event.

For the international language, most of them are just simply type characters /
conversion between different language. It will not use such characters to
control applciation.

It is just a personal opinion about it.

Regards,

Hilary

NIIBE Yutaka wrote:

> 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
>
> --
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.