Revert 104438: Windows Spanning Multiple Monitors #104956

Harley Acheson · 2023-02-19T19:12:32+01:00

Harley Acheson commented

2023-02-19 19:12:32 +01:00

Revert of commits that allowed non-temp Blender windows to be saved
and restored that spanned multiple monitors on the Windows platform.
This causes problems with temp windows (like Preferences & Render) that
cannot currently be fixed.

The first complication is the way that we position temporary Blender windows. We attempt to center them around the mouse position at the time they are created. For Preferences for example, this means we are wanting it to the left of the main window. Since by default the main window is taking up the entire monitor, the default position of Preferences is left of the monitor edge.

We were relying on Ghost to sanitize the size and positions of these windows, so this behavior had no real consequence. But I was attempting to allow a user to create windows that spanned monitors and these windows are currently designed to do exactly that. It isn't an option to just move or alter them because that is behavior I am trying to allow. If you want a window spanning monitors that should be fine. But we don't actually want that for these.

The obvious approach is to instead sanitize these window positions and sizes at the call site. That way we can deal with temp windows specially. But we currently cannot get a behavior that is similar to the mouse-centered positioning. This is because we cannot consistently determine the distance between a Blender window and its containing monitor edge. We don't always know where it is in relation to the monitor.

The above might sound incorrect. In a simple setup with a blender window on the main monitor, we do know all this because we have that monitor's dimensions and the window's size and offset position. However, when a blender window is on any other monitor we don't have enough information because we don't have other monitor dimensions or positions. We do have desktop dimensions but we are missing per-monitor rects so to know where that monitor is placed within it. Otherwise we might know that the main monitor is 1920x1080 and that our blender window is 1000x500 with its bottom corner at -1500, 3000. We can guess that it is on a monitor to the left and above the main one, but we don't know where it is within its monitor bounds.

Changing how child windows are positioned is a separate discussion. I have once proposed this but was told we prefer the way we do it now. Adding per-monitor information (all monitor sizes and position within the desktop) is complex because it would involve multiple platforms.

This patch simply returns GHOST_WindowWin32.cpp back to how it was before I started mucking about.

Revert of commits that allowed non-temp Blender windows to be saved and restored that spanned multiple monitors on the Windows platform. This causes problems with temp windows (like Preferences & Render) that cannot currently be fixed. --- The first complication is the way that we position temporary Blender windows. We attempt to **center** them around the mouse position at the time they are created. For Preferences for example, this means we are wanting it to the left of the main window. Since by default the main window is taking up the entire monitor, the default position of Preferences is left of the monitor edge. We *were* relying on Ghost to sanitize the size and positions of these windows, so this behavior had no real consequence. But I was *attempting* to allow a user to create windows that spanned monitors and these windows are currently designed to do exactly that. It isn't an option to just move or alter them because that is behavior I am trying to allow. If you want a window spanning monitors that should be fine. But we don't actually want that for these. The obvious approach is to instead sanitize these window positions and sizes at the call site. That way we can deal with temp windows specially. But we currently cannot get a behavior that is similar to the mouse-centered positioning. This is because we cannot consistently determine the distance between a Blender window and its containing monitor edge. We don't always know where it is in relation to the monitor. The above might sound incorrect. In a simple setup with a blender window on the main monitor, we do know all this because we have that monitor's dimensions and the window's size and offset position. However, when a blender window is on any other monitor we don't have enough information because we don't have other monitor dimensions or positions. We do have desktop dimensions but we are missing per-monitor rects so to know where that monitor is placed within it. Otherwise we might know that the main monitor is 1920x1080 and that our blender window is 1000x500 with its bottom corner at -1500, 3000. We can guess that it is on a monitor to the left and above the main one, but we don't know where it is within its monitor bounds. Changing how child windows are positioned is a separate discussion. I have once proposed this but was told we prefer the way we do it now. Adding per-monitor information (all monitor sizes and position within the desktop) is complex because it would involve multiple platforms. This patch simply returns `GHOST_WindowWin32.cpp` back to how it was before I started mucking about.

Harley Acheson added 1 commit 2023-02-19 19:12:40 +01:00

aac47d25bc Revert 104438: Windows Spanning Multiple Monitors

Revert of commits that allowed non-temp Blender windows to be saved
and restored that spanned multiple monitors on the Windows platform.
This causes problems with temp windows (like Preferences & Render) that
cannot currently be fixed.

Ray molenkamp approved these changes 2023-02-19 19:23:11 +01:00

Harley Acheson merged commit e1e2dae317 into main

2023-02-19 19:28:18 +01:00

Harley Acheson deleted branch Revert104438

2023-02-19 19:28:18 +01:00

Harley Acheson referenced this issue from a commit

2023-02-19 19:28:19 +01:00

Revert 104438: Windows Spanning Multiple Monitors

Jeroen Bakker referenced this issue from a commit

2023-02-20 15:49:08 +01:00

Revert 104438: Windows Spanning Multiple Monitors

Harley Acheson referenced this issue from a commit