[Uim] Re: Turning on/off m17n-lib should be implemented to m17n-lib layer?

[TOKUNAGA Hiroyuki]

On Wed, 27 Oct 2004 09:24:09 +0900 (JST)
Kenichi Handa <handa at m17n.org> wrote:

> In article <20041027040701.5f4f8815.tkng at xem.jp>, TOKUNAGA Hiroyuki
> <tkng at xem.jp> writes:
> >>  The m17n-lib itself doesn't read user events.  How can it
> >>  know when to toggle an input method?
> 
> > The m17n-lib knows user's key events. They would be able to be used
> > for switching input modes of an input method.
> 
> For that, m17n-lib has to know which key event means
> toggling of an input meethod in advance.

Yes. But m17n-lib can define on/off key. m17n-lib already defines some
key binds, for example, change-candidate is defined in ja-anthy.mim. So
IMHO adding a key bind is not a problem.


> > But I think that m17n-lib
> > can/can't is not a problem here, m17n-lib should/shouldn't is. (As I
> > wrote in the previous mail, I couldn't find an answer to this
> > question for now.)
> 
> A key to turn on an input method is managed
> (i.e. defined/customized) by input-method broker such as uim
> and SCIM.  And, an IM broker can use multiple input-method
> engines in background.  In this case, if each IM engine
> defines its own key to turn off an input method, a usr have
> to remember which key to turn off which input method.  It's
> a very inconvenient situation.  So, I think a key to turn
> off an input emthod should also defined/customized at IM
> broker level (I believe using the same key for turning on
> and off is the best).

Key binds is used not only for on/off toggling, but also for selecing a
candidate, etc. From that point of view, do you agree that all key bind
should be unified (and customizable by users)?

Anyway, I see your opinion, I'll implement on/off feature to uim-m17n-*.


Regards,

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