[Uim] Development reformation: Current status of uim

[Etsushi Kato]

Hi,

On 2005/11/18, at 5:16, YamaKen wrote:

> Hi folks, let's start to reform our development. At first, we
> should share our own status.

OK.

> Viewing from my eyes, current uim trunk seems as below. Please
> confirm it.
>
> Because the information will be used as the facts which
> subsequent development plan is based on, please fix and
> complement the information to avoid misdirections.
>
>   - achievements
>
>     * uim-skk is well-featured to meet the requirements of most
>       users

Thanks.  I'm having a plan to implement user server for SKK
dictionary management to reduce memory usage before long, maybe.
Anyway I'm quite satisfied with current status.

>     * uim-anthy and uim-canna are lacking some important
>       features, and having some hard problems (e.g. kana input)

I'm not sure about these IMs, but it is better to support
re-conversion of string and word predictions at least for anthy.
Re-conversion requires to support surrounding text handling as
Tokunaga-san explained before.

>     * Hangul IM is going to be useful with the Park Jae-hyeon's
>       contribution

At the moment, http://newton.kias.re.kr/~jhpark/uim/ seems to have
some problems.  We should contact him to obtain latest version.

>     * implementation status and stability of uim-prime is
>       unknown for me

For me, stability is fine, but it is quite heavy for normal use.
And we should implement some way of showing an annotation and/or meaning
of the candidate word within a extra label and/or window besides the 
candidate window.  It is also applicable for uim-skk's word 
annotations.

>     * uim-m17nlib is lacking user customization data bridging
>       between m17nlib and uim. other features and stability is
>       unknown for me

I'm not sure about this.

>     * uim-scim is broken
>
>     * IM bridges are mostly covering input environments on UNIX
>       flavors
>
>     * uim-el (the Emacs bridge) is going to be finished
>
>     * basic IM-switching feature is working but seriously not
>       useful for frequent operation
>
>     * graphical preference editor is usable although some aspect
>       of the UI is still rough
>
>     * toolbar is useful for basic user requirements although
>       more extensions (icon etc) are anticipated

Maybe implementing IM switching from toolbar is required.

>     * standard conformance of the Scheme interpreter is not
>       enough
>
>     * the Scheme interpreter consumes slightly large memories
>
>     * the mark and sweep garbage collection is heavy for
>       low-power environemnts

>   - code organizations
>
>     1. architectural limitation is preventing feature extensions
>     2. some part of libuim API are not useful and it costs
>        bridge development heavy
>     3. the codes of libuim is complicated and easily spawn bugs
>        if edited

Right.

>   - development motivations
>
>     * there is no committer that have a passion to refine
>       user-oriented desktop usability (like scim-anthy achieved)
>       even if heavy effort is cost architecturally (this will be
>       changed once the composer introduced)

What do you me by "heavy effor is cost architecturally"?

>     * there is no committer that want to refine the awkward look
>       and feel of the uim-pref for now

Hmm...

>     * YamaKen has enough passion to reform the overall
>       architectures and enthusiastic IM components

I'm very happy to hear that!

Cheers,
-- 
Etsushi Kato
ekato at ees.hokudai.ac.jp