Fix #93685: Allow Outliner Drag to Other Windows #105196

Harley Acheson · 2023-02-25T02:09:20+01:00

Harley Acheson commented

2023-02-25 02:09:20 +01:00

Allow dragging items from Outliner to other windows. Disables EdgePan
operator when entering new window. Canceling the drop redraws target
area and resets all modal cursors. But this does not fix incorrect
mouse cursor during operations on the remote target window.

This PR cancels the EdgePan operator (view2d_ops.cc) when your mouse enters a new window. This is the main cause of drag and drop not working between windows: not allowing it when another modifier is running (wm_event_cursor_other_windows) and EdgePan runs continuously once started.

This also makes changes to the code executed when a drag finishes (wm_drags_exit). It fixes two things. One is that nothing is redrawn if the drag is canceled (any_active is false) so the 3DView widget remains drawn, when on a different window than it starts from. The second issue is that our modal cursors are per-window, so you can imagine moving from one window to another and back again will leave the modal state set on the middle one. This code clears modal cursors across all windows.

This also makes other changes in wm_dragdrop.cc so that all operations work on the window under the cursor, not just the active window. This means that you can drag an Object from Outliner in one window and drop it into the 3DView of another window. And you can can also drop the name into text input boxes, etc.

HOWEVER, this does not fix the fact that the mouse cursor is not updated and can be shown correctly within the remote target window. So the feedback from the mouse cursor will quite often be wrong, even though the process otherwise works. This seems to be a larger problem within our wm_event_system.cc where we deal with each window in turn, only dealing with events with cursor positions relative to it, but not in other windows relative to the active one. This means that that while one window is active, but you are in an operation over another window that one does not get ED_screen_set_active_region called on it.

I'm not seeing any easy fixes or workarounds for this, so it might have to remain a known limitation and "to do", that dragging to another window does not correctly update the mouse cursor. But at least this PR would allow the operation to work.

The following shows a drag and drop operation from one window to another. It works for all regions, but the cursor shown is always the one that it enters the window with, in this case the default pointer:

Following shows the same (successful) operation, but the mouse leaves the source window at a no-drop zone, which is why the "stop sign" cursor is shown while in the target window:

Allow dragging items from Outliner to other windows. Disables EdgePan operator when entering new window. Canceling the drop redraws target area and resets all modal cursors. But this does not fix incorrect mouse cursor during operations on the remote target window. --- This PR cancels the EdgePan operator (view2d_ops.cc) when your mouse enters a new window. This is the main cause of drag and drop not working between windows: not allowing it when another modifier is running (wm_event_cursor_other_windows) and EdgePan runs continuously once started. This also makes changes to the code executed when a drag finishes (wm_drags_exit). It fixes two things. One is that nothing is redrawn if the drag is canceled (any_active is false) so the 3DView widget remains drawn, when on a different window than it starts from. The second issue is that our modal cursors are per-window, so you can imagine moving from one window to another and back again will leave the modal state set on the middle one. This code clears modal cursors across all windows. This also makes other changes in `wm_dragdrop.cc` so that all operations work on the window under the cursor, not just the active window. This means that you can drag an Object from Outliner in one window and drop it into the 3DView of another window. And you can can also drop the name into text input boxes, etc. HOWEVER, this does not fix the fact that the mouse cursor is not updated and can be shown correctly within the remote target window. So the feedback from the mouse cursor will quite often be wrong, even though the process otherwise works. This seems to be a larger problem within our wm_event_system.cc where we deal with each window in turn, only dealing with events with cursor positions relative to it, but not in other windows relative to the active one. This means that that while one window is active, but you are in an operation over another window that one does not get `ED_screen_set_active_region` called on it. I'm not seeing any easy fixes or workarounds for this, so it might have to remain a known limitation and "to do", that dragging to another window does not correctly update the mouse cursor. But at least this PR would allow the operation to work. The following shows a drag and drop operation from one window to another. It works for all regions, but the cursor shown is always the one that it enters the window with, in this case the default pointer: ![Drop1.gif](/attachments/ef0b8f10-0655-4a2c-81ab-2e6d74ce3c5a) Following shows the same (successful) operation, but the mouse leaves the source window at a no-drop zone, which is why the "stop sign" cursor is shown while in the target window: ![Drop2.gif](/attachments/e5740407-c0e5-45c3-ad43-67058546c9a9)

