[Uim] New helper design

[TOKUNAGA Hiroyuki]

Sorry for my long response time, I've operated some rats...

On Wed, 14 Jul 2004 13:08:55 +0900
Seiichi SATO <ssato at sh.rim.or.jp> wrote:

> mlterm in the latest cvs no longer uses uim-helper-candwin-gtk.

Thanks for your infomation.


On Thu, 15 Jul 2004 12:40:14 +0900
Kazuki Ohta <mover at hct.zaq.ne.jp> wrote:

> > I think core/helper contrast is reasonable.
> But set_prop_list_update_cb(), set_prop_label_update_cb(), 
> uim_prop_list_update(), uim_prop_label_update() is included in core
> API.
> This is because IMState is changed by key strokes, and what handles
> key strokes is core part.Then, IMState is passed on through helper
> system. So core/helper fusion cannot avoid to some extent.

Property functions are in core API, because showing/changing status of
input methods are important and essencial. Key strokes are unconcerned
here. IMO in the current code tree, core and helper don't fused. They
are mere APIs from the point of view of bridge. (If you don't understand
this paragraph, I'll try to use other terms.)

> > IPC part is utility code for communication. That's confusing point,
> > we have uim-ipc.c, but there is no function named "helper-foo". We
> > can't say uim-ipc consist of helper. It's my design fault obviously.
> Hm.
> uim_ipc_open_command defined in uim-ipc.c is used only to communicate
> between Core and CandwinApp.
> So, if we prepare candwin related API which use uim_ipc, we need not
> to expose uim_ipc_open_command and the code duplication around
> candidate window (see uim/gtk-im-uim.c and
> helper/helper-candwin-gtk.c)

No, uim-prime is using uim_ipc_open_command, too. In addition, if we
have spell check support in uim, that also use uim_ipc_open_command.

> > Core API have littile support for state indicator, the forthcoming
> > APIs are essentially only two. To set callback function to input
> > context and to send messages to input context. This means bridges
> > like gtk-imm bridge and uim-xim must be implemented to communicate
> > with state indicator. This design is basically good, but concreate
> > design of API is ugly. (Meaningless distinction of label and list,
> > no icon support. If you have a interest, see property related API in
> > uim.h)
> label and list distinction is deleted ASAP.

I can't guess what you are saying. label and list are still distincted
in current API. You want to say "dictinction should be deleted ASAP"?

> Now, we have state indicator as toolbar, panel applet, system tray.
> But the functions of applet and system tray is different, and the
> interface is also different.
> So, we need to use only one way to achieve consistent helper GUI.

Really? Both of applet and system tray seems using functions defined in
helper-toolbar-common-gtk.c.


> I think toolbar is the best.
> Toolbar is independent application, thus it isn't affected by desktop 
> environment.

But integrating state indicator and desktop environment is also
important. (We need desktop independent state indicator, of course.) We
cannot discard applet and system tray. (I guess you would agree.)


> > Here is a list of current problems. Feel free to add items to this
> > list.
> >
> >  - IPC part is not in uim-ipc.c
> >  - Maybe we sholdn't use a word 'server' for uim-helper-server.
> >  - Property related API is ugly and complicated.
> - uim_ipc_open_command is only used for the communication between core
> and candwin-app
> - inconsistent GUI system


Regards,

-- 
TOKUNAGA Hiroyuki
http://kodou.net/