Regression: SCREEN_OT_area_dupli from ActionZone Not Working Correctly #85526

New Issue

Harley Acheson · 2021-02-10T18:18:18+01:00

Harley Acheson commented

2021-02-10 18:18:18 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 745/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 398.11

Blender Version
Broken: version: 2.93.0 Alpha, Commit 1c4ae8a11c
Worked: 5bddfde217 and prior

Short description of error
Invoking "Duplicate Area into New Window" from corner zones works once, but not subsequently

Exact steps for others to reproduce the error
Hold down "Shift" key while left-mouse dragging from the corner of any screen area. It works the first time, but afterward it just performs a split. Invoking the same operator from an "Area" menu instead continues to work as before. It is possible that this only affects Windows.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 745/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 398.11 **Blender Version** Broken: version: 2.93.0 Alpha, Commit 1c4ae8a11c820e33da725816d7cccb2668680e51 Worked: 5bddfde217b1477c02de9dcfa8c078969d432519 and prior **Short description of error** Invoking "Duplicate Area into New Window" from corner zones works once, but not subsequently **Exact steps for others to reproduce the error** Hold down "Shift" key while left-mouse dragging from the corner of any screen area. It works the first time, but afterward it just performs a split. Invoking the same operator from an "Area" menu instead continues to work as before. It is possible that this only affects Windows.

Harley Acheson commented

2021-02-10 18:18:18 +01:00

Added subscriber: @Harley

Harley Acheson self-assigned this 2021-02-10 18:33:08 +01:00

Harley Acheson commented

2021-02-10 18:33:08 +01:00

I mostly wanted to file this bug in case anyone else notices it. SCREEN_OT_area_dupli is a fairly hidden feature at the moment so might not be noticed, and this might also only affect Windows (not sure). I know what is going on and can fix, but would like to do it well as part of my current focus on simplifying and improving the window creation process. So might take a few days to do nicely.

in a nutshell this one operator is the only thing we have that calls WM_window_open(). That function - despite its name - does not actually open a window. More confusingly we do have a seemingly sibling function, WM_window_open_temp(), that does.

WM_window_open() only does part of the job of window creation and then relies on the running of other functions to clean up afterward. Like wm_check(), wm_window_ghostwindows_ensure(), and wm_window_ghostwindow_ensure(). Those function though always create only one type of window which (obviously) doesn't support windows of differing types (parented or not, dialog or not, etc).

The nice solution will be to remove the current WM_window_open. Then rename WM_window_open_temp to WM_window_open and have it take an "is_temp" argument. And then have SCREEN_OT_area_dupli fully create its window properly. Should leave everything much more logical and gives us a nice way to create non-temp windows of any type.

I mostly wanted to file this bug in case anyone else notices it. SCREEN_OT_area_dupli is a fairly hidden feature at the moment so might not be noticed, and this might also only affect Windows (not sure). I know what is going on and can fix, but would like to do it well as part of my current focus on simplifying and improving the window creation process. So might take a few days to do nicely. in a nutshell this one operator is the **only thing** we have that calls WM_window_open(). That function - *despite its name* - does not actually open a window. More confusingly we do have a seemingly sibling function, WM_window_open_temp(), that does. WM_window_open() only does part of the job of window creation and then relies on the running of other functions to clean up afterward. Like wm_check(), wm_window_ghostwindows_ensure(), and wm_window_ghostwindow_ensure(). Those function though always create only one type of window which (obviously) doesn't support windows of differing types (parented or not, dialog or not, etc). The nice solution will be to remove the current WM_window_open. Then rename WM_window_open_temp to WM_window_open and have it take an "is_temp" argument. And then have SCREEN_OT_area_dupli fully create its window properly. Should leave everything much more logical and gives us a nice way to create non-temp windows of any type.

Philipp Oeser commented

2021-02-11 09:03:32 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-02-11 09:03:32 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2021-02-11 09:03:32 +01:00

It works the first time, but afterward it just performs a split

and this might also only affect Windows (not sure)

Same thing on Linux it seems.

> It works the first time, but afterward it just performs a split > and this might also only affect Windows (not sure) Same thing on Linux it seems.

blender-admin commented

2021-02-12 19:39:33 +01:00

This issue was referenced by ba03f7f0b1

This issue was referenced by ba03f7f0b1d0c40acf997749949a0b0efe19e6d0

Harley Acheson commented

2021-02-12 20:25:36 +01:00

Added subscriber: @brecht

Harley Acheson commented

2021-02-12 20:25:36 +01:00

