[SDK] auto-scroll input fields when OSK visibility changes

[Bill Filler]

Currently when you select in an input field, it causes the osk to be displayed. If the field is located beneath the osk it is obscured. Currently many of the apps have to write special code to handle the osk visiblilty and handle scrolling of the field. This should be done automatically by the sdk if the app opt's in somehow.

Here is a pointer to code in lp:phone-app that makes the input filed for sending text messages scroll based on osk visibility. Same is repeated in webbrowser-app:

http://bazaar.launchpad.net/~phablet-team/phone-app/trunk/view/head:/src/qml/Widgets/KeyboardRectangle.qml
http://bazaar.launchpad.net/~phablet-team/phone-app/trunk/view/head:/src/qml/DetailViewCommunication/CommunicationView.qml#L235

You basically anchor the KeyboardRectangle item to the bottom of your view, and then the contents you want to scroll you anchor to the top of the KeyboardRectangle. This KeyboardRectangle is a normal item that has the size of the virtual keyboard.
When the keyboard is visible it has the height of the keyboard, when the keyboard is hidden, it has a height of 0

UX Solution
The solution identified by Florian above is 100% correct

[Nekhelesh Ramananthan (nik90)]

I think renato is also working on this bug. You can see his MP at https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-keyboard-visibility/+merge/174503

[Florian Boucault (fboucault)]

Actually what Renato did does not fix this. It will certainly help though.

[Giorgio Venturi (giorgio-venturi-deactivatedaccount)]

Yes, I agree, this is an important bug and it should be fixed asap

[Zsombor Egri (zsombi)]

Similar situation is valid also when a component focused using TAB/Shift+TAB key falls outside of the visible area. As all focusable components are derived from StyledItem, I feel we can implant the "scrolling" functionality into that component.