Conversation
…handled is called - add event.is_pointer_event()
jneem
left a comment
jneem
left a comment
There was a problem hiding this comment.
Thanks! I guess figuring out the status of wheel isn't super critical, since mouse up/down are much more important.
This conversation has made me realize, though, that I don't really understand exactly when it's appropriate to set_handled...
| ctx.set_handled(); | ||
| if event.is_pointer_event() && previous_hot { | ||
| if layer.child.is_active() { | ||
| ctx.set_handled(); |
There was a problem hiding this comment.
Do we still need this set_handled? Given your point about set_handled affecting the rest of the widget tree, it seems maybe better to avoid it?
There was a problem hiding this comment.
Do you mean replace it with the obstructed flag or just remove it?
There was a problem hiding this comment.
There's a good chance I'm missing something, but I was thinking just remove it. Does that work?
I'm expecting that this child is active but not hot, and it will know how to correctly handle mouse events based on that, even if they aren't marked as handled.
There was a problem hiding this comment.
I'm expecting that this child is active but not hot, and it will know how to correctly handle mouse events based on that, even if they aren't marked as handled.
The child only knows that it is not hot because it received a follow up event (Mouse event while active is set) which was marked as ´handled´.
In any case we either need set_handled or obstructed.
There was a problem hiding this comment.
It is about the Pod not the widget. The Pod sees a mouse event inside its bounds. Therefore it sets its hot state to true. The only exception is that active and hot are both set. In that case the Pod sets hot to false but still propagates the event.
There was a problem hiding this comment.
You mean handled and not active, right? So in that case I understand why you need set_handled here, thanks for the explanation! I still think it isn't ideal because (as you explained in some other thread) it affects the global widget tree and not just the subtree under the zstack. But I don't think figuring it out needs to block this pr...
There was a problem hiding this comment.
Ups my mistake. I meant active and set_handled. In this case hot is set to false even if the curser is inside the widgets bounds
There was a problem hiding this comment.
I still think it isn't ideal because (as you explained in some other thread) it affects the global widget tree and not just the subtree under the zstack. But I don't think figuring it out needs to block this pr...
I aggree. The only thing which is still brocken is scrolling while pressing a mousebutton. That is not the most impprtant usecase. I think we can merge this PR as it is.
Event::Wheel is now a pointer event, which is probably the easiest solution. |
- update example
3 participants
This PR makes it possible for a parent widget to use mouse events (for an example scrolling) while hovering over a
ZStack.TODOs: