Win32: Center windows within the work area, taking occlusions like the Task Bar into account #437
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On Windows, things like the Task Bar permanently reserve a part of the area within the bounds of a monitor. The Task Bar is "always on top", so if you try to force your window into some of its space, your window will simply be covered. The
Center
method inBaseFlutterWindow
in the Win32 back-end (base_flutter_window.cc
) computes the new bounds without taking this into account. For instance, if your task bar is occupying 40 pixels at the bottom of a 1920x1080 display, and you center a window that is 1,000 pixels tall, it will be placed so that there is 460 pixels above the window and 460 pixels below it -- but 40 out of those 460 below it are actually occupied by the Task Bar. If the window is 1040 pixels tall, then theCenter
function will place it so that there are 40 pixels above it, but the bottom edge is touching the Task Bar. If the window is more than 1040 pixels tall, then some of it will be hidden behind the Task Bar.The problem gets worse if the task bar is resized and uses more space (if it is docked to the left or right, it uses considerably more space).
This PR solves the problem. It's a quick one-liner. When you call
GetMonitorInfo
to get information about a monitor's placement in the virtual desktop space, oneRECT
calledrcMonitor
gives you the pixel coordinates of the raw boundaries of the monitor, but there's anotherRECT
calledrcWork
that gives you the "work area" -- the space left after the Task Bar and anything else docked to the edge have been taken into account. So, the calculation is changed to usercWork
instead ofrcMonitor
.