How to 'flick' to move across pages?

[yanshay]

On an embedded device with touch, I'd like to implement the behavior of switching across pages (like in mobile phones main view showing applications that allows switching between pages), so touching, scrolling to the side and lifting the finger switch to a different page.
Similar to the Printer App Demo, but instead of using buttons to switch between pages, to move using a flick gesture.
The flickable component is the closest I found but it scrolls, and doesn't let me force certain boundaries across pages.
Also, the screens I want to switch among also include standard controls, so need to have standard touch still pass to all touch areas under the larger area, so I can't even implement it myself using TouchArea on the entire screen because those other areas below will not get the events.
Any way to achieve what I want? Somehow catch the event of the flickable instead of letting it control the view?

Edit: I found #6005, SwipeGestureRecognizer, is that what I'm looking for?

[ogoffart]

Yes, SwipeGestureRecognizer might be the solution for your problem, and it is in the master branch right now.
Maybe you can get inspired with the example there: https://snapshots.slint.dev/master/docs/slint/src/language/builtins/elements.html#swipegesturerecognizer

[yanshay]

Yes, this is what I'm looking for.

Are the timeouts configurable? Especially for embedded touch devices where the sensitivity could vary, sometimes would require to allow longer press before moving to swipe (even if at expense of passing the press event to inner touch area).

[ogoffart]

Right now they aren't configurable.
If that's something that's really needed, we could make it configurable in a future release, or adjust to better default.

[igiona]

Right now they aren't configurable. If that's something that's really needed, we could make it configurable in a future release, or adjust to better default.

I would welcome these timer to be configurable as well.
On a flickable, the 100ms for the movement recognition is sometimes a bit harsh on a constraint embedded device and leads to poor UX

[yanshay]

I managed to get it working on WT32-SC01-Plus, ESP32S3 based device.

First time, it started scrolling and then panicked with the following.

====================== PANIC ======================
panicked at /Users/user/.cargo/git/checkouts/slint-8153123e5dffa129/ef18244/internal/core/software_renderer/draw_functions.rs:295:51:
called `Result::unwrap()` on an `Err` value: ()

After that it worked fine (nothing changed, just reset the device).
So seems like there are certain cases where something panics there.

Another note, it's not always 'catching' the swipe. As I thought, it seems like functionality with room for tuning, so if you can expose parameters to tune it, that could be very helpful. I guess the touch on embedded devices is not as good and accurate as on tablets/mobile phones, could be pretty noisy data.

Also: Change the code to vertical swipe, from time to time I get the following when swiping up (so far happened only when up).
I thought it was due to animation (because it referenced timers), but it happened also when I disabled the animations.
Any ideas what could cause this?

panicked at /Users/yanivshaya/.cargo/git/checkouts/slint-8153123e5dffa129/ef18244/internal/core/timers.rs:257:13:
Recursion in timer code

[ogoffart]

panicked at /Users/user/.cargo/git/checkouts/slint-8153123e5dffa129/ef18244/internal/core/software_renderer/draw_functions.rs:295:51:

Oh that sounds bad. Looking at the code in

slint/internal/core/software_renderer/draw_functions.rs

Line 295 in 725b0c9

Self(value.try_into().map_err(|_| ()).unwrap() << 4)

it looks like there was some overflow when drawing rounded rectangle. Would love to see a reproducable testcase.

Recursion in timer code

This might happen if you are calling slint::platform::update_timers_and_animations() from one of the timer handler itself.

In both case, a more complete backtrace might be useful.

[yanshay]

The first panic happened only once so far. I think at the point it happened I had only one type of rounded rectangle (though several of those), the 'special' thing about them was that they formed a circle, so the corner-radius was the width divided by two and width equaled height. Maybe that could help identifying the cause? Some edge case of animating the position change of such fully rounded rectangle? Maybe if the width/height is an odd number of pixels?

As for the 2nd panic - I don't use any slint timers, at least knowingly. I'm using the update_timers_and_animations in my rust event loop, but the only slint timers that may be executing would be due to slint code, and I myself don't have any. My code didn't include even animations and it happened also when I disabled the animations triggered from the Swipe action. So the only timers I can think of are in case SwipeGestureRecognizer uses timer and between uses of such timers it gives control back to my even loop that calls update_timers_and_animations().

As for complete backtrace, on panics from slint I get only the what I pasted. From other libraries I get a full backtrace. Any ideas why would that be?

[yanshay]

Recursion in timer code

This might happen if you are calling slint::platform::update_timers_and_animations() from one of the timer handler itself.

In both case, a more complete backtrace might be useful.

I'm beginning to understand what's causing this, even though not why, I filed the issue as #6332 and following a question I received I identified the cause. It may be interesting to read it as it is related to a solution to a limitation of slint in the case of async apps event loop.