[Uim] Re: Suggestion: Renaming new API functions
tkng at xem.jp
Fri Oct 8 23:52:20 EEST 2004
On Thu, 07 Oct 2004 10:06:41 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Thu, 7 Oct 2004 06:26:51 +0900,
> tkng at xem.jp wrote:
> > On Fri, 01 Oct 2004 17:48:52 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > > > So I suggest an accurate name uim_get_im_name_of_context().
> > > >
> > > > Because uim's input context has plural input methods (so of
> > > > course plural input method names), I opposite this function
> > > > name. Anyway, I need your blow-by-blow opinion.
> > >
> > > In your view, an input context HAS an input method as slave. So
> > > each input context also has the concept 'current input context'.
> > Yes, but it's not my view. A uim_context keeps a list of available
> > input methods as a struct member actually.
> I can't find such member in struct uim_context_. What are you
> referring to? In my view, uim_im_array keeps a list of
> available IMs in C-side.
Sorry, that's my misunderstanding. (Though there is another problem,
developers would expect number of currently enabled input methods as a
return value of uim_get_nr_im, because the function take a uim_context
as an argument.)
> uim_get_nr_im() uses uim_im_array to count the number of
> available IMs. uim_context does nothing about it.
As I described above, that's very confusing. uim_get_nr_im should not
take a uim_context as an argument. (But it's another story.)
> My suggestion does not change any actual codes or behaviors. It
> only wants a renaming to avoid confusion.
> uim_switch_im() actually performs the switching as follows.
> (1) An uim_context is pointing to an anthy-context
> As explained above, the Scheme-side contexts does not have the
> concept 'current input method'. The contexts are permanently
> related to its only one input method although an uim_context can
> switch corresponding Scheme-side context.
I think we should not bother internal implementation of libuim, because
that make discussion (and conclusion) more difficult.
> However, the concept 'current input method of context' can be
> accepted if developer regards uim_context as an concrete
> IM-multiplexer rather than abstract context object, although the
> concept is inaccurate. It accurately means 'the input method of
> (Scheme-side) context that is currently being bound to an
> But the concept enforces 'regard uim_context as IM-multiplexer'
> to all developers, and implies that an assumption 'an
> uim_context will switches its IM regularly'. But the concept and
> assumption is only an optional use case of libuim. We should not
> enforce one specific use case to developers.
> Simply to say, the name uim_get_current_im_name() is too
> specific about its purpose. So I want to rename it to a more
> generic name uim_get_im_name_of_context().
> Consider following case.
> (1) A bridge implementaion that does not use uim_im_switch()
> such as IMKit-uim exists. IMKit-uim will not use
> uim_im_switch() since the Qtopia platform well-supports its
> own IM-switching mechanism. And almost embedded application
> will also not use the IM-switching itself
Maybe I understand your opinion.
The brief of your opinion is 'uim_get_current_im_name' is not
appropriate because some bridges like IMKit-uim doesn't use uim's im
switch mechanism except the function to get a name of input method,
What I want to say here is, do bridge developers like IMKit-uim need
If they need, uim_get_current_im_name is certainly inappropriate. We
should change the name of function. But I don't like
uim_get_im_name_of_context, because _of_context make me confusing. I
propose _uim_get_im_name instead.
If not, they should ignore the function as well as uim_switch_im.
More information about the uim