You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setup: I have a Macbook Pro hooked up to an external monitor as below. The Macbook is set to "more space" which means it's a 3600x2388 monitor scaled to 1800x1169. Next to it is an external monitor running at 3440x1440.
The laptop screen works fine in isolation: monitor.size() returns PhysicalSize { width: 3600, height: 2338 } and monitor.position() returns PhysicalPosition { x: 0, y: 0 }. Windows inside the monitor report a physical position with x between 0 and 3600. So far so good. It's just using totally unscaled numbers.
But the second monitor reports its position as PhysicalPosition { x: 1800, y: -271 }. This implies it's using the scaled size of the laptop screen to compute the external monitor's offset in physical space:
1800 is the scaled width of the laptop screen, so 1800 is the starting x value the secondary monitor to its right
because the scaled height of the laptop screen is 1169, the secondary monitor is 271 pixels taller and thus starts at -271
So it's being inconsistent: widths unscaled, offsets scaled.
What makes this problematic is that windows inside the second monitor report their physical positions in ways consistent with the second monitor. So a window there has a physical x position of between 1800 and 5200 (1800 + 3440 = 5200). This makes the total physical space inconsistent, such that:
there are multiple window positions that report the same physical position (e.g. x=2000 corresponds to a position on both monitors)
dragging the window from left to right so that it crosses into the second monitor will cause the physical position to rise until it his the edge of the monitor, then drop sharply down (from 3599 to 1800)
calling set_position() on its current physical position can switch which monitor it's on:
match event {
tauri::WindowEvent::Moved(tauri_pos) => {// physical position of moved window on second monitorprintln!("{:?}", tauri_pos);// => PhysicalPosition { x: 1947, y: -12 }// now move it to the position it thinks it's already at// moves it back onto the first monitor!
window.set_position(tauri_pos);
In practice, where this came up for me is that I save the positions and current monitor of windows so that when the user reopens the application, the windows reopen in the right places. I check that the saved positions lie within the bounding box of the stored monitor name and then set_position the tauri windows into place. But it often puts them on the wrong monitor. This is because the stored physical position is actually ambiguous, since I recorded it from the position on the secondary monitor but it's equally valid on the laptop monitor and that's where Tauri puts it.
Reproduction
No response
Expected behavior
I think monitors and windows need to be completely consistent about whether physical position corresponds to scaled or unscaled sizes and positions. (I suspect they should mean scaled sizes always, but that may have consequences I don't understand; the more important point is to be consistent.)
Describe the bug
Setup: I have a Macbook Pro hooked up to an external monitor as below. The Macbook is set to "more space" which means it's a 3600x2388 monitor scaled to 1800x1169. Next to it is an external monitor running at 3440x1440.
The laptop screen works fine in isolation:
monitor.size()
returnsPhysicalSize { width: 3600, height: 2338 }
andmonitor.position()
returnsPhysicalPosition { x: 0, y: 0 }
. Windows inside the monitor report a physical position with x between 0 and 3600. So far so good. It's just using totally unscaled numbers.But the second monitor reports its position as
PhysicalPosition { x: 1800, y: -271 }
. This implies it's using the scaled size of the laptop screen to compute the external monitor's offset in physical space:So it's being inconsistent: widths unscaled, offsets scaled.
What makes this problematic is that windows inside the second monitor report their physical positions in ways consistent with the second monitor. So a window there has a physical x position of between 1800 and 5200 (1800 + 3440 = 5200). This makes the total physical space inconsistent, such that:
set_position()
on its current physical position can switch which monitor it's on:In practice, where this came up for me is that I save the positions and current monitor of windows so that when the user reopens the application, the windows reopen in the right places. I check that the saved positions lie within the bounding box of the stored monitor name and then
set_position
the tauri windows into place. But it often puts them on the wrong monitor. This is because the stored physical position is actually ambiguous, since I recorded it from the position on the secondary monitor but it's equally valid on the laptop monitor and that's where Tauri puts it.Reproduction
No response
Expected behavior
I think monitors and windows need to be completely consistent about whether physical position corresponds to scaled or unscaled sizes and positions. (I suspect they should mean scaled sizes always, but that may have consequences I don't understand; the more important point is to be consistent.)
Platform and versions
Stack trace
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: