[SCIM] Re: [Uim] Design philosophy and strength of uim
James Su
suzhe at tsinghua.org.cn
Thu Jun 24 06:38:39 PDT 2004
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
YamaKen wrote:
>Hi James, sorry for late reply.
>
>I'm still having problem to run scim-uim, so I can't comment
>about GUI component sharing between SCIM and uim. So I only
>comment to future work for now.
>
>At Mon, 21 Jun 2004 23:12:46 +0800,
>suzhe at tsinghua.org.cn wrote:
>
>
>>- The future work to unify the input method interface:
>> * extend SCIM's IMEngine/FrontEnd interface to support complex
>>features like Microsoft's TSF. (I know nothing about TSF, do you have
>>any documentation?)
>>
>>
>
>I think that TSF is not a feature but a different model. The
>distinction is important.
>
>I'm also having insufficient knowledge about TSF, but a TSF
>input method programmer had introduce the technology to me as
>below (may contain my misunderstanding).
>
>- applications export 'text store'
>
>- pluggable 'text services' can access and rewrite several 'text
> store' through TSF manager
>
>- accessing to 'text store' is transactional like a database. a
> transaction has transaction ID, and may be aborted. This
> allows simultaneous access to one text store
>
>- 'text service' can be implemented as an input method
>
>- committing of input method is modeled as rewriting text
> store of application at cursor position
>
>See following page for further information.
>
>http://msdn.microsoft.com/library/library/en-us/tsf/tsf/text_services_framework.asp
>
>I think that above processing model is useful to enable some
>advanced input method implementation such as Japanese kana-kanji
>conversion system based on a recognition of entire text that
>client application has (possibly megabytes of).
>
>But I also think that now is not the time to introduce such
>processing model into uim or SCIM. We should focus on the short
>term goal, completing useful input method environment for now.
>
>What to do for now is to keep in mind the different model.
>
>Once the model is required in the future, uim can eaisly follow
>such changes using following strength.
>
> * allows rapid scrap & build of core library using flexibility
> of Scheme, well-balanced pragmatism, and in-process tight
> relationship with client
>
>The strength is important value of uim for me. Yes, the way
>seems dirty from the viewpoint of SCIM or IIIMF, but I need this
>strength to implement advanced input method involving client API
>extension. I don't expect that my opinion is recognized
>soon. You and I will need more opinion exchange to know each
>other.
>
>
>FYI: Microsoft is planning another input system for Longhorn.
>
>The "Avalon" Input System
>http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/avaloninput.asp
>
>
>
>> * implement an unified C binding API for SCIM's IMEngine interface.
>>
>>
>
>Good direction! I hope that the C binding simplifies input
>method programming for client-side programmer. I suggest one
>additional development step before making the binding. The step
>is 'semantic API unification' I called.
>
>I think that SCIM's IMEngine instance and uim's uim_context is
>similar, but having some trivial difference such as following
>example. The difference brings learning cost and confusion to
>client-side programmer and costs boring work.
>
> SCIM:
> virtual bool process_key_event (const KeyEvent &key) = 0;
>
> uim:
> int uim_press_key(uim_context uc, int key, int state);
>
>The two function may be more similar as below.
>
> SCIM:
> virtual bool filter_key_event (const KeyEvent &key) = 0;
>
> uim:
> int uim_filter_key_event(uim_context uc, const KeyEvent *key);
>
>The names is example for example. We should select appropriate
>names that forms good mental model into client-side programmer.
>
>Following effect is intended for the work.
>
>- offers unified simple input method programming model for
> client-side programmer to popularize input method capability
> to applications (or toolkits). our promotion effort will also
> be unified
>
>- developer document for client-side programmer can be (partly)
> shared with uim, at least overview of programming model
>
>- possibly brings several uim bridges such as console, Mac OS X,
> Qtopia (Zaurus), and so on to SCIM although some thin wrapper
> may be required
>
>The semantic API unification makes SCIM C binding closer to uim,
>so we get broader cooperation possibility. As I mentioned above,
>I want to keep direct interaction with client application for
>future. But I also think scim-uim is useful option for users, so
>I want to make both the way happier with consistency. The
>unification helps this, maybe.
>
>
>Please wait for my opinion about GUI cooperation between SCIM
>and uim.
>
>
>
>
>>YamaKen wrote:
>>
>>
>>
>>>Hi folks, I'm now trying to discover what the uim is.
>>>
>>>Although uim is known as an useful software, the philosophy is
>>>not known well. Considering recent circumstances of uim
>>>involving SCIM, IIIMF, and immodule for Qt, we should explain to
>>>the community what is the value we want.
>>>
>>>Following is a my personal opinion about uim. Other uim
>>>developers may have completely different view, so please let me
>>>know! Especially Tabata-san must have a deeper opinion about
>>>security.
>>>
>>>
>>>- design philosophy
>>> * simple & efficient
>>> * be clean for valuable things
>>> * be pragmatic for unimportant problem
>>> * refuse generalization for generalization
>>> * keep simple to follow the requirements beyond input method
>>>
>>>- strength
>>> * allows rapid scrap & build of core library using flexibility
>>> of Scheme, well-balanced pragmatism, and in-process tight
>>> relationship with client
>>>
>>> * (security considarasions will be here)
>>>
>>> * offers easy-to-use simple programming model to client (apps
>>> & bridges) programmers
>>>
>>> * offers flexible programming platform using Scheme to backend
>>> (input method) programmers
>>>
>>> * requires few resources
>>>
>>> * supports broad-range platforms such as UNIX desktop, Mac OS
>>> X, PDA, Embedded platforms with poor resources, possibly
>>> cell-phones, game console, digital-appliances, etc.
>>>
>>>- what is not acceptable
>>> * to lose above strength
>>> * (security considarasions will be here)
>>>
>>>- what is acceptable
>>> * to embed uim as a conversion engine of another framework if
>>> original security consideration is preserved. although the
>>> scheme is acceptable, this is regarded as 'alternative
>>> bridge implementation' for now
>>>
>>> * discontinue and merge several non-core components such as
>>> bridges, applets, GUIs with corresponding one of external
>>> project
>>>
>>> * alter the client API to be (semantically) unified with the
>>> another API of external projects to offer unified
>>> programming model to client-side programmers
>>>
>>> * unifying the efforts with external projects that popularize
>>> input method capability (with CJK considerations) to
>>> client-side programs
>>>
>>>Attention again, the opinion is not of the project but my
>>>personal one.
>>>
>>>Note that, 'beyond input method' is intended to suppose a newer
>>>technology like Microsoft's Text Services Framework that has more
>>>generic and different model rather than input method model.
>>>
>>>
>>>SCIM developers, let's start exchanging opinions each other. We
>>>would like to know the philosophy of SCIM as second step (of
>>>course at the scim at freedesktop.org). I believe that we are going
>>>to actualize good thing for all participant of input method
>>>world.
>>>
>>>Discussions and questions are welcome.
>>>
>>>
>
>Regards,
>-------------------------------
>YamaKen yamaken at bp.iij4u.or.jp
>
>_______________________________________________
>uim mailing list
>uim at freedesktop.org
>http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/uim
>
>
>
More information about the scim
mailing list