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

[Lars Knoll]

On Tuesday 08 February 2005 16:29, Daisuke Kameda wrote:
> Lars Knoll <lars at trolltech.com> wrote:
> > A commit string is just a special special case of a surrounding text
> > modification, so I think these two could be one event.
> >
> > So what we could do is to have to Events: InputMethodCompose and
> > InputMethodCommit. I don't like InputMethodEnd, as you were asking for
> > independent compose and commit actions. In that case a commit would not
> > end the composition.
> >
> > Would this approach be better?
>
> I approve of your proposal of using InputMethodCommit instead of
> InputMethodEnd.
>
> But, I oppose to treating commit string and surrounding text modification
> as one event. It is because I think that those events' meaning are unclear
> for the developer of input method and the application developer.  I like
> treating as respectively different event.

I thought through this problem once again, and came to the conclusion that it 
would be better for the widget developer to keep all the handling inside one 
event. Input widgets are not that common, and we can solve most of the 
problems handling the event by writing good documentation for it.

A separation between commit and preedit will mean that the developer has to 
cast to the correct event type in the inputMethodEvent() handler. 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.

Best regards,
Lars