1. 10 Aug, 2022 1 commit
  2. 22 Jul, 2022 2 commits
  3. 20 Jun, 2022 2 commits
  4. 12 May, 2022 1 commit
    • bob's avatar
      swipe-tracker: fix memory leak · 61a0488b
      bob authored
      AdwSwipeTracker allocates a GArray to hold event history but never
      frees it. This commit adds a finalize implementation that ensures the
      array gets freed.
      Fixes 689b8734.
  5. 03 Feb, 2022 2 commits
  6. 19 Jan, 2022 1 commit
    • Chun-wei Fan's avatar
      Remove g_auto* usage · c2d77ba7
      Chun-wei Fan authored
      It is unfortunately a GCCism, so use the traditional method instead.
      Unfortunately the autocleanup compiler extensions are not standard across the
  7. 28 Dec, 2021 2 commits
  8. 06 Dec, 2021 2 commits
  9. 22 Nov, 2021 1 commit
  10. 08 Nov, 2021 3 commits
  11. 03 Nov, 2021 1 commit
  12. 26 Jul, 2021 1 commit
  13. 01 Jun, 2021 1 commit
  14. 17 May, 2021 1 commit
  15. 07 May, 2021 6 commits
  16. 02 Apr, 2021 1 commit
    • Alexander Mikhaylenko's avatar
      Stop translating properties · cd8f3a23
      Alexander Mikhaylenko authored
      This was useful for Glade and GtkInspector; Glade doesn't work on GTK 4 and
      GtkInspector stopped showing property names. Translating them is a lot of
      work for translators, and these are most of our translatable strings.
      Fixes #89
  17. 02 Mar, 2021 3 commits
  18. 19 Feb, 2021 4 commits
    • Alexander Mikhaylenko's avatar
      swipe-tracker: A small cleanup · 07403f12
      Alexander Mikhaylenko authored and Adrien Plazas's avatar Adrien Plazas committed
      Actually use the `pos` parameter in get_bounds().
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Add allow-long-swipes property · 45833931
      Alexander Mikhaylenko authored and Adrien Plazas's avatar Adrien Plazas committed
      Since we now have the ability to support swiping through multiple pages,
      expose it as a property.
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Rework end point calculation · fff1ad51
      Alexander Mikhaylenko authored and Adrien Plazas's avatar Adrien Plazas committed
      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
      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
      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
      We'll use the deceleration formula from
      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
      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
      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.
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Calculate velocity using scroll history · 689b8734
      Alexander Mikhaylenko authored and Adrien Plazas's avatar Adrien Plazas committed
      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.
  19. 13 Jan, 2021 1 commit
  20. 12 Jan, 2021 2 commits
  21. 22 Dec, 2020 1 commit
  22. 15 Dec, 2020 1 commit
    • Alexander Mikhaylenko's avatar
      swipe-tracker: Fix coordinate transformation for scrolling · 4e6ba0b1
      Alexander Mikhaylenko authored
      Event coordinates are relative to the GdkWindow the event was on.
      Meanwhile, gtk_widget_translate_coordinates() transforms coordinates from
      a widget to another widget, instead of from a window to widget. This means
      that it's only correct if the widget and window coordinates match, which is
      not always the case and leads to misplaced swipe area in some cases.