[tabs] Tabs should only be navigated by swiping or tapping on the header area

Some questions:
1. The behavior of the header stays the same (for now)?
2. Can you comment in the bug report what is the behavior for calendar? Maybe I'll have to check the code when I remove the canvas swipe to ensure that the behavior there will still be possible
3. What about animations when switching tabs? Should stay the same? or a cross-fade? (the way we have the tabs in the header
now there is not really a fixed order from left-to-right because any tab may be listed as the first one)
4. The "classic" tabs are still in the code somewhere, but never used. I guess it is safe to remove them completely. Am I correct?

2 > Perhaps the swiping in the calendar should work exactly the same as in the home screen? So not with a "tabs header", but with a header that is attached to the month? This would be a custom implementation in calendar.

The header stays the same for now.

The Calendar app has uniquely paired swiping over the calendar area with the tabs to navigate the months. This is an exception, and only applies to the part of the screen where the calendar is expanded. This sounds like a custom implementation, yes.

Animation should remain the same for now.

Classic tabs should be removed. They were never suitable for touch.

Calendar app for reference : http://design.canonical.com/2013/02/app-patterns-applied-calendar-key-journeys/

Just for the sake of clarity :)

I like the content area swiping, because it is more ergonomic. Most users hold the phone in one hand and use ther thumb to navigate. Reaching the header with thumb is not easy and not ergonomic.

We need to make possible to use controls what capture the swipe gestures in the tabs.

I know that event handling in QML component is different than in many other components, but I would expect the events handled in a specific order. If a control can and wants to use an input than it must be possible. If a control does not use an input than the input should be passed to the "parent" of the control. So In my opinion the swipe should be the default tab switching input gesture unless there is a control in the tab what can capture and use the swipe. That is exactly how the Shell lenses work. The swipe input switches between lenses, but if the user swipes on a carousel (people, music, etc) then the carousel captures the swipe and does what it suppose to do.

> We need to make possible to use controls what capture the swipe gestures in the tabs.

This can be done now in QML. Flickables do what you'd expect, the topmost takes the gesture and decides to accept it or pass it below. Similar to MouseAreas. For case that there's a MouseArea inside a Flickable, MouseArea has a "preventStealing" property, which when turned on, will ensure that the MouseArea receives all mouse events, and so a swipe gesture won't be grabbed by the Flickable that contains it. We need to update things like slider to use this.

For reference, here are some related bugs of which fixes are complicated because of the swipe-to-switch-tabs behavior:
- https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1096969 Slider does not work in tab with swipeToSwitchTabs enabled
- https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1124071 Cannot add Tabs programmatically
but these are implementation issues.

Let's first decide on which behavior we would prefer. I also like the swiping to switch between tabs, but in some applications (example: gallery-app, where horizontal swiping scrolls through photos in the Events view, or turns the page when viewing an Album) it cannot be used, so in order to be consistent we should then disable the swipe-to-switch-tabs entirely.

Concluding, I don't know what is the correct solution. I haven't seen a perfect solution (in terms of design) yet that I think is ideal.

Is there a way to incorporate the swipe-to-switch-tabs behavior in the header instead of inside the tab's contents? So, for example swiping to left on the header will go the tab on the right of the current tab? There is a conflict here with he current behavior and it adds an extra step for the user (scrolling up when the header is hidden) before they can switch tabs compared to the current swiping in the contents area.

After I finish my current task I'd like to try out the following behavior:
- No swiping inside contents area to switch tabs
- Swiping (press and move, then release while moving) on the header will immediately change to the tab on the left/right, and not scroll through the tabs in the header (new behavior)
- Swiping 2 (press and move, then stop moving at least once before releasing): scroll through the tab titles in the header (= current behavior)
- Tapping (press and release, no move) the tabs header shows all the tabs in the header and the user can scroll and select one to switch tabs (= current behavior)

I marked this one as critical because other bug fixes such as this one https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1096969 that are critical can depend on the decision.

Quote,

"For reference, here are some related bugs of which fixes are complicated because of the swipe-to-switch-tabs behavior:
- https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1096969 Slider does not work in tab with swipeToSwitchTabs enabled
- https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1124071 Cannot add Tabs programmatically
but these are implementation issues.

Let's first decide on which behavior we would prefer. I also like the swiping to switch between tabs, but in some applications (example: gallery-app, where horizontal swiping scrolls through photos in the Events view, or turns the page when viewing an Album) it cannot be used, so in order to be consistent we should then disable the swipe-to-switch-tabs entirely."

@Tim Peeters, I believe that switching Tabs by swiping is essential for easy navigation as correctly pointed out by Zoltan that users use their thumb for this. Regarding the horizontal swiping scrolls in the gallery-app, they should use prevent-stealing to fix this issue. As a proof, please have a look at the timer implementation at lp:ubuntu-clock-app.

For the timer, a user sets the timer by moving the clock hand. However by using prevent-stealing property, I have made sure that this touch input by the user is not stolen to switch between tabs. Please consider this into your decision making process.

