[Uim] Towards 1.0

[YamaKen]

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?

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?

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?

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?

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. 

To start discussion about it from now will produce a better
result than from 0.7 has been started. Let's start slow-pace
discussion.

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