[UX/apps] OSK <> apps behavior is not clearly defined

Bug #1131249 reported by Olivier Tilloy on 2013-02-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Fix Released
Florian Boucault
Ubuntu UX
Oren Horev
ubuntu-ui-toolkit (Ubuntu)

Bug Description

In various applications (telephony, browser, …) where the OSK can be invoked, we are using a trick to ensure that the OSK doesn’t cover content: a KeyboardRectangle component whose height is "Qt.inputMethod.visible ? Qt.inputMethod.keyboardRectangle.height : 0", anchored at the bottom of the mainview, and the rest of the content is anchored to its top.

This means code duplication, and unnecessary logic to handle something that the window manager should be taking care of.

Related branches

Olivier Tilloy (osomon) on 2013-02-21
summary: - [W/M] apps should be resized to accomodate for the OSK when shown
+ [W/M] apps should be resized to accomodate for the OSK when it’s visible

In the same way we've decided against handling orientation on the WM level, I'm against having the OSK rectangle being respected like this.

Indeed we could provide ways that the MainView could, potentially by default, resize to accommodate for the keyboard rectangle, but apps need to be able to override that behaviour.

We also need defined the preferred User Experience - should the toolbar always be there on top of the OSK? If not - is the toolbar unavailable when the OSK is up? Is it always on screen (sacrificing screen real estate)? Is there a way to invoke / dismiss the toolbar when OSK is up?

If there's a text entry in the toolbar (like there is in the Browser) obviously it needs to be visible when typing, but maybe generic bottom bars should dismiss the keyboard when invoked?

summary: - [W/M] apps should be resized to accomodate for the OSK when it’s visible
+ [UX/apps] OSK <> apps behavior is not clearly defined
Changed in manhattan:
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

You’re raising interesting questions that will need input from design.

In the browser use case, design would like to have the chrome follow the OSK when animated in (see bug #1119331). At the moment this is not possible, since all we know from the keyboard is its bounding rectangle in window coordinates. We cannot anchor to it directly. As a result, the chrome bar is animated upwards first, followed by the OSK. This feels odd (but I guess we can learn to live with it).

Pat McGowan (pat-mcgowan) wrote :

also cc design

information type: Proprietary → Public
affects: manhattan → touch-preview-images
Changed in touch-preview-images:
assignee: nobody → Thomas Voß (thomas-voss)
John Lea (johnlea) on 2013-07-16
Changed in ubuntu-ux:
assignee: nobody → Rachel Liu (rachelliu)
Oren Horev (oreneeshy) on 2013-07-16
Changed in ubuntu-ux:
assignee: Rachel Liu (rachelliu) → Oren Horev (oreneeshy)
Changed in touch-preview-images:
importance: Undecided → High
affects: touch-preview-images → ubuntu-ui-toolkit
Changed in ubuntu-ui-toolkit:
assignee: Thomas Voß (thomas-voss) → Florian Boucault (fboucault)
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:ubuntu-ui-toolkit at revision 633, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

Changed in ubuntu-ui-toolkit:
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-ui-toolkit - 0.1.46+13.10.20130718-0ubuntu1

ubuntu-ui-toolkit (0.1.46+13.10.20130718-0ubuntu1) saucy; urgency=low

  [ Kaleo ]
  * Popover: added manual test program.
  * Popover simplifications: - simplified pointer positioning by only
    computing the position of the tip; it's up to the pointer to
    rotate/translate adequately. - fixed implementation of
    Popover.callerMargin and set default value to 0. - removed unused
    parameter 'pointerMargin' from InternalPopupUtils.CallerPositioning.

  [ tpeeters ]
  * Fix bug where toolbarActions.opened was not properly updated when
    the user swipes to show/hide the toolbar. (LP: #1192673)
  * Improve code examples in documentation.
  * Use UnityActions to make Actions available to HUD: - Action now
    inherits UnityActions.Action - Added "actions" property to MainView
    to contain global actions that are available in HUD as long as the
    app is running. - Added "actions" property to Page to contain local
    actions that are available in HUD when the Page is active. (LP:

  [ Renato Araujo Oliveira Filho ]
  * Make sure that the keyboard does not obscure the contents of main
    window. (LP: #1131249)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 633
 -- Ubuntu daily release <email address hidden> Thu, 18 Jul 2013 06:07:54 +0000

Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Fix Released
Changed in ubuntu-ui-toolkit:
status: Fix Committed → Fix Released
Oren Horev (oreneeshy) on 2013-09-09
Changed in ubuntu-ux:
status: New → Fix Committed
importance: Undecided → High
John Lea (johnlea) on 2014-07-17
Changed in ubuntu-ux:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers