[Uim] Development reformation: Current status of uim

[YamaKen]

Hi guys, thanks for the responses.

I've updated the list. Please confirm again.

At Thu, 17 Nov 2005 21:25:47 +0100,
david at start.no wrote:
> Although not directly related to development itself, switching IMs on 
> UIM has an additional problem besides being difficult; it will often 
> make programs such as gnome-terminal crash, at least on Ubuntu Linux. I 
> think using a menu of some sort and fixing the crash bug would make UIM 
> much simpler to use.

Mmm... I can't reproduce it. Is it caused on the immodule bridge
with uim-im-switcher-gtk?  And would you give us the backtrace?
Menu-based ones will be provided after the composer framework is
introduced.

At 18 Nov 2005 15:47:07 +0900,
jhpark at tuhep.phys.tohoku.ac.jp wrote:
> I wish there were a short-cut key for switching among different IMs
> (like Alt-Shift used in Windows IME) because (a) switching can be done
> more efficiently, and (b) UIM is not always supposed to be used with
> GTK/X11, but it can be used in a text-only environment.

It's partly being implemented by Etsushi. User can register one
"Alternative IM", and switch to it by a key operation. It
requires an addiotional uim API to be finished, and maybe
available on next stable series. Further flexibility will be
provided by the composer.

At Fri, 18 Nov 2005 08:45:26 +0100,
asmodai at in-nomine.org wrote:
> 
> -On [20051118 07:46], Jae-hyeon Park (jhpark at tuhep.phys.tohoku.ac.jp) wrote:
> >I wish there were a short-cut key for switching among different IMs
> >(like Alt-Shift used in Windows IME) because (a) switching can be done
> >more efficiently
> 
> Agreed.  Especially in the age of RSI having a short-cut key (configurable)
> would be very welcome.

Is the RSI "Repetitive Strain Injuries"? I've just googled
it. Hmm... in my rough recognition, avoiding mouse operations is
most important for uim about it. Right?

Fortunately, the new development direction will be same with the
one resolves it.

At Fri, 18 Nov 2005 17:05:36 +0900,
ekato at ees.hokudai.ac.jp wrote:
> On 2005/11/18, at 5:16, YamaKen wrote:
> >   - 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"?

What I intended is that there is no architectural support, or
current codebase or design may prevent implementing the
features. So I would like to resolve them after the introduction
of composer framework. But if someone want to do it in near
future, I consider it with new roadmap.


  - achievements

    * uim-skk is well-featured to meet the requirements of most
      users although some refinements is still going on

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

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

    * uim-prime is working stable, but quite heavy and lacking
      an important feature (annotations)

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

    * uim-scim is broken

    * IM bridges are mostly covering various input environments
      (GTK+, Qt, XIM, terminal, Emacs) on UNIX flavors, and also
      Mac OS X

    * uim-el (the Emacs bridge) is going to be finished

    * basic "choose from the list" style GUI IM-switching
      feature is working but seriously not useful for frequent
      operation, and terminal environment is not supported

    * "swapping primary and secondary IM" style hotkey-based IM
      switching feature is being implemented by Etsushi. it
      requires an addiotional uim API to be finished

    * 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

    * 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

  - development motivations

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

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

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

  - Desired features reminder (not intended to be complete)

    * various flexible IM switching methods (toolbar, candidate
      selector, key operation, MRU, situation-sensible, etc)
      which supports both graphical and text environemnt (will
      be resolved with the composer framework)

    * generic annotation display facility cooperates with
      candidate selector (using GUI when the bridge can)

    * uim-skk
      - GUI-based annotations

    * uim-anthy
      - re-conversion (requires target text retrieval mechanism)
      - prediction

    * uim-byeoru
      - annotations for Korean-to-Chinese conversion

    * uim-prime
      - annotations

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp