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

[James Su]

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:
>  
>
>>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.
>>>      
>>>
>
>-------------------------------
>YamaKen  yamaken at bp.iij4u.or.jp
>
>_______________________________________________
>uim mailing list
>uim at freedesktop.org
>http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/uim
>
>  
>