Nested TouchArea: catch the same event at different levels.

[timjrd]

Hi! 🙂 I'm implementing a screensaver for my C++/Slint app, which is running in kiosk mode. I would like to trigger the screensaver after a given idle period, aka after some time without any incoming touch event. Basically I would like to do something like that:

TouchArea {
    clicked => { debug("also catched"); }
    TouchArea {
        clicked => { debug("catched"); }
    }
}

When I try this, only the inner-most TouchArea gets notified. How can I make it working? Alternatively, is there a way to listen to touch events globally from C++?

Thanks! 🙂

[tronical]

I think @FloVanGH was trying to solve a similar issue for the energy monitor demo. How did you do that again?

My naive and untested approach would be to place a touch area at the bottom:

export component App {
    // ... all your UI elements here

    // This comes last and will span the entire window
    if screen-saver-enabled: TouchArea {
        clicked => { root.screen-saver-enabled = false; }
    }
}

I made a little example on SlintPad.

[timjrd]

Thanks for your answer. 🙂 I played around with this solution a bit, but that doesn't work for my use case: I would like to get notified each time the root window gets an incoming touch event (or any user input event), without preventing that event from reaching its destination. I can workaround this by calling the same callback in every TouchArea of my application, but it feels a bit heavy. Putting TouchArea at the bottom of the root component catches everything, but it cancel the event propagation. Nesting TouchArea doesn't prevent propagation, but the top-level one only catches events that are not caught by lower-level ones.

[tronical]

Ahh right, the proposed suggestion intercepts the event, but you want it to go still be processed, right?

Perhaps it would suffice to have an accept field in the pointer-event's event argument, default it to true, but allow you to set it to false - so that you see the event but you can say "I don't accept it" and thus it'll be propagated to what's underneath the area.

Olivier, you're the TouchArea expert :-). Does this make sense?

[ogoffart]

We're missing such API, yes.
Some option on how we could implement this feature:

1. We could change the return type of the pointer-event callback, and have a feature that some enum can be constructed from void in return position.
2. we could add a property to the touch area transparent or propagate
3. We could use a different element that have different behavior like a gesture recognizer or something like that.

[tronical]

I think (1) is the cleanest if it's combined with a warning that this conversion will be removed in say "2.0" and that one must specify accept or ignore (like for the focus scope).

[ogoffart]

So if you want to have a Transparent TouchArea you'd do

// use ta.pressed and other properties in the rest of the code
ta := TouchArea {
    clicked => { debug("clicked") }
    
    //but in order to make it transparent, add this callback
    pointer-event => { return reject }
}

But the problem is that EventResult::reject is already currently the default value of that enum.

combined with a warning

We will get lots and lots of warning. Also i find it less ergonomic in the typical case to always have to return something

[timjrd]

Thanks for your interest in my use case! In the meantime I think I will simply redefine my own TouchArea with a custom hook in clicked, and use this MyTouchArea everywhere. 🙂