Re: Input Method of Gnome

[NIIBE Yutaka <gniibe chroot org>]

Hello Owen, thanks for Cc:-ing to <gtk-i18n-list@redhat.com>.  I
haven't known it.  Hello hackers!

Owen Taylor writes:
 > But, abandoning XIM would have its difficulties. XIM, for
 > better or worse, is the X standard,

XIM exists and is X standard, it's true.  Nevertheless, if it's not
good enough, we should go further.  And my strong feeling (yes, it's
just a feeling, not so logical so far) is that we haven't reached good
solution for input method with X *yet*.  Really.

I believe that input method support is complex problem and should be
handled in the higher layer, in the big picture.

In the days of X development, we don't have GNOME, CORBA, Guile
Extention, dynamic loading of shared library, or good widget set like
GTK+.  Hence, people (at that time) force to handle it in the lower
layer and it resulted XIM.  As it's complex enough, they defined and
split out Input Method Server, not to define the policy, but to offer
the mechanism (in the lower layer).  In that day, it would be only
possible solution.

But let's think it again from the view of the desktop environment.
Now we have the big picure.  We have good tools in the desktop
environment.

Well, from the view of the desktop environment, the structure of XIM
is not good, IMHO.  We should not define Input Method Server
independent and solve it with the lower layer.  We can handle it in
the higher layer (i.e. the desktop environment), in more natural way.

My proposal: Throw XIM out.  It's only the workaround of the days in
which we needed to define in lower layer.  We need total design of
text/entry widget with support of input method for
internationalization.  It can be solved straightforward in the layer
of widget.

 > 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.

Thank you very much for your suggestion.  It's cleaner solution to
have interface to CORBA within a shared module to be loaded.

You may know that there're also implementations of input method in
Emacs Lisp for many languages.  So, I think about text/entry widget
with Guile extention.

Besides, I think that it's good to have extention scheme in text/entry
widget, as people want editing features with it.

How about following?

  (1) GTK+ Text/Entry widget with extention (possibly in Guile, or shared 
      module)
  (2) Input method support implemented as extention module for Text/Entry.
  (3) Japanese input method suport as extention module for Text/Entry, 
      using CORBA.

#1 belongs to GTK+, #2 and #3 would be GNOME.  Don't you have good
codename?:)

Best wishes, 
-- 
Niibe Yutaka