[Uim] Towards 1.0

[TOKUNAGA Hiroyuki]

On Sat, 13 Aug 2005 01:47:58 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:

> At Sat, 6 Aug 2005 06:34:21 +0900,
> tkng at xem.jp wrote:
> > 
> > On Sat, 06 Aug 2005 03:15:22 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > 
> > > At Sat, 6 Aug 2005 01:28:35 +0900,
> > > tkng at xem.jp wrote:
> > > > 
> > > > On Fri, 05 Aug 2005 11:27:41 +0900
> > > > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > > > What is the higher level API you suppose?
> > > > 
> > > > Current libuim API is hard to use for bridge developer,
> > > > especially for desktop applications. i.e. Implementing their
> > > > own candidate window is hard. higher API will provide candidate
> > > > window and misc utilities.
> > > 
> > > It sounds an ordinary API reorganization. I can't imagine how
> > > 'high level' the API is. What are the key concepts?
> > 
> > No, it's not a reorganization, only adding new API. Higher level API
> > will provide candidate window (by GTK+ or QT) and misc utilities
> > such as state indicator. Therefore, when someone want to make new
> > bridge, he/she need not to implement their own candidate window.
> 
> I've likely understood. What you intended by the word "higher
> level API" is not defining a programming interface but providing
> a set of standard implementations built on the API. Isn't it?

What I want to do with higher level API is that reducing the cost of
new bridge implementation. That is most important thing.


> If above recognition is correct, I also favor it. And it is also
> what the chooser widget interface (and other widgets) of the
> composer framework is being directed to.
> 
> But I still have some questions about it. Please answer.
> 
> 1. uim-candwin-* for uim-xim should be reorganized with the new
>    facility. Are you also thinking so?

Yes.

> 2. I suppose that introducing such implementations will also
>    introduce a new interface for bridge<->candwin such as
>    uim-xim uses, in addition to bridge<->libuim. Does it
>    supposed?

Yes.

> 3. The bridge<->candwin interface should able to communicate
>    with both in-process candwin and separated process via
>    IPC. And the difference of the two communication styles
>    should transparently hidden into a single C API (i.e. the
>    protocol handling is hidden into API functions). Are you also
>    thinking about the API like this?

Of course.

> I would like that the facility will become the chooser-widget
> capable one. Since I have some requirements to make it such one
> (and Etsushi may also), please indicate your current design or
> requirements about it. 

Sory, there's no design yet.


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem jp