Before this fix, Win32API is used to get the current monitor. This
might not work and return an unexpected monitor on some machines after
the runloop starts.
Instead, use the current window to get the current monitor correctly
instead of the Win32APIs. To get the initial monitor, the API
ForegroundWindow is still used.
Updates #1584
Updates #1844
This is a breaking change. On macOS, `SetFullscreen` creates a new
independent space and maximize the size of the window there.
Updates #1506Closes#1579
IsWindowBeingClosed reports whether the window is being closed by
the user.
SetWindowClosingHandled sets whether the window closing is handled
or not. If the state is true, the window is not closed immediately
by the user and the game can handle the closing state. In this case,
the Update function should return an error in order to end the game.
This change also adds examples/windowclosing.
Closes#1574
At least on macOS, Maximize invokes the SetSize callback in the game's
Update. This change fixes this issue by unregisting the callback
temporarily like what #1505 did.
Closes#1576
Especially in the initial phase before calling Run/RunGame, the
window position is not reliable and then getting the device scale
factor does not make sense based on the window position. Avoid
using the window position, and instead use the glfw.Monitor in
this situation.
On Windows, the window could be maximized even when the window was
not resizable. This behavior is confusing. Forbid it so that the
behavior will be clearer.
This change changes the behavior of WindowPosition /
SetWindowPosition. The window position is now a relative position
and the origin position is the left-upper of the current monitor.
Fixes#1115
