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

[Daisuke Kameda]

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 feature "IM-switching controlled by application
> menu of an ordinary application (such as text editor)", the
> feature can be implemented using QInputMethodFactory::keys() and
> QApplication::changeAllInputContext().
> 
> 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?



> > Now, I think the feature which disable selecting such input method should 
> > be implemented not in general error handling but in input method plugin.
> > So, it will be better to introduce the signal for error handling.
> 
> I will develop as following. Check it.
> 
> - I will introduce QInputContext::deletionRequested() signal to
>   handle fatal error in an input context. It will be used for
>   XIM.
> 
> - We should implement QInputContextPlugin::isDisabled() function
>   when it is actually demanded. But we should not implement it
>   now to avoid wrong assumption about the requirement.
> 
> - There is no other error handling demand now.

I Checked it. This plan is good.


-- 
Daisuke Kameda <kaminmat at cc.rim.or.jp>