osu-framework icon indicating copy to clipboard operation
osu-framework copied to clipboard

Hover events likely shouldn't raise if an active drag is in progress

Open peppy opened this issue 3 years ago • 5 comments

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

peppy avatar Apr 28 '22 05:04 peppy

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.

smoogipoo avatar Apr 29 '22 03:04 smoogipoo

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"

frenzibyte avatar Apr 29 '22 03:04 frenzibyte

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.

peppy avatar Apr 29 '22 03:04 peppy

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?

ekrctb avatar May 06 '22 09:05 ekrctb

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.

peppy avatar May 06 '22 11:05 peppy