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

[Lars Knoll]

On Wednesday 23 February 2005 11:39, Daisuke Kameda wrote:
> 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.

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.

> 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.

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

I can't see a big difference between having one event and having several here.

> 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.

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

The default handling in QInputContext would do this.

Best regards,
Lars

> 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.