[Development] QPlatformInputContext needs more informations

Pekka Vuorela pekka.ta.vuorela at nokia.com
Thu Apr 19 14:42:14 CEST 2012


On Wed, 2012-04-18 at 10:50 -0700, ext BogDan wrote:
> > From: Pekka Vuorela <pekka.ta.vuorela at nokia.com>
> 

> >>  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. 
> > 
>   It will be strange for Android users, I want Qt apps to look&*feel* the same
> as any native Android application.

If the same actions are triggered, then both the look and feel are
exactly the same. For me it looks this can, and should, be implemented
without any new API.

I suppose the current version you have is something like platform input
context keeping the native transparent window the same size and position
with the new input method query. Now, if instead Android Qt Components
text widgets (or whatever API is targeted for application development)
would do the same thing when focused, there would be no difference from
operating system point of view. Plain QML editors would not support this
feature but they wouldn't have the Android look&feel anyway, and do not
support the feature in any other platform.

The option of just tracking Android keyboard size and doing the resizing
internally in the toolkit might provide even better results by allowing
better modifying behavior based on needs. Emulating look&feel would not
necessarily be that hard.

Also based on this
http://developer.android.com/resources/articles/on-screen-inputs.html

It looks like even on Android the editors can have an opinion on how
panning&resizing work. Note portrait e-mail application resizing even
though focus is on single line editor. Qt version with a fixed policy on
platform input context would not allow the same.





More information about the Development mailing list