Window resizing changed #81
Conversation
…ize, and adjust the window position after resizing to preserve the center.
|
I got around to booting up an Ubuntu VM and while I think mkxp-z was using X11 instead of Wayland, Ubuntu caps the window size to the size of the usable display area and doesn't let the top move above it, so this shouldn't introduce any bugs there. |
|
+1 on concept, I was getting kind of annoyed when the window got larger than my resolution. What's the behavior of this PR on systems with multiple monitors? |
|
SDL_GetWindowDisplayIndex will return the monitor the center of the window is on, so it'll use those dimensions. |
No objection to this being the default. Can we accommodate users who want the mkxp-z window to span multiple monitors? E.g. by having a config option that makes it use the combined desktop space (i.e. the space of all monitors combined) instead of a single monitor? |
| double maxWidth = displayRect.w; | ||
| double maxHeight = displayRect.h - top; |
There was a problem hiding this comment.
Why are you only using top rather than all four outputs of SDL_GetWindowBordersSize?
I thought about this some more, and I'm not going to block this PR on that, as I now think this is better-handled by the OS rather than the application. I'm still confused by the |
I decided to implement #65 and got a little carried away. In addition to allowing Graphics.scale to go beyond 4x, now all resize methods are capped to the display size and attempt to keep the center of the window's position on the screen without the top leaving the screen. I also fixed a little wonkiness with Graphics.center on Windows resulting from the title bar not being included in the height calculations.
I tested this on macOS and Windows, but not Linux.
Fixes #65