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

[Daisuke Kameda]

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.

But, realizing this will introduce big complexity into immodule for Qt.
Therefore, I think that current API in trunk is fully ideal.


> > 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?

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.


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

I fully approve your opinion. 


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