[Uim] Scheme to determine default IM

[Takuro Ashie]

Hi.

I'm sorry for too late response.


On Tue, 20 Jul 2004 05:17:43 +0900
TOKUNAGA Hiroyuki <tkng at xem.jp> wrote:

> Retaining all of them is a bother! So, we should unify the input method
> at the bridge level, and have a mechanism to determine that which input
> method should be default. (Is there any objection?)

I agree with it, but we need to discuss (or confirm) which level we
should unify it. libuim? bridge?

I agree with your opinion. I think we should unify it at bridge level.
uim aims to be a simple library, so I don't want destroy current simple
API.


> 
> I made a list about features which we will need to resolve this problem.
> 
>  - Function to get a list of input method which can be used current context.

Sorry, but I can't understand what you mean.
Which layer does it mean? libuim? helper protocol?
Maybe more explanation is needed.

I wondering why we need an another function to get a list of input
method. uim has already have a API for quering available IMs named
uim_get_im_name(). I think you mean "available" is depended on current
context, such as locale. But I also think it can be detect at bridge
level, and probably there aren't any other limits.

To switch IM from external helper application, we need a helper protocol.
But I think we can realize it with existing protocol (branch/leaf).


>  - Function to get a locale of current context. (We don't store current
>     locale to the context of input method, this item may need more
>     discussion.)

Do you mean it is not enough by quering by setlocale()?


>  - Input method witching mechanism from other process. (Do we need helper extension?)
>  - Useful input method switcher, of course GUI.

I agree with it.
And I think extension is not needed as above.


>  - New environment variable to determine the default input method. (Mainly for
>     debugging use?)

To determine default input method, I think it is a good solution that we
use "custom" API which YamaKen implemented.
Although environmental variable is not a best way, current users are
already familiar with such environmental variable, so it may be a better
way in current status.

In my opinion, we should introduce both way, and priority should be
given to the environment variable for debugging and so on.


BTW, I want to implement unified IM bridge (and switching mechanism) to
the uim-gtk-imm bridge now. I'll post the patch later if there are no
objections about it. 

Probably, existence of a prototype will advance the discussion.

Regards,

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