Post AxzIij2gU2DgoSa12W by lhp@mastodon.social
 (DIR) More posts by lhp@mastodon.social
 (DIR) Post #AxzIihWO8cnA60Si3s by matt@toot.cafe
       2025-09-07T23:59:23Z
       
       0 likes, 0 repeats
       
       For anyone who thinks Wayland compositors are being overly restrictive by not allowing applications to set absolute positions for their windows, as I did, there are good reasons for this restriction. https://canonical-mir.readthedocs-hosted.com/stable/explanation/window-positions-under-wayland/
       
 (DIR) Post #AxzIij2gU2DgoSa12W by lhp@mastodon.social
       2025-09-08T02:28:02Z
       
       0 likes, 0 repeats
       
       @matt I myself am immediately suspicious of anyone who has an issue with this. It's just a lot of application developers who for whatever reason think they know better than the desktop where windows should be positioned, which is so weird. Like, stay in your lane? Just leave window management to the desktop?
       
 (DIR) Post #AxzIik82Rc64BM5o1Y by BrodieOnLinux@mstdn.social
       2025-09-08T06:23:50Z
       
       0 likes, 0 repeats
       
       @lhp @matt It is there lane as on Windows, MacOS and X11 application developers are able to control the window placement. If that were never the case then this wouldn't be discussion anyone is having. The concern with the current state of Wayland is this use case has been put to the side leaving these devs with no options to natively support Wayland even if they want to.
       
 (DIR) Post #AxzIilU3PFIkNvOtyi by matt@toot.cafe
       2025-09-08T00:02:25Z
       
       0 likes, 0 repeats
       
       Yes, this is a problem for some applications. But such applications can still run under Xwayland, and that will likely remain the case for a long time. So I think the Wayland community's approach of carefully, deliberately addressing specific use cases through protocol extensions is correct, though it's annoying to application developers in the short term.