[immodule-qt] Why reconstruct the number of event's event type to one?

[Daisuke Kameda]

I consider that it is better to prepare two or more events
and to handle them by respectively different method.

The most important thing is that high extendibility 
and high readability are realizable. So, widget developer
will be able to implement original processing of
input method easily.

Localizing the processing method which does not mutually
depend about input makes realization of original
implementation difficult. 


Furthermore, if a method is divided for every event,
it will be easy to implement default operation. 

About preedit, preedit displayed in over-the-spot
style may be able to be implemented in QInputContext.

About commit, generating QKeyEvent only containing
commit string may be able to implement.


On Tuesday 22 February 2005 20:50, Lars Knoll wrote:
> A separation between commit and preedit will mean that the developer has to
> cast to the correct event type in the inputMethodEvent() handler.

I think the implementation mentioned above
resolve this problem.


> Another problem is that you have to send 2 events for the 
> common case where you need a commit string and at the same
> time clear (or modify) the preedit string. This would
> lead to flicker in the widget and there is no way for 
> the application developer to avoid it.

Does this problem really occur?

Although processing which commits the contents of preedit
and eliminates preedit is realized in two events on gtk,
I have not seen that such a problem occurred.

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