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?
1 Like
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.
2 Likes
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.
3 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!
7 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
no offense, i honestly cannot comprehend what’s so difficult about it.
obviously kwin is already able to read the current position and size of windows. (as it can read these properties e.g. by clicking settings → window management → window rules → detect properties).
also kwin can obviously apply a certain position and size to a window (as it can apply said window rules).
imho the only steps missing are:
- an automated detection of the properties of the window at the time it was closed
- a file to store these properties
- an automated application of these properties when the window is opened again
so basically a window rule that automatically detects and updates window properties at the time of closing a window.
3 Likes
I think folks taking that approach would be well-served to take a bit of a dive into the code of a window manager like KWin: Plasma / KWin · GitLab
…and at the work involved in creating a standard protocol across FOSS desktops: staging: Add xdg-session-management protocol (!18) · Merge requests · wayland / wayland-protocols · GitLab
…and then evaluate the ease of implementation. Not trying to be snarky, but it’s a pretty common human experience that when the desired output of a process seems close to what you can see now, we all tend to assume that it’s a negligible amount of work to get it “the rest of the way”. I haven’t been a KDE developer or on this scale of software project, but my experience trying to pull off and trying to manage other projects told me that the first 50% of anything was usually quick and easy - the next 40% was a lot of work, and the last 10% was where folks often tore their hair out trying to get it to work 
In this situation, the folks who really, really need this stuff to work in a specific way are also likely the folks who will have use cases that depend on that 10% working really, really well. I do believe it will eventually happen!
I understand that some problems are harder than they look at first glance, but it’s been over 25 years and Wayland still can’t save window positions. I can’t believe that every dev is happy having to manually position their windows every boot and have probably worked around it with custom hacky workarounds but that is not a great solution for the project as a whole.
Forgive my frustration but this is the only thing that has been really annoying making the daily driver switch from Windows. I guess I’ll go and write a hacky workaround since I know my capabilities and time availability are not up to solving this in Wayland proper.
2 Likes
Maybe, one day, the Wayland Gods will bless us with the ability to remember where windows were last. One can dream.
The current version of the related protocol has been implemented on the compositor side in both KWin and Mutter.
Chrome has a client side implementation, as does Qt as does GTK
Some of these implementations might be guarded by a config switch or similar since the protocol is not fully “released” yet
Not expected to change though unless testing between those implementations unearths any issues
Hello,
My grain of salt.
I have two experiences with window positioning in X11.
In a computer with KUbuntu 25.04 and KDE 6.3.6, I use two monitors that I never unplug. There, the windows positioning remembering is working “perfectly”. Even when I use the Windows Rules to force a window on a specific worspace. It works.
But, on another computer with KUbuntu 25.04, with KDE 6.3.6, the windows positioning is not functional when I change my monitors configuration.
Typically :
I have only one monitor, and I use the Windows Rules to force a window on a specific worskpace. The monitor is the primary monitor.
Then I plug (or I enable with xrand) my second monitor => the first monitor is the primary.
The second monitor is put left of the primary one.
But then the window appears in the good worskpace but in the wrong monitor. x_X
NOTE : in the Windows Rules parameters, the parameter for “Position” seems to use pixels but without taking the screens into account.
Therefore, I think I’m on the 10% use-case that johnandmegh speaks of, and I can sense the difficulty of this problem (it must work for : one screen, multiple screens, multiple screens but sometimes not all used, etc), so I really hope the big brains that work on the ways to solve it take all the time they need to iron a solution that allows a maximum of users to do what they want with their windows positioning.
What I find curious is some apps know how to keep their position. VLC, Blender and Wine for example. Chrome does not. Firefox does not. Kodi should, but it is borked even in X11. In X11, the settings say “remember apps position for apps that support it”, but it seems everything, with the notable exception of Veracrypt, seemed to support it, which is rather dubious. I do acknowledge that it even took X11 a very long time to get that right (basically around 2019 it started to be a seamless experience).
Still doesn’t work 100% reliably for me and none of the apps support restoring the correct activity
1 Like
If this is “10% use-case” my case is probably 0.1% use case. I better give up my hopes for now. =/ As I described elsewhere, positioning and size works fine on two monitors, but become a really bad mess on three monitors. And it is even worse, since it is a multi window application I cannot just use window rule parameters to set the position and size, because it only affects the main window. All the other minor issues I can tolerate, but this crashes the otherwise overall good experience so far.