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

[Lars Knoll]

On Friday 04 February 2005 08:07, Daisuke Kameda wrote:
> I have checked the code.
> I appreciate adoption of attribute in QInputMethodEvent.
>
> But I have question about new QInputMethodEvent structure.
>
> Why reconstruct the number of QInputMethodEvent's
> event type to one?
>
>
> I think that it is difficult for application developer
> to realize this structure and implementation to deal
> with this event.
>
> When this event contain committing and preedit string,
> for example, does the developer understand the order?
>
>
> And, in this implementation, when leaving preedit and
> committing a string , it is necessary to send the
> committing string and preedit's string simultaneously
> or individually, isn't it?
>
> It means preedit disappear, If input context does not
> send preedit string one by one. I think that it is more
> flexible and extensible for End and Composing to exist.
>
>
> Furthermore, I consider it more convenient to express
> modification of surrounding text with one event type.

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?

Regards,
Lars

>
>
> I'd like to hear the opinion of other developers.
> Let's discuss.
>
>
> Regards,