Hi Simon,
> While it's true that show(), etc. don't have the focus object as a
> parameter, you do have a three ways
Yes, sure: show() is not the problem.
( We also have situations, where the virtual keyboard is started by
pressing a button, while the input should go to some sort of label
sed 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
> on behalf of Uwe Rathmann
> Sent: Wednesday, June 13, 2018 11:09:
missing the handling of QInputMethodEvent, the querying
kind in particular?
Simon
From: Development on
behalf of Uwe Rathmann
Sent: Wednesday, June 13, 2018 11:09:46 AM
To: development@qt-project.org
Subject: Re: [Development] QInputMethod woes
Hi Simon,
&g
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 inform
f Uwe Rathmann
Sent: Wednesday, June 13, 2018 9:03:13 AM
To: development@qt-project.org
Subject: [Development] QInputMethod woes
Hi all,
when working on our virtual keyboard I had to realize that the design of
QInputMethod is inappropriate to achieve what we need:
a) the input method is tied to the item
Hi all,
when working on our virtual keyboard I had to realize that the design of
QInputMethod is inappropriate to achieve what we need:
a) the input method is tied to the item having the focus
We have a touch screen but also an special input device, that offers a
wheel to navigate along the fo
