[SCIM] Re: [Uim] Re: [m17n-lib:00111] Re: SCIM help for M17N input methods (was: Custom Keyboard Layout Editor/Interpreter for SCIM)

YamaKen yamaken at bp.iij4u.or.jp
Tue Feb 22 01:07:29 PST 2005


Hi Kenichi,

At Tue, 22 Feb 2005 17:19:08 +0900 (JST),
handa at m17n.org wrote:
> In article <200501130830.RAA13294 at etlken.m17n.org>, Kenichi Handa <handa at m17n.org> writes:
> > I'm going to implement these new API's (the detail is
> > attached at the tail).  I'd like to hear your opinions.
> 
> > (1) For getting a description text of an input method
> [...]
> > (2) For customizing input keys
> [...]
> > (3) For customizing the behaviour of an input method
> [...]
> > (4) For loading and saving the customization.
> [...]
> 
> We have implementd (1), (2), (3) with the attached API
> (slightly modified from the one previous proposed).  I also
> attach a sample program to use that API.  It contains a
> program imtest.c (sorry for a few comments in it) and two
> sample data files im-cmd.tbl (list of global commands) and
> test.mim (test input method that contains variables).
> 
> Could you please check it?
> 
> We have not yet implemented (4).  Do you think it's surely
> necessary?

I think that selecting better way should be based on user
convenience and your own development/maintenance cost.

uim can save the customization using uim's own facility or
m17n's one as required, although some key binding customization
data overriding m17nlib's one will be saved into uim's facility
to preserve uim-dependent special key handling information (such
as chord operation). The implementation cost for uim may
approximately be same in both ways.

Since I don't know what amount and variety of the customization
items exist, my opinion should be ignored if inappropriate.

#I'm answering without take a look into imtest.tar.gz and actual
#customization variable definitions because time constraints me.
#Sorry.

Regards,
-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp


More information about the scim mailing list