still having this issue, and this keeps me using Chrome + XWayland as I have many windows in 3 virtual desktops
With the death of Win10, I was so certain that I would be moving to linux, but my flow for my browser consists of “workspaces”, at any given time I may have like 10 firefox windows open, so on a reboot having to sort through them all to my 3rd monitor is an absolute no-go.
I thought for a moment I should just rethink my flow, but no, this honestly is a core feature that just needs to work for linux desktop to be feasible. I saw a bug report from 25 years ago, literally dated 2000. Pls Fix 
Before demanding this or that to get fixed, I can recommend the read of this blog post, explaining the inner-working of the KDE community:
Where bugfixes and new features come from – Adventures in Linux and KDE
2 Likes
It was an informative read, I was under the misconception of there was dedicated developers, however I see how that reads as a ‘demand’ but as someone who gives my time as a hobby to support things, I know very well you don’t owe me anything.
I was however generally frustrated that such a core feature was left out from waylands side (maybe intentionally?), but also as far as I can tell, no WM has this feature implemented with wayland.
As stated: remembering Window geometry, position on desktop, as well as position on a given monitor is functionality that’s been present since Windows 98 and is essentially basic functionality that should have been implemented when Wayland was first conceived as a protocol. Even X11 supports such functionality better than Wayland.
The problem with Wayland is the fact that from the onset devs essentially went full reverse and ended up with nothing more than a basic protocol that was too stripped out, lacking basic functionality like that mentioned above. What makes things even more frustrating is that basic functionality is ignored in favor of things like VRR and HDR - Ideally, basic functionality that’s been part of every other OS for decades now should have been implemented before VRR and HDR under Wayland.
Essentially, remembering Window geometry, position on the desktop, and position on a given monitor (not to mention virtual desktop) should never have been in the red box from the onset, as it’s essentially fundamental desktop functionality.
3 Likes
I have several Firefox profiles (one for each activity) and each has between 5 and 10 windows, in totally easily 20-30.
On each activity they are spread across 6 virtual desktops and three monitors.
Since Firefox doesn’t really know about the activity concept I restore each profile manually on the correct activity and let Firefox place its windows on virtual desktops and screen.
It sometimes fails for one or two windows but I can live with that.
Haven’t had time to yet to test this on Wayland but since it works on X11 I don’t have any immediate need.
It wasn’t “left out” just took longer to agree on a good mechanism.
Part of the advantages of getting a new display stack is having the time to rethink how things are implemented.
The approach taken by the Wayland window session restore protocol allows desktop environments (or rather their compositor) to save window state information that only they know about, e.g. in case of KWin the information about Plasma activities.
Mutter and KWin have an implementation of the latest protocol draft, expected to be close to the final form unless testing reveals some unexpected issue.
Since it is not the final form yet both compositors (and probably others) do not enable it by default but have either settings or environment variables to opt-in for testing purposes.
Various toolkits like GTK/Qt/SDL and “app environments” like Chromium have similar toggles to enable the client side of the draft support to gain some real world data on how it works in practice.
Other major applications with their own client stack, e.g. Firefox, might also have siimilar capability already.
That would have needlessly delayed the uptake in non-desktop usage scenarios.
I.e. a lot of the Wayland extension protocols are only needed for the desktop use case and would be hard or even impossible to support in others.
Many of those things are being developed in parallel but only few people follow the process closely enough to see the individual progress. This leads to a distorted view of the timeline, e.g. features appearing to have been tackled earlier when in fact work on them started later.
Counterintuitively, some features that appear to (or even are) difficult ti implement are really easy to specify at the protocol level, while things that appear to be (or might even be) trivial to implement are often very hard to get right at the protocol level.
While I don’t know the individual timelines of VRR, HDR or window session restore I would not be surprised if the latter has been under development for much longer than the other two and requires a lot more “talking” between apps and compositor than the other two.
Again the question is what would have been gained by artificial sequencing for a specific desktop-centric use case.
Once the protocol for VRR or HDR had been agreed and draft implementation moved to the final version, what could possibly have been the benefit of not releasing these capabilities until the window session restore could be completed?
When features are closely related to one another it can make sense to release them together, however features that are very orthogonal like HDR window content and window positioning can easily be released in the order in which they become available.
1 Like
My needs are a bit more immediate, at least until I found out microsoft extended 10 support for ‘free’, my experience with wayland has been terrible, but KDE 6 is so good otherwise. First I really needed wayland for waydroid and I was on Nvidia at the time, so I said screw it and switched teams just for linux. Now I’m running into a brick wall with this issue so, it hurts.
That’s great news. I’ll probably see if I can find these envvars to see if I can get it working. My choices were between mint and cachyos, and I didn’t like how buggy cinnamon was for me, and while plasma was lacking that feature, the stuff it did do was very smooth and mostly pain free.
Thanks for all the explanation you’ve given, I’m a little more optimistic now. I really want linux desktop to be viable enough to recommend.
It is possible to run most Wayland compositors (e.g. kwin_wayland) as an X11 client.
E.g. runnnin kwin_wayland konsole on an X11 session will run Konsole inside a KWin Wayland window.
2 Likes
I just found this KDE Script that adds this functionality, which might be useful to others finding this thread in the future: “RememberWindowPositions“ by rxappdev on Github. (I’m not allowed to use links here yet)
1 Like
Interesting
3 Likes