[Uim] New helper design

[TOKUNAGA Hiroyuki]

Hi,

I want to describe current helper system design of uim and clarify
problems lying there. If you have other complaints about current herlper
design, please reply. (I've wanted to propose new helper design, but now
I don't have enough time to do...)

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 think core/helper contrast is reasonable. But coverage of the word
"helper" is too wide, we need more breakdown.

Business of helpers are 3 categories.

 - Inter process communication (IPC)
 - Candidate window (used by uim-xim and mlterm)
 - State indicate/change


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.

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


Candidate window part is a program, which communicate with uim-xim,
mlterm, and so on. They use standard input/output for communication. And
actual code using IPC part of helper.


State indicator is a program to indicate current input mode, state, and
so on. It also assumes a role in sending message from user to change
input modes, open word registration window, blah-blah-blah.

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)


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.
 - Propery related API is ugly and complicated.


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