On Tue Apr 29 13:07:09 2025 +0000, Alexandros Frantzis wrote:
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.
- 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).
Those do seem like legitimate issues.
However, as it stands, some parts of some windows are simply inaccessible. Has any progress been made on not clipping input?