At first glance I was like "this looks great lets merge it", but I do want to take a step back and think about this for a second.

By adding a "one-frame released" event, we now have time based state transitions. This feels a bit odd to me because all of the other states change solely based on user input. And some people won't care about the "released" event, but with the new api they have to handle the "released" state too, likely by treating it the same as the None or Hovered state. But when we're in the Released state, how do we know if we're None or Hovered?

Can we quick brainstorm some alternatives that resolve these "issues"?

Good points!

Regarding the knowing if you are in None or Hovered state, the user should treat clicked as being in Hovered. You can only go from Hovered -> Pressed and from Pressed -> Clicked. The next frame it will go back to Hovered. Only if you move the cursor outside the bounding box of the node in the exact frame after you release the mouse button it will transition the Interaction to Clicked -> None but in that case I think it should not be a problem to think of the Clicked state as also meaning Hovered.

Regarding having to handle the Clicked interaction I think you make a valid point. Though currently you also have to handle the Hovered / Pressed state even though you might not always be interested in that either.

Besides these two issues, I agree it is a good idea to consider the impact of having time based transitions in general. An alternative could be to keep Interactions always be based on user inputs, and fire off events based on interactions like clicked, doubleclicked, pressed, hover, focus etc.

Closing this PR as I don't think this is the right way to handle UI events/interactions. We should probably look to do something closer to #431