> On 13 Jun 2018, at 14:07, Simon Hausmann <simon.hausm...@qt.io> wrote:
>
> Hi,
>
> While it's true that show(), etc. don't have the focus object as a parameter,
> you do have a three ways of tracking the focus object, via QWindow and
> QGuiApplication's signal as well as via setFocusObject in the input context
> itself.
This is how we track the focus object on e.g. iOS, where we also reconfigure
the keyboard to match the focus object, e.g. if it needs numbers only input. Or
we hide the keyboard or show the keyboard when moving from/to a focus object
that has IM enabled or not.
Tor Arne
>
> I'm missing something then, why is your virtual keyboard hidden when the
> focus object transitions from an element in the regular UI to an element in
> your virtual keyboard? Hiding is usually connected to the acceptance of the
> newly focused object with regards to IME enabling when issuing an IME query.
> Are those elements perhaps missing the handling of QInputMethodEvent, the
> querying kind in particular?
>
> Simon
> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org>
> on behalf of Uwe Rathmann <uwe.rathm...@tigertal.de>
> Sent: Wednesday, June 13, 2018 11:09:46 AM
> To: development@qt-project.org
> Subject: Re: [Development] QInputMethod woes
>
> 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
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
