Already noted on https://community.kde.org/Plasma/Wayland_Showstoppers.

We can use this as the bug report to track it.

*** Bug 442192 has been marked as a duplicate of this bug. ***

*** Bug 442283 has been marked as a duplicate of this bug. ***

*** Bug 453849 has been marked as a duplicate of this bug. ***

*** Bug 455105 has been marked as a duplicate of this bug. ***

*** Bug 455900 has been marked as a duplicate of this bug. ***

So something like this will eventually be able to help it? https://www.youtube.com/watch?v=fRdnRwPBFBk

(In reply to Nate Graham from comment #19)
> In general, Plasma has enough testers and QA people. What it lacks is enough
> developers to fix all the issues those people find.

Or the devs you already have are interested only in next shiny thing than to fix bugs in their code...:-) Sure, we can't force devs to stick around forever and fix bugs in their code but sometimes, its good to stop new development and just fix the bugs. You will have more adoption and participation, and that can potentially get you more devs.

(In reply to devsk from comment #20)
> Or the devs you already have are interested only in next shiny thing than to
> fix bugs in their code...:-) Sure, we can't force devs to stick around
> forever and fix bugs in their code but sometimes, its good to stop new
> development and just fix the bugs. You will have more adoption and
> participation, and that can potentially get you more devs.

As a user, I also wish session restore to worked on Wayland, but inflammatory comments won't help expedite it.

I would like to know what's making this difficult. X11 had a session management protocol; does Wayland define something equivalent? If not, could Plasma do something limited to KDE apps?

Where is the current session save/restore code? Any documentation we could link in this bug to support someone who wants to give a shot at it?

