[Uim] New helper design

[Kazuki Ohta]

Hi, Hiroyuki.

Thank you for describing helper design in detail and clarifying the problem
of current helper design.


> First, now all programs except using core API only programs are named
> helper-*.  E.G. uim-helper-toolbar-gtk, uim-helper-candwin-gtk, and so
> on. Maybe you don't what's core API. Core API is defined in uim.h, while
> helper API is defined in other header files.
I listed be;pw the helper-system related source codes along with your 
categorizing.
- Inter process communication (IPC)
  uim/uim-helper.h
  uim/uim-helper.c
  uim/uim-helper-client.c
  uim/uim-helper-server.c
  uim/uim-ipc.c
- Candidate window (used by uim-xim and mlterm)
  helper/helper-candwin-gtk.c
  qt/qtkde-helper/src/candwin/uim-helper-candwin.h
  qt/qtkde-helper/src/candwin/uim-helper-candwin.cpp
  doc/HELPER-CANDWIN
- State Indicator
  helper/helper-* except helper-candwin.gtk
  qt/qtkde-helper/src/* except candwin

> 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.

> 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)

According to doc/HELPER-CANDWIN, What we need is:
  uim_candwin_activate(char* candidates);
  uim_candwin_select(int idx);
  uim_candwin_move(int x, int y);
  uim_candwin_show();
  uim_candwin_hide();
  uim_candwin_deactivate();

> To communicate with other process, we have a server using UNIX domain
> socket. All applications supporting uim are client of this server.
> uim-helper-server recieve messages from clients, and transfer the
> messages to other clients. Maybe we should use the word 'message bus
> daemon', instead of the word 'server'.
That's right.

> 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.

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.

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


> 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.

-- 
---------------------------------
Move the worl:D!
Kazuki Ohta : mover at hct.zaq.ne.jp