In case the swiping in the content area would go away, I would like to know which animations we should show when switching tabs. The current animations are not really suitable since the order of the tabs in the contents area is fixed while it may change in the header (in the header it is a carousel).

nik90, thanks for the valuable input. I will wait for a decision from design before proceeding.

Hi guys. This is the design decision as it stands, it was never the intention that the tabs pattern for apps would have a flickable canvas for tab switching. I think it is better if we start with the intended pattern, then improve if need be rather than where we are now, with a pattern which causes problems with interactive elements in an app screen and accidental app switching.

Nekhelesh; yeah I agree that it's a nice quick way to navigate the clock app, but thinking about the need for the patterns to cover the essentials for an app, it is better that any app with a swipeable canvas is the exception to the rule, not the norm.

Once the SDK is updated, we can review the implications on the apps for which we have become accustomed to using the swipeable canvas to navigate and take it from there.

Decision: No content swiping to switch tabs.

If there are applications that do this, they are an exception and they will have a custom implementation. Note that for that case we may need to have a way to link the content to the tabs header to automatically update.

Why not to add a property in the "Tab" Tag called "swipedTab" with whatever default the design team chooses. And so if somebody wants that content/tab swiping, can enable or disable easily. So far I have seen more apps which have _no_ problem with the content swiping then apps which do have a problem with it.
Providing a toggable property to enable a standarized content swipe seems to me smarter then to drop the swipe at all. (i repeat, even with the default value would be "off")

Adrian, I understand your point of view, however, the implementation of the "swiped" tabs uses a VisualItemModel which causes some other bugs (such as the inability to add tabs programmatically). I plan to have no swiped tabs by default, but to add the possibility for Tabs to have no associated Page, so only the tabs header is shown and not its contents and the developer can add their own swiping area for the contents.

The problem that I mentioned above for adding tabs programatically is described in these two bugs:
https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1124071
https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1167568

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

This bug was fixed in the package ubuntu-ui-toolkit - 0.1.46daily13.06.05.1-0ubuntu1

---------------
ubuntu-ui-toolkit (0.1.46daily13.06.05.1-0ubuntu1) saucy; urgency=low

  [ Zoltán Balogh ]
  * update the example app for the latest UI Toolkit.
  * A simple app to check few locales.
  * Add qttools5-dev-tools to build dependencies to provide
    qhelpgenerator for creating QtC help files from documentation.
  * Build documentation and publish the qch file.
  * Offer symlinks for qmlscene via 'qmlrunner' package. See package
    description for usage instructions. (LP: #1155634). (LP: #1155634)

  [ Loïc Molinari ]
  * [UbuntuShape] Correctly stored the current material. (LP: #1132771)
  * [UbuntuShape] Ensured the texture is available in updatePaintNode().
    (LP: #1171437)

  [ Kaleo ]
  * QML_IMPORT_PATH is deprecated for QtQuick 2.0. Switch to
    QML2_IMPORT_PATH.
  * Added syntax description for CHANGES file in CHANGES.syntax.
  * UCScalingImageProvider: respect 'requestedSize' parameter. That
    ensures that the 'sourceSize' property of Image is respected even
    when the toolkit automatically scales the asset for the device. (LP:
    #1130120)
  * Added documentation for bitmap suffixes in the resolution
    independence page. (LP: #1092051)
  * Revamped component showcase now called 'Ubuntu UI Toolkit Gallery'.
    Works on Ubuntu Touch. (LP: #1130603)
  * Benchmarks for time critical components.
  * Added ListItem.ValueSelector example. Fixed incorrect 'Multi value'
    label. (LP: #1172663)
  * Toolkit Gallery: added examples for Sheets.
  * Automatic rotation of applications depending on the device
    orientation. For applications that are using MainView, they opt-in
    by setting 'automaticOrientation' to true. New component
    OrientationHelper for applications that do not use MainView but
    still need an easy way to automatically rotate.
  * UbuntuShape: fix slight distortion of image when set. This
    distortion was quite disturbing when the content has text in it, as
    it is often the case in Popups and Popovers. (LP: #1170878)
  * Use standard animation ubuntu snap beat for popups fade in.
  * Removed unnecessary clipping from Tabs, Popover, Dialog and
    MainView.
  * All ListItems: set default contents right and left margins to 2 gu.
    ListItems Base, Standard and ValueSelector: deprecated private
    properties __leftIconMargin and __rightIconMargin IconVisual
    (private): removed properties leftIconMargin and rightIconMargin
    Standard: removed ugly progression highlight background when there
    is no split.
  * ListItems: constrain size of the icon by default. Deprecated private
    properties __iconWidth and __iconHeight.
  * Ubuntu UI Toolkit Gallery tweaks: - Made window wider and left
    column the width of the phone: 40gu. - Removed 'slider.' from Slider
    example's labels. - Renamed 'Switches' into 'Toggles'. Renamed
    'Progress Bars' into 'Progress and activity'. - Use resolution
    independence for navigation example screenshots.
  * Support source with quotes in .sci files. (LP: #1080719)
  * Reverted unjustified changes to ubuntu-ui-toolkit-gallery.desktop.
  * Popover: simplified com...

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".