This is now working correctly on Windows, but with a fix that only changed code for Win32 platform. So can't close this yet because of @lichtwerk's report that this is not working correctly on Linux. So if confirmed there it would have to be something else as well that isn't also affecting Win32.

For a change in 1c4ae8a11c that breaks Linux but not break Windows would have to be a difference in is_dialog or parent handle for new window, or related to @brecht's changes in GHOST_WindowX11.cpp. In this case, for area_dupli, the new window should have a parenthandle and would not be is_dialog. The call to XCreateWindow() does seem to no longer pass parent handle (but it might be done elsewhere), and the call to XSelectInput() is omitted. But for these to be a problem, we should also see similar issues for every window opened by Blender, and haven't heard that yet.

This is now working correctly on Windows, but with a fix that only changed code for Win32 platform. So can't close this yet because of @lichtwerk's report that this is not working correctly on Linux. So if confirmed there it would have to be something else as well that isn't also affecting Win32. For a change in 1c4ae8a11c820e33da725816d7cccb2668680e51 that breaks Linux but not break Windows would have to be a difference in is_dialog or parent handle for new window, or related to @brecht's changes in GHOST_WindowX11.cpp. In this case, for area_dupli, the new window should have a parenthandle and would not be is_dialog. The call to XCreateWindow() does seem to no longer pass parent handle (but it might be done elsewhere), and the call to XSelectInput() is omitted. But for these to be a problem, we should also see similar issues for every window opened by Blender, and haven't heard that yet.

Brecht Van Lommel commented

2021-02-18 19:19:59 +01:00

I can't confirm this on Linux.

Harley Acheson commented

2021-02-18 19:27:05 +01:00

@lichtwerk - Do you mind checking this again on Linux? You had added a "Same thing on Linux it seems." This working great on Windows, but with a fix that only changed code on that platform.

Philipp Oeser commented

2021-02-18 19:42:56 +01:00

I might have gotten this wrong.

It still behaves like this in current master (but only when the "new" window still has focus). When focus is in the "new" window, and you try to shift-drag the corner in the "old" window, this results in a split (still).
The "old" window will gain focus back.
This might all be expected behavior -- in that case: sorry for the noise.

I might have gotten this wrong. It still behaves like this in current master (but only when the "new" window still has focus). When focus is in the "new" window, and you try to shift-drag the corner in the "old" window, this results in a split (still). The "old" window will gain focus back. This might all be expected behavior -- in that case: sorry for the noise.

Harley Acheson commented

2021-02-18 22:55:15 +01:00

@lichtwerk
It still behaves like this in current master (but only when the "new" window still has focus). When focus is in the "new" window, and you try to shift-drag the corner in the "old" window, this results in a split (still).
The "old" window will gain focus back.
This might all be expected behavior -- in that case: sorry for the noise.

No, no noise at all. I'm just sure what to do with this report.

I am not able to recreate what you see on Windows. No matter which of the windows has focus I am able area_dupli, so this might be something only Linux and/or Mac.

But this bug is really about it being completely broken on Windows, and that part is fixed. So do we close this and then can open a new one if we get later complaint on Linux? Or we could leave it open and I could find someone to confirm whether this behavior has changed on Linux and bisect when it changed. I just don't compile for Linux so a bit hampered there. But don't mind chasing this down if need be.

> @lichtwerk > It still behaves like this in current master (but only when the "new" window still has focus). When focus is in the "new" window, and you try to shift-drag the corner in the "old" window, this results in a split (still). > The "old" window will gain focus back. > This might all be expected behavior -- in that case: sorry for the noise. No, no noise at all. I'm just sure what to do with this report. I am not able to recreate what you see on Windows. No matter which of the windows has focus I am able area_dupli, so this might be something only Linux and/or Mac. But this bug is really about it being completely broken on Windows, and that part is fixed. So do we close this and then can open a new one if we get later complaint on Linux? Or we could leave it open and I could find someone to confirm whether this behavior has changed on Linux and bisect when it changed. I just don't compile for Linux so a bit hampered there. But don't mind chasing this down if need be.

Brecht Van Lommel commented

2021-02-22 16:51:35 +01:00

Changed status from 'Confirmed' to: 'Archived'

Brecht Van Lommel closed this issue

2021-02-22 16:51:35 +01:00

Brecht Van Lommel commented

2021-02-22 16:51:35 +01:00

This has never worked on Linux as far as I know. It happens even in 2.79, or when e.g. using shift + select.

This is a known issue mentioned in #55364 and #40155.

This has never worked on Linux as far as I know. It happens even in 2.79, or when e.g. using shift + select. This is a known issue mentioned in #55364 and #40155.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: SCREEN_OT_area_dupli from ActionZone Not Working Correctly #85526