Created attachment 109042 [details] video (video attached for illustration; also full disclosure: I have no clue if kwin is actually at fault here, may be kscreen for all I know) kwin has the handy tiling feature that when dragging a window to a side of the screen you can snap it into a reasonable place depending on where you drag it. by default we snap all-left, all-right and four corners. which is lovely under the assumption that a screen has more width than height. when rotating a 16:9 secondary screen 90 degrees (using kscreen; on x11) this becomes awkwardly unsuitable though. when rotated the most space efficient usage would be all-top, all-bottom and four corners as the screen is now much high than wide. more generally put: the midline fold should always be on the longest axis of the screen, currently it is always on the X axis which is wrong when the screen is rotated as you'd then snap a super tall, albeit way too narrow window. I am also going to add a quick drawing to show what I think this should look like.
Created attachment 109043 [details] picture
I don't think we have sufficient information for that.
I was assuming you'd at least know the (rotated) screen resolution. The way I see it you would need to `if maxX>=maxY then splitHorizontal else splitVertical` and the split would always yield smart space usage. The fact that the screen is rotated doesn't really matter in the end, you only need to know the "aspect orientation", for lack of a better word, and that can easily be checked through the resolution.
If you are interested, you could try to implement yourself. We have a complete test coverage for quick tiling in autotest/integration/test_quick_tiling.cpp and implementation should be in geometry.cpp
The pertinent logic actually seems to live in `AbstractClient::checkQuickTilingMaximizationZones`. I do have some code which implements the alternate logic but it is fairly spaghetti. I'll have to think about it a bit more. I also found the existing code rather meh to read because of the manual border checking, so I was thinking about QRecting the entire thing until I realized that the current method operates on the maximized size of the client (i.e. excluding the panel) which made qrect rather unusable unless one extends them well beyond the maximized area coordinates so as to cover potential panels on each side. All fairly meh.