[Uim] Design philosophy and strength of uim

James Su suzhe at tsinghua.org.cn
Tue Jun 29 18:32:28 EEST 2004

Yes, I agree with you.

Ken Deeter wrote:

>Just my 2 cents:
>I think it may be worthwhile to try to see what overall goals that need
>to be achieved in terms of input methods and see how each project fits.
>In my mind there are several clear and related goals:
>1) Create a system that works now, is multi-lingual, has some kind of
>switching mechanism, and is available ASAP.
>2) Create a comprehensive 'framework' for input methods, including
>thinking about how to manage them, how to provide consistent GUI's, how
>to unify access to them (both from the user's point of view and also
>API point of view), and how to keep their development manageable.
>3) Explore new ideas in input methods, including new API's and new
>interaction mechanisms.
>All the efforts right now contribute to each of these goals in different
>As for goal #1, it looks like combination of SCIM + IIIMF + uim will
>work the best. To meet this goal, each party needs to make sure that
>they ahve modular and stable designs so that the functionality of each
>system can easily be integrated with the other. The scim-uim efforts as
>well as the scim-iiimf efforts fall into this category, I would say.
>As for goal #2, it seems that SCIM and IIIMF have different approaches,
>but the idea is similar. The strengths of these frameworks are that they
>have been carefuly built with this type of goal in mind, and should
>continue to be developed with that goal.
>For Goal #3, I feel that uim and maybe to some extent scim fit well. For
>uim in particular, I think that what this means is that uim developers
>can worry less about how to implement IM switching or desktop IM
>management (or legacy compatibility with XIM) and rather explore new
>avenues for input method API's. Even if it means just developing novel
>methods for Japanese, in the end, any new API concepts developed in UIM
>should cause IIIMF and SCIM to react if their API's are unable to deal
>with the new requirements.
>In short, we need to separate the goal of 'integration' with the goal of
>'exploration' and realize that the three projects can reduce a lot of
>overlap if it is made clear which direction each is heading in.
>As a recent new user to scim, i am extremely greatful for the
>integrative capabilities it has, and cannot wait for the qt-immodule
>version. I would very much like for scim to continue its efforts on
>trying to figure out how to provide uniform interfaces to input methods,
>and to maintain bridges to new methods like uim. At the same time I
>would like to see uim keep forging ahead trying new ideas, without the
>fear or risk of destroying SCIM's structural stability just to add some
>small little feature that actually might not be too important in the
>I would say likewise for IIIMF, though I have not been able to use it
>directly on my gentoo box yet (even though I wrote the original versino
>of the pacage ;-P).
>uim mailing list
>uim at freedesktop.org

More information about the uim mailing list