1. 22 Mar, 2021 1 commit
  2. 02 Mar, 2021 8 commits
  3. 01 Mar, 2021 1 commit
  4. 26 Feb, 2021 1 commit
  5. 19 Feb, 2021 6 commits
    • Alexander Mikhaylenko's avatar
      swipe-tracker: A small cleanup · 07403f12
      Alexander Mikhaylenko authored
      Actually use the `pos` parameter in get_bounds().
      07403f12
    • Alexander Mikhaylenko's avatar
    • Alexander Mikhaylenko's avatar
      carousel: Add allow-long-swipes property · c6ded459
      Alexander Mikhaylenko authored
      Expose the AdwSwipeTracker property, as it's relevant here.
      c6ded459
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Add allow-long-swipes property · 45833931
      Alexander Mikhaylenko authored
      Since we now have the ability to support swiping through multiple pages,
      expose it as a property.
      45833931
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Rework end point calculation · fff1ad51
      Alexander Mikhaylenko authored
      Previously we used a bunch of heuristics for this. We checked if velocity
      was directed towards the nearest snap point and its value was larger than
      a threshold. If it is, we completed the swipe, otherwise we cancelled it.
      
      This was good enough at the time, because this code was originally written
      for back/forward swipe. Since then, the swipe tracker was extended to
      handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
      on text direction. After that it was iterated on, but never significantly
      redone.
      
      This worked well enough, but had two problems:
      
      1. In some cases, notably for AdwCarousel with non-expanded pages, it may
         be wanted to be able to swipe through multiple pages at once. This
         wasn't really possible because we always picked the adjacent snap
         point.
      
      2. Since we can't do that well, we want to restrict swipes to one page at a
        time. It was done in a rather hacky way by clamping the position into
        [-1, 1] range from the place where we started the swipe. This works
        if we start the swipe from idle position, but if an animation was
        already going, the range would be clamped to arbitrary values, and very
        likely containing only one snap point, which we already swiped past at
        this point. In this case, finishing the swipe would cancel it regardless
        of velocity. This means that if one tries to quickly move through
        carousel pages via swiping, half of the swipes will be inexplicably
        cancelled.
      
      We'll use the deceleration formula from
      https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
      to calculate then projection point, then pick the nearest snap point and
      calculate the duration as we did before. It works well enough for short
      distances, but has two problems:
      
      1. It caps the maximum distance at a pretty low value - about 5 pages in my
      testing.
      
      2. With how we pick the nearest snap point, it's too easy to accidentally
      cancel the swipe,
      
      To combat the first problem, we can modify the curve: only use linear
      function at small distances, and smoothly transition it to a parabola
      further.
      
      For the second problem we can add two special cases: first, if the swipe
      ended up between the initial snap point and the next one, we always prefer
      the latter. Second, a good old velocity threshold for cancelling.
      
      We'll also use a slightly smaller deceleration value for touchpad: 0.997
      instead of 0.998.
      
      Now that we can pick any snap point, the [-1, 1] clamping doesn't make
      sense anymore, so instead let's replace it with a more flexible
      mechanism: if we're near a snap point, pick its adjacent snap points.
      Otherwise, take the two nearest snap points, and take their adjacent
      snap points. This way we have 3 snap points to choose from when
      starting a swipe from an idle position, and 4 if we start during an
      ongoing transition.
      
      This way, if we've just swiped from snap point n to n+1, the transition
      will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
      likely land on n+2. During that transition, if we swipe again, it will
      likely have already passed the snap point n+1, so this time the available
      snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
      still complete, and so on.
      
      This will make it easy to allow multi-page swipes as well, by just
      removing the clamping.
      fff1ad51
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Calculate velocity using scroll history · 689b8734
      Alexander Mikhaylenko authored
      In some cases we may get event with very low delta at the end of the swipe.
      While we can't completely ignore them, we can smooth them using a scroll
      history, similarly to what GTK kinetic scrolling does: keep track of the
      last 150ms of events, and sum their deltas when calculating the velocity.
      689b8734
  6. 16 Feb, 2021 10 commits
  7. 09 Feb, 2021 1 commit
    • Adrien Plazas's avatar
      demo: Drop useless margins · cb4f740c
      Adrien Plazas authored
      This drops margins around clamps put in HdyStatusPage, as it already
      provides margins. This avoids having stupidly large margins in the Lists
      and Avatar pages.
      cb4f740c
  8. 02 Feb, 2021 1 commit
  9. 23 Jan, 2021 1 commit
  10. 22 Jan, 2021 2 commits
  11. 21 Jan, 2021 3 commits
  12. 20 Jan, 2021 5 commits