Make sure bindings that don't expose properties in docs still have
descriptions.

Deltas don't contain it anymore.

Follow GTK4.

- Add G_PARAM_STATIC_STRINGS everywhere.
- Add missing G_PARAM_EXPLICIT_NOTIFY
- Remove G_PARAM_EXPLICIT_NOTIFY from read-only and construct-only props
- Consistently order them to ease grepping

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.

Maximiliano authored Dec 30, 2021 and Alexander Mikhaylenko committed Feb 03, 2022

It is not used by gir.

It is unfortunately a GCCism, so use the traditional method instead.
Unfortunately the autocleanup compiler extensions are not standard across the
board.

It's not necessary and removing it makes it simpler to copy between
libhandy and libadwaita.

All widgets have migrated, we can do it now.

Fixes #27

Keep duration for now, it will be removed after all widgets have stopped
using it.

Manuel Genovés authored Nov 16, 2021 and Alexander Mikhaylenko committed Nov 22, 2021

Update migration guides.

Move begin-swipe to when the swipe actually starts, replace what it was
before with a prepare signal.

Currently we have a hack in AdwFlap to check starting swipe in update-swipe
instead of begin-swipe because the latter runs too early. Now it can be
removed.

Update migration guides.

Fixes #79

It's not critical to depend on 2.70 right now, and it can cause problems:
even some of our CI images don't have 2.70 yet.

Instead, define G_DEFINE_FINAL_TYPE and G_DEFINE_FINAL_TYPE_WITH_CODE for
older glib versions, so we can use the newer macros when available.

This should be good enough for now, later if we decide to bump the version
this can be reverted.

See https://www.bassi.io/articles/2021/07/27/final-types/

Don't do this in the demo for now.

Fixes #273

Fix a refcycle between the widget and the swipe tracker.

See https://spdx.org/licenses/.

Alexander Mikhaylenko authored Mar 08, 2021 and Adrien Plazas committed May 07, 2021

While this makes perfect sense for touchpad, on touch it's useful to be
able to start a swipe outside the swipe area and move the finger over to
the swipe area.

This should make swipes more responsive in AdwFlap.

Alexander Mikhaylenko authored Feb 26, 2021 and Adrien Plazas committed May 07, 2021

They existed for AdwSwipeGroup, can be removed too now. Just inline them.

Alexander Mikhaylenko authored Feb 26, 2021 and Adrien Plazas committed May 07, 2021

Stop using adw_swipe_tracker_emit_end_swipe() so we can remove it.

Alexander Mikhaylenko authored Feb 26, 2021 and Adrien Plazas committed May 07, 2021

Another thing that's not needed without swipe groups.

Alexander Mikhaylenko authored Feb 26, 2021 and Adrien Plazas committed May 07, 2021

GtkButton doesn't claim the event sequence on press anymore, so we can
safely swipe from it.

Fixes #18

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

Avoid wrapping back to the first page when swiping forward from the last
page.

Alexander Mikhaylenko authored Feb 08, 2021 and Adrien Plazas committed Feb 19, 2021

Actually use the `pos` parameter in get_bounds().

Alexander Mikhaylenko authored Jul 09, 2020 and Adrien Plazas committed Feb 19, 2021

Since we now have the ability to support swiping through multiple pages,
expose it as a property.

Alexander Mikhaylenko authored Feb 04, 2021 and Adrien Plazas committed Feb 19, 2021

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.

Alexander Mikhaylenko authored Feb 04, 2021 and Adrien Plazas committed Feb 19, 2021

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.

Turns out gtk_get_current_event() is (transfer full), we need to free it.

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.