[SDK] the flickables should only be active if there is enough content for scrolling

[Sebastien Bacher]

The current behaviour is somewhat strange ... if you have content fitting on screen and use a flickable, the content is going to scroll offscreen and bounce back ... shouldn't it rather do nothing? (it's easy to trigget scrolling by mistake when trying to interact with the UI)

In ubuntu-system-settings we worked around the behaviour by using "boundsBehavior: Flickable.StopAtBounds" in our flickables, but that's changing the scrolling behaviour when panels don't fit on screen

The issue was discussed on IRC and we are now changing to
                boundsBehavior: (contentHeight > mainPage.height) ? Flickable.DragAndOvershootBounds : Flickable.StopAtBounds

We agreed it would be good to have a bug to discuss the default behaviour and see if we need that changed in the toolkit, so here we go... ;-)

Design solution:
If flickable content does not exceed the available space, it should not flick at all.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-system-settings - 0.1+13.10.20130716-0ubuntu1

---------------
ubuntu-system-settings (0.1+13.10.20130716-0ubuntu1) saucy; urgency=low

  [ Sebastien Bacher ]
  * Tweak the flickable behaviour to make the scrolling consistant with
    the other applications, but still avoid scrolling if there is no
    need for it See https://launchpad.net/bugs/1201394 for the details.
    (LP: #1201394)
  * storage: the design says to use zero decimal for kilobytes values,
    do that.
  * storage: translate the units.
  * about: display N/A when there is no IMEI information.

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 143
 -- Ubuntu daily release <email address hidden> Tue, 16 Jul 2013 07:01:48 +0000

[Giorgio Venturi (giorgio-venturi-deactivatedaccount)]

Yes, I agree. If flickable content does not exceed the available space, it should not flick at all.

[Tim Peeters (tpeeters)]

this is a setting for the apps? I don't know if we can change the default for upstream Flickable

[Matthew Paul Thomas (mpt)]

When you are at the top of a scrollable element, or the element very nearly fills the screen, it may not be obvious whether anything is off-screen. If flicking always scrolls and bounces, doing that is an easy way to confirm that nothing is off-screen: flick to reveal empty space above/below. But if that flicking does nothing, you may not be sure whether it's because nothing is off-screen, or because the phone or screen has glitched so the flick didn't work.

Having scroll-and-bounce either on, or off, for both ends at once, also introduces an inconsistency. For example, enter System Settings > "Sound" > "Message received", and flick downward; nothing happens. Now do the same in "Ringtone"; the list scrolls down and bounces back. In both cases, you are at the *top* of the list, but if you flick to verify that, it does different things depending on whether you are at the *bottom* of the list. That's weird.

Those are the reasons I can think of for making a flickable element always scroll. What are the reasons against? What's an example of when you "trigger scrolling by mistake"?

[Sebastien Bacher (seb128)]

I don't have specific "example", I just know I happened to hit that case quite often in normal interactions with panel settings. Like even doing a tap on a checkbox would often lead to a small dnd that would make the panel content shift a bit, which is somewhat looking weird