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

[YamaKen]

Hi Daisuke,

At Sat, 24 Jul 2004 21:21:43 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> On Tuesday 20 July 2004 23:32, YamaKen wrote:
> > Daisuke, is your requirement 'API for external IM-switching'
> > satisfied in recent trunk? I think that current API have
> > satisfied both immodule-switching and external-switching
> > requirements.
> 
> 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.

> > > My idea is making impossible selection of the input method which the
> > > error took place in the application. Of course, other applications should
> > > not be affected. (This is about error handling.)

> > Daisuke, I think that we should collect each error handling
> > situations and fix it by ordinary way rather than introducing
> > generic error handling feature. What are you thinking now?
> 
> I agree witch you.
> 
> 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.

> > QInputContext::language() stands for 'current inputting
> > language' and it is required for language tagging in
> > QIMEvent. The feature is required to distinguish unified han
> > character correctly. It enables proper font and character code
> > handling. Suppose CJK-multilingual web browser (automatically
> > modifies fonts) and XML editor (automatically inserts lang
> > attr).
> >
> > QInputContextPlugin::language( key ) is also required as you
> > (and Ken Deeter) said. The function stands for 'what language(s)
> > will be used by this input method'. Some input methods handles
> > multilanguage at once, so the function should return QStringList
> > rather than QString.
> 
> I fully approve your opinion. 

Okay, I'll implement QInputContextPlugin::language( key ).

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