Set thumb color to lighter in core_widgets_observers when dragging with pointer not over

[ickshonpe]

Objective

In core_widgets_observers the thumb should stay the active color during drags when the pointer is not hovering the slider.

Solution

• In slider_on_change_hover, query for CoreSliderDragState and set the thumb color lighter if the slider is hovered or dragged.
• Add a system update_thumb_color_when_drag_ends to update the thumb color when dragging ends.

Not ideal implementation, would be better with some way to observe the drag state.

[viridia]

Can we hold off on this until after the renaming goes in?

I agree with the motivation, the only reason I didn't implement this before was I was hoping for a better way to do it.

All of the feathers widgets would be greatly simplified with a real reactive framework: I have similar widgets in both thorium_ui and bevy_reactor and they are a lot less messy.

[alice-i-cecile]

Blocked on #20944.

[ickshonpe]

Can we hold off on this until after the renaming goes in?

I agree with the motivation, the only reason I didn't implement this before was I was hoping for a better way to do it.

All of the feathers widgets would be greatly simplified with a real reactive framework: I have similar widgets in both thorium_ui and bevy_reactor and they are a lot less messy.

Yep, this is just the least worst fix I could think of so it's not broken for the 0.17 release.

My naive idea for a proper fix I was thinking about earlier would be to rework the picking events to something like:

• When a drag starts, dispatch Out before DragStart.
• When a drag ends, dispatch Over after DragEnd.
• Don't dispatch Over and Out while dragging.
• For simplicity's sake, disallow simultaneous drags with multiple buttons.

And maybe add a Dragged component similar to Hovered that is updated when an entity's drag state changes.

[viridia]

On the web, the modern way to do this kind of dragging is to call setPointerCapture(), which means that all pointer events will be routed to the capture element, bypassing the normal picking logic. I lobbied for this a couple years ago, but I lost that argument.

[ickshonpe]

On the web, the modern way to do this kind of dragging is to call setPointerCapture(), which means that all pointer events will be routed to the capture element, bypassing the normal picking logic. I lobbied for this a couple years ago, but I lost that argument.

Yes I quite like that. I guess it's pretty similar to my solution above, just more explicit than implicit. But with setPointerCapture it would eliminate any confusion when a drag starts with the pointer hovering more than one UI node.