Add stop(), start(), and restart() methods to Timer

[codeshaunted]

Adds timer start(), stop(), and restart() methods. Closes #7476. Not sure how testing should be done for the interpreter here.

[ogoffart]

Thanks,this looks good.

The only missing thing I can see is the documentation.

I've also added comments about adding extra tests for Timer in sub components.

Not sure how testing should be done for the interpreter here.

The JS scripts take care of it.

[ogoffart]

I believe we need to keep a reference to the original element only to be able to lookup its index later as it is part of the .restart() function.
I'm wondering if there is a better way. I could think of storing the index within the Element Or rewriting the call to RestartTimer to have the timer index. But that seems dangerous.
I'm worried that the timer could be wrong after some inlining steps or something like that though. But it might be fine.

[ogoffart]

👍

Could you add an extra timer in another component?

Like add some component such as

component ComponentWithTimer {
   timer-a := Timer { ... }
   if true: Rectangle { // Make sure it works in condition.
      timer-b := Timer { 
          running: false; 
          interval: 3s; 
          triggered => { self.stop(); root.triggered("b") }
          init => { timer-b.start() }
      } 
   } 
   
   callback trigerred(string);  // called from the triggered callback of the timers
   function ... // to start and restart timer-a
}

And then use that component twice, from the Window.

Just to make sure that nothing fishy happens when the timer is in a sub component.

This code is just an example feel free to be creative ;-)

[ogoffart]

Thanks for the extra tests.

What I would have liked to see is a test where the Timer is in a different component. Because i am afraid that when in-lining, the timer id in the expressions might not be correctly adjusted.

[tronical]

Awesome work, looks very clean to me. I've found one potential issue - see comment inline. I'll defer to Olivier for the final approval :)

[tronical]

My guts feeling is that this should perhaps be an ElementWeak instead of an ElementRc.

[ogoffart]

indeed, to be sure, it should be an ElementWeak.

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

Thanks.

I'd still left two inline comments in the code, but it already looks good. If you don't have more time to work on this, i could take over. (But it'll take some times because i'll be traveling the next few weeks)

[ogoffart]

Thanks for the extra tests.

What I would have liked to see is a test where the Timer is in a different component. Because i am afraid that when in-lining, the timer id in the expressions might not be correctly adjusted.

[ogoffart]

indeed, to be sure, it should be an ElementWeak.

[ogoffart]

The CI is failing with the interpreter, as i was fearing. I am pretty sure this is because the timers are not being properly inlined.

This line:

slint/internal/compiler/passes/inlining.rs

Line 204 in 917c9a8

root_component.timers.borrow_mut().extend(inlined_component.timers.borrow().iter().cloned());

We'd need to map the element within the timer structure.

[ogoffart]

To be explicit, in the inline_element function, there is a mapping hashmap that maps from ElementRc in the component being inlined, to the inlined ElementRc, so you need to apply the mapping, so that instread of inlined_component.timers.borrow().iter().cloned() you'd do inlined_component.timers.borrow().iter().map(....) and this map would take care of changing the Timer::element and map it using the mapping hashmap.