[Uim] Re: [SCIM] Re: Design philosophy and strength of uim

James Su suzhe at tsinghua.org.cn
Tue Jun 29 16:43:32 EEST 2004

Yes, you are right.

YamaKen wrote:

>Slightly offtopic:
>I think that the design of SCIM's proxy-style architecture is
>reasonable to implement client-server functionality. The
>implementation enables IMEngines to run within client
>application process or run on scim server according to runtime
>dynamic configuration. And the design requires less learning
>cost to the client-side programmer because IMEngine interface
>transparently handles socket communication.
>At Fri, 25 Jun 2004 10:03:09 +0800,
>james.su at gmail.com wrote:
>>  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:
>>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
>>scim-uim with uim can be an IMEngine object in the first process.
>>James Su
>>On Thu, 24 Jun 2004 19:03:24 +0200, David Oftedal <david at start.no> wrote:
>>>James Su wrote:
>>>> 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.
>>>>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.
>YamaKen  yamaken at bp.iij4u.or.jp
>uim mailing list
>uim at freedesktop.org

More information about the uim mailing list