[AdaptivePageLayout] can't easily grab scrollbar if dual column

Bug #1545118 reported by Bill Filler on 2016-02-12
50
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Medium
Zoltan Balogh
Ubuntu UX
Medium
Matthew Paul Thomas
ubuntu-ui-toolkit (Ubuntu)
Medium
Zoltan Balogh
ubuntu-ui-toolkit (Ubuntu RTM)
Medium
Zsombor Egri

Bug Description

If you have an app that uses AdaptivePageLayout and supports 2 columns, if there is a scrollbar in the first column, it's very difficult to grab it with your mouse because when you get close to it, you get the horizontal arrows showing to allow resizing of the panels in the multi-column layout.

You can try this with messaging-app in silo 30 (soon to land)

Bill Filler (bfiller) on 2016-02-12
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: nobody → Zoltan Balogh (bzoltan)
Changed in canonical-devices-system-image:
assignee: nobody → Zoltan Balogh (bzoltan)
milestone: none → ww08-2016
importance: Undecided → Medium
Changed in ubuntu-ui-toolkit (Ubuntu):
importance: Undecided → Medium
Andrea Bernabei (faenil) wrote :

This was discussed already this week, the UX team will provide a solution to the conflict.

The column resizing area was large to allow easy resizing using touch, but since we now could have draggable scrollbars there (on touch as well), the situation has become delicate.

Adding ubuntu-ux

no longer affects: ubuntu-ui-toolkit
Changed in ubuntu-ux:
importance: Undecided → High
importance: High → Medium
Matthew Paul Thomas (mpt) wrote :

    (A) A scrollbar is immediately adjacent to a column splitter
is a special case of
    (B) a scrollbar’s touch area overlaps with the touch area for anything else
which is a special case of
    (C) the touch areas for any two things overlap.

In the long run we will need a solution for (C). But for now, here’s my proposal for (B). <https://goo.gl/kKcynn> Unfortunately that document is Canonical-only and what I’ve written is not yet approved. So for now, here’s what I’ve written:
____________

As an exception to any standard control touch area clash behavior, if any part of a scrollbar thumb’s touch area clashes with the touch area of one or more other controls, then:
 * If you press on that area, neither/no element should receive the press event until one of the following happens.
 * If you release without a substantial drag, the press and release should be passed to the control(s) that aren’t the thumb.
 * If you begin dragging (nearly) vertically, it should be treated as dragging the thumb.
 * If you begin dragging in any other direction, the press event and any future events should be passed to the control(s) that aren’t the thumb.
____________

Changed in ubuntu-ux:
assignee: nobody → Matthew Paul Thomas (mpt)
status: New → Fix Committed
Changed in canonical-devices-system-image:
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
milestone: ww08-2016 → 11
Changed in ubuntu-ui-toolkit (Ubuntu RTM):
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Zsombor Egri (zsombi)
Andrea Bernabei (faenil) on 2016-05-05
summary: - can't easily grab scrollbar with mouse if dual column
+ [AdaptivePageLayout] can't easily grab scrollbar if dual column
Changed in canonical-devices-system-image:
milestone: 11 → 12
status: Confirmed → In Progress
Zsombor Egri (zsombi) wrote :

Sorry, UX, this doesn't solve the proper aiming on the AdaptivePageLayout column divider.

Implementing such a functionality is pretty complex and error prone. First, the order the overlapping components are receiving the touch events is not predefined, and not even predictable. A touch event is handled by the topmost instantiated component first, meaning if the divider is above the Scrollbar, that will get the event first, and will consume it. This means the Scrollbar below will not even see the event coming.

In order to implement the event handling above, we could think of the following solutions:
1) Create a touch event handler component which would be shared between the scrollbar and the divider. The component will then need to be explicitly shared between the APL and Scrollbar -> cannot be automated by the toolkit and would require to expose some (weird) APIs for both Scrollbar/Scrollview and APL, and app developers would need to bind these two components manually.
2) make sure the Scrollview is parented so that is always going to be above the APL divider, in this way it can get the touch events prior to the APL divider. Then Scrollbar should consume vertical touch drags only, and APL divider the horizontal ones, but neither of these should consume the touch press events. This may cause problems as the touch events will be forwarded to the flickable component under the scrollbar, and no further touch events will be handled.

I was thinking more on a touch grabber spot presence on the APL divider, and the touch events should be grabbed only when that spot is aimed.

BUT, we still have the mouse interaction, which had not been addressed by UX at all. So I'm moving back the UX share to In Progress, until we get a proper solution for both input use cases.

Changed in ubuntu-ux:
status: Fix Committed → In Progress
Kugi Eusebio (kugi-igi) wrote :

It seems that Dekko is not affected by this bug.

Andrea Bernabei (faenil) wrote :

because Dekko is not currently using AdaptivePageLayout

Changed in canonical-devices-system-image:
milestone: 12 → 13
Changed in canonical-devices-system-image:
milestone: 13 → backlog
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers