[immodule-qt] Re: language() and error handling (Re: Question about svn trunk)

[YamaKen]

At Tue, 27 Jul 2004 22:23:27 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > > My liking is enabling programmer to implement "IM switching application", 
> > > even if it doesn't make immodule plugin. If my understanding is right, 
> > > this is impossible in present code.
> > 
> > I'm not sure what you mean by "IM switching application".

> > If it is the "external IM-switcher panel", it can be
> > accomplished by using "QMultiInputContext with an IPC channel
> > for external switcher panel". And I think that switching
> > mechanism should be pluggable and replaceable. It should not be
> > hardcoded into the Qt library.
> > 
> > If else, please show me an use case scenario as example.
> 
> I have thought "external IM-switcher panel not using QMultiInputContext 
> but using IPC". However, I thought that we should not add the code to 
> Qt library in order to realize it, since complexity will be introduced.
> 
> Do you understand by this explanation?

Not yet.

You had said that some feature is impossible to be implemented
on current API, but I can't understand what is impossible. Tell
me what is impossible using actual example.

I'm not sure what "external IM-switcher panel not using
QMultiInputContext but using IPC" means. I mean
"QMultiInputContext with an IPC channel for external switcher
panel" as "a subclass of QMultiInputContext that extends an IPC
channel for external switcher panel to choose an immodule such
as uim-anthy".

if "not using QMultiInputContext" means "not using
immodule-switching but transparent switching in backend
IM-framework", it can be implemented as same as SCIM
immodule. Although there is no unified switcher for multiple
IM-framework yet, current immodule API can accept it by writing
corresponding plugin.

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