[Uim] Re: Suggestion: Renaming new API functions

[TOKUNAGA Hiroyuki]

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
(snip)
> 
> 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
> IM-multiplexer'.
>
> 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,
right?

What I want to say here is, do bridge developers like IMKit-uim need
uim_get_current_im_name?

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.


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