[immodule-qt] Why reconstruct the number of event's event type to one?
lars at trolltech.com
Fri Feb 4 11:17:40 EET 2005
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
Would this approach be better?
> I'd like to hear the opinion of other developers.
> Let's discuss.
More information about the immodule-qt