[Uim] Scheme to determine default IM

TOKUNAGA Hiroyuki tkng at xem.jp
Tue Aug 3 22:52:15 EEST 2004


On Tue, 3 Aug 2004 14:49:45 +0900
Takuro Ashie <ashie at homa.ne.jp> wrote:

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

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

> >  - 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 mean extension of helper protocol. (I shold use the word 'feature'
here instead of 'function'.)

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

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


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

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.

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

I agree with you.

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

That's great. I hope you post the patch at an early date.

What I want to say in early mail (and forgot to write) is that:

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


I have no will to change core API now. Personally I want to change, but
API/ABI compatibility is quite important, so we can't change without
careful consideration. (We may have no chance to change core API until
1.0.0. If we have, one chance at best.)


Regards,


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



More information about the uim mailing list