[Uim] Scheme to determine default IM

[Takuro Ashie]

Hi Hiroyuki.

On Wed, 4 Aug 2004 04:52:15 +0900
TOKUNAGA Hiroyuki <tkng at xem.jp> wrote:

> Bridge. I think unifying at libuim is impossible. If we do so, we cannot
> support multiple input methods.

It is a little terrible, but I'dont think "impossible".
Why do you think "impossible"?


> How can we? Do you mean we can realize it with a combination of current
> helper protocol and custom API? (Sorry, I don't follow custom API damn
> well. But because I 'must' know all other stuff in helper API, I
> couldn't imagine any other possibility.)

I think "minimal implementation" is possible by using current
"branch/leaf" message (but, of course we have to add new prop_*).

My answer is in the patch I posted yesterday.
(It may not correspond with your draft, so we should continue more
discussion.)

But there are some issues:

 * We should confirm whether bridge is allowed to modify the contents of
   the communication between helper and IM engine or not.
 * It cannot categorize IM engines by language groups (such as SCIM).
 * Some IM engine doesn't communicate with helper, so current interrupting
   design doesn't work well with it.

To solve second problem, we should introduce another concept instead of
the current branch/leaf.


> I intended to get current locale from other process. For example, when A
> is an application and B is an IM-switcher proccess, the way to know the
> locale of the A from the B.

I understand it.
But I'm still wondering whether IM-switcher need to know the locale of the
appilication or not.

Default IM can be determined at bridge level.
If we need to filter the IM engines menus, it also can do at bridge level:

Application  <----->  Bridge (may not exist) <----->  IM-switcher
                |                               |
             notify locale               send current IM engine and available
             determine default IM        IM engies menu.
                                         It may already filtered by locale.


>  The cost of current helper implementation is high, if we want to add
> new command, we have to add some code in each bridge. I want to resolve
> this problem, and it will need some changes of helper spec. (That's my
> forecast, if we can do withou changes, that's brilliant.)

Surely it is brilliant if we can do it, but I have no idea about it yet.


Regards,

-- 
Takuro Ashie <ashie at good-day.co.jp>