Stupid question probably, but why don’t kde save window positions in wayland? Surely an issue that must’ve popped up a thousand times before but I get conflicting arguments when I google it.
I can close a window and open it in the same session and it appears in the middle of the screen though I would rather like it where I left it in the top right. I’m no proper developer but it seems like a kde issue rather than a wayland issue?
It has indeed popped up a thousand times before. See 15329 – Save and remember positions of all windows.
KWin will eventually gain the feature, but it hasn’t happened yet.
1 Like
With X11 apps typically do it themselves - save window geometry in their settings and restore it on startup. This also works on other platforms like Windows and macOS, making it a cross-platform solution… Until Wayland came along. With Wayland apps aren’t allowed to position themselves on screen (again, unlike with all other major desktop windowing systems on Linux or other platforms) and this approach doesn’t work. This is something that needs to be implemented in each Wayland compositor directly, and AFAIK doesn’t exist yet.
2 Likes
There are valid reasons for the Wayland approach. What you may be forgetting is that on X11, only some apps remember their own positions. Many don’t do it at all; it’s a per-window opt-in thing. Until I implemented this feature for KXMLGui, almost no KDE apps did. And even now, all non-KDE apps that implement this feature have to do it themselves, because no cross-toolkit library exists for window positioning. Generally this is fine as long as you have a single screen, but the moment you have two or more, it breaks down because the level of complexity increases dramatically and every app that implements the feature handles that complexity in a different way.
For example some store an absolute position relative to the total geometry, which breaks if you re-arrange your screens. Some try to remember which screen they were on by storing the screen used and the position on that screen, but this can break because there are many ways to identify screens and almost all of them are volatile. Some abuse the feature to always position themselves on the primary screen whether you want this or not. And so on. I learned how challenging of a task it is to get this right while writing and later tweaking the aforementioned KXMLGui feature in response to a great deal of user feedback.
The net result is that on X11 almost every window positions itself (or not) in subtly different ways that in practice can feel very random, even if you have a simple single-screen setup–and it’s much worse if you have a multi-screen setup. The Wayland approach allows for all of this to go away because the compositor applies one set of rules for how to handle positioning that all windows have to obey, which makes the positioning consistent and predictable. It also allows you to disable the behavior if you’d prefer for the compositor to always position all windows.
Of course that’s in principle what will be possible once the feature is implemented in KWin. I do understand that it’s frustrating to read about theoretical benefits when there’s no implementation yet!
6 Likes
Thank you for the exhaustive description of the problem. I realize that’s one thing that barely works on multi-monitor setups even on Windows, so I can appreciate the effort put into it.
I guess that’s one of the things preventing me from switching entirely, the other being the mouse buttons never work on first start 
But I really love what you’ve done with it. I switch sessions from time to time on my tumbleweed to check progress, and it feels fantastically smooth most of the time.
1 Like