osu-framework
osu-framework copied to clipboard
Hover events likely shouldn't raise if an active drag is in progress
Checked that this is standard behaviour on macOS and windows
https://user-images.githubusercontent.com/191335/165684195-5fd49b7f-ac21-4819-ab29-4544395342a0.mp4
https://user-images.githubusercontent.com/191335/165684538-630f5599-3768-431a-aef1-6c255544b97c.mp4
Doesn't feel great
It depends on the context though. For example it will raise hover events if you're dragging files around in Finder (or on the desktop), whether it is onto other folders or onto the sidebar tree.
That is true, but I think it is the unlikely case for o!f since these hover events come from whether the hovered element accepts receiving the dragged element and handling it. Maybe we can add a rule against this once o!f supports "drop targets"
Drag/drop targets are definitely an edge case. but we don't really have anything like that implemented yet. maybe something to consider when addressing this issue though.
Perhaps a natural behavior is that, while the mouse is "captured" (dragging is a special case) by a node, a hover event shouldn't be dispatched to other nodes. osu!framework don't have a notion of exclusive mouse capturing, but an approximation is using mouse left button's "mouse down input queue", like:
@@ -629,7 +629,8 @@ private void updateHoverEvents(InputState state)
if (HandleHoverEvents)
{
// First, we need to construct hoveredDrawables for the current frame
- foreach (Drawable d in PositionalInputQueue)
+ var inputQueue = (IEnumerable<Drawable>)GetButtonEventManagerFor(MouseButton.Left).ButtonDownInputQueue ?? PositionalInputQueue;
+ foreach (Drawable d in inputQueue)
Or perhaps all buttons of the mouse should considered. The change above passes all framework tests. Is it a good solution?
That may work quite well. Still won't handle the drop target case (unless said drop target is handling mouse everywhere) but seems like it will improve the one mentioned in the opening post.