Drop2.gif

426 KiB

Drop1.gif

327 KiB

👍 3 ❤️ 4

Harley Acheson referenced this pull request

2023-02-25 02:13:48 +01:00

Regression: Dragging an ID from the Outliner of a window cannot be dropped in another window #93685

Harley Acheson changed title from ~~Fix 93685: Allow Outliner Drag to Other Windows~~ to Fix #93685: Allow Outliner Drag to Other Windows

2023-02-25 02:24:40 +01:00

Germano Cavalcante commented

2023-02-27 19:23:48 +01:00

The 3rd change looks like it could be in another Pull Request.
I'm having a hard time listing the advantages and disadvantages of that change.

But is possible to overlap two windows in such a way that you can drag directly from a "no drop" zone on the source window to a "drop" zone on the target window

I feel that the GHOST_IWindow *GHOST_System::getWindowUnderCursor(int32_t x, int32_t y) could be edited to test the windows in "Z-order" (or else test the active window first). So that wouldn't be a problem anymore?

The 3rd change looks like it could be in another Pull Request. I'm having a hard time listing the advantages and disadvantages of that change. > But is possible to overlap two windows in such a way that you can drag directly from a "no drop" zone on the source window to a "drop" zone on the target window I feel that the `GHOST_IWindow *GHOST_System::getWindowUnderCursor(int32_t x, int32_t y)` could be edited to test the windows in "Z-order" (or else test the active window first). So that wouldn't be a problem anymore?

Harley Acheson commented

2023-02-27 20:38:08 +01:00

The 3rd change looks like it could be in another Pull Request.
I'm having a hard time listing the advantages and disadvantages of that change.

Me, too. I really only added that because I just hate the idea of working on something like this and not leaving it perfect, but

But is possible to overlap two windows in such a way that you can drag directly from a "no drop" zone on the source window to a "drop" zone on the target window

I feel that the GHOST_IWindow *GHOST_System::getWindowUnderCursor(int32_t x, int32_t y) could be edited to test the windows in "Z-order" (or else test the active window first). So that wouldn't be a problem anymore?

I'm no expert there so might have some of this wrong, but without doing #3...

When you generally move the mouse around the interface we are looking for areas under the cursor and if there are none we then look for the gaps between areas, and if there isn't anything at all we show a default pointer for outside of the window.

While doing a drag and drop operation though it is setting a modal cursor. While this is set the setting of pointer outside of the window just continues to show the last one, rather than set it to default pointer.

When the mouse moves completely to another window then our calculation of which area we are in starts screwing up. In this drag operation the source window is still active and so the location of the mouse is relative to that window and we can't tell that what area is which. So it looks like we are just outside of the source window and not actually in one of our windows. It tries to show the default arrow but just continues to show the last one because of the modal status.

This means that without #3 things sort of look okay in simple situations. Your mouse is in Outliner or 3DView, looks like an arrow and you drag it out of the window. The arrow continues to be an arrow between windows and does so the entire time you are in that target window (even whether a drop target or not)

But if you instead drag from Outliner over Properties you get a "no-drop" cursor, drag off the window and it continues to show that (because modal) and will keep showing that in the target window. #3 just resets that cursor correctly between windows and as you enter the new one. But even with #3 it does not show "no-drop" over the target window Properties area.

