[immodule-qt] Re: language() and error handling (Re: Question about svn trunk)
kaminmat at cc.rim.or.jp
Tue Jul 27 16:23:27 EEST 2004
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
> 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
> - 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>
More information about the immodule-qt