[SCIM] Re: Design philosophy and strength of uim

[Zhe Su]

Hi,
  SCIM is very flexible. It can be act as a pure library as well as a
C/S structure (like iiimf). You may see these two picture:

http://freedesktop.org/~suzhe/screenshots/scim-structure-local.png
http://freedesktop.org/~suzhe/screenshots/scim-structure-cs.png

The first picture demonstrates a single process scim xim server. All
IMengines and a x11 FrontEnd object are running within one process,
which acts as a xim server. The GUI Panel runs as a separated process.

The second picture demonstrates a C/S like usage. All real IMEngines
and a socket FrontEnd object are running within one process, which
acts as a socket server daemon. A socket IMEngine and a x11 FrontEnd
object are running within another process, which acts as a xim server
and get input method services from the first process. A gtk2
application with scim's gtkimmodule is another client of the first
process. There is only one GUI Panel process which provides gui
services for all scim process (including the gtk2 apps with scim's
gtkimmodule.)

scim-uim with uim can be an IMEngine object in the first process.

Regards
James Su

On Thu, 24 Jun 2004 19:03:24 +0200, David Oftedal <david at start.no> wrote:
> 
> James Su wrote:
> > Hi,
> >  I think 'semantic API unification' is not so simple, because there are
> > too many differences between uim and scim, for example:
> >  1. scim uses one api process_key_event to handle both key press and key
> > release events. uim uses two.
> >  2. scim uses show/hide/update methods for preedit string, while uim
> > uses clear/pushback/update, these are very different.
> >  3. the candidates api of scim and uim are also very different.
> >  4. etc. etc.
> >
> >  The code base of scim and uim are both very large, changing scim and
> > uim into a set of similar api may affact very large amount of code.
> >  So I think wrapper (binding) is easier and better way, just like what
> > scim-uim does (only about 700 lines).
> >
> >  But the most important, you had better to try scim-uim first.
> >
> > Regards
> > James Su
> 
> Another issue is how SCIM aims to be compatible with XIM and is run via
> a backend application, while UIM is just a library which aims to be
> implemented directly in the APIs that use it (like Qt and GTK). If SCIM
> and UIM were to merge, one would have to abandon one of those two goals,
> or combine them in some way.
> 
> In that way, I think both UIM and SCIM have an advantage over the
> other... UIM can be used without running a backend process, while SCIM
> gives a nice unified interface with an organized menu that's accessible
> from almost anywhere.
> 
> David
> 
> 
> 
> _______________________________________________
> scim mailing list
> scim at freedesktop.org
> http://freedesktop.org/mailman/listinfo/scim
>