[Uim] What's going on: the composer framework

[YamaKen]

Hi Hiroyuki,

At Fri, 22 Jul 2005 06:54:19 +0900,
tkng at xem.jp wrote:
> I agree the basic idea of composer framework.
> I strongly agree with the concept of chooser.

Thanks for letting me know. I'll devote into developing them.

> I doubt the idea of lazy-instantiator. (i.e. I'm thinking all im should
> be loaded automatically (if possible.))

What did you mean by the words "loaded automatically"? All IMs
are being loaded automatically in my sense. I can't imagine what
you worried about.

The instantiator is not responsible for the module loading
feature (i.e. It is not a replacement of lazy-loading feature of
current uim). It is designed to reduce resource consumptions
until the instances are actually used. Suppose a GUI form which
has 200 textareas that has discrete anthy input context for
each.

> To tell the truth, you may not believe, I want to release 1.0 as soon
> as possible. (If possible, I want to release 1.0 until the year end.)

Please let me know the specification you want on 1.0.

Does it contain so much features that requires time until the
year end?  What are lacking against 0.4.8?

> Now I'm not thinking composer framework is must item for 1.0, because
> this big reorganization is likely to cause some troubles. Introducing
> new code would cause drop-off in quality temporarily.

The milestones I mentioned in the roadmap can be renamed to 1.x
or 2.x. I don't persist in what is the uim 1.0.

> Is is possible to introduce composer framework without affection to
> other parts?

The framework can be optional at uim 0.6 in my roadmap. Other
than ng-anthy and ng-canna will not be affected.

But 0.7 and later can't be. Since I want to develop the 0.7 as
soon as possible once I achieved the 0.6, I want sooner release
of your 1.0.

> On Wed, 13 Jul 2005 03:04:09 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > 6. Roadmap
> > 
> > My roadmap is shown below. Other developers maybe have another. Let me
> > know your plan if something is conflicting.
> > 
> > - 0.5 (devel) and 0.6 (stable)
> >   main goal: establish the composer framework roughly
> >   schedule:  several months after
> > 
> > 
> >   * merge the codes from composer branch into trunk
> > 
> >   * add ng-anthy IM based on composer framework. former version of
> > anthy may coexist if ng-anthy is not lightweight enough
> > 
> >   * add ng-canna IM if some lacking features of canna.c is
> > complemented
> > 
> >   * ng-anthy and ng-canna will be registered as legacy IM via API
> > adapter
> > 
> >   * support dead keys and Japanese "RO" key in libuim and bridges
> > 
> >   * add icon, separator and single action button support to helper
> >     protocol and toolbar
> > 
> > 
> > - 0.7 (devel) and 0.8 (stable)
> >   main goal: internal cleanup by the framework
> >   schedule:  should be released before the next year
> 
> Is this schedule possible? Of course schedule depends on the numbers of
> contributers, but now we have no full-time commiter. I guess this
> schedule is very aspiring and would be hard if we cannot get some new
> contributers.

The words "should be released" represents a wish rather than
possibility at this time. The release of 0.6 will refine
possibility of the schedule.


> >   * port all input methods to composer framework
> > 
> >   * replace the IM management codes written in C (related with
> >     uim_im_array) with composer-based one
> > 
> >   * the context management codes written in C (related with
> > context_array) will be kept
> > 
> >   * replace the IM switching codes written in C with composer-based
> > one
> > 
> >   * enable flexible IM switching by key operation, candidate
> > selector, etc
> > 
> >   * enable flexible toolbar customization using chooser and action
> > 
> >   * obsolete many legacy codes inside libuim and scm, but C APIs will
> > be kept untouched (including uim_switch_im())
> > 
> >   * support advanced key bindings with uim-pref if someone want to
> > develop it

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