[Development] QPlatformInputContext needs more informations

Pekka Vuorela pekka.ta.vuorela at nokia.com
Tue Apr 17 16:12:13 CEST 2012


On Mon, 2012-04-16 at 09:23 -0700, ext BogDan wrote:
> > From: Pekka Vuorela <pekka.ta.vuorela at nokia.com>
> > To: BogDan <bog_dan_ro at yahoo.com>
> > Cc: Samuel Rødal <samuel.rodal at nokia.com>; "development at qt-project.org" <development at qt-project.org>
> > Sent: Monday, April 16, 2012 12:57 PM
> > Subject: Re: [Development] QPlatformInputContext needs more informations
> > 
> > On Mon, 2012-04-16 at 01:17 -0700, ext BogDan wrote:
> >>  > From: Samuel Rødal <samuel.rodal at nokia.com>
> > 
> >>  >>  In order to be sure the user sees the entire control and its 
> > content I need 
> >>  > to know
> >>  >>  the control position and its size, otherwise the virtual keyboard 
> > may cover 
> >>  > the 
> >>  >>  control and its content.
> >>  > 
> >>  > Isn't that what QPlatformInputContext::keyboardRect() is for?
> >>  > 
> >> 
> >>  On Android platform the keyboard rect is unknown, because is an external 
> > service.
> >>  The only way to be sure the user will see the entire control and its 
> > content,
> >>  is to create a dummy transparent Android native widget in the same position 
> > and 
> >>  with the same size as the qt control, I pass that widget to the keyboard 
> > service, 
> >>  then the Android window manager will do the magic for me, it will pan the 
> > screen or 
> >>  it will resize it if necessary.
> >>  Please check the video I posted on youtube [1].
> > 
> > On Meego, at least, the panning and resizing has been made application's
> > responsibility. That's why the keyboard rectangle is available and not
> > the other way around
> > 
> > I don't know the Android interfaces, but would it be then possible to
> > infer keyboard size by creating a transparent fullscreen native widget
> > and seeing how much the window manager resizes it?
> >
> 
> I'm afraid is not possible (at least not in all cases). If you check the video
> I posted on youtube you'll see that there are 3 different cases on how the
> virtual keyboard interacts with the screen and in only one case the screen
> is resized.
> Let me give you more explanation about that video.
> - the first case is when the widget is small so the screen doesn't need to
> be resize, but the control will be covered by the keyboard, so the whole 
> screen must be moved up.
> - the second case is when the widget is too big and the screen must be
> resized in order to make room for virtual keyboard, it can not be moved up
> because the user will not see the entire control or its content. This is the
> only case when I know how determine the keyboard size.
> - the third and the last case is when widget is small enough and it will
> not be covered by the keyboard, in this case the keyboard will just appear
> on top of your app, no panning and no resize is needed.
> 
> Even if with magic trick I'll get the keyboard size, on android is not helping
> too much, because I still need to know the control position and size,
> otherwise I don't see how can I decide which from the 3 cases to choose. 
>
> So pretty please consider to add this information, otherwise we'll have to
> do some super dirty workarounds to get it working on Android.

What you describe above is how Android is making sure editors stay
visible. There is nothing per se requiring panning and resizing
happening exactly as above. For example, just always resizing the window
to remaining visible area would be a start. Meegotouch on N9 on the
other hand never resizes the window for this, it just adds some
temporary extra space to scrollable widget and scrolls what is
necessary. Application/toolkit being in charge how it wants to ensure
editor visibility.

What I meant with the fullscreen window to infer keyboard size was to
get QInputMethod::keyboardRectangle() return the correct size. Editor
knows its size so it could then trigger similar behavior what you
described above. 

I'd be careful adding this to inputmethod queries. E.g. usage would also
need similar transformations as were done for cursorRectangle in
QInputMethod.





More information about the Development mailing list