(In reply to Bernie Innocenti from comment #21)
> (In reply to devsk from comment #20)
> > Or the devs you already have are interested only in next shiny thing than to
> > fix bugs in their code...:-) Sure, we can't force devs to stick around
> > forever and fix bugs in their code but sometimes, its good to stop new
> > development and just fix the bugs. You will have more adoption and
> > participation, and that can potentially get you more devs.
> 
> As a user, I also wish session restore to worked on Wayland, but
> inflammatory comments won't help expedite it.

I swear inflammation was not the intention. But truth can be hard sometimes and it lands wrongly in written communications. My apologies if it sounded like that.

It is true that devs like to move onto newer things. I see it everyday at work. And good teams and leaders have to bring them back to the table. We have burnt sprints doing just bug fixes solely because of this. And it works! The overall quality of the code improves and customers are happier and they spread the good word!

*** Bug 460567 has been marked as a duplicate of this bug. ***

(In reply to ticonzero from comment #28)
> Hi all, 
> 
> same problem here does anyone know if the bug has been fixed?
> 
If it had been fixed, the status would have changed. 
With the "Importance" downgraded to "normal", I don't expect it to be fixed before Plasma 6.

(In reply to ticonzero from comment #35)

> Well I do like it, in fact I'm sticking with it, but I do miss being able
> to restore the old session, for me it means not having to reopen dozen of
> pdfs in different okular instances on different desktops

Same here. This bug is the only reason why I am not running Wayland. I usually have about a dozen PDF (okular) and over twenty text (kate) files open. It is too much work to open each of these files again every time I restart the computer.

(In reply to Francisco Cribari from comment #37)
> (In reply to ticonzero from comment #35)
> 
> > Well I do like it, in fact I'm sticking with it, but I do miss being able
> > to restore the old session, for me it means not having to reopen dozen of
> > pdfs in different okular instances on different desktops
> 
> Same here. This bug is the only reason why I am not running Wayland. I
> usually have about a dozen PDF (okular) and over twenty text (kate) files
> open. It is too much work to open each of these files again every time I
> restart the computer.

If your windows don't change too much you can find a workaround on my dup: https://bugs.kde.org/show_bug.cgi?id=455900

(In reply to Bernie Innocenti from comment #21)
> I would like to know what's making this difficult. X11 had a session
> management protocol; does Wayland define something equivalent? 

Let me loosely quote the wiki [1]
> Session restoring does not include Wayland native windows (...). 
> Our sessions management recover engine is based on the X Session Management Protocol
> and there is apparently currently no generic concept to do it on Wayland.
> But on Qt it's plugin-able and GNOME has had their own implementation for some time. [2]

Regarding opened discussions, there's an issue in the kwin repo, see "Goal 2: Session restore" [3]

[1] https://community.kde.org/Plasma/Wayland_Showstoppers
[2] https://wiki.gnome.org/Projects/SessionManagement/GnomeSession
[3] https://invent.kde.org/plasma/kwin/-/issues/113#note_500909

See also the MR linked in the issue above: "Draft: wayland: Add support for xdg-session-v1" [1]

[1] https://invent.kde.org/plasma/kwin/-/merge_requests/3024

Are there any reasonable workarounds? Say a script that reads all window positions, sizes, etc., and saves the information, and then another script that can read this info and open and arrange the windows?

For a while I used a script based on:

https://github.com/zepalmer/script-vdr

but it's for Python-2 and X11 and I haven't tried to bring it up to date. It's based around wmctrl, which AFAIK is not supported on Wayland, but there might be something useful there. Note that it's designed to save/restore the windows belonging to one process, e.g. your browser, not the full user session.

According to the plasma/wayland showstoppers page, session restore is a priority:
https://community.kde.org/Plasma/Wayland_Showstoppers

However, on the plasma 6 development page there is no mention of session restore:
https://community.kde.org/Plasma/Plasma_6

Does anyone know if session restore is supposed to be in plasma 6?

> Does anyone know if session restore is supposed to be in plasma 6?
The plan is to solve all Wayland Showstoppers - including session restore - until Plasma 6.0 is released [1]

[1] https://pointieststick.com/2023/09/06/september-plasma-6-update/#comment-37811

from my understanding the issue was downgraded to a non-showstopper anymore. At least this is shown now in the wiki page (https://community.kde.org/Plasma/Wayland_Showstoppers). I hope that Qt-pluginable option will still be provided on plasma 6. Is there  any update about when it will be integrated?

The plan right now is as follows:
- For Plasma 6.0, implement a sort of fake session restore that on login, simply re-opens apps that were open on last logout, and count on apps that have state worth saving doing the saving themselves (and many apps already do; for example Firefox, Discord, Dolphin, Kate, Kile, Elisa...).
- For a later Plasma 6 version, implement real session restore that's governed by a new Wayland protocol (one is in progress) and make KDE apps opt into it.
- After that, keep the fake session restore and use it for apps that don't opt into the real session restore.

This should ultimately produce a better UX than on X11, where many apps never opted into session restore and so it was semi-random as to which apps got launched on login.

For the fake session restore, I can't make any promises about that. I've talked to the fellow doing the work and he wants to take those into consideration, but it becomes more technically challenging, so the first version might not. But I do expect those to *eventually* work in the fake session restore.

(In reply to Nate Graham from comment #62)

> - For Plasma 6.0, implement a sort of fake session restore that on login,
> simply re-opens apps that were open on last logout, […]

Wow, that sounds great! I mean, real session restore would be a fantastic feature to have, but the “fake” option is already a great improvement to what we have at the moment (i.e. nothing).

I got already worried this was dropped entirely when I saw the change in the showstopper bug list. This is after all by far the biggest pain point I have with KDE Wayland.

(In reply to Nate Graham from comment #62)
> The plan right now is as follows:
> - For Plasma 6.0, implement a sort of fake session restore that on login,
> simply re-opens apps that were open on last logout, and count on apps that
> have state worth saving doing the saving themselves (and many apps already
> do; for example Firefox, Discord, Dolphin, Kate, Kile, Elisa...).

Aside from the virtual desktop issue already mentioned by several people, it's worth noting that Dolphin does not currently restore its state correctly even under X11. Briefly, if you have more than one Dolphin window, some with the Terminal open and some not, the restored Dolphin will have all windows showing the Terminal in the same state, either open or closed, apparently at random.

I reported this over a year ago (see https://bugs.kde.org/show_bug.cgi?id=455324) but never saw a reply.

Indeed, Dolphin lost a lot of its session features, like restoring at the original position.

For me, being an Nvidia user (didn't know the drawbacks at the time and Plasma looked to work good enough with x11 and Nvidia), has become more and more unlikely I would move to the next Plasma at all. This combination that makes any input unusable, the mouse pointer or the keyboard signals being sent to Plasma after 30 secs or so, but also lacking session, are unacceptable. I understand some features are  ~ maybe ~ difficult to implement, but basic features like these are a must. I can't expect from a user to rather change a laptop just because he would use a DE, sorry.

(In reply to Nate Graham from comment #62)
> The plan right now is as follows:
> - For Plasma 6.0, implement a sort of fake session restore that on login,
> simply re-opens apps that were open on last logout, and count on apps that
> have state worth saving doing the saving themselves (and many apps already
> do; for example Firefox, Discord, Dolphin, Kate, Kile, Elisa...).
> - For a later Plasma 6 version, implement real session restore that's
> governed by a new Wayland protocol (one is in progress) and make KDE apps
> opt into it.
> - After that, keep the fake session restore and use it for apps that don't
> opt into the real session restore.
> 
> This should ultimately produce a better UX than on X11, where many apps
> never opted into session restore and so it was semi-random as to which apps
> got launched on login.

Does Konsole save session (the windows and tabs and the current directory of each tab) by itself? My experience is that it does not, but given that things like Kate does, why can't Konsole, which is also a KDE app, do that? Am I missing something?

(In reply to Bruno Friedmann from comment #71)
> > Does Konsole save session (the windows and tabs and the current directory of each tab) by itself? My experience is that it does not, but given that things like Kate does, why can't Konsole, which is also a KDE app, do that?
> > Am I missing something?
> 
> Yes my experience proove it, I usually have 10 tabs opened in konsole, most
> of them are dedicated to a relative work, and as such the directory in which
> the last session was run, and is restored on the right desktop.
> That IS the most reason I don't use (yet) Wayland.

One workaround for Konsole exists on Stack-Exchange: https://unix.stackexchange.com/a/593779 It also works on Wayland. However, I believe this should be possible with built-in functionality.

I have made two scripts (heavily modified from scripts that I found somewhere else) to help session restore semi-automatically:

https://github.com/Kelvin-Ng/konsole-session-restore:
This script saves and reopens the Konsole windows with original tabs and directories.

https://github.com/Kelvin-Ng/kde-window-status-restore:
This script saves and restores the statuses of the windows, currently only activity and desktop. Note that it does not reopen the windows. The windows will have to be first reopened before running the restore script.

Hope these scripts are helpful.

(In reply to Nate Graham from comment #62)
> The plan right now is as follows:
> - For Plasma 6.0, implement a sort of fake session restore that on login,
> simply re-opens apps that were open on last logout, and count on apps that
> have state worth saving doing the saving themselves (and many apps already
> do; for example Firefox, Discord, Dolphin, Kate, Kile, Elisa...).
> - For a later Plasma 6 version, implement real session restore that's
> governed by a new Wayland protocol (one is in progress) and make KDE apps
> opt into it.
> - After that, keep the fake session restore and use it for apps that don't
> opt into the real session restore.
> 
> This should ultimately produce a better UX than on X11, where many apps
> never opted into session restore and so it was semi-random as to which apps
> got launched on login.

Alright, maybe my question was a bit too difficult to understand.  So I rephrase it a bit: will session restore in Plasma-6-X11 work _right from the start_ as it does in Plasma-5-X11 or not?  Some people don't give a damn about Wayland but do care about reliable and complete session restore.

(In reply to imaginator from comment #76)
> Alright, maybe my question was a bit too difficult to understand.  So I
> rephrase it a bit: will session restore in Plasma-6-X11 work _right from the
> start_ as it does in Plasma-5-X11 or not?  Some people don't give a damn
> about Wayland but do care about reliable and complete session restore.

On X11? No changes have been made to session restore on X11 there so I would expect so. However I can't personally guarantee no regressions, as I'm not personally using X11 anymore and therefore not testing for regressions there. Someone else will need to step in for that.

(In reply to Nate Graham from comment #78)
> (In reply to imaginator from comment #76)
> > Alright, maybe my question was a bit too difficult to understand.  So I
> > rephrase it a bit: will session restore in Plasma-6-X11 work _right from the
> > start_ as it does in Plasma-5-X11 or not?  Some people don't give a damn
> > about Wayland but do care about reliable and complete session restore.
> 
> On X11? No changes have been made to session restore on X11 there so I would
> expect so. However I can't personally guarantee no regressions, as I'm not
> personally using X11 anymore and therefore not testing for regressions
> there. Someone else will need to step in for that.

Thanks for clarifying this.

*** Bug 476831 has been marked as a duplicate of this bug. ***

*** Bug 481745 has been marked as a duplicate of this bug. ***

Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now.

*** Bug 479886 has been marked as a duplicate of this bug. ***

We've introduced a fallback. plasma-fallback-session-save which provides something.

It's not perfect. It just sees which apps were open and then reopens them. The application has no mechanism to save any state. 
There's definitely room for improvement, but that involves upstream and updating all  applications(!) which isn't worth us tracking in our bug tracker.

Git commit 804976c5ecec1fbf5f6e7e09970a8269bdf748d2 by David Edmundson.
Committed on 08/03/2024 at 09:17.
Pushed by davidedmundson into branch 'master'.

Migrate manual session saving to plasma-shutdown

This allows the wayland fallback session saving to run too and removes
more ksmserver logic from our library code.

session-restore is patched to also run when the configuration file is
set to restore the manually saved session.

M  +0    -3    libkworkspace/CMakeLists.txt
M  +2    -3    libkworkspace/sessionmanagement.cpp
M  +1    -0    startkde/plasma-shutdown/org.kde.Shutdown.xml
M  +24   -2    startkde/plasma-shutdown/shutdown.cpp
M  +1    -0    startkde/plasma-shutdown/shutdown.h
M  +1    -1    startkde/session-restore/restore.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/804976c5ecec1fbf5f6e7e09970a8269bdf748d2

> We've introduced a fallback. plasma-fallback-session-save which provides something.

Thanks!

> It's not perfect. It just sees which apps were open and then reopens them. The application has no mechanism to save any state. 

Let's take Konsole as an example.  Does this mean that Konsole will not save its current directory?

Correct. Because real session restore is not implemented on Wayland yet, at the moment this manual session restore hooks into the "real fake session restore" mechanism that will be used until we get real session restore.

(In reply to Nate Graham from comment #87)
> Correct. Because real session restore is not implemented on Wayland yet, at
> the moment this manual session restore hooks into the "real fake session
> restore" mechanism that will be used until we get real session restore.

Any idea on when real session-restore might be coming?

Once the proposed Wayland protocol gets approved and merged, support in Plasma will likely arrive quickly. I don't know if it's helpful to speculate as to when the protocol might get approved. It could be tomorrow and it could be in two years. Obviously we all would prefer the former over the latter. :)

(In reply to Nate Graham from comment #62)
> The plan right now is as follows:
> - For Plasma 6.0, implement a sort of fake session restore that on login,
> simply re-opens apps that were open on last logout, and count on apps that
> have state worth saving doing the saving themselves (and many apps already
> do; for example Firefox, Discord, Dolphin, Kate, Kile, Elisa...).
> - For a later Plasma 6 version, implement real session restore that's
> governed by a new Wayland protocol (one is in progress) and make KDE apps
> opt into it.
> - After that, keep the fake session restore and use it for apps that don't
> opt into the real session restore.
> 
> This should ultimately produce a better UX than on X11, where many apps
> never opted into session restore and so it was semi-random as to which apps
> got launched on login.

I've just installed Fedora 40 with Plasma 6 on Wayland. I'm sorry to say the "fake session restore" simply doesn't work. The only app that re-opens on login is (ironically) Firefox, which isn't even a Plasma app. Both Konsole and Dolphin fail to appear and have to be started manually every time.

Needless to say, this is a considerable inconvenience.

As you just quoted "The plan right now is as follows:" this was the plan back in 2023. If you look at the "Version Fixed in" on the top right, it says 6.1. You have to wait til June or so. :)

(In reply to postix from comment #95)
> As you just quoted "The plan right now is as follows:" this was the plan
> back in 2023. If you look at the "Version Fixed in" on the top right, it
> says 6.1. You have to wait til June or so. :)

In a post from January, Neil said he hoped to have this working for F40:

https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/PMAYGU3UJ6RXEOBGQJD6ZPKBLXEYLNJ2/

(you'll have to scroll down. The current list archive system doesn't seem to offer links to a specific message).

(In reply to Patrick O'Callaghan from comment #96)
> 
> (you'll have to scroll down. The current list archive system doesn't seem to
> offer links to a specific message).

Click on the link symbol in the upper right corner of the message.

https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/message/HP26SLPOXK264324MAJMVC24MDEMOXQ7/

(In reply to Bernd Steinhauser from comment #97)
> (In reply to Patrick O'Callaghan from comment #96)
> > 
> > (you'll have to scroll down. The current list archive system doesn't seem to
> > offer links to a specific message).
> 
> Click on the link symbol in the upper right corner of the message.
> 
> https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/
> message/HP26SLPOXK264324MAJMVC24MDEMOXQ7/

Thanks. The reference is:

https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/message/XSBZENY3VQCY57W3GXGCL7RMFZDANLTO/

The hack is definitely there. 
It follows the systemsettings -> desktop session -> session restore settings

It is set to "On last logout" here, but nothing gets launched on the next log in.

Same here using Gentoo.

Oh, I'm on Gentoo as well. Maybe it is our packaging that disables this feature? 

David, could you, please, point out the implementation location so I can try to figure out why it does not work?

The fake session restore is part of plasma 6.1 and not available in 6.0 as far as I can tell. However, as stated in the link in Comment 98, Fedora has backported the session restore to their plasma packages (version 6.0) for Fedora 40.

Hope this clears up that confusion.

Here the link to the commit for the Fedora 40 package: https://src.fedoraproject.org/rpms/plasma-workspace/c/d03958da910f3ba08c531e7569ff40c19ca2f045?branch=f40

(In reply to Armin from comment #109)
> Here the link to the commit for the Fedora 40 package:
> https://src.fedoraproject.org/rpms/plasma-workspace/c/
> d03958da910f3ba08c531e7569ff40c19ca2f045?branch=f40

Note that this is not yet available in the Fedora repos, so probably better to wait.

Regarding the actual session restore functionality, I have just switched to Fedora 40 and tested this a bit. So far, the fake session restore was not useful at all since it only launches the applications, but those apparently are not capable of remembering their previous state.

For instance, I rebooted my machine with 1 Kate, 2 Okular and 2 Konsole instances open, and while Kate, 2 Okular and 2 Konsole windows opened after the restart, none of those opened the previously open document or changed to the directory they previously were at. Back in X11, the session restore would not only reopen the applications, but also restore the actual documents (e.g. reopen the PDF file in Okular, change to the directory in Konsole, or restore a session in Kate).

As such, the current session restore doesn't add any value, since I need to manually open the documents/session anyway myself.

(In reply to Patrick O'Callaghan from comment #110)
> (In reply to Armin from comment #109)
> > Here the link to the commit for the Fedora 40 package:
> > https://src.fedoraproject.org/rpms/plasma-workspace/c/
> > d03958da910f3ba08c531e7569ff40c19ca2f045?branch=f40
> 
> Note that this is not yet available in the Fedora repos, so probably better
> to wait.

Ok, what makes you think it is not? As far as I can tell, the F40 spec file contains the patch: https://src.fedoraproject.org/rpms/plasma-workspace/blob/f40/f/plasma-workspace.spec#_33

(In reply to Armin from comment #112)
> (In reply to Patrick O'Callaghan from comment #110)
> > (In reply to Armin from comment #109)
> > > Here the link to the commit for the Fedora 40 package:
> > > https://src.fedoraproject.org/rpms/plasma-workspace/c/
> > > d03958da910f3ba08c531e7569ff40c19ca2f045?branch=f40
> > 
> > Note that this is not yet available in the Fedora repos, so probably better
> > to wait.
> 
> Ok, what makes you think it is not? As far as I can tell, the F40 spec file
> contains the patch:
> https://src.fedoraproject.org/rpms/plasma-workspace/blob/f40/f/plasma-
> workspace.spec#_33

Because of:

https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/message/HP26SLPOXK264324MAJMVC24MDEMOXQ7/

which mentions 6.1 "due out in June". I know we're in June now, but 6.1 is not out yet, at least in stable Fedora repos.

Updated Arch with Plasma 6.1, rebooted, didn't work. Then, switched setting to: "When session was manually saved" and rebooted. Don't remember seeing a button to "Save Session" but it worked same as setting: "On last logout". Switched back to "On last logout" and it is still working. Very pleased! Thanks to everyone who put in the hard work to make this happen for Plasma 6.

(In reply to Patrick O'Callaghan from comment #120)
> Just a heads-up to note that Plasma 6.1 is now available. I have installed
> it on Fedora 40 (via the normal dnf upgrade system) and look forward to
> testing it.

Here's my experience after brief testing:

* Apps are restored, including non-KDE ones such as Firefox and Evolution, but Yakuake does not restore.

* They all appear on the first desktop and have to be manually repositioned. Window sizes are correct but window positioning within the desktop is arbitrary.

* AFAIK each app is responsible for its own internal state. Konsole does not preserve tabs. Dolphin does not preserve terminal open/closed state independently for each window (though all windows are present) and instead of 3 windows in different directories they are all copies of each other (probably a Dolphin problem).

* Shortcut for normal interactive logout doesn't work consistently, not does the Logout menu selection. The shortcut for immediate logout (Shift-Ctrl-Alt-Del) does work.

Login/logout is very fast compared to 6.0 on Wayland.

(In reply to undoIT from comment #121)
> Updated Arch with Plasma 6.1, rebooted, didn't work. Then, switched setting
> to: "When session was manually saved" and rebooted. Don't remember seeing a
> button to "Save Session" but it worked same as setting: "On last logout".
> Switched back to "On last logout" and it is still working. Very pleased!
> Thanks to everyone who put in the hard work to make this happen for Plasma 6.

I am on Fedora 40 and I pretty much had to go through the same steps to actually enable this feature. Also the manual option didn't make the "save session" button show up even after reboot.

System Info:
Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics
Manufacturer: LENOVO
Product Name: 20RD002RUS
System Version: ThinkPad E15

(In reply to Armin from comment #131)
> (In reply to imaginator from comment #115)
> > So why don't you just dump Plasma-Wayland and use Plasma-X11 until this
> > essential (but nowadays rather trivial) feature is _fully_ implemented?
> 
> Well, with modern laptops featuring extremely high resolution displays, and
> a multiscreen setup, X11 simply cannot handle such setups any more.
> 
> With Wayland, a bunch of X11-features that have been "sort of working" like
> X-forwarding, screen sharing (in Teams/Zoom), and session management stopped
> working, but a whole lot of pain points that I had to work through over the
> past two decades went away, such as the resolution issue mentioned above.
> Ever since I adopted Wayland, screen sharing has been fixed and X-forwarding
> can be replaced by alternatives like VNC, which leaves session management as
> the last big ticket item.
> 
> Regarding the fake session report, Fedora 40 has backported the patches to
> Plasma 6.0 a few months ago, so there was not really any change with the
> update to Plasma 6.1. I otherwise came to realise that the fake session
> restore is working exactly as advertised (cf.
> https://bugs.kde.org/show_bug.cgi?id=436318#c84 or the commit message at
> https://invent.kde.org/plasma/plasma-workspace/-/commit/
> 660988b0e30ee8ccac98c0cf164b142d70709675).
> 
> So, got to wait until somebody with the necessary knowledge and skills
> implements true session management in KDE Plasma.

I generally agree, though I had hoped that the 6.1 version would be a little better and it really isn´t. What worries me is that apparently proper session restore is a missing feature in Wayland itself (Gnome has a non-standard workaround) so I don't know how long we are going to have to wait. This is not a good situation.

I would be much happier if we could at least have windows restored to their proper desktops and positions, but I don't know enough to guess how hard that is to do. Is there no way for the 'session save' action to interrogate the window manager (or Wayland server) and save this information?

(In reply to imaginator from comment #135)
> Now it seems that Plasma-6-users are at the mercy of the Wayland-devs
> (comment 89).

Well, not really. There is nothing stopping KDE devs to go ahead and implement the Wayland session management draft protocol. In fact, it would not be a bad thing at all to have an implementation of the protocol in order to identify any issues early on.

The Gnome devs did exactly that, and implemented the draft protocol in Mutter and GTK:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7370

Maybe this helps KDE devs to move things along for Plasma as well...

(In reply to Nate Graham from comment #87)
> Correct. Because real session restore is not implemented on Wayland yet, at
> the moment this manual session restore hooks into the "real fake session
> restore" mechanism that will be used until we get real session restore.

It's a bit bad UX that this is not at least communicated to the user in the settings where this is selected. Quite frankly I cannot see why it was not hooked to the real session save which it at least attempts to do...

I've been following this bug because I used session restore back when it worked.  I have found a workaround that works for me but I have not seen it mentioned here yet.  Here's what I do.  I have two monitors and use 4 virtual desktops.  I'm able to have a console window with multiple tabs open on the left monitor in virtual desktop 1 by using the konsole option --tabs-from-file.  One of the tabs starts with top running.   Chrome starts on the left monitor in virtual desktop 2.  Thunderbird starts on the right monitor in all virtual desktops.  I am able to do this by using the autostart section of the system setting app to specify what apps start at login.  Then in the Window Rules section (in Apps & Windows -> Window Management) I am able to specify where each app appears.  Like I said, this works for me.  Of course it does not save the current session so that it comes back on the next login.

Git commit 4dff1973116597210cf9fb1c102e5c9433d13b1d by Fushan Wen, on behalf of David Edmundson.
Committed on 14/09/2024 at 13:22.
Pushed by fusionfuture into branch 'master'.

startkde: Fix wayland session restore saving

When we added manual saving support to plasma-shutdown a guard was
changed in the normal shutdown path. This guard was wrong, we want to
check we're in the restorePreviousLogout path here.

This amends 804976c5ecec1fbf5f6e7e09970a8269bdf748d2

M  +1    -1    startkde/plasma-shutdown/shutdown.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/4dff1973116597210cf9fb1c102e5c9433d13b1d

Git commit fae71841ff018e34bbb02aa1098b53f63c1743d2 by Fushan Wen.
Committed on 17/09/2024 at 07:53.
Pushed by fusionfuture into branch 'Plasma/6.2'.

startkde: Fix wayland session restore saving

When we added manual saving support to plasma-shutdown a guard was
changed in the normal shutdown path. This guard was wrong, we want to
check we're in the restorePreviousLogout path here.

This amends 804976c5ecec1fbf5f6e7e09970a8269bdf748d2


(cherry picked from commit 4dff1973116597210cf9fb1c102e5c9433d13b1d)

89ee67ad startkde: Fix wayland session restore saving

Co-authored-by: David Edmundson <kde@davidedmundson.co.uk>

M  +1    -1    startkde/plasma-shutdown/shutdown.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/fae71841ff018e34bbb02aa1098b53f63c1743d2

I wonder why there is extra button for save session since this is the button for leave session when configuration is restore previous session?

Am I correct in assuming that the commit marked as fixing this issue only enables the 'fake session restore' (that opens all the applications that were previously opened without restoring their state)?

From my experiments, it still looks like *saving* the session information (which is what this bug title references) is not fixed by that commit. That would probably require progress on https://invent.kde.org/plasma/kwin/-/issues/113

(In reply to Kishore Gopalakrishnan from comment #165)
> Am I correct in assuming that the commit marked as fixing this issue only
> enables the 'fake session restore' (that opens all the applications that
> were previously opened without restoring their state)?
> 
> From my experiments, it still looks like *saving* the session information
> (which is what this bug title references) is not fixed by that commit. That
> would probably require progress on
> https://invent.kde.org/plasma/kwin/-/issues/113

From [1]: "Fixed a bug that caused real-fake-session-restore to not work properly on Wayland (David Edmundson, Plasma 6.2.0. Link)"

I'm not sure what a "real-fake-session-restore" is but I guess it's the surrogate session-restore that's been delivered to Plasma-6-wayland-users lately.

Now, if only that crutch is fixed, it's indeed hard to see how that would qualify to mark *this* bug (again) as "resolved".  Perhaps after three years the pain became just too much to bear.
--

[1] https://pointieststick.com/2024/09/20/this-week-in-plasma-polishing-like-mad/

Folks, please try to keep down the chatter in here. I know it's very frustrating that this feature hasn't been implemented on Wayland yet (it is for me too, believe me), but more comments in here about how Wayland sucks or KDE developers are like Microsoft devs or workarounds using other software are off-topic, and I have hidden them to improve the signal-to-noise ratio in here. Let's please try to keep comments technical and steered in the direction of getting the feature implemented. Thanks!

(In reply to Nate Graham from comment #175)
Thanks, Nate, for confirming that KDE developers are  working on this. I guess users would be less confused if you also clean the "Version fixed in" filed, because it is clearly not fixed and most of the recent comments say just that.

Good call, I forgot to do that. Thanks.

*** Bug 496674 has been marked as a duplicate of this bug. ***

*** Bug 471977 has been marked as a duplicate of this bug. ***

I'd like to add to this bug report.  I can reliably (100% of the time) reproduce this bug as submitted on 

Fedora 41
KDE Frameworks Version:  6.9.0
Qt Version:  6.8.1
Graphics Platform:  Wayland 

Additionally, once I select "Application Launcher" -> Leave -> "Save Session"  CTRL-ALT-DEL becomes 'inactive.'  That is, hitting CTRL-ALT-DEL has no response by the system whatsoever.  To restart or shutdown I have to use the bash command line.  I can also reproduce this behavior 100% of the time.

I currently have a set of apps in Autostart, but it's still annoying to have to manually move windows onto the right desktops after logging in. As a partial workaround, I wrote a couple of scripts using kdotool (see your local KDE repo). They can occasionally give strange error messages, and don't do anything for window positions within a desktop because that doesn't seem to be possible, but I thought I'd post them here in case anyone finds them useful. Note that I invoke them manually. There may be a way to automate this, but I haven't found it. (Simple login/logout scripts are not the answer).:

Save:
--------
#!/bin/bash
# Save desktop state of selected windows
# pocallaghan@gmail.com - 22/11/2024

# FIXME: assumes all the window names are distinct
# and restored on restarting

SAVE_FILE=$HOME/.save_desktops

true > "$SAVE_FILE"     # Zero the file

apps=(dolphin firefox evolution konsole)

for app in "${apps[@]}"
do
        for d in $(kdotool search "$app")
        do
#               cn=$(kdotool getwindowclassname $d)
#               [ "$cn" = plasmashell ] && continue     # Plasma has no desktop
                dt=$(kdotool get_desktop_for_window "$d")
                wn=$(kdotool getwindowname "$d")
                echo "$dt $wn" >> "$SAVE_FILE"
        done
done
---------
Restore:
---------
#!/bin/bash
# Restore the virtual desktops of saved windows
# pocallaghan@gmail.com - 23/11/2024

SAVE_FILE=$HOME/.save_desktops

cat "$SAVE_FILE"|while read dt wn ; do
        window=$(kdotool search "$wn")
        [ "$window"x = x ] && continue
        kdotool set_desktop_for_window "$window" "$dt"
done
------

(In reply to Patrick O'Callaghan from comment #181)  
If you uploaded the script to even something as simple as a GitHub Gist or GitLab Snippet, and then linked that here, I think it'd be more useful, since questions and suggestions can't be posted here without notifying 118 people. Thanks for it, though.

(In reply to Roke Julian Lockhart Beedell from comment #182)
> (In reply to Patrick O'Callaghan from comment #181)  
> If you uploaded the script to even something as simple as a GitHub Gist or
> GitLab Snippet, and then linked that here, I think it'd be more useful,
> since questions and suggestions can't be posted here without notifying 118
> people. Thanks for it, though.

Good idea. I've put it on:

https://gist.github.com/pjoc/a5059b93321ee67d42f4af8d45b7276f

Thanks

While hunting for any recent updates, I found this. Looks like gnome-48 will contain some form of session restore:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7682
https://www.phoronix.com/news/Mutter-XDG-Session-Management

I can't really find any recent updates for KDE for similar effort. Is this ever going to be worked on by KDE?

(In reply to devsk from comment #184)
> While hunting for any recent updates, I found this. Looks like gnome-48 will
> contain some form of session restore:
> 
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7682
> https://www.phoronix.com/news/Mutter-XDG-Session-Management
> 
> I can't really find any recent updates for KDE for similar effort. Is this
> ever going to be worked on by KDE?

I surely hope so.  I'm sure I'm not the only one who finds it extremely annoying to have to reposition my windows each time I log in or reboot my system.  In fact, I update my system only once a month (dnf upgrade) because I'm tired of having to resize and reposition my windows each time.  

SunOS OpenLook did this beautifully, accurately, and reliably way back in 1990.  I've tried 4 Linux distros, and this does not work on any of the ones I've tried.  Why is it that Linux has so much trouble with basic things like this?  Who does the prioritization of work on Linux platforms?  Do they get the feedback from users?

> Is this ever going to be worked on by KDE?

In my mind, there are two answers to this question, and both are correct answers:

1. We have no plan to get this working on KDE anytime soon
2. We have a plan and here is the schedule (gnome guys took this approach)

I haven't seen 2) for KDE anywhere on the interwebs. Can we at least create a plan? Its fine if its done in 6 months from now or 1 year. But let's have a plan and work toward it.

1) is also fine but then, let's state that clearly so that we can stop coming back to this bug (its almost 4 years old now) every few months.

To me, it almost feels like, because this bug is open, someone is working on it in the background when, in reality, no one is, and there is no way of knowing if someone is or not.

PS: I found the following for kwin but its 2 years old and open: https://invent.kde.org/plasma/kwin/-/merge_requests/3024

(In reply to Peter Huatan from comment #185)

> > Is this ever going to be worked on by KDE?
> 
> I surely hope so.  I'm sure I'm not the only one who finds it extremely
> annoying to have to reposition my windows each time I log in or reboot my
> system.  In fact, I update my system only once a month (dnf upgrade) because
> I'm tired of having to resize and reposition my windows each time.  

There is a work-round if you use sddm: select X11 on the login screen, rather than Wayland, and you'll have the proper restoration of desktops and their windows. It works for me, anyway.

(In reply to Peter Humphrey from comment #187)
> (In reply to Peter Huatan from comment #185)
> 
> > > Is this ever going to be worked on by KDE?
> > 
> > I surely hope so.  I'm sure I'm not the only one who finds it extremely
> > annoying to have to reposition my windows each time I log in or reboot my
> > system.  In fact, I update my system only once a month (dnf upgrade) because
> > I'm tired of having to resize and reposition my windows each time.  
> 
> There is a work-round if you use sddm: select X11 on the login screen,
> rather than Wayland, and you'll have the proper restoration of desktops and
> their windows. It works for me, anyway.

Regarding session-restore, Plasma-X11 works for anybody. ;)  
The question is whether your distribution offers it, as Plasma-wayland unfortunately is the default now.

To me the central problem in this affair seems to be the obviously still missing wayland-protocol (see Comment 89).

(In reply to imaginator from comment #188)
> (In reply to Peter Humphrey from comment #187)
> > (In reply to Peter Huatan from comment #185)
> > 
> > > > Is this ever going to be worked on by KDE?
> > > 
> > > I surely hope so.  I'm sure I'm not the only one who finds it extremely
> > > annoying to have to reposition my windows each time I log in or reboot my
> > > system.  In fact, I update my system only once a month (dnf upgrade) because
> > > I'm tired of having to resize and reposition my windows each time.  
> > 
> > There is a work-round if you use sddm: select X11 on the login screen,
> > rather than Wayland, and you'll have the proper restoration of desktops and
> > their windows. It works for me, anyway.
> 
> Regarding session-restore, Plasma-X11 works for anybody. ;)  
> The question is whether your distribution offers it, as Plasma-wayland
> unfortunately is the default now.
> 
> To me the central problem in this affair seems to be the obviously still
> missing wayland-protocol (see Comment 89).

I said: "if you use sddm."

(In reply to Peter Humphrey from comment #189)
> (In reply to imaginator from comment #188)
> > (In reply to Peter Humphrey from comment #187)
> > > (In reply to Peter Huatan from comment #185)
> > > 
> > > > > Is this ever going to be worked on by KDE?
> > > > 
> > > > I surely hope so.  I'm sure I'm not the only one who finds it extremely
> > > > annoying to have to reposition my windows each time I log in or reboot my
> > > > system.  In fact, I update my system only once a month (dnf upgrade) because
> > > > I'm tired of having to resize and reposition my windows each time.  
> > > 
> > > There is a work-round if you use sddm: select X11 on the login screen,
> > > rather than Wayland, and you'll have the proper restoration of desktops and
> > > their windows. It works for me, anyway.
> > 
> > Regarding session-restore, Plasma-X11 works for anybody. ;)  
> > The question is whether your distribution offers it, as Plasma-wayland
> > unfortunately is the default now.
> > 
> > To me the central problem in this affair seems to be the obviously still
> > missing wayland-protocol (see Comment 89).
> 
> I said: "if you use sddm."

It doesn't matter whether your display manager is sddm, lightdm, gdm or whatever.  If the distribution supports Plasma-X11 in addition to Plasma-Wayland, you can choose between them when logging in.

(In reply to Peter Huatan from comment #185)
> (In reply to devsk from comment #184)
> > While hunting for any recent updates, I found this. Looks like gnome-48 will
> > contain some form of session restore:
> > 
> > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825
> > https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7682
> > https://www.phoronix.com/news/Mutter-XDG-Session-Management
> > 
> > I can't really find any recent updates for KDE for similar effort. Is this
> > ever going to be worked on by KDE?
> 
> I surely hope so.  I'm sure I'm not the only one who finds it extremely
> annoying to have to reposition my windows each time I log in or reboot my
> system.  In fact, I update my system only once a month (dnf upgrade) because
> I'm tired of having to resize and reposition my windows each time.  
> 
> SunOS OpenLook did this beautifully, accurately, and reliably way back in
> 1990.  I've tried 4 Linux distros, and this does not work on any of the ones
> I've tried.  Why is it that Linux has so much trouble with basic things like
> this?  Who does the prioritization of work on Linux platforms?  Do they get
> the feedback from users?

A Linux-system is a huge mosaic of several hundreds or more pieces of software provided by probably as many individual projects (communities of developers).  There is no central authority that can set/enforce priorities or order certain devs to get out of slo-mo mode and finally provide what others urgently need.  

By making Wayland the default for Plasma-6 instead of sticking with X11 (and publicly explaining why), KDE unfortunately gave away the only leverage they had in this affair.

(In reply to imaginator from comment #191)
> By making Wayland the default for Plasma-6 instead of sticking with X11 (and
> publicly explaining why), KDE unfortunately gave away the only leverage they
> had in this affair.

openSUSE Leap 16.x still uses X11 / KDE 5 as default as far as I know or better as I'm using it.

(In reply to Andreas Hartmann from comment #192)
> (In reply to imaginator from comment #191)
> > By making Wayland the default for Plasma-6 instead of sticking with X11 (and
> > publicly explaining why), KDE unfortunately gave away the only leverage they
> > had in this affair.
> 
> openSUSE Leap 16.x still uses X11 / KDE 5 as default as far as I know or
> better as I'm using it.

You probably mean 15.x?  AFAIK they do not even offer Wayland for those versions.  But anyway, we're talking about Plasma-6 here, not Plasma-5.  
KDE chose Wayland as default for Plasma-6.  So if a distribution only offers the default Plasma-6, then  the user has no choice - and no session-restore.

(In reply to Patrick O'Callaghan from comment #183)
> (In reply to Roke Julian Lockhart Beedell from comment #182)
> > (In reply to Patrick O'Callaghan from comment #181)  
> > If you uploaded the script to even something as simple as a GitHub Gist or
> > GitLab Snippet, and then linked that here, I think it'd be more useful,
> > since questions and suggestions can't be posted here without notifying 118
> > people. Thanks for it, though.
> 
> Good idea. I've put it on:
> 
> https://gist.github.com/pjoc/a5059b93321ee67d42f4af8d45b7276f
> 
> Thanks

Updated the Restore script to handle window titles with special characters.

(In reply to Patrick O'Callaghan from comment #181)
> I currently have a set of apps in Autostart, but it's still annoying to have
> to manually move windows onto the right desktops after logging in. As a
> partial workaround, I wrote a couple of scripts using kdotool (see your
> local KDE repo). They can occasionally give strange error messages, and
> don't do anything for window positions within a desktop because that doesn't
> seem to be possible, but I thought I'd post them here in case anyone finds
> them useful. Note that I invoke them manually. There may be a way to
> automate this, but I haven't found it. (Simple login/logout scripts are not
> the answer).:

Have you ever put the script that restores the windows into "Autostart" as well?  I don't know whether one has any influence on the sequence in which the programs are started but _if_ they are started in alphabetical order you could name it something like z_script.

More on topic: the funny and real mean thing with session-save/-restore in Plasma-wayland (-5.27.11.1) is that _restoring_ a previous session does work fine (perhaps apart from minor differences in window-positions).  I can tell because when I log out of a Plasma-X11 session and then log in to a Plasma-wayland session, the previous (Plasma-X11) session is restored almost perfectly, incl. kate, dolphin, whatever.  And that's reproducible.  However, if one then logs out of the Plasma-wayland session and in to a Plasma-X11 session (or Plasma-wayland session), the previous session is gone, except for non-KDE-apps like Firefox or Thunderbird.

So, from what I see here with Plasma-wayland, the real problem is not _restoring_ a session but _saving_ it correctly.  And what makes matters worse (somehow) is that the state of non-KDE-apps like Firefox/Thunderbird _is_ saved correctly in ksmserverrc [1].  What's not saved is the state of KDE-apps.  But perhaps you know all this already. ;)

--

[1]
[LegacySession: saved at previous logout]
count=0

[LegacySession: saved by user]
count=0

[Session: saved at previous logout]
clientId1=104c55580000173762586300000023360009
clientId2=104c55580000173870527300000023170111
clientId3=104c55580000173902919800000078330002
count=3
program1=thunderbird
program2=firefox
program3=pulseaudio
restartCommand1=/opt/thunderbird/thunderbird,--sm-client-id,104c55580000173762586300000023360009
restartCommand2=/opt/firefox/firefox,--sm-client-id,104c55580000173870527300000023170111
restartCommand3=
[...]

(In reply to imaginator from comment #195)
> (In reply to Patrick O'Callaghan from comment #181)
> > I currently have a set of apps in Autostart, but it's still annoying to have
> > to manually move windows onto the right desktops after logging in. As a
> > partial workaround, I wrote a couple of scripts using kdotool (see your
> > local KDE repo). They can occasionally give strange error messages, and
> > don't do anything for window positions within a desktop because that doesn't
> > seem to be possible, but I thought I'd post them here in case anyone finds
> > them useful. Note that I invoke them manually. There may be a way to
> > automate this, but I haven't found it. (Simple login/logout scripts are not
> > the answer).:
> 
> Have you ever put the script that restores the windows into "Autostart" as
> well?  I don't know whether one has any influence on the sequence in which
> the programs are started but _if_ they are started in alphabetical order you
> could name it something like z_script.

It doesn't work (I tried it). AFAIK Plasma fires all the Autostart scripts concurrently and I don't see a way to make the Restore script wait until everything else is up, or at least has mapped its window(s). Maybe there's some systemd magic that would do it.
 
> More on topic: the funny and real mean thing with session-save/-restore in
> Plasma-wayland (-5.27.11.1) is that _restoring_ a previous session does work
> fine (perhaps apart from minor differences in window-positions).  I can tell
> because when I log out of a Plasma-X11 session and then log in to a
> Plasma-wayland session, the previous (Plasma-X11) session is restored almost
> perfectly, incl. kate, dolphin, whatever.  And that's reproducible. 
> However, if one then logs out of the Plasma-wayland session and in to a
> Plasma-X11 session (or Plasma-wayland session), the previous session is
> gone, except for non-KDE-apps like Firefox or Thunderbird.
> 
> So, from what I see here with Plasma-wayland, the real problem is not
> _restoring_ a session but _saving_ it correctly.  And what makes matters
> worse (somehow) is that the state of non-KDE-apps like Firefox/Thunderbird
> _is_ saved correctly in ksmserverrc [1].  What's not saved is the state of
> KDE-apps.  But perhaps you know all this already. ;)

That is interesting.

(In reply to Patrick O'Callaghan from comment #196)
> (In reply to imaginator from comment #195)
> > (In reply to Patrick O'Callaghan from comment #181)
> > > I currently have a set of apps in Autostart, but it's still annoying to have
> > > to manually move windows onto the right desktops after logging in. As a
> > > partial workaround, I wrote a couple of scripts using kdotool (see your
> > > local KDE repo). They can occasionally give strange error messages, and
> > > don't do anything for window positions within a desktop because that doesn't
> > > seem to be possible, but I thought I'd post them here in case anyone finds
> > > them useful. Note that I invoke them manually. There may be a way to
> > > automate this, but I haven't found it. (Simple login/logout scripts are not
> > > the answer).:
> > 
> > Have you ever put the script that restores the windows into "Autostart" as
> > well?  I don't know whether one has any influence on the sequence in which
> > the programs are started but _if_ they are started in alphabetical order you
> > could name it something like z_script.
> 
> It doesn't work (I tried it). AFAIK Plasma fires all the Autostart scripts
> concurrently and I don't see a way to make the Restore script wait until
> everything else is up, or at least has mapped its window(s). Maybe there's
> some systemd magic that would do it.

You could use "sleep" (-> sleep --help) to delay the execution of the relevant parts of your script until other scripts have run or the desktop is fired up.  Example:

#!/bin/bash

# Test "sleep".
sleep 10
echo "This was a test."


HTH.

(In reply to imaginator from comment #197)  
On older systems, this wouldn't really work, since there's always something that randomly takes ages to launch. Is there a way to wait for a specific process to be invoked? If so, perhaps wait for `plasmashell` to be running, then run the script, since it's usually one of the last things to run. https://stackoverflow.com/a/9118509/9731176 might be of use.

(In reply to imaginator from comment #197)
> (In reply to Patrick O'Callaghan from comment #196)
> > (In reply to imaginator from comment #195)
> > > (In reply to Patrick O'Callaghan from comment #181)
> > > > I currently have a set of apps in Autostart, but it's still annoying to have
> > > > to manually move windows onto the right desktops after logging in. As a
> > > > partial workaround, I wrote a couple of scripts using kdotool (see your
> > > > local KDE repo). They can occasionally give strange error messages, and
> > > > don't do anything for window positions within a desktop because that doesn't
> > > > seem to be possible, but I thought I'd post them here in case anyone finds
> > > > them useful. Note that I invoke them manually. There may be a way to
> > > > automate this, but I haven't found it. (Simple login/logout scripts are not
> > > > the answer).:
> > > 
> > > Have you ever put the script that restores the windows into "Autostart" as
> > > well?  I don't know whether one has any influence on the sequence in which
> > > the programs are started but _if_ they are started in alphabetical order you
> > > could name it something like z_script.
> > 
> > It doesn't work (I tried it). AFAIK Plasma fires all the Autostart scripts
> > concurrently and I don't see a way to make the Restore script wait until
> > everything else is up, or at least has mapped its window(s). Maybe there's
> > some systemd magic that would do it.
> 
> You could use "sleep" (-> sleep --help) to delay the execution of the
> relevant parts of your script until other scripts have run or the desktop is
> fired up.  Example:
> 
> #!/bin/bash
> 
> # Test "sleep".
> sleep 10
> echo "This was a test."
> 
> 
> HTH.

I generally think timer-based solutions are inferior to triggers, but you can do that if want. It strikes me as even more kludgey than what I already have, and given that the user has to manually save the session anyway it wouldn't even have the advantage of transparency.

Behaviour may have changed. Not sure of when this happened but I just noticed that the session restore does not resume windows to the first virtual desktop. It restores the windows to the last virtual desktop that was used in the previous session. I little window is flashed that says the name of the virtual desktop and then proceeds to restore the windows in that desktop.

I finally moved to wayland with 6.3. I had to jump through some hoops though. Here is the code in case someone wants to try the save/restore scripts (make sure to read the comments on the gist before using this code):

https://gist.github.com/devsk/9eff2d08d6cd5772afd2b178930b66ae

(In reply to Roke Julian Lockhart Beedell from comment #198)
> (In reply to imaginator from comment #197)  
> On older systems, this wouldn't really work, since there's always something
> that randomly takes ages to launch. Is there a way to wait for a specific
> process to be invoked? If so, perhaps wait for `plasmashell` to be running,
> then run the script, since it's usually one of the last things to run.
> https://stackoverflow.com/a/9118509/9731176 might be of use.

I simply went with the option of starting all the applications from the saved session and then giving user a dialog box to OK the moving of the windows to their respective desktops, positioning them at the saved location and resizing them as per the saved info.

The user just waits for all the application windows to start in the current desktop and then, pressing OK does the work. There are tricks to center the dialog box, keep it above all windows and activating it. kdotool works really well to do the rest.

Checkout the gist I posted. Most of code can be used as is. Only binary names need adjusting/addition/deletion.

(In reply to devsk from comment #202)
> (In reply to Roke Julian Lockhart Beedell from comment #198)
> > (In reply to imaginator from comment #197)  
> > On older systems, this wouldn't really work, since there's always something
> > that randomly takes ages to launch. Is there a way to wait for a specific
> > process to be invoked? If so, perhaps wait for `plasmashell` to be running,
> > then run the script, since it's usually one of the last things to run.
> > https://stackoverflow.com/a/9118509/9731176 might be of use.
> 
> I simply went with the option of starting all the applications from the
> saved session and then giving user a dialog box to OK the moving of the
> windows to their respective desktops, positioning them at the saved location
> and resizing them as per the saved info.
> 
> The user just waits for all the application windows to start in the current
> desktop and then, pressing OK does the work. There are tricks to center the
> dialog box, keep it above all windows and activating it. kdotool works
> really well to do the rest.
> 
> Checkout the gist I posted. Most of code can be used as is. Only binary
> names need adjusting/addition/deletion.

What does kwin-fix_crazy_gesture.patch do? Seems to be a patch to the kwin source code.

(In reply to Patrick O'Callaghan from comment #203)
> (In reply to devsk from comment #202)
> > (In reply to Roke Julian Lockhart Beedell from comment #198)
> > > (In reply to imaginator from comment #197)  
> > > On older systems, this wouldn't really work, since there's always something
> > > that randomly takes ages to launch. Is there a way to wait for a specific
> > > process to be invoked? If so, perhaps wait for `plasmashell` to be running,
> > > then run the script, since it's usually one of the last things to run.
> > > https://stackoverflow.com/a/9118509/9731176 might be of use.
> > 
> > I simply went with the option of starting all the applications from the
> > saved session and then giving user a dialog box to OK the moving of the
> > windows to their respective desktops, positioning them at the saved location
> > and resizing them as per the saved info.
> > 
> > The user just waits for all the application windows to start in the current
> > desktop and then, pressing OK does the work. There are tricks to center the
> > dialog box, keep it above all windows and activating it. kdotool works
> > really well to do the rest.
> > 
> > Checkout the gist I posted. Most of code can be used as is. Only binary
> > names need adjusting/addition/deletion.
> 
> What does kwin-fix_crazy_gesture.patch do? Seems to be a patch to the kwin
> source code.

On all platforms where I have used the swipe gesture, it takes to the right desktop when you swipe left. With X11, it was like that (imagine years of motor tuning). With wayland, it drove me crazy because every time I wanted to go a desktop, it took me to the wrong desktop.

This behavior would be typically changeable but everything I tried using touchegg, confused the desktop navigation more: touchegg would move it to next but kwin would move it back, meaning that it did not change the desktop. After some real desperation, I took the drastic step of finding and toggling the gesture in code.

(In reply to devsk from comment #204)
> (In reply to Patrick O'Callaghan from comment #203)
> > (In reply to devsk from comment #202)
> > > (In reply to Roke Julian Lockhart Beedell from comment #198)
> > > > (In reply to imaginator from comment #197)  
> > > > On older systems, this wouldn't really work, since there's always something
> > > > that randomly takes ages to launch. Is there a way to wait for a specific
> > > > process to be invoked? If so, perhaps wait for `plasmashell` to be running,
> > > > then run the script, since it's usually one of the last things to run.
> > > > https://stackoverflow.com/a/9118509/9731176 might be of use.
> > > 
> > > I simply went with the option of starting all the applications from the
> > > saved session and then giving user a dialog box to OK the moving of the
> > > windows to their respective desktops, positioning them at the saved location
> > > and resizing them as per the saved info.
> > > 
> > > The user just waits for all the application windows to start in the current
> > > desktop and then, pressing OK does the work. There are tricks to center the
> > > dialog box, keep it above all windows and activating it. kdotool works
> > > really well to do the rest.
> > > 
> > > Checkout the gist I posted. Most of code can be used as is. Only binary
> > > names need adjusting/addition/deletion.
> > 
> > What does kwin-fix_crazy_gesture.patch do? Seems to be a patch to the kwin
> > source code.
> 
> On all platforms where I have used the swipe gesture, it takes to the right
> desktop when you swipe left. With X11, it was like that (imagine years of
> motor tuning). With wayland, it drove me crazy because every time I wanted
> to go a desktop, it took me to the wrong desktop.
> 
> This behavior would be typically changeable but everything I tried using
> touchegg, confused the desktop navigation more: touchegg would move it to
> next but kwin would move it back, meaning that it did not change the
> desktop. After some real desperation, I took the drastic step of finding and
> toggling the gesture in code.

So this patch has actually nothing to do with session restore. I'd suggest posting it somewhere else to avoid confusion.

I've had a quick look at your scripts but haven't tried them. They seem quite complicated, but maybe they do more than mine. I've taken note of how you use 'kdotool windowmove' and have added this to my own scripts (don't know why I hadn't noticed this before :-). I'll upload them shortly (still not very familiar with Gist to be honest).

(In reply to Patrick O'Callaghan from comment #194)
> (In reply to Patrick O'Callaghan from comment #183)
> > (In reply to Roke Julian Lockhart Beedell from comment #182)
> > > (In reply to Patrick O'Callaghan from comment #181)  
> > > If you uploaded the script to even something as simple as a GitHub Gist or
> > > GitLab Snippet, and then linked that here, I think it'd be more useful,
> > > since questions and suggestions can't be posted here without notifying 118
> > > people. Thanks for it, though.
> > 
> > Good idea. I've put it on:
> > 
> > https://gist.github.com/pjoc/a5059b93321ee67d42f4af8d45b7276f
> > 
> > Thanks
> 
> Updated the Restore script to handle window titles with special characters.

Updated again to save/restore window positions.

(In reply to Patrick O'Callaghan from comment #205)
> 
> So this patch has actually nothing to do with session restore. I'd suggest
> posting it somewhere else to avoid confusion.

Yes. I don't think anybody cares about flipping the gestures behavior. I will keep this patch around.

> I've had a quick look at your scripts but haven't tried them. They seem
> quite complicated, but maybe they do more than mine. I've taken note of how
> you use 'kdotool windowmove' and have added this to my own scripts (don't
> know why I hadn't noticed this before :-). I'll upload them shortly (still
> not very familiar with Gist to be honest).

Yes. My script does do way more..:-) It saves a lot more information in a format which is easily read in bash. Then, it starts all the apps and waits for the user to ack the restoration process which restores their desktop, position and size.

I had to add a lot of code for robustness e.g. some random processes make their way into 'kdotool search' when they don't have a real window associated with them e.g. plasmashell. 

For example, restoring from X11 to wayland, the window class changes from konsole to org.kde.konsole.

For example, the size and location on wayland are floating point numbers sometimes, which was not apparent until wayland locked up on creating a window with 0 size with infinite memory allocation loop and got killed by OOM.

For example, if you saved session from a crontab periodically, kdotool just doesn't find any windows because crontab does not have access to the user environment to access the DBUS.

Lots of accounting for quirks.

(In reply to devsk from comment #207)
> (In reply to Patrick O'Callaghan from comment #205)
> > 
> > So this patch has actually nothing to do with session restore. I'd suggest
> > posting it somewhere else to avoid confusion.
> 
> Yes. I don't think anybody cares about flipping the gestures behavior. I
> will keep this patch around.

I'd suggest keeping it separate from the rest. It's confusing to have it lumped in with the save/restore stuff.

> > I've had a quick look at your scripts but haven't tried them. They seem
> > quite complicated, but maybe they do more than mine. I've taken note of how
> > you use 'kdotool windowmove' and have added this to my own scripts (don't
> > know why I hadn't noticed this before :-). I'll upload them shortly (still
> > not very familiar with Gist to be honest).
> 
> Yes. My script does do way more..:-) It saves a lot more information in a
> format which is easily read in bash. Then, it starts all the apps and waits
> for the user to ack the restoration process which restores their desktop,
> position and size.

All the apps I've used already remember their sizes on restarting, so I don't bother with that.

I'll consider using Zenity or similar, but given that it only helps with restoring and not saving, I wouldn't place a high priority on it. If there were a reliable way to save state on logging out, that would change. Unfortunately the Auto-start logout scripts only seem to trigger once all windows have been destroyed.

> I had to add a lot of code for robustness e.g. some random processes make
> their way into 'kdotool search' when they don't have a real window
> associated with them e.g. plasmashell. 

I already skip plasmashell, and if anything else has this behaviour it would be trivial to add.

> For example, restoring from X11 to wayland, the window class changes from
> konsole to org.kde.konsole.

I don't care about X11. I wrote this specifically for Wayland.

> For example, the size and location on wayland are floating point numbers
> sometimes, which was not apparent until wayland locked up on creating a
> window with 0 size with infinite memory allocation loop and got killed by
> OOM.
>

kdotool can return floating-point values for position, but doesn't accept them when trying to set it. This to me is a bug. However I'm not worried about fractions of a pixel, so I just truncate these to integers.

> For example, if you saved session from a crontab periodically, kdotool just
> doesn't find any windows because crontab does not have access to the user
> environment to access the DBUS.

Not something I do. I only save the state explicitly.

> All the apps I've used already remember their sizes on restarting, so I don't bother with that.

konsole doesn't do that for me. It opens a single window of a dimension from the profile.

My script opens as many konsole windows as you had open before, moves to the right location in the right desktop and sizes them.

(In reply to devsk from comment #209)
> > All the apps I've used already remember their sizes on restarting, so I don't bother with that.
> 
> konsole doesn't do that for me. It opens a single window of a dimension from
> the profile.
> 
> My script opens as many konsole windows as you had open before, moves to the
> right location in the right desktop and sizes them.

Thanks for pointing that out I almost never have more than one Konsole terminal open so hadn't noticed. It does however remember the size of the single one it opens.

Some coverage: https://www.youtube.com/watch?v=UAMAlqqVijY

This is a bug tracker, not a forum. If you're not adding something, don't post things.

People are working on this. 

There's the window management stuff in kwin that's linked somewhere, rebased very recently and there's also Qt work here: https://codereview.qt-project.org/c/qt/qtwayland/+/603992

But that's not the important part of session restore. You need to actually restart the apps. 

We cannot blindly copy XSMP because that's a huge security hole for Flatpak'd apps. *including on X11*

 It is going to need something that that allows apps in flatpaks to request a restart command and have something outside that rewrite that command with the security prefixing. 
This is the part that's in progress in xdg-desktop-portals and why the Wayland part is seemingly stuck.

(In reply to David Edmundson from comment #216)
> This is a bug tracker, not a forum. If you're not adding something, don't
> post things.

I posted something that gets me 95% of the way there. If KDE had gotten me there 1/2/3/4 years ago, I would have moved to wayland much earlier and never complained.

> People are working on this. 

Why so secret about it if people are working on it? We rarely see any updates here or anywhere else I could find with google search. What I could find showed that the development stopped more than 2 years ago.

> This is the part that's in progress in xdg-desktop-portals and why the
> Wayland part is seemingly stuck.

Can you please point to the discussion thread for this? I need read-only access and have no (or had any) intention of spamming anyone. The last thing I want to do is to annoy the people who are working voluntarily on this feature.