https://bugs.kde.org/show_bug.cgi?id=489983
--- Comment #5 from Frank Praznik <frank.praz...@gmail.com> --- (In reply to Zamundaaa from comment #3) > > The window size sent in the configure event for floating windows is just a > > hint, so I don't think that SDL is in the wrong here by ignoring it in > > favor of what it knows to be correct > It's not just a hint. It's a maximum to allow resizing to a specific aspect > ratio, but it is not meant to allow clients to decide an arbitrary size. If > the client is supposed to pick a size, the compositor will send a configure > event with size 0. > In practice, doing this on the client side will break our placement tracker > restoring window state after display hotplug events. > 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" 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. 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. > > which it has historically had to do since some older compositors would send > > incorrectly resize the window when transitioning from non-floating to > > floating states > Is that causing practical issues, or is it just making the size wrong? If > it's the latter, please just drop that workaround. If the compositor is > doing things that users don't like, it's up to the compositor to stop doing > that. 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. 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. -- You are receiving this mail because: You are watching all bug changes.
