Add hot state updating via wheel events.

[xStrom]

This fixes an edge case where we receive a wheel event at a location different than the last move event.

[luleyleo]

Looks good.
I was wondering why MouseMove is a special case for recursion.
It should probably get a comment about why that was done.
Should I open an issue for that?

[xStrom]

No need for an issue, I'll send a simple PR with that comment in a few minutes.

[cmyr]

I have a thought related to this that I'm not sure I've ever spelled out:

I think it should be an invariant that changes in mouse position always generate a move event.

That is: a click or a wheel or any other mouse event should always occur at the same position as the last move.

If this isn't something the platform enforces, it's something that we could implement in druid-shell.

I think this offers a lot of clarity at the druid layer; it would simplify a lot of code, and would then be a very useful guarantee that we could pass along to users.

Is there any reason this doesn't make sense?

[xStrom]

Yeah that makes sense and we can do it. I don't think any of the platforms we support guarantee a move event before click, but druid-shell could do that. It would indeed greatly simplify not just druid logic, but also the logic in apps built on druid.

[luleyleo]

Yes, this sounds like a good idea, after all widgets care about mouse movement relative to their own position, which would be changed by scrolling a Scroll for example. Not sure tho, if it should always generate a MouseMove, for example when nothing is moving despite scrolling. But then again I doubt there is any harm in having to many stationary move events 🤔

[cmyr]

I wouldn't include scroll in this, I think that's an over-complication. Hot might change as scroll does, but this doesn't involve a mouse move?

[xStrom]

Hmm, well this is actually a bit tricky. So druid-shell could guarantee that there's a move event before a click event if the position has changed - but this is only in relation to the window.

Druid would still suffer. Imagine the following scenario:

• Mouse is moved to location X, druid widget gets the move event.
• Druid widget moves to a new location (could be a timer, a database result, whatever)
• Mouse is clicked, druid-shell doesn't send a move event because in relation to the window the mouse is in the same position as previously. However in relation to the widget the location has changed.
• The widget gets a click event with a position different from the last move event.

I don't think this can be solved without keeping some sort of state per widget about the mouse location. This would have to be in druid, not druid-shell.

Thus I'm not sure if it's worth doing this move event guarantee. It would end up in more complex code than right now.

[cmyr]

I guess the other thing to consider is do we want to make scrolling first-class, and have some sort of 'ScrollChanged' lifecycle event?

[xStrom]

Not sure I understand. ScrollChanged sent to children of Scroll to inform of origin changes?`

(Also just to be clear, my example above about a widget moving is independent of scrolling and can happen with regular widgets and regular clicks.)

[luleyleo]

I think druid should generate MouseMove events when scrolling or layout in general changes 🤔
Because currently the list example visualizes the issue quite nicely, hovering a button marks it 'hot', after scrolling until the cursor is no longer over the button it still is hot and the button that should be hot did not get an update.

[xStrom]

Hot state is already updated after layout changes. I think this is something specific to Scroll. I opened #956 to track this.

[luleyleo]

I see, as long as hot state is reliable, it could be ok not to generate MouseMoves when scrolling but I still think it would be necessary to get something like region select + scroll which most platforms allow, as it would probably require reliable MouseMoves relative to the widget position.

[cmyr]

I think MouseMove should only be sent if the user has moved the mouse.

And yes, ScrollChanged would be a lifecycle event sent to children in a container that has been scrolled. I'm not saying we want this, but it's possible; there are a bunch of funny things about scrolling that suggest it might need special casing.