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

[Daisuke Kameda]

On Wednesday 23 February 2005 22:55, Lars Knoll wrote:
> > 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.
>
> The way I see this it won't be easy no matter what we do, as the widget
> developer has to honour all the attributes for the preedit string. This
> usually requires a lot more work than the commit or replace actions.
>
> I've talked about this with a few people here at Trolltech that are
> involved with input methods (on embedded) and widget development. Noone
> sees a big problem with having only one event.
>
> Fortunately there are very few people implementing their own input widgets.
> All of KDE has 2-3 input widgets where they would need to implement the
> event handling. Other projects are smaller and have at most one input
> widget they write themselves, usually none at all.

I see. But, I think it unclear to treat surrounding text
and commit as the same thing.


> > Localizing the processing method which does not mutually
> > depend about input makes realization of original
> > implementation difficult.
>
> I don't think so. Please have a look at the implementation of the
> inputMethodEvent() in QLineEdit and QTextEdit. They are not very
> complicated.

I agree with you. But I have some misgivings about methods becoming 
complicated, when the attribute of preedit or commit strings 
comes to be utilized rather than now. 


> > About preedit, preedit displayed in over-the-spot
> > style may be able to be implemented in QInputContext.
>
> Adding default handling to QInputContext using an over the spot widget is a
> very good idea. But it is completely independent of the structure of the
> event.

I agree with you, now.

> > About commit, generating QKeyEvent only containing
> > commit string may be able to implement.
>
> The default handling in QInputContext would do this.

I agree with you.
I think translateQInputMethodEvent() is good name.
And the method becoming not virtual is better.

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