On Tue Apr 29 12:01:05 2025 +0000, Julian Orth wrote:
The reasons for this are discussed in the thread at
https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581 (TL;DR is that doing this would fix some cases but break other cases). I had seen that but I don't think there were any actual examples showing anything being broken with this approach.
Below are a couple problems I have seen myself (and probably others I am forgetting about). The earlier experimental branch, which also use the "move windows to origin" approach, tried to use some special casing and workarounds for such issues, but the final complexity (and fragility) made the whole effort less enticing compared to some of the other simpler ideas mentioned above.
1. Multi-monitor scenarios are problematic with a simple move to (0,0), especially when combined with fullscreen (since fullscreen is a "state" inferred from window position and size on win32). The (0,0) positioning in the original MR was supposed to be just the first step, since we didn't support multiple monitors then. The experimental branch was tracking which output each surface was on (with enter/leave events), but this turned out to be complex/fragile in terms of syncing etc
2. Applications that are very strong-minded about where they want their windows to be placed, and react with another reposition/resize when we try to position them. A particular problematic case I have seen is in fullscreen or maximized scenarios, with some apps/games insisting that they are sized just a little bit bigger than the target monitor and centering themselves accordingly (so not anchored at monitor origin).