[Development] QInputMethod woes

Uwe Rathmann Uwe.Rathmann at tigertal.de
Wed Jun 13 11:09:46 CEST 2018


Hi Simon,

> But my initial guess is that this isn't an inherent design
> problem of the input method API.

Well, one problem is that the input context needs to know about the 
current item, as it has to correspond with it. But QInputMethod::show/
commit/reset/update/hide do not transfer any information about the item 
calling them.

In case of show() all the context can do is to assume that the item 
having the active focus is the one to correspond ( what actually is not 
always correct in our application ) with.

In case of all other calls the context has no chance to find out if the 
caller was the item it is corresponding with - at least not, when the 
active focus has moved somewhere else.

And you find various situations in QQuickWindow or the controls, where 
inputMethod calls are done from items not being the corresponding one.

F.e. in  QQuickWindowPrivate::setFocusInScope/clearFocusInScope 
QInputMethod::commit() gets called, whenever the focus is changing. As 
this is might be wrong all our context can do is to ignore these calls in 
general.

--

As we also implement our own type of controls ( in C++ ) I can work 
around most of these issue with bypassing the QInputMethod API and 
calling our context manually using a proprietary API, where I'm adding 
the caller as parameter.

But this is obviously no option for the average Qt user.

Uwe 




More information about the Development mailing list