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

[YamaKen]

Hi Daisuke, Cougar, let's restart the suspended discussion.

At Fri, 16 Jul 2004 02:07:23 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> On Thursday 15 July 2004 01:19, LiuCougar wrote:
> > On Tue, 13 Jul 2004 02:46:53 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > What do you think 'API for external IM-switching' as? I think that
> > > no additional API is required to communicate with external
> > > IM-switching infrastructure. The switcher may be able to be
> > > implemented as ordinary IM plugin. Suppose SCIM. Although it
> > > only switches between its own IMEngines, all input methods are
> > > multiplexed as one plugin. Qt is not aware of the switching.
> >
> > Yeap, this is a situation, but there is another one we should
> > consider: dynamic switching qt-immodule, such as between uim-qtimm and
> > scim-qtimm in the same application? I think qt-immodule infracture
> > should support this, won't it?
> 
> I also think so. immodule-qt will be desirable to support a dynamic 
> switching between qtimms. But, Qt should be not aware of this switching.
> (Only input method currently used needs to know. Only input method 
>  currently used needs to know.)

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.

> > > > - prevention of choosing the module in appliation in use
> > >
> > > I can't understand what you mentioned. Please show me a scenario
> > > as example.
> >
> > IMO, one example is: a qt-immodule plugin (say scim-qtimm) can only
> > handle CJK (in fact can also handle some other ones) input methods,
> > then it makes no sense to display this plugin in a context-menu under
> > other locales (other then utf-8, of course)
> > So I think this suggest us to have some properties support in
> > qt-immodule, such as what languages it can handle etc.

I agree with your requirement. But it is not a error handling of
input context but a instanciation management. It will be done by
adding a query method to QInputContextPlugin such as following.

  QStringList QInputContextPlugin::language( key )

We should discuss language() methods more.

> 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.)

I've now understood what is intended. But I don't think that
generic error handling feature is required for it.

Since 'selection of the input method' also means 'create new
input context' as you know, there is no matter in
QInputContext. To actualize your idea, we can add a query method
to QInputContextPlugin such as isDisabled() to distinguish live
input methods and zombies.

I prefer straightforward error handling using ordinary functions
and signals rather than unnaturally generalized error handling
feature. All current requirements can be solved so (including my
"delete me signal" suggestion).

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?

> > BTW: I do not think a Language() function in inputcontext is a good
> > practice, maybe we should do it in a more generic way, such as a
> > generic query API, so we can add/delete properties without breaking BC
> > or adding new APIs.

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.

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