https://bugs.kde.org/show_bug.cgi?id=489983
--- Comment #6 from Zamundaaa <xaver.h...@gmail.com> --- > The spec only states that the width/height are a maximum if the window is > fullscreen or being interactively resized, and must be precisely obeyed in > the maximized state. Otherwise, it says "The width and height arguments > specify a hint to the window about how its surface should be resized in > window geometry coordinates" Technically that's correct, but that's not the intention of the spec. It's just left out because some toolkits won't resize down below their minimum size, and that shouldn't cause protocol errors. > Nothing in the spec states that the size must be considered a maximum in the > floating state, and even if it was, a client sending a smaller size, as in > this case, shouldn't be an issue. It's not a protocol error, but it is very much an issue. > There is always the option to not ack the configure event if the requested > floating size is not precisely obeyed, but that results in the window not > being placed back where it was when leaving the maximized state. No, unless the requested size is 0, you should simply resize to the requested size, with no exceptions. > If I remember correctly, the workaround was originally introduced years ago > due to Mutter shrinking the floating window when leaving fullscreen. That > seems to be fixed in 46.2, but I'll have to check on the versions in LTS > distros. But yes, it was solving a practical problem. The SDL automated tests > also check that the proper size is restored upon leaving a fixed-size state > such as maximized or fullscreen. That autotest is testing for Mutter's behavior then, and not SDL itself. You can fix that by starting the window maximized, and only then un-maximizing it; in that case the compositor doesn't know the un-maximized size and will request a size of zero / that SDL should choose. > Even if SDL always obeys and passes through the size it receives, the client > app/game can arbitrarily resize itself at any point, and if it does so > between the initial restored configure event and the correction, the current > behavior will cause the window to shrink and overwrite the client requested > size. The compositor resizing the window is not a bug, it's intentional. KWin keeps a record of what sizes windows should go to in various window and display states, and the application should never attempt to overwrite that. -- You are receiving this mail because: You are watching all bug changes.