> The 3rd change looks like it could be in another Pull Request. > I'm having a hard time listing the advantages and disadvantages of that change. Me, too. I really only added that because I just hate the idea of working on something like this and not leaving it perfect, but > > But is possible to overlap two windows in such a way that you can drag directly from a "no drop" zone on the source window to a "drop" zone on the target window > > I feel that the `GHOST_IWindow *GHOST_System::getWindowUnderCursor(int32_t x, int32_t y)` could be edited to test the windows in "Z-order" (or else test the active window first). So that wouldn't be a problem anymore? I'm no expert there so might have some of this wrong, but without doing #3... When you generally move the mouse around the interface we are looking for areas under the cursor and if there are none we then look for the gaps between areas, and if there isn't anything at all we show a default pointer for outside of the window. While doing a drag and drop operation though it is setting a **modal** cursor. While this is set the setting of pointer outside of the window just continues to show the last one, rather than set it to default pointer. When the mouse moves completely to another window then our calculation of which area we are in starts screwing up. In this drag operation the source window is still active and so the location of the mouse is relative to that window and we can't tell that what area is which. So it looks like we are just outside of the source window and not actually in one of our windows. It tries to show the default arrow but just continues to show the last one because of the modal status. This means that without #3 things sort of look okay in simple situations. Your mouse is in Outliner or 3DView, looks like an arrow and you drag it out of the window. The arrow continues to be an arrow between windows and does so the entire time you are in that target window (even whether a drop target or not) But if you instead drag from Outliner over Properties you get a "no-drop" cursor, drag off the window and it continues to show that (because modal) and will keep showing that in the target window. #3 just resets that cursor correctly between windows and as you enter the new one. But even with #3 it does not show "no-drop" over the target window Properties area.

Harley Acheson requested review from Julian Eisel 2023-03-06 00:48:31 +01:00

Harley Acheson referenced this pull request

2023-03-08 19:24:14 +01:00

Fix #105435: Pause Win32 Auto-Focus During Text Entry #105446

Harley Acheson changed title from ~~Fix #93685: Allow Outliner Drag to Other Windows~~ to WIP: Fix #93685: Allow Outliner Drag to Other Windows

2023-03-10 17:05:47 +01:00

Harley Acheson force-pushed EdgePanDrag from 0408bd7fa8 to b5a931305f

2023-03-10 19:36:22 +01:00

Compare

Harley Acheson changed title from ~~WIP: Fix #93685: Allow Outliner Drag to Other Windows~~ to Fix #93685: Allow Outliner Drag to Other Windows

2023-03-10 19:51:44 +01:00

Harley Acheson commented

2023-03-10 19:57:11 +01:00

I removed the changes to ED_screen_set_active_region. Although that earlier change, along with what is in this PR now, correctly shows the mouse cursor at all times it was a very incorrect change. It caused that function to ONLY work on the one window under the cursor and not for all of them, which is the intention when it is called in ED_screens_init. It fixed the cursor for this problem when called from wm_event_do_handlers.

I removed the changes to `ED_screen_set_active_region`. Although that earlier change, along with what is in this PR now, correctly shows the mouse cursor at all times it was a very incorrect change. It caused that function to ONLY work on the one window under the cursor and not for all of them, which is the intention when it is called in `ED_screens_init`. It fixed the cursor for this problem when called from wm_event_do_handlers.

Harley Acheson changed title from ~~Fix #93685: Allow Outliner Drag to Other Windows~~ to WIP: Fix #93685: Allow Outliner Drag to Other Windows

2023-03-11 19:20:29 +01:00

Harley Acheson force-pushed EdgePanDrag from b5a931305f to 5611b109e4

2023-03-11 20:49:25 +01:00

Compare

Harley Acheson changed title from ~~WIP: Fix #93685: Allow Outliner Drag to Other Windows~~ to Fix #93685: Allow Outliner Drag to Other Windows

2023-03-12 19:24:10 +01:00

Thomas Dinges commented

2023-03-14 15:44:08 +01:00

@JulianEisel Hey, can you please take a look at this PR? It fixes a high priority report. Thanks.

Harley Acheson added this to the User Interface project 2023-04-07 19:23:28 +02:00

Harley Acheson added 2 commits 2023-07-21 01:05:49 +02:00

8279cc73c3 Merge branch 'main' of projects.blender.org:blender/blender into EdgePanDrag

888b0dcf6b Updated. small cleanup

Dalai Felinto requested review from Brecht Van Lommel 2023-08-15 17:52:05 +02:00

Brecht Van Lommel approved these changes 2023-08-15 19:46:48 +02:00

Harley Acheson added 2 commits 2023-08-17 00:14:11 +02:00

a2f38ebf75 Merge branch 'main' of projects.blender.org:blender/blender into EdgePanDrag