436318 2021-04-28 16:11:50 +0000 Support for real session save/restore for window content and state on Wayland 2026-07-09 15:37:46 +0000 1 1 4 Plasma kwin general 5.24.4 Fedora RPMs Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=442192 https://invent.kde.org/plasma/kwin/-/issues/113#note_500909 wayland-only VHI wishlist --- 510929 1 pocallaghan kwin-bugs-null 4wy78uwh ads-kde-bugs agurenko akontsevich alex andihartmann andreas.davour anssi.hannula anton.schenker arisu+kdebugs aspotashev auxsvr bdk bednarczyk.pawel bela73 bernie bruno bugs.kde.org bugs.kde butirsky bvbfan cdennett cengique chris christian.rohmann coque.couto cribari cruzki123 david.narvaez dennis desw dkxls23 drew.m.fisher edtoml endymion+kde equeim etaash.mathamsetty eugene.savitsky eugene.shalygin+bugzilla.kde fedin-ilja2010 feus73 forums freisim93 funtoos gimmemahlulz gordan.kresic grahamperrin gzatko hoehnp hoperidesalone imaginator itsforspam99 jakeskelton11 JanNowak94 jaro.schmidt jason.boissiere jhasse jhs jlp jman27449 jmtornetta johannes.hirte john.ettedgui julien.dlq julien kairo kde.bugzilla.2012 kde KDE kde kdebugsq kimiblock kishore96 kmg952 L.Bonnaud lassi.vaatamoinen linux m.kurz madness742 mail mail majzoube matt matteo.mazzarelli mauromol me michel-heidkamp miranda mmkthecoolest mmtsales msdobrescu mwc85.23yp nate nerumo nico.kruber niklas nkwkelvin null ol+kde oleg.goro omosnacek peter pfeiffer pietromrl0 piotr.mierzwinski plasma-bugs-null playpsic04 pmrpla+bugskde postix rcrit rdieter roman s2 sam sandysareon scottn severin.hamader shai shtetldik silvan.calarco silver.salonen smit17xp stefan steve_garnier t.p.northover tbondvagyok ticonzero2010 tombrown9501 victualsquid ville.aakko wdmlist whyhow+tech winter xqgrhiovxf6bw12h https://invent.kde.org/plasma/kwin/-/commit/54b3364a5ef7856788d509b1883123a3cd44a794 6.7.0 0 oldest_to_newest 2028441 0 pocallaghan 2021-04-28 16:11:50 +0000 SUMMARY After configuring session-restore on login, then saving the session, many items are missing after starting a new session. STEPS TO REPRODUCE 1. Enable "Manually saved session" 2. Set up some apps including Firefox, Konsole, Dolphin 3. Save the session using the Leave button OBSERVED RESULT On logging in again, neither Dolphin nor Konsole windows are restored. Firefox is restored. EXPECTED RESULT All saved windows should be restored. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora 34 (available in About System) KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION 2028485 1 nate 2021-04-28 19:36:34 +0000 Already noted on https://community.kde.org/Plasma/Wayland_Showstoppers. We can use this as the bug report to track it. 2060950 2 nate 2021-09-14 15:07:58 +0000 *** Bug 442192 has been marked as a duplicate of this bug. *** 2061453 3 nate 2021-09-16 17:51:46 +0000 *** Bug 442283 has been marked as a duplicate of this bug. *** 2117856 4 funtoos 2022-04-18 06:53:30 +0000 @Nate: is this going to be taken up any time soon? This is one of the biggest roadblocks to adopting plasma wayland for me. For example, its painful to rearrange firefox windows into different desktops after I start it. I have gone back to X11 solely because of this. 2117920 5 nate 2022-04-18 14:29:15 +0000 I don't know, sorry. 2123914 6 nate 2022-05-16 18:46:11 +0000 *** Bug 453849 has been marked as a duplicate of this bug. *** 2130243 7 etaash.mathamsetty 2022-06-10 02:21:17 +0000 unfortuantely still an issue on plasma 5.24.90 2130275 8 kde 2022-06-10 07:15:22 +0000 *** Bug 455105 has been marked as a duplicate of this bug. *** 2135058 9 kde 2022-06-27 11:10:43 +0000 *** Bug 455900 has been marked as a duplicate of this bug. *** 2135714 10 shtetldik 2022-06-29 04:50:24 +0000 So something like this will eventually be able to help it? https://www.youtube.com/watch?v=fRdnRwPBFBk 2142252 11 cribari 2022-07-29 11:27:38 +0000 Will this bug get fixed soon? It is the sole reason why I'm not on Wayland. Can someone let us know what time frame can be realistic expected for this to be sorted out? Thank you. 2142327 12 nate 2022-07-29 15:36:14 +0000 It's listed on https://community.kde.org/Plasma/Wayland_Showstoppers, so it will eventually get fixed/implemented. 2149041 13 dkxls23 2022-08-30 06:46:51 +0000 This annoying issue is still present on Fedora 36 using KDE 5.97.0 with Wayland. Is somebody looking into this, or is there a timeline for when this will be fixed? 2149145 14 piotr.mierzwinski 2022-08-30 17:44:31 +0000 To be honest it stops me before using/testing Plasma session with Wayland. IMO. This is one from the biggest advantage in KDE (recently even Windows 10 got it, at least for me. I don't understand why this is so low on the priority list (issue reported over 1 year ago). 2149146 15 nate 2022-08-30 17:51:04 +0000 Would you like to contribute technical work towards fixing this issue? That's what there's not enough of right now. 2149186 16 piotr.mierzwinski 2022-08-30 20:13:15 +0000 (In reply to Nate Graham from comment #15) > Would you like to contribute technical work towards fixing this issue? > That's what there's not enough of right now. I'm not sure if this is the question to me, because you didn't quote my statement only answered just after me. Assuming you asked me, I can reply only that maybe I would like, but technically this would be not feasible due to few free time (private reasons). Only from time to time I can report some issue and this is enough what I can do, sorry. Recently I use Neon unstable, so I think, I'm up to date with what's new in Plasma so in this way I test. Sorry for my previous complains. 2149187 17 nate 2022-08-30 20:15:58 +0000 Hopefully this has contributed to answering your question: everyone with the technical ability to work on this issue is busy with other things that they have prioritized higher. :) 2149958 18 piotr.mierzwinski 2022-09-02 21:15:32 +0000 (In reply to Nate Graham from comment #17) > Hopefully this has contributed to answering your question: everyone with the > technical ability to work on this issue is busy with other things that they > have prioritized higher. :) NOP for me. I work with X11, because here more things works better, or just work. Only, IMHO, KDE/Plasma a bit suffer because has less testers, because of this. And please don't understand me wrong, I would not like to set development priorities of KDE/Plasma. 2149961 19 nate 2022-09-02 21:46:18 +0000 In general, Plasma has enough testers and QA people. What it lacks is enough developers to fix all the issues those people find. 2157625 20 funtoos 2022-09-30 18:15:36 +0000 (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. 2157635 21 bernie 2022-09-30 18:57:11 +0000 (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? 2157640 22 funtoos 2022-09-30 19:15:29 +0000 (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! 2157723 23 xqgrhiovxf6bw12h 2022-10-01 12:53:02 +0000 For me, with x11 applications running under x11 ad Wayland, it just seems to be a app startup mechanism. xcalc for example doesn't remain state after logging out. The observed result has been found because Firefox has a option to reopen the pages that were closed during the shutdown of Firefox. Therefore i think changing restore to reopen would be more accurate and a more concrete path to a solution. after the user ends session by logging out, rebooting, etc. Before closing the applications, the paths of the open applications should be saved to a (session) file from where these can be opened. I would be interested to know how the x11 application reopen is done in Wayland as hopefully some of the solution can be reused or be expanded on to include Wayland applications. Im not completely confident in my c++ skills yet as im studying it, so maybe some would like to help me tackle by introducing me to the project structure and the working parts making up KDE. 2157873 24 imaginator 2022-10-02 13:32:10 +0000 (In reply to devsk from comment #22) > (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. Your comment was not inflammatory at all. It was your opinion expressed in a friendly and factual manner. IMO. But it seems to me that esp. in the FOSS community quite a few people simply can't stand critigue, however constructive or well intentioned or politely formulated it may be. They seem to experience critigue as an aggression and not as a chance for improvement. And I consider that a major weakness and an obstacle to success. 2157874 25 imaginator 2022-10-02 13:34:48 +0000 This "bug" or missing key feature, as I see it, is obviously really bad and at this point of time quite shocking. Two days ago I was about switching to Plasma-Wayland because I had such a favorable impression of it. Until I discovered this thing. I don't know whether this situation is due to a lack of provision in the Wayland-design or an inability of developers to focus on what really matters. But if the Plasma devs could solve this on their own, I'd strongly suggest they drop any other Wayland related work *NOW* and start working like hell on resolving this issue. Because this is so detrimental to Plasma's and KDE's reputation that they may not recover from it. IMO. 2162367 26 nate 2022-10-17 20:06:11 +0000 *** Bug 460567 has been marked as a duplicate of this bug. *** 2178269 27 andihartmann 2022-11-27 14:48:53 +0000 Same problem here with leap 15.4. Would be really nice to get it fixed ... . 2183116 28 ticonzero2010 2022-12-09 09:14:13 +0000 Hi all, same problem here does anyone know if the bug has been fixed? thanks Andrea 2183143 29 imaginator 2022-12-09 11:43:07 +0000 (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. 2183183 30 ticonzero2010 2022-12-09 16:43:15 +0000 ok, thanks for the clarification, I will be moving back to Xubuntu 20.04 LTS, since I make big use of this feature 2183196 31 imaginator 2022-12-09 17:41:44 +0000 (In reply to ticonzero from comment #30) > ok, thanks for the clarification, I will be moving back to Xubuntu 20.04 > LTS, since I make big use of this feature I'd say that 99 % of the users make use of this feature. The rest either don't know that it exists or never log out because they are incurably addicted to Plasma-Wayland. ;) 2183200 32 andihartmann 2022-12-09 17:56:30 +0000 I don't think there are so many Wayland users out there because Wayland has so many restrictions and bugs so far (and I don't see any solution). 2184171 33 154513 edtoml 2022-12-11 19:54:02 +0000 Created attachment 154513 attachment-25640-0.html Andreas, I would respectfully disagree. I switched to wayland once multi monitor support started working and have not looked back. Here, at least, the color is more vivid using wayland (eg X looks washed out). Aside from a few irritating bugs like this one, it works well. On Fri, Dec 9, 2022 at 12:56 PM Andreas Hartmann <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #32 from Andreas Hartmann <andihartmann@freenet.de> --- > I don't think there are so many Wayland users out there because Wayland > has so > many restrictions and bugs so far (and I don't see any solution). > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2184173 34 shtetldik 2022-12-11 19:55:56 +0000 (In reply to Andreas Hartmann from comment #32) > I don't think there are so many Wayland users out there because Wayland has > so many restrictions and bugs so far (and I don't see any solution). Just as a reference point, Wayland session usage is shown gradually growing here: https://www.gamingonlinux.com/index.php?module=statistics&view=trends#SessionType-top 2184180 35 154515 ticonzero2010 2022-12-11 20:19:51 +0000 Created attachment 154515 attachment-30227-0.html 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 On Sun, 11 Dec 2022, 20:54 Ed Tomlinson, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #33 from Ed Tomlinson <edtoml@gmail.com> --- > Andreas, I would respectfully disagree. I switched to wayland once multi > monitor support started working and have not looked back. Here, at least, > the color is more vivid using wayland (eg X looks washed out). Aside from > a few irritating bugs like this one, it works well. > > On Fri, Dec 9, 2022 at 12:56 PM Andreas Hartmann <bugzilla_noreply@kde.org > > > wrote: > > > https://bugs.kde.org/show_bug.cgi?id=436318 > > > > --- Comment #32 from Andreas Hartmann <andihartmann@freenet.de> --- > > I don't think there are so many Wayland users out there because Wayland > > has so > > many restrictions and bugs so far (and I don't see any solution). > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2184181 36 154516 ticonzero2010 2022-12-11 20:21:13 +0000 Created attachment 154516 attachment-30617-0.html You were not replying to me I guess ... On Sun, 11 Dec 2022, 21:19 ti conzero, <ticonzero2010@gmail.com> wrote: > 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 > > On Sun, 11 Dec 2022, 20:54 Ed Tomlinson, <bugzilla_noreply@kde.org> wrote: > >> https://bugs.kde.org/show_bug.cgi?id=436318 >> >> --- Comment #33 from Ed Tomlinson <edtoml@gmail.com> --- >> Andreas, I would respectfully disagree. I switched to wayland once multi >> monitor support started working and have not looked back. Here, at least, >> the color is more vivid using wayland (eg X looks washed out). Aside from >> a few irritating bugs like this one, it works well. >> >> On Fri, Dec 9, 2022 at 12:56 PM Andreas Hartmann < >> bugzilla_noreply@kde.org> >> wrote: >> >> > https://bugs.kde.org/show_bug.cgi?id=436318 >> > >> > --- Comment #32 from Andreas Hartmann <andihartmann@freenet.de> --- >> > I don't think there are so many Wayland users out there because Wayland >> > has so >> > many restrictions and bugs so far (and I don't see any solution). >> > >> > -- >> > You are receiving this mail because: >> > You are on the CC list for the bug. >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > 2184186 37 cribari 2022-12-11 20:33:59 +0000 (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. 2184190 38 mauromol 2022-12-11 21:21:12 +0000 (In reply to Francisco Cribari from comment #37) > It is too much work to open each of these files again every time I > restart the computer. Ever heard about sleep and hibernation? ;-) 2184193 39 cribari 2022-12-11 21:27:43 +0000 (In reply to Mauro Molinari from comment #38) > Ever heard about sleep and hibernation? ;-) Sure. I use them daily. I'm on Arch Linux which is not shy in updates. Several updates (kernel (zen), etc.) require a reboot. 2184205 40 john.ettedgui 2022-12-12 00:03:59 +0000 (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 2184313 41 154521 ticonzero2010 2022-12-12 03:33:04 +0000 Created attachment 154521 attachment-13297-0.html It wouldn't work for me, I need to switch between different OSs and need to restart On Sun, 11 Dec 2022, 22:21 Mauro Molinari, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #38 from Mauro Molinari <mauromol@tiscali.it> --- > (In reply to Francisco Cribari from comment #37) > > It is too much work to open each of these files again every time I > > restart the computer. > > Ever heard about sleep and hibernation? ;-) > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2184345 42 imaginator 2022-12-12 09:10:02 +0000 (In reply to John E from comment #40) > (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 my view, the most obvious and promising "workaround" for an ordinary user is to continue enjoying Plasma-X11 until all major issues in Plasma-Wayland are fixed and it's ready for productive use. ;) 2184347 43 154527 ticonzero2010 2022-12-12 09:29:14 +0000 Created attachment 154527 attachment-19101-0.html I installed kubuntu 22.04LTS, that came with Wayland, how can I get back to X11-Plasma, without returning to 18.04LTS ? On Mon, 12 Dec 2022, 10:10 , <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #42 from imaginator@mailbox.org --- > (In reply to John E from comment #40) > > (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 my view, the most obvious and promising "workaround" for an ordinary > user is > to continue enjoying Plasma-X11 until all major issues in Plasma-Wayland > are > fixed and it's ready for productive use. ;) > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2184351 44 imaginator 2022-12-12 09:41:35 +0000 (In reply to ticonzero from comment #43) > Created attachment 154527 [details] > attachment-19101-0.html > > I installed kubuntu 22.04LTS, that came with Wayland, how can I get back to > X11-Plasma, without returning to 18.04LTS ? I think that's a question for the kbuntu support forum / mailing list. 2184356 45 154528 ticonzero2010 2022-12-12 10:01:59 +0000 Created attachment 154528 attachment-23823-0.html Thanks! On Mon, 12 Dec 2022, 10:41 , <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #44 from imaginator@mailbox.org --- > (In reply to ticonzero from comment #43) > > Created attachment 154527 [details] > > attachment-19101-0.html > > > > I installed kubuntu 22.04LTS, that came with Wayland, how can I get back > to > > X11-Plasma, without returning to 18.04LTS ? > I think that's a question for the kbuntu support forum / mailing list. > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2184503 46 john.ettedgui 2022-12-13 01:07:29 +0000 (In reply to imaginator from comment #42) > (In reply to John E from comment #40) > > (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 my view, the most obvious and promising "workaround" for an ordinary user > is to continue enjoying Plasma-X11 until all major issues in Plasma-Wayland > are fixed and it's ready for productive use. ;) That's what I do as well, but it's not really what I would call a workaround. 2200612 47 andihartmann 2023-01-22 17:44:26 +0000 Exactly same problem can be seen even if KDE is run in wayland mode ... . 2200613 48 andihartmann 2023-01-22 17:45:45 +0000 Please ignore my last entry - wrong ticket :-). 2214040 49 bruno 2023-03-05 14:40:39 +0000 I've been "forced" to move now to wayland to get the per screen scale factor as it will never be implemented on X11. But loosing restore session is a pain. It seems we miss a global review on plasma development, with clear objectives for each release, to make all users (and developers) happy. 2214053 50 imaginator 2023-03-05 15:02:11 +0000 (In reply to Bruno Friedmann from comment #49) > I've been "forced" to move now to wayland to get the per screen scale factor > as it will never be implemented on X11. But loosing restore session is a > pain. > It seems we miss a global review on plasma development, with clear > objectives for each release, to make all users (and developers) happy. I'm sure it holds the top position on their priority list for Plasma 6. But: who knows? ;) 2214100 51 postix 2023-03-05 18:47:55 +0000 (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 2214102 52 postix 2023-03-05 18:55:34 +0000 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 2238114 53 funtoos 2023-06-24 16:13:55 +0000 Looks like some work was started 3 months ago and then, it stopped. I tried to use wayland again to see if the experience is any better and went back to x11 after an hour of frustration. I have 4 different desktops for various projects and just restoring all my konsole windows (about 9 of them) and their tabs, and placing them in their respective places on each boot is a big pain. Let's not even talk about putting other apps where I am used to seeing them. How does a serious dev use wayland at all? I am just curious. 2238141 54 pocallaghan 2023-06-24 21:23:29 +0000 (In reply to devsk from comment #53) > Looks like some work was started 3 months ago and then, it stopped. > > I tried to use wayland again to see if the experience is any better and went > back to x11 after an hour of frustration. I have 4 different desktops for > various projects and just restoring all my konsole windows (about 9 of them) > and their tabs, and placing them in their respective places on each boot is > a big pain. Let's not even talk about putting other apps where I am used to > seeing them. > > How does a serious dev use wayland at all? I am just curious. My thoughts exactly. I've no doubt that serious devs *do* use Wayland, but I've no idea what their workflow is like. For me, session restore is an absolute requirement, so I keep feeling I must be missing something. 2238176 55 imaginator 2023-06-25 09:58:40 +0000 (In reply to Patrick O'Callaghan from comment #54) > (In reply to devsk from comment #53) > > Looks like some work was started 3 months ago and then, it stopped. > > > > I tried to use wayland again to see if the experience is any better and went > > back to x11 after an hour of frustration. I have 4 different desktops for > > various projects and just restoring all my konsole windows (about 9 of them) > > and their tabs, and placing them in their respective places on each boot is > > a big pain. Let's not even talk about putting other apps where I am used to > > seeing them. > > > > How does a serious dev use wayland at all? I am just curious. > > My thoughts exactly. I've no doubt that serious devs *do* use Wayland, but > I've no idea what their workflow is like. For me, session restore is an > absolute requirement, so I keep feeling I must be missing something. Session restore is such a basic feature nowadays that it seems crazy to even have to waste one thought on it. It *has* to be there. Like wheels on a car. If not, something went seriously wrong somewhere. My way to deal with that - IMO disappointing - Wayland-show is that I simply don't care any more. To me it doesn't offer any benefit. And as long as there's a Plasma-X11 I'm happy. 2242695 56 majzoube 2023-07-25 18:11:32 +0000 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? 2242766 57 pocallaghan 2023-07-25 21:05:59 +0000 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. 2244847 58 wdmlist 2023-08-06 20:40:53 +0000 Still an issue on Kubuntu 22.04, going to switch back to X until it is fixed. 2257086 59 majzoube 2023-10-05 20:05:01 +0000 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? 2257095 60 postix 2023-10-05 21:11:49 +0000 > 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 2264936 61 hoehnp 2023-11-11 16:04:38 +0000 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? 2264938 62 nate 2023-11-11 16:22:05 +0000 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. 2264942 63 cdennett 2023-11-11 16:38:01 +0000 Will what is planned for KDE 6 take into account multiple monitors and multiple virtual desktops so that apps start in the desired monitor/virtual desktop? 2264948 64 ticonzero2010 2023-11-11 17:01:06 +0000 That is crucial! On 11/11/23 17:38, Charles Dennett wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #63 from Charles Dennett <cdennett@gmail.com> --- > Will what is planned for KDE 6 take into account multiple monitors and multiple > virtual desktops so that apps start in the desired monitor/virtual desktop? > 2264949 65 nate 2023-11-11 17:08:11 +0000 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. 2264966 66 ol+kde 2023-11-11 18:59:52 +0000 (In reply to Charles Dennett from comment #63) > Will what is planned for KDE 6 take into account multiple monitors and > multiple virtual desktops so that apps start in the desired monitor/virtual > desktop? And please don't forget about activities! I'm tired of moving Firefox windows to different activities manually each time after login even on KDE 5 X11 session. 2268354 67 dkxls23 2023-11-25 11:52:18 +0000 (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. 2268356 68 pocallaghan 2023-11-25 12:11:45 +0000 (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. 2268630 69 msdobrescu 2023-11-26 14:07:38 +0000 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. 2270410 70 nkwkelvin 2023-12-01 21:12:14 +0000 (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? 2270506 71 bruno 2023-12-02 08:36:44 +0000 > 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. 2272227 72 hoehnp 2023-12-08 13:53:20 +0000 (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. 2272893 73 ticonzero2010 2023-12-11 08:54:38 +0000 the same here. On 02/12/23 09:36, Bruno Friedmann wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #71 from Bruno Friedmann <bruno@ioda-net.ch> --- >> 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. > 2273049 74 imaginator 2023-12-11 18:59:16 +0000 (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 that plan also apply to Plasma-6-X11 or will session restore there just keep working like in Plasma-5-X11? Thanks. 2273051 75 nkwkelvin 2023-12-11 19:21:41 +0000 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. 2275030 76 imaginator 2023-12-19 09:07:47 +0000 (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. 2275047 77 164287 ticonzero2010 2023-12-19 10:46:08 +0000 Created attachment 164287 attachment-2084366-0.html Count me among those who need reliable session restore, I'm stuck with xubuntu 20.4 and will stay there until session restore will work properly On Tue, 19 Dec 2023, 10:07 , <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #76 from imaginator@mailbox.org --- > (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. > > -- > You are receiving this mail because: > You are on the CC list for the bug. 2275313 78 nate 2023-12-20 18:16:44 +0000 (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. 2275398 79 imaginator 2023-12-20 21:17:12 +0000 (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. 2279897 80 butirsky 2024-01-12 16:12:32 +0000 *** Bug 476831 has been marked as a duplicate of this bug. *** 2291497 81 fanzhuyifan 2024-02-24 05:37:23 +0000 *** Bug 481745 has been marked as a duplicate of this bug. *** 2294714 82 nate 2024-03-04 19:26:29 +0000 Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now. 2295653 83 nate 2024-03-06 15:40:33 +0000 *** Bug 479886 has been marked as a duplicate of this bug. *** 2297011 84 kde 2024-03-08 09:06:53 +0000 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. 2297014 85 kde 2024-03-08 09:17:19 +0000 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 2297022 86 L.Bonnaud 2024-03-08 09:27:33 +0000 > 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? 2297582 87 nate 2024-03-09 00:09:58 +0000 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. 2297751 88 pocallaghan 2024-03-09 10:26:02 +0000 (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? 2298101 89 nate 2024-03-10 03:18:43 +0000 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. :) 2298203 90 L.Bonnaud 2024-03-10 09:01:05 +0000 How about using this piece of software? https://github.com/Vladimir-csp/uwsm 2301110 91 piotr.mierzwinski 2024-03-15 00:19:20 +0000 Session is restored in strange way. Firstly starts applications, so we have black screen and starting apps. and at end starts plasmashell. Second thing is that session in konsole is not restored, but in IceWm its working well. 2301545 92 niklas 2024-03-15 22:00:11 +0000 (In reply to Piotr Mierzwinski from comment #91) > Session is restored in strange way. Firstly starts applications, so we have > black screen and starting apps. and at end starts plasmashell. > Second thing is that session in konsole is not restored, but in IceWm its > working well. Applications also start in front of a black screen for me as well in 5.27 on X (and have in 5.24 as well). 2301556 93 kde 2024-03-15 22:55:48 +0000 >How about using this piece of software? That's not what's missing, that's a replacement for what we call "startkde" 2314192 94 pocallaghan 2024-04-25 11:13:05 +0000 (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. 2314193 95 postix 2024-04-25 11:15:54 +0000 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. :) 2314199 96 pocallaghan 2024-04-25 11:55:28 +0000 (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). 2314206 97 linux 2024-04-25 12:16:27 +0000 (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/ 2314209 98 pocallaghan 2024-04-25 12:36:01 +0000 (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/ 2324909 99 funtoos 2024-06-06 05:55:03 +0000 This is marked RESOLVED as FIXED for a while now. Do people have experience with the new session restore in Plasma 6? How good is it working with X11 and wayland? 2324917 100 eugene.shalygin+bugzilla.kde 2024-06-06 06:32:49 +0000 No signs of session restore as of 6.0.90 2324919 101 kde 2024-06-06 06:35:03 +0000 The hack is definitely there. It follows the systemsettings -> desktop session -> session restore settings 2324921 102 eugene.shalygin+bugzilla.kde 2024-06-06 06:54:44 +0000 It is set to "On last logout" here, but nothing gets launched on the next log in. 2324924 103 cruzki123 2024-06-06 07:14:06 +0000 Same here using Gentoo. 2324948 104 eugene.shalygin+bugzilla.kde 2024-06-06 09:04:01 +0000 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? 2324952 105 cruzki123 2024-06-06 09:26:33 +0000 Could be related, could be not but I am "loosing" configurations set in system settings since a couple of versions. Not sure when this starts to happen but sure after the release of the first "stable" version. For example, I am lousing manual file association that I have configured, the landing page of system settings is no longer showing me the last used configurations pages and the restored session is not working. These are the ones I have noticed. But the theme is correctly saved and restored, for example. Could be that these configs are stored in places that gentoo eats or has set the wrong permissions? Any log file I could check for this kind of errors? The key point is that I have recently switched to wayland. The FIRST log in, these things were working (so I have correct file associations, a correct restored session and the used last used config pages) but as soon as I reboot / log off (not sure what was the action), I lost all of them. In any case, the problem with file association and landing page of system settings is also happening on xorg (but not the restored session, that is working fine on xorg). Should I file a different bug report or do you think it could be the same problem? Should I fill this in gentoo bugtracker or here? 2324959 106 pocallaghan 2024-06-06 10:34:16 +0000 (In reply to Cruz Enrique from comment #105) > Could be related, could be not but I am "loosing" configurations set in > system settings since a couple of versions. Not sure when this starts to > happen but sure after the release of the first "stable" version. For > example, I am lousing manual file association that I have configured, the > landing page of system settings is no longer showing me the last used > configurations pages and the restored session is not working. These are the > ones I have noticed. But the theme is correctly saved and restored, for > example. Could be that these configs are stored in places that gentoo eats > or has set the wrong permissions? Any log file I could check for this kind > of errors? > > The key point is that I have recently switched to wayland. The FIRST log in, > these things were working (so I have correct file associations, a correct > restored session and the used last used config pages) but as soon as I > reboot / log off (not sure what was the action), I lost all of them. In any > case, the problem with file association and landing page of system settings > is also happening on xorg (but not the restored session, that is working > fine on xorg). > > Should I file a different bug report or do you think it could be the same > problem? Should I fill this in gentoo bugtracker or here? Please file a separate bug report. I don't think this is related. (By the way, the word you're looking for is "losing", not "loosing". Two different things. No offence but this is a common mistake). 2324962 107 pocallaghan 2024-06-06 10:38:28 +0000 (In reply to Cruz Enrique from comment #105) > Could be related, could be not but I am "loosing" configurations set in > system settings since a couple of versions. Not sure when this starts to > happen but sure after the release of the first "stable" version. For > example, I am lousing manual file association that I have configured, the > landing page of system settings is no longer showing me the last used > configurations pages and the restored session is not working. These are the > ones I have noticed. But the theme is correctly saved and restored, for > example. Could be that these configs are stored in places that gentoo eats > or has set the wrong permissions? Any log file I could check for this kind > of errors? > > The key point is that I have recently switched to wayland. The FIRST log in, > these things were working (so I have correct file associations, a correct > restored session and the used last used config pages) but as soon as I > reboot / log off (not sure what was the action), I lost all of them. In any > case, the problem with file association and landing page of system settings > is also happening on xorg (but not the restored session, that is working > fine on xorg). > > Should I file a different bug report or do you think it could be the same > problem? Should I fill this in gentoo bugtracker or here? Please file a separate bug report. I don't think this is related. (By the way, the word you're looking for is "losing", not "loosing". Two different things. No offence but this is a common mistake).(In reply to devsk from comment #99) > This is marked RESOLVED as FIXED for a while now. > > Do people have experience with the new session restore in Plasma 6? How good > is it working with X11 and wayland? Not as yet on Fedora 40, Plasma 6.0.5. I think 6.1 is expected soon and hopefully Fake Session Restore will be part of it. 2324964 108 dkxls23 2024-06-06 10:40:13 +0000 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. 2324965 109 dkxls23 2024-06-06 10:43:50 +0000 Here the link to the commit for the Fedora 40 package: https://src.fedoraproject.org/rpms/plasma-workspace/c/d03958da910f3ba08c531e7569ff40c19ca2f045?branch=f40 2324967 110 pocallaghan 2024-06-06 10:46:00 +0000 (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. 2324970 111 dkxls23 2024-06-06 10:54:54 +0000 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. 2324972 112 dkxls23 2024-06-06 11:04:32 +0000 (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 2324990 113 170201 ticonzero2010 2024-06-06 12:24:01 +0000 Created attachment 170201 attachment-3317129-0.html here I have Kubuntu 20.04 and plasmashell 5.18.8 works (almost) perfectly: - it reopens okular, konsoles, kate, thunderbird and multiple firefoxes in the same Desktops, same location, on the same files or webpage - it reopens Tekstudio in the wrong desktop with the same files open - it reopens gvim and Paraview with no file open I'm stuck with Kubuntu 20.04 because I just need this feature On 06/06/24 12:54, Armin wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #111 from Armin<dkxls23@gmail.com> --- > 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. > 2324992 114 pocallaghan 2024-06-06 12:31:32 +0000 (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. 2325012 115 imaginator 2024-06-06 13:27:39 +0000 (In reply to Armin from comment #111) > 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. "If things don't come easy, there is no premium on effort." (Branch Rickey). So why don't you just dump Plasma-Wayland and use Plasma-X11 until this essential (but nowadays rather trivial) feature is _fully_ implemented? At least from a productivity point of view a masochistic adherence to Wayland doesn't make sense. 2325017 116 imaginator 2024-06-06 13:36:33 +0000 (In reply to Patrick O'Callaghan from comment #114) > (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. What's mentioned there as "rudimentary support" for 6.1 seems to be what's described in comment 84. For me that wouldn't be enough. 2325036 117 niklas 2024-06-06 14:29:16 +0000 (In reply to ticonzero from comment #113) > Created attachment 170201 [details] > attachment-3317129-0.html > > here I have Kubuntu 20.04 and plasmashell 5.18.8 works (almost) perfectly: > > - it reopens okular, konsoles, kate, thunderbird and multiple firefoxes > in the same Desktops, same location, on the same files or webpage > > - it reopens Tekstudio in the wrong desktop with the same files open > > - it reopens gvim and Paraview with no file open > > > I'm stuck with Kubuntu 20.04 because I just need this feature You're not stuck there. Session restore (still) works on the X11 session on Plasma 5.24 (Kubuntu 22.04) and Plasma 5.27 (Kubuntu 24.04). 2325037 118 ticonzero2010 2024-06-06 14:31:02 +0000 thanks, I will give it a try On 06/06/24 16:29, Niklas Sombert wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #117 from Niklas Sombert <niklas@ytvwld.de> --- > (In reply to ticonzero from comment #113) >> Created attachment 170201 [details] >> attachment-3317129-0.html >> >> here I have Kubuntu 20.04 and plasmashell 5.18.8 works (almost) perfectly: >> >> - it reopens okular, konsoles, kate, thunderbird and multiple firefoxes >> in the same Desktops, same location, on the same files or webpage >> >> - it reopens Tekstudio in the wrong desktop with the same files open >> >> - it reopens gvim and Paraview with no file open >> >> >> I'm stuck with Kubuntu 20.04 because I just need this feature > You're not stuck there. Session restore (still) works on the X11 session on > Plasma 5.24 (Kubuntu 22.04) and Plasma 5.27 (Kubuntu 24.04). > 2325868 119 funtoos 2024-06-09 07:19:32 +0000 So, after reading the comments, it looks like it is still the "same old same old". Sticking with plasma 5 then! 2329566 120 pocallaghan 2024-06-20 10:06:09 +0000 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. 2330062 121 forums 2024-06-21 04:50:13 +0000 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. 2330087 122 funtoos 2024-06-21 06:50:06 +0000 > 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. What you are saying is that switching away and the switching back to this option made the session restore work properly for you with 6.1. Can you please confirm what all works? Does it put all your console windows with their tabs in their respective desktops? How about firefox windows? What else did you try to restore? 2330096 123 ticonzero2010 2024-06-21 07:23:16 +0000 restoring okular is also important for me On 21/06/24 08:50, devsk wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #122 from devsk <funtoos@yahoo.com> --- >> 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. > What you are saying is that switching away and the switching back to this > option made the session restore work properly for you with 6.1. > > Can you please confirm what all works? Does it put all your console windows > with their tabs in their respective desktops? How about firefox windows? > > What else did you try to restore? > 2330144 124 pocallaghan 2024-06-21 09:34:46 +0000 (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. 2330182 125 imaginator 2024-06-21 11:10:48 +0000 (In reply to Patrick O'Callaghan from comment #124) > (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). That's in line with comment 84. So still no proper session-restore for Plasma-Wayland. Clearly, this bug is not yet fixed and therefore should not be labelled as such. And to make Wayland the default for Plasma 6 with such a deficiency was a rather questionable decision which borders on self-sabotage, IMO. 2330186 126 pocallaghan 2024-06-21 11:28:08 +0000 (In reply to imaginator from comment #125) > (In reply to Patrick O'Callaghan from comment #124) > > (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). > > That's in line with comment 84. So still no proper session-restore for > Plasma-Wayland. Clearly, this bug is not yet fixed and therefore should not > be labelled as such. > > And to make Wayland the default for Plasma 6 with such a deficiency was a > rather questionable decision which borders on self-sabotage, IMO. Plasma under X11 didn't do those things correctly for me either, except possibly the tabs in Konsole. I'm not sure because I always used Autostart, which I'm intentionally not doing now, so behaviour maybe be different. 2330194 127 imaginator 2024-06-21 11:57:43 +0000 (In reply to Patrick O'Callaghan from comment #126) > (In reply to imaginator from comment #125) > > (In reply to Patrick O'Callaghan from comment #124) > > > (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). > > > > That's in line with comment 84. So still no proper session-restore for > > Plasma-Wayland. Clearly, this bug is not yet fixed and therefore should not > > be labelled as such. > > > > And to make Wayland the default for Plasma 6 with such a deficiency was a > > rather questionable decision which borders on self-sabotage, IMO. > > Plasma under X11 didn't do those things correctly for me either, except > possibly the tabs in Konsole. I'm not sure because I always used Autostart, > which I'm intentionally not doing now, so behaviour maybe be different. If session-restore also doesn't work in Plasma-6-X11 (it's always been working flawlessly for me in Plasma-5-X11) the situation would be even worse as there would be no correctly functioning alternative. For the sake of Plasma and KDE I hope that this is not the case. To give you an impression: among other things and apart from quite a few tabs in Dolphin and several instances of Konsole, Okular and Gwenview, I currently have over 20 docs open in Kate. That's not unusual for me. And would I want to re-open all that stuff _manually_ each time I have updated the kernel, for instance? In the year 2024!? I wouldn't even dream of it! 2330294 128 mmkthecoolest 2024-06-21 16:35:45 +0000 (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 2330761 129 rpbikker 2024-06-22 23:17:12 +0000 Fedora 40, KDE Plasma 6.1.0. When I login on a Wayland with my own account, I am greeted by a heap of 18 konsole and firefox windows, all stacked up on the first of my eight virtual desktops. I am the designated one to distribute and reposition them again, until next reboot. It's unusable like this. I can't use my own account under wayland, not even just for testing. The current state only really 'works' for one use case: you only have one desktop and all your windows are maximised. Granted, that's how most MS Windows users I know use their computer, so maybe it fills many people's needs. But it's not up to par with what a long time plasma/x11 user expects. Session management is very much _not_ fixed and because of this, plasma/wayland is still not ready for prime time in my workflow. 2331121 130 funtoos 2024-06-24 08:36:39 +0000 Is there more work planned for plasma 6.2 to address the issues with session restore (via another bug)? or do we need to reopen this bug and address the remaining issues via this bug? 2331129 131 dkxls23 2024-06-24 09:03:44 +0000 (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. 2331140 132 pocallaghan 2024-06-24 09:38:01 +0000 (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? 2331161 133 mmkthecoolest 2024-06-24 10:43:46 +0000 I am also in the camp that windows not remembering which desktops were in is a dealbreaker for me. I sometimes use multiple desktops in my workflow and this feature may be more tedious to deal with than having session restore disabled. I'd rather have the feature disabled and start over from each reboot than have to sort through lots of windows to their right desktops. 2331163 134 pocallaghan 2024-06-24 10:57:05 +0000 (In reply to Mustafa Kamran from comment #133) > I am also in the camp that windows not remembering which desktops were in is > a dealbreaker for me. I sometimes use multiple desktops in my workflow and > this feature may be more tedious to deal with than having session restore > disabled. I'd rather have the feature disabled and start over from each > reboot than have to sort through lots of windows to their right desktops. I defined some shortcuts (Ctrl-<N> for "send window to desktop N") but it's still tedious to have to do it for every login. 2331174 135 imaginator 2024-06-24 11:50:26 +0000 (In reply to Patrick O'Callaghan from comment #132) > (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. In this respect perhaps "Failand" might be a more suitable name. Anyway - in comment 25 I already pointed to the possibility of Wayland being the root-problem. And I guess that KDE has been aware of it since long (comment 62). But instead of using their clout as a leading Linux-DE and publicly pointing out and criticizing a glaring Wayland-deficiency they even chose Wayland as default for Plasma 6. IMO, this was a major strategic error as it not only leaves Plasma-6-users with a bad and obviously hard to fix regression but also lifted the pressure off the Wayland-devs to finally (!) provide a basic feature of modern DEs. Now it seems that Plasma-6-users are at the mercy of the Wayland-devs (comment 89). 2331229 136 dkxls23 2024-06-24 14:55:14 +0000 (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... 2331277 137 imaginator 2024-06-24 16:52:49 +0000 (In reply to Armin from comment #136) > (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... Taking the initiative and going ahead may indeed be the right move. Certainly better than wasting more time by waiting and hoping for a long overdue protocol to get approved (or not) at an unspecified point in time. 2333146 138 lassi.vaatamoinen 2024-06-28 18:18:30 +0000 (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... 2335296 139 gimmemahlulz 2024-07-06 13:52:47 +0000 Why was this bug marked resolved/fixed? It's still an issue under Wayland in plasma 6.1.1. Manually saving a session does not save all windows/apps and the ones that do reopen on the wrong desktops. Simply putting the onus on wayland to "hopefully" fix it is not a solution. 2351810 140 bdk 2024-09-06 02:27:47 +0000 Maybe we should change the severity of this bug to CRITICAL. 2351811 141 funtoos 2024-09-06 02:47:28 +0000 Gentoo sort of forced me to update to latest plasma by deprecating some of the packages because of dependency hell. And now, the X11 session restore is broken....:-( 2351893 142 bdk 2024-09-06 13:45:06 +0000 (In reply to devsk from comment #141) > Gentoo sort of forced me to update to latest plasma by deprecating some of > the packages because of dependency hell. > > And now, the X11 session restore is broken....:-( Not sure about Gentoo, but for Fedora, there is no X11, Wayland is the default. X11 only apps are handled by a bridge. Even before this the Wayland session restore was broken. The X11 session restore was broken but was fixed some time ago. With Wayland some applications are not restored at all and onlers are all restored to the first virtual desktop. Had I known the session restore was not fixed in wayland I never would have upgraded to Fedora 40 from 39 2351895 143 4wy78uwh 2024-09-06 13:50:51 +0000 (In reply to Brian Kaye from comment #142) The X11 package still exists for Fedora - see https://www.reddit.com/r/Fedora/comments/1cbgria/comment/l1dor96/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button - it's merely not included by default. 2351902 144 equeim 2024-09-06 13:57:48 +0000 (In reply to Brian Kaye from comment #142) > (In reply to devsk from comment #141) > > Gentoo sort of forced me to update to latest plasma by deprecating some of > > the packages because of dependency hell. > > > > And now, the X11 session restore is broken....:-( > > Not sure about Gentoo, but for Fedora, there is no X11, Wayland is the > default. X11 only apps are handled by a bridge. Even before this the Wayland > session restore was broken. The X11 session restore was broken but was fixed > some time ago. > > With Wayland some applications are not restored at all and onlers are all > restored to the first virtual desktop. Had I known the session restore was > not fixed in wayland I never would have upgraded to Fedora 40 from 39 That's Fedora's own initiative. Fedora's mission is to "lead the charge" on innovations even if it breaks some people's workflows. Plasma 6 still supports X11 session and there are more conservative distros that aim to support X11 (IDK if they upgraded to Plasma 6 yet though). 2351903 145 4wy78uwh 2024-09-06 13:59:12 +0000 (In reply to equeim from comment #144) openSUSE Tumbleweed has upgraded to Plasma 6, yet retained its XOrg 11 session. 2351906 146 pocallaghan 2024-09-06 14:01:04 +0000 (In reply to Brian Kaye from comment #142) > (In reply to devsk from comment #141) > > Gentoo sort of forced me to update to latest plasma by deprecating some of > > the packages because of dependency hell. > > > > And now, the X11 session restore is broken....:-( > > Not sure about Gentoo, but for Fedora, there is no X11, Wayland is the > default. X11 only apps are handled by a bridge. Even before this the Wayland > session restore was broken. The X11 session restore was broken but was fixed > some time ago. > > With Wayland some applications are not restored at all and onlers are all > restored to the first virtual desktop. Had I known the session restore was > not fixed in wayland I never would have upgraded to Fedora 40 from 39 IIRC this was discussed on the Fedora KDE mailing list (by me and others) before F40 was released. I hate it but I go along with it because the alternative is to eventually fall out of support shortly after F41 comes out. I currently have shortcuts to move my (many) open windows to the right desktops. My main issue is with Dolphin not remembering the state of each of its open windows, but I suspect session restore on its own isn't going to fix that. See https://bugs.kde.org/show_bug.cgi?id=455324 2351942 147 msdobrescu 2024-09-06 15:58:45 +0000 Indeed, this is the last thing keeping me from using Wayland! I'd be happy with dolphin restoring for the beginning. 2351946 148 pocallaghan 2024-09-06 16:29:36 +0000 (In reply to Mihai Sorin Dobrescu from comment #147) > Indeed, this is the last thing keeping me from using Wayland! > I'd be happy with dolphin restoring for the beginning. Dolphin doesn't restore properly on X11 either. 2351947 149 imaginator 2024-09-06 16:47:42 +0000 I'm also having this problem in the X11-session of Plasma-5.27.11 (with security-update plasma-workspace-5.27.11.1). The symptoms are the same as described several times already. Just KDE-apps are restored but only in their native state, that is without previously opened documents etc. Now even the the latest version of Plasma 5 is completely unusable. What a dire story. 2351959 150 msdobrescu 2024-09-06 17:41:32 +0000 (In reply to Patrick O'Callaghan from comment #148) > (In reply to Mihai Sorin Dobrescu from comment #147) > > Indeed, this is the last thing keeping me from using Wayland! > > I'd be happy with dolphin restoring for the beginning. > > Dolphin doesn't restore properly on X11 either. Currently, having the following configuration, Dolphin restores good enough, meaning it loses only its windows positions, but keeps all the opened paths, split views etc.. Operating System: MocaccinoOS (Gentoo) KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.116.0 Qt Version: 5.15.14 Kernel Version: 6.6.47-mocaccino (64-bit) Graphics Platform: X11 Processors: 16 × 11th Gen Intel® Core™ i7-11700K @ 3.60GHz Memory: 61.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 Manufacturer: ASUS 2351960 151 cdennett 2024-09-06 17:47:58 +0000 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. 2351981 152 pocallaghan 2024-09-06 21:29:54 +0000 (In reply to Charles Dennett from comment #151) > 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. AFAIK this wouldn't solve the "multiple Dolphin windows" problem. To summarise: I have 3 Dolphin windows, all on the same desktop. Window A has two panes, each in a different directory. Window B also has two panes, each in a different directory. Window C has a single pane but an open terminal and is in yet another directory. On session restore, all three windows are identical copies of *one* of A, B or C. Which one it happens to be is essentially random, though it might be the one that happened to be on top last time. When I first reported this over two years ago I was using X11. AFAIK the bug has received no attention in the interim. (This should really be discussed on the other report already linked above). 2352080 153 imaginator 2024-09-07 11:33:05 +0000 (In reply to Patrick O'Callaghan from comment #152) > (In reply to Charles Dennett from comment #151) > > 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. > > AFAIK this wouldn't solve the "multiple Dolphin windows" problem. To > summarise: > > I have 3 Dolphin windows, all on the same desktop. Window A has two panes, > each in a different directory. Window B also has two panes, each in a > different directory. Window C has a single pane but an open terminal and is > in yet another directory. > > On session restore, all three windows are identical copies of *one* of A, B > or C. Which one it happens to be is essentially random, though it might be > the one that happened to be on top last time. "Thunar" keeps the settings after (Plasma-) session-restore, just checked your use case. It doesn't have an integrated terminal, though. 2352084 154 pocallaghan 2024-09-07 12:21:59 +0000 (In reply to imaginator from comment #153) [...] > > I have 3 Dolphin windows, all on the same desktop. Window A has two panes, > > each in a different directory. Window B also has two panes, each in a > > different directory. Window C has a single pane but an open terminal and is > > in yet another directory. > > > > On session restore, all three windows are identical copies of *one* of A, B > > or C. Which one it happens to be is essentially random, though it might be > > the one that happened to be on top last time. > "Thunar" keeps the settings after (Plasma-) session-restore, just checked > your use case. It doesn't have an integrated terminal, though. I just tried it, but no. After saving the session and re-logging in, Thunar is not restored and when I start it manually it doesn't recover the saved sessions. I haven't tried it with Auto-start. I note that it does have an "open terminal here" option (which currently fails because of some setting). I presume it doesn't open a new pane in the same window, though that wouldn't be critical. 2352086 155 imaginator 2024-09-07 12:40:14 +0000 (In reply to Patrick O'Callaghan from comment #154) > (In reply to imaginator from comment #153) > [...] > > > I have 3 Dolphin windows, all on the same desktop. Window A has two panes, > > > each in a different directory. Window B also has two panes, each in a > > > different directory. Window C has a single pane but an open terminal and is > > > in yet another directory. > > > > > > On session restore, all three windows are identical copies of *one* of A, B > > > or C. Which one it happens to be is essentially random, though it might be > > > the one that happened to be on top last time. > > "Thunar" keeps the settings after (Plasma-) session-restore, just checked > > your use case. It doesn't have an integrated terminal, though. > > I just tried it, but no. After saving the session and re-logging in, Thunar > is not restored and when I start it manually it doesn't recover the saved > sessions. I haven't tried it with Auto-start. I note that it does have an Sorry. Perhaps we are using different Plasma-versions. I reverted to -5.27.11 where session-restore does work for X11 (it does _not_ in -5.27.11.1). And here Thunar-4.18.6 behaves as described. > "open terminal here" option (which currently fails because of some setting). > I presume it doesn't open a new pane in the same window, though that > wouldn't be critical. Actually Thunar does offer split windows. And for the one window where you need the integrated terminal you could use Dolphin. Good luck! 2352243 156 pocallaghan 2024-09-08 09:12:53 +0000 (In reply to imaginator from comment #155) [...] > > "open terminal here" option (which currently fails because of some setting). > > I presume it doesn't open a new pane in the same window, though that > > wouldn't be critical. > Actually Thunar does offer split windows. And for the one window where you > need the integrated terminal you could use Dolphin. Yes, I know Thunar has horizontally split panes. I meant that a terminal wouldn't open in a new horizontal pane in the same window, as with Dolphin. However this is a minor point. 2353815 157 qydwhotmail 2024-09-14 13:22:08 +0000 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 2354490 158 msdobrescu 2024-09-15 07:53:43 +0000 (In reply to Fushan Wen from comment #157) > 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 Hi, I've just tried this on Plasma 6.2 Dev on KDE Neon. The build was done from scratch issuing kde-builder --refresh-build workspace --ignore-modules sddm-kcm (SDDM KCM module fails at build but it's not essential here). I've got the following behavior: - left a Dolphin open at logoff/shutdown - logged in back with a Wayland session - Dolphin opened at login, but maximized on the screen - left a Dolphin open at logoff/shutdown once more - logged in back - no Dolphin anymore 2355152 159 qydwhotmail 2024-09-17 08:15:36 +0000 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 2355791 160 ticonzero2010 2024-09-18 11:57:34 +0000 so is it fixed now? If I install kubuntu 24.04, and the necessary updates, will I have full session restore ? On 17/09/24 17:46, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > Nate Graham <nate@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Version Fixed In|6.2 |6.2.0 > 2355792 161 nate 2024-09-18 12:06:17 +0000 If Kubuntu 24.04 ships Plasma 6.2.0, then yes, unless the change that fixed this didn't actually work. 2355801 162 ticonzero2010 2024-09-18 12:21:14 +0000 what distro should I install to get session restore working? or can I install Plasma 6.2.0 on top of Kubuntu 24.04 ? On 18/09/24 14:06, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=436318 > > --- Comment #161 from Nate Graham <nate@kde.org> --- > If Kubuntu 24.04 ships Plasma 6.2.0, then yes, unless the change that fixed > this didn't actually work. > 2355802 163 nate 2024-09-18 12:22:35 +0000 There are over 100 people CCd on this bug report, and every comment sends all of them an email. So I would recommend taking installation and versioning questions like those elsewhere — for example to https://discuss.kde.org. Thanks a lot! 2357846 164 bvbfan 2024-09-21 05:55:45 +0000 I wonder why there is extra button for save session since this is the button for leave session when configuration is restore previous session? 2358104 165 kishore96 2024-09-22 09:58:30 +0000 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 2358379 166 imaginator 2024-09-23 08:59:40 +0000 (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/ 2358384 167 pocallaghan 2024-09-23 09:10:28 +0000 (In reply to imaginator from comment #166) > (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. IMHO the bug is definitely not Resolved. Save/Restore session continues to be an unimplemented feature. I appreciate Nate's efforts with regard to "fake session restore" but it is a stopgap, not a genuine solution. 2358418 168 imaginator 2024-09-23 11:26:18 +0000 (In reply to Patrick O'Callaghan from comment #167) > (In reply to imaginator from comment #166) > > (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. > > IMHO the bug is definitely not Resolved. Save/Restore session continues to > be an unimplemented feature. I appreciate Nate's efforts with regard to > "fake session restore" but it is a stopgap, not a genuine solution. Well, you reported this bug. And if you think that it is still not resolved then re-open it. I'm pretty sure that the vast majority of people on the cc-list would support and appreciate that move. However, it would be better if the assignee(s) reopened it. Doing so would be the most sensible thing anyway for anyone who has understood what this bug-report is about. It would also display some respect for their users and that they are not trying to lead them down the garden path. 2358420 169 pocallaghan 2024-09-23 11:34:25 +0000 (In reply to imaginator from comment #168) > (In reply to Patrick O'Callaghan from comment #167) > > (In reply to imaginator from comment #166) > > > (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. > > > > IMHO the bug is definitely not Resolved. Save/Restore session continues to > > be an unimplemented feature. I appreciate Nate's efforts with regard to > > "fake session restore" but it is a stopgap, not a genuine solution. > > Well, you reported this bug. And if you think that it is still not resolved > then re-open it. I'm pretty sure that the vast majority of people on the > cc-list would support and appreciate that move. > > However, it would be better if the assignee(s) reopened it. Doing so would > be the most sensible thing anyway for anyone who has understood what this > bug-report is about. It would also display some respect for their users and > that they are not trying to lead them down the garden path. Done. I also edited the title to make it clear that it covers Resume as well as Save. 2365327 170 bdk 2024-10-12 20:23:21 +0000 Session restore still not fixed with plasma 6.2 rpms on Fedora FC40. 2373063 171 bdk 2024-11-09 18:19:51 +0000 Still not fixed with plasma 6.2.3-1 rpms on Fedora 31. Sessions still restored to first virtual desktop. A pain but they are at least restored somewhere. 2373656 172 nate 2024-11-12 15:16:14 +0000 That's something else: Bug 482816. 2373727 173 bdk 2024-11-12 16:49:16 +0000 (In reply to Brian Kaye from comment #171) > Still not fixed with plasma 6.2.3-1 rpms on Fedora 31. Sessions still > restored to first virtual desktop. A pain but they are at least restored > somewhere. Typo. Shoul refer to Fedora 31 rpms 2373734 174 bdk 2024-11-12 16:54:40 +0000 Should be Fedora 41 RPMS. I am a lousy typer :-). Would be nice to edit a comment. 2373741 175 nate 2024-11-12 17:36:38 +0000 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! 2373747 176 eugene.shalygin+bugzilla.kde 2024-11-12 17:44:46 +0000 (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. 2373764 177 nate 2024-11-12 18:08:14 +0000 Good call, I forgot to do that. Thanks. 2376958 178 nate 2024-11-25 20:20:59 +0000 *** Bug 496674 has been marked as a duplicate of this bug. *** 2382795 179 nate 2024-12-19 18:04:22 +0000 *** Bug 471977 has been marked as a duplicate of this bug. *** 2388481 180 null 2025-01-10 19:03:00 +0000 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. 2391629 181 pocallaghan 2025-01-22 13:05:21 +0000 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 ------ 2391648 182 4wy78uwh 2025-01-22 14:15:03 +0000 (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. 2391654 183 pocallaghan 2025-01-22 15:00:19 +0000 (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 2393207 184 funtoos 2025-01-28 08:35:34 +0000 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? 2393320 185 null 2025-01-28 17:19:21 +0000 (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? 2393375 186 funtoos 2025-01-28 20:02:41 +0000 > 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 2393511 187 peter 2025-01-29 11:21:58 +0000 (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. 2393524 188 imaginator 2025-01-29 12:36:09 +0000 (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). 2393558 189 peter 2025-01-29 14:37:52 +0000 (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." 2393594 190 imaginator 2025-01-29 16:49:07 +0000 (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. 2393596 191 imaginator 2025-01-29 16:54:11 +0000 (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. 2393602 192 andihartmann 2025-01-29 17:08:14 +0000 (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. 2393627 193 imaginator 2025-01-29 18:26:02 +0000 (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. 2394317 194 pocallaghan 2025-02-01 13:31:51 +0000 (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. 2396015 195 imaginator 2025-02-08 16:14:03 +0000 (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= [...] 2396164 196 pocallaghan 2025-02-09 10:39:28 +0000 (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. 2396186 197 imaginator 2025-02-09 12:11:01 +0000 (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. 2396199 198 4wy78uwh 2025-02-09 13:52:47 +0000 (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. 2396213 199 pocallaghan 2025-02-09 15:10:39 +0000 (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. 2400237 200 bdk 2025-02-19 16:45:14 +0000 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. 2404765 201 funtoos 2025-03-05 00:53:15 +0000 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 2404779 202 funtoos 2025-03-05 03:26:25 +0000 (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. 2404882 203 pocallaghan 2025-03-05 12:23:26 +0000 (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. 2405015 204 funtoos 2025-03-05 17:02:17 +0000 (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. 2405056 205 pocallaghan 2025-03-05 17:57:47 +0000 (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). 2405066 206 pocallaghan 2025-03-05 18:13:55 +0000 (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. 2405273 207 funtoos 2025-03-06 04:12:50 +0000 (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. 2405328 208 pocallaghan 2025-03-06 11:31:29 +0000 (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. 2405562 209 funtoos 2025-03-06 23:19:04 +0000 > 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. 2405644 210 pocallaghan 2025-03-07 11:24:35 +0000 (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. 2406552 211 kmg952 2025-03-10 23:28:42 +0000 Can someone please give a status update on Wayland's progress on the protocol mentioned in Comment #89? 2406559 212 eugene.savitsky 2025-03-11 00:13:52 +0000 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 I believe this is the protocol of the topic. Turned 5 years now. Hurray, happy anniversary! :-/ 2406560 213 eugene.savitsky 2025-03-11 00:21:53 +0000 Some coverage: https://www.youtube.com/watch?v=UAMAlqqVijY 2406632 214 imaginator 2025-03-11 09:31:41 +0000 (In reply to Eugene Savitsky from comment #212) > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 > > I believe this is the protocol of the topic. Turned 5 years now. Hurray, > happy anniversary! :-/ What are 5 years in the ocean of time. :) 2407473 215 funtoos 2025-03-14 06:08:42 +0000 (In reply to Kevin Gilbert from comment #211) > Can someone please give a status update on Wayland's progress on the > protocol mentioned in Comment #89? That can only happen if someone was working on it. Nobody is. The presence of this bug gives that wrong impression. I gave up on this bug ever getting fixed. That's why I ended up writing the set of elaborate shell functions I wrote. They do most of the work for session restore for me and I have been super happy with that. It works better than both the x11 and wayland restore in KDE right now. 2407508 216 kde 2025-03-14 09:14:54 +0000 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. 2407707 217 funtoos 2025-03-14 21:10:57 +0000 (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. 2410410 218 akontsevich 2025-03-25 07:24:49 +0000 (In reply to devsk from comment #217) > (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. > > > 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. Seems not stopped, and still have some activity and progress: https://www.youtube.com/watch?v=UAMAlqqVijY https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18#note_2657667 However not clear: roadmap, blockers, estimate, etc. Open source projects sometime lacks such info. > > This is the part that's in progress in xdg-desktop-portals and why the > > Wayland part is seemingly stuck. Any wiki, forum, info where we can track progress. problems? Modern tendencies forces us to switch to wayland, however many important features are still missed and a lot of Known Significant Issues exists: https://community.kde.org/Plasma/Wayland_Known_Significant_Issues 2410421 219 4wy78uwh 2025-03-25 10:43:33 +0000 (In reply to Aleksey Kontsevich from comment #218) > However not clear: roadmap, blockers, estimate, etc. Open source projects sometime lacks such info. As you've just stated, https://invent.kde.org/plasma/kwin/-/milestones would be usable if there were milestones for this. If you want it to be used, I'd suggest you posit it in Discourse in the Brainstorm category, because that, if it *is* a problem, evidently affects more than solely this ticket. > Any wiki, forum, info where we can track progress. problems? If this issue really isn't enough, you can watch the MediaWiki page at https://community.kde.org/index.php?title=Plasma/Wayland_Known_Significant_Issues&oldid=103027#Waiting_on_new_Wayland_protocol:~:text=Upstream%5Bedit%5D,Hibernation%20(Suspend%20To%20Disk)%20instead. https://community.kde.org/index.php?title=Plasma/Next/SessionManagement&oldid=35103#Integration_Story_2:~:text=Started%20by%20the%20startkde%20script%2C,kwin%20in%20kwin's%20session%20file *might* work too, but I'd doubt that it'll ever change. Please just stop spamming for updates, everyone who is. You'll get them when you see a commit comment from the Bug Janitor Service. 2410462 220 imaginator 2025-03-25 13:54:36 +0000 (In reply to Roke Julian Lockhart Beedell from comment #219) > (In reply to Aleksey Kontsevich from comment #218) > > However not clear: roadmap, blockers, estimate, etc. Open source projects sometime lacks such info. > > As you've just stated, https://invent.kde.org/plasma/kwin/-/milestones would > be usable if there were milestones for this. If you want it to be used, I'd > suggest you posit it in Discourse in the Brainstorm category, because that, > if it *is* a problem, evidently affects more than solely this ticket. > > > Any wiki, forum, info where we can track progress. problems? > > If this issue really isn't enough, you can watch the MediaWiki page at > https://community.kde.org/index.php?title=Plasma/ > Wayland_Known_Significant_Issues&oldid=103027#Waiting_on_new_Wayland_protocol > :~:text=Upstream%5Bedit%5D,Hibernation%20(Suspend%20To%20Disk)%20instead. > https://community.kde.org/index.php?title=Plasma/Next/ > SessionManagement&oldid=35103#Integration_Story_2:~: > text=Started%20by%20the%20startkde%20script%2C, > kwin%20in%20kwin's%20session%20file *might* work too, but I'd doubt that > it'll ever change. > > Please just stop spamming for updates, everyone who is. You'll get them when > you see a commit comment from the Bug Janitor Service. You don't seem to realize the gravity of the situation. The sheer number of people on cc should give you an idea. But I guarantee you that this is only the tip of the iceberg. This bug is critical and several years old already. It's a real strain on users' nerves. There's no noticeable progress. And other than this thread practically no information. No wonder patience is coming to an end. Thus, instead of brushing off legitimate requests for information as *spamming* and expecting users to just shut up, sit still and wait in awe for comments from the Bug Janitor Service, I suggest you either significantly increase your efforts to find a solution for this or at least re-evaluate your communication policy and your attitude towards yet loyal users. If you don't want to go under, that is. Thanks. 2410464 221 4wy78uwh 2025-03-25 14:09:01 +0000 (In reply to imaginator from comment #220) > I suggest you either significantly increase your efforts to find a solution for this or at least re-evaluate your communication policy and your attitude towards yet loyal users. I don't represent KDE. Where did you get that from?! I just don't want my mailbox filled with whining. Asking for updates here, no matter how much it annoys any of us, provides 0 help to the developers working on it. The relevant FreeDesktop and KDE GitLab URIs have already been provided. If you register accounts there and subscribe to the threads, you'll receive updates. I get them every few months when a few new commits are pushed. To summarise, you can subscribe to: 1. https://community.kde.org/index.php?title=Plasma/Wayland_Known_Significant_Issues 2. https://bugs.kde.org/show_bug.cgi?id=436318#c0 3. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 4. https://invent.kde.org/plasma/kwin/-/issues/113 Certainly, continue to post greivances here, if you wish (they're much better put here than there), but try to *add something*. This is an >200-comment thread, so most things you can think of have already been said. 2410495 222 imaginator 2025-03-25 16:27:16 +0000 (In reply to Roke Julian Lockhart Beedell from comment #221) > (In reply to imaginator from comment #220) > > I suggest you either significantly increase your efforts to find a solution for this or at least re-evaluate your communication policy and your attitude towards yet loyal users. > > I don't represent KDE. Where did you get that from?! I just don't want my I inferred that from the kind of and wording of your reply to a user who was simply asking for information. > mailbox filled with whining. Asking for updates here, no matter how much it > annoys any of us, provides 0 help to the developers working on it. Who's "whining" here? Most are just seeking information that is hard to find elsewhere. Some opposed attempts to prematurely close this bug. Others contributed (partial) workarounds. I can't see anything wrong in that. Indeed, I found that more instructive and constructive than the sound of silence from the "officials". > > The relevant FreeDesktop and KDE GitLab URIs have already been provided. If > you register accounts there and subscribe to the threads, you'll receive > updates. I get them every few months when a few new commits are pushed. To > summarise, you can subscribe to: > > 1. > https://community.kde.org/index.php?title=Plasma/ > Wayland_Known_Significant_Issues > 2. https://bugs.kde.org/show_bug.cgi?id=436318#c0 > 3. > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 > 4. https://invent.kde.org/plasma/kwin/-/issues/113 > > Certainly, continue to post greivances here, if you wish (they're much > better put here than there), but try to *add something*. This is an > >200-comment thread, so most things you can think of have already been said. Again, I don't like your deprecating wording and I find it completely unfitting. Contributions to deal with this mess have been made, by me and others and if you can't rate that as "something added", so be it. But one cannot expect the users here to solve a bug that so far has been unsolvable for the experts. And BTW: what have _you_ added to solve this? I consider my reply to your post indeed a contribution as it hopefully brought it home to the KDE-guys that this is a _huge_ problem and that they urgently need to do something about it or at least improve their communication. Just hushing this up is not going to work much longer. But if you don't like being bothered by "whinings" or "grievances" like that, simply take yourself off the cc-list. 2410507 223 4wy78uwh 2025-03-25 16:58:27 +0000 (In reply to imaginator from comment #222) You may be correct, but this isn't the place to discuss grievances with a specific person. For the sake of everyone else's mailbox, if you want to discuss this, PM me on Discourse. I posted my comment to consolidate the relevant tracking URIs into a single comment. 2410513 224 akontsevich 2025-03-25 17:47:13 +0000 David Edmundson is it resolved? What Plasma version? How to test? Is it the same session restore like in X11, or better, or some fake restore? Could You explain please? Thanks! 2410578 225 bdk 2025-03-25 21:36:59 +0000 What does a "Status: Closed Later" mean? 2410599 226 bdk 2025-03-25 22:30:18 +0000 Maybe the resolution description is too broad. Perhaps if the problem is broken down into smaller pieces some of he users would be satisfied withe some of the steps toward the final objective. For me the first piece would be to restore the windows to the proper desktop(s). I realize there are subsets to the solution like same window on multiple desktops, of multiple instances of the application in the same window. But first define the end objective and prioritize the steps to get there. As a part of this does anyone know what is the format of the session save file? To restore you first have to save the current information correctly. 2410665 227 funtoos 2025-03-26 03:31:59 +0000 > David Edmundson is it resolved? > What does a "Status: Closed Later" mean? Now that you guys have pissed off the main developer, whatever implementation was coming in the spring is now off the table. just kidding....:-) Nothing was coming this spring. All David had to do was to remove himself from the CC list and he would be fine. But he had to use his developer hammer. The patience and the kindness comes difficult these days! In the meantime, I made a change to my code snippet to match the title with regex because I realized that if the title of the window had some information that was variable (e.g. a tab in firefox has yahoo mail and N unread messages, and next moment it is N+10), it won't restore it correctly. In case you want a poor man's session restore: https://gist.github.com/devsk/9eff2d08d6cd5772afd2b178930b66ae PS: This feature will require a fresh, young (think college grad) set of eyes and will come in due time, and when it comes, it will come fast! I am very hopeful. 2414694 228 nate 2025-04-10 16:40:53 +0000 With https://invent.kde.org/plasma/kwin/-/merge_requests/7475, preliminary support for session restore has been merged for Plasma 6.4! This implements the WIP wayland protocol at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. Since the protocol itself is WIP, things could change, and support should be considered somewhat experimental at the moment. Also keep in mind that since it's a new protocol, toolkits and apps need to opt into it. So don't expect everything to immediately start working as soon as you upgrade to Plasma 6.4. Support from apps should start trickling in over time, likely with KDE apps leading the way. There's still an open question as to what we do with apps that haven't opted in yet. This is still being discussed. Regardless, things are moving! Thanks for your patience here, everyone. Soon our long national nightmare of no session restore on Wayland will be over. :) 2414816 229 pocallaghan 2025-04-10 21:09:32 +0000 (In reply to Nate Graham from comment #228) > With https://invent.kde.org/plasma/kwin/-/merge_requests/7475, preliminary > support for session restore has been merged for Plasma 6.4! > > This implements the WIP wayland protocol at > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. > Since the protocol itself is WIP, things could change, and support should be > considered somewhat experimental at the moment. > > Also keep in mind that since it's a new protocol, toolkits and apps need to > opt into it. So don't expect everything to immediately start working as soon > as you upgrade to Plasma 6.4. Support from apps should start trickling in > over time, likely with KDE apps leading the way. There's still an open > question as to what we do with apps that haven't opted in yet. This is still > being discussed. > > Regardless, things are moving! Thanks for your patience here, everyone. Soon > our long national nightmare of no session restore on Wayland will be over. :) That's encouraging news. Does this mean that at least window placement on desktops will start working, even if individual windows don't restore their state? 2414823 230 funtoos 2025-04-10 22:14:52 +0000 (In reply to Patrick O'Callaghan from comment #229) > (In reply to Nate Graham from comment #228) > > With https://invent.kde.org/plasma/kwin/-/merge_requests/7475, preliminary > > support for session restore has been merged for Plasma 6.4! > > > > This implements the WIP wayland protocol at > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. > > Since the protocol itself is WIP, things could change, and support should be > > considered somewhat experimental at the moment. > > > > Also keep in mind that since it's a new protocol, toolkits and apps need to > > opt into it. So don't expect everything to immediately start working as soon > > as you upgrade to Plasma 6.4. Support from apps should start trickling in > > over time, likely with KDE apps leading the way. There's still an open > > question as to what we do with apps that haven't opted in yet. This is still > > being discussed. > > > > Regardless, things are moving! Thanks for your patience here, everyone. Soon > > our long national nightmare of no session restore on Wayland will be over. :) > > That's encouraging news. Does this mean that at least window placement on > desktops will start working, even if individual windows don't restore their > state? Properties like desktop number, window position and window size should all be independent of the apps opting in. kwin controls these. This is 95% of the way there. Its the internal state of the app, like how many tabs of konsole in a window on desktop 3 or which file in kate on desktop 1 was open last, that will take some work on the app side. Nate, is my understanding correct? PS: Thanks for this much needed update! And thanks to David for working on the PR. Appreciate your efforts! 2414885 231 m.kurz 2025-04-11 06:28:59 +0000 > Properties like desktop number, window position and window size should all be independent of the apps opting in. kwin controls these. This is 95% of the way there. Does kwin also control which activity a windows was placed in? 2415162 232 nate 2025-04-11 18:48:31 +0000 To clarify: - The protocol is implemented; support for it needs to be added app-by-app. - The protocol currently supports window geometry, positioning, and virtual desktop but not actual in-app content. I don't know of the status for Activities. - In-app content restoration is also planned, and will come later. 2415182 233 postix 2025-04-11 20:14:45 +0000 Thanks for the update Nate! (In reply to Nate Graham from comment #232) > - The protocol is implemented; support for it needs to be added app-by-app. If there is a Wiki page, which enlists all apps and their current state of implementation (fully supported, partially supported, planned), it would be great to link it here, otherwise I'd make sense to create one I'd say. 2415217 234 nate 2025-04-11 21:27:35 +0000 It's a bit more complicated than that. We can probably opt all KDE apps into the window sizing and positioning stuff all at once by changing something in they all use. Individual KDE apps that do have additional state to save will need to opt into saving it one by one, and also only after the Wayland protocol supports this. 3rd-party apps are in a similar boats; for example GNOME may also be able to opt all their apps in all at once, but would need individual apps to opt into saving their app-specific states. Non-GNOME GTK apps will likely need to be opted into each individual thing one by one. The situation with other toolkits like Electron isn't clear to me. A wiki page with all this information sounds like a massive coordination project to undertake. Also it's not really KDE-specific, so it should probably be done somewhere upstream. Personally I don't have the bandwidth for a project like, so someone else would need to give that a go. If anyone else wants to work on it, please feel free! 2415371 235 kde 2025-04-12 14:21:09 +0000 There's a lot of confusion still. The protocol on it's own does not help with apps restoring their position size or desktop *even if* the app opted into this protocol. It would still need to know it's restoring an older state which means we it goes hand-in-hand with the in-app content restoration protocol. It it not a user-facing useful step on it's own. 2429465 236 pocallaghan 2025-06-01 13:36:58 +0000 (In reply to Nate Graham from comment #228) > With https://invent.kde.org/plasma/kwin/-/merge_requests/7475, preliminary > support for session restore has been merged for Plasma 6.4! > > This implements the WIP wayland protocol at > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. > Since the protocol itself is WIP, things could change, and support should be > considered somewhat experimental at the moment. > > Also keep in mind that since it's a new protocol, toolkits and apps need to > opt into it. So don't expect everything to immediately start working as soon > as you upgrade to Plasma 6.4. Support from apps should start trickling in > over time, likely with KDE apps leading the way. There's still an open > question as to what we do with apps that haven't opted in yet. This is still > being discussed. > > Regardless, things are moving! Thanks for your patience here, everyone. Soon > our long national nightmare of no session restore on Wayland will be over. :) Is this actually usable now? In the various announcements for Plasma 6.4 I haven't noticed any mention of it. 2431838 237 nate 2025-06-10 16:11:33 +0000 *** Bug 503259 has been marked as a duplicate of this bug. *** 2436992 238 nate 2025-06-27 19:03:10 +0000 With https://codereview.qt-project.org/c/qt/qtbase/+/649886, support has landed in Qt 6.10 for real Wayland session restore. This means that KDE apps can start opting in, and then they can benefit from *real* session restore when built against Qt 6.10. To be clear: nothing user-facing will visibly change until KDE apps opt in and are running on top of Qt 6.10. Non-KDE apps will also be able to open in once they or their UI toolkit implements support for the xx-session-management-v1protocol. 2437018 239 pocallaghan 2025-06-27 21:31:00 +0000 (In reply to Nate Graham from comment #238) > With https://codereview.qt-project.org/c/qt/qtbase/+/649886, support has > landed in Qt 6.10 for real Wayland session restore. > > This means that KDE apps can start opting in, and then they can benefit from > *real* session restore when built against Qt 6.10. > > To be clear: nothing user-facing will visibly change until KDE apps opt in > and are running on top of Qt 6.10. > > Non-KDE apps will also be able to open in once they or their UI toolkit > implements support for the xx-session-management-v1protocol. To clarify: does this mean that only apps which have opted in will have their desktop and window positions restored? Not talking about window contents, which does of course req 2437026 240 akontsevich 2025-06-27 22:31:07 +0000 (In reply to Patrick O'Callaghan from comment #239) > (In reply to Nate Graham from comment #238) > > With https://codereview.qt-project.org/c/qt/qtbase/+/649886, support has > > landed in Qt 6.10 for real Wayland session restore. > > > > This means that KDE apps can start opting in, and then they can benefit from > > *real* session restore when built against Qt 6.10. > > > > To be clear: nothing user-facing will visibly change until KDE apps opt in > > and are running on top of Qt 6.10. > > > > Non-KDE apps will also be able to open in once they or their UI toolkit > > implements support for the xx-session-management-v1protocol. > > To clarify: does this mean that only apps which have opted in will have > their desktop and window positions restored? Not talking about window > contents, which does of course req Yep, not clear: under X11 all app are restored regardless they support session management or not. 2437045 241 lassi.vaatamoinen 2025-06-28 03:41:42 +0000 (In reply to Aleksey Kontsevich from comment #240) > Yep, not clear: under X11 all app are restored regardless they support > session management or not. What do you find unclear here? In X11, it is the X11 session management which is responsible of keeping track of which applications belong to a session. In Wayland, it is up to the application to remember that it belongs to a session. 2437100 242 akontsevich 2025-06-28 10:40:52 +0000 (In reply to Lassi Väätämöinen from comment #241) > (In reply to Aleksey Kontsevich from comment #240) > > > Yep, not clear: under X11 all app are restored regardless they support > > session management or not. > > What do you find unclear here? In X11, it is the X11 session management > which is responsible of keeping track of which applications belong to a > session. > > In Wayland, it is up to the application to remember that it belongs to a > session. I do not much care how Wayland/X11 algorithm works, I'm curious if I get the same result/behavior in Wayland comparing to X11. Seems not! So do not push us to migrate to weird buggy Wayalnd. 2437104 243 pocallaghan 2025-06-28 11:05:15 +0000 (In reply to Lassi Väätämöinen from comment #241) > (In reply to Aleksey Kontsevich from comment #240) > > > Yep, not clear: under X11 all app are restored regardless they support > > session management or not. > > What do you find unclear here? In X11, it is the X11 session management > which is responsible of keeping track of which applications belong to a > session. > > In Wayland, it is up to the application to remember that it belongs to a > session. I for one didn't know that. I like to think I'm a fairly knowledgeable user, but I'm not a GUI programmer. I understand that apps need to take of their own internal state, but their desktop and window placement are presumably not their concern. Maybe I'm wrong or we're using the terminology in contradictory ways. What I do know is that with kdotool I can place and resize windows from an external script, so I fail to see why the desktop manager can't do this for me. 2437127 244 hoehnp 2025-06-28 12:34:44 +0000 First of all, a really thanks to the developers for pushing this forward. Really appreciated. One critical question: wouldnt it make sense to keep this bug open until at least Qt 6.10 is finally released? From what i see the planned date for the final release is planned for the 23rd of September. So apart from any development system, this fix will actually reach no users before that date. 2437134 245 lassi.vaatamoinen 2025-06-28 13:21:39 +0000 (In reply to ilovekiruna from comment #244) > One critical question: wouldnt it make sense to keep > this bug open until at least Qt 6.10 is finally released? Depending on how an organizations bug process is defined, the answer is maybe yes or maybe no. From KDE perspective, the bug is fixed. It's the upstream that this depends on. So perhaps the upstream issue could be linked here. >this fix will actually reach no users before that date. What comes to this part, the real user-visible fix(es) will only show once the applications adopt this, which may be now, later, or never. So in that regard it doesn't make sense to keep this big open, as far as I see it. 2437138 246 nate 2025-06-28 14:15:42 +0000 (In reply to Lassi Väätämöinen from comment #245) > From KDE perspective, the bug is fixed. It's the upstream that this depends > on. So perhaps the upstream issue could be linked here. > > >this fix will actually reach no users before that date. > > What comes to this part, the real user-visible fix(es) will only show once > the applications adopt this, which may be now, later, or never. So in that > regard it doesn't make sense to keep this big open, as far as I see it. Yep, this is accurate and reflects the Bugzilla ticket lifecycle that KDE uses. The next step is for client software (Plasma and apps) to implement support now. 2437142 247 bdk 2025-06-28 14:19:54 +0000 The big problem is that the true solution needs to be done multiple times. That is at least once for each application instead of once for each session manager. I agree that each application needs to keep track of its own state(s) but the solution provided is really a step back. That said hopefully there will be some sample applications which will make it easier to implement the new protocol. I also suspect there may be situations where one might not want to restore the application or the application state. 2437148 248 4wy78uwh 2025-06-28 14:40:19 +0000 (In reply to Brian Kaye from comment #247) > I also suspect there may be situations where one might not want to restore the application or the application state. I agree on this point. I've, many a time, had this be a problem on AOSP and Windows 11. Would this be implementable in KWin, or require standardisation by FreeDesktop? I'd presume merely the former. 2437158 249 akontsevich 2025-06-28 15:22:03 +0000 (In reply to Brian Kaye from comment #247) > The big problem is that the true solution needs to be done multiple times. > That is at least once for each application instead of once for each session > manager. I agree that each application needs to keep track of its own > state(s) but the solution provided is really a step back. +1 ! Absolutely!!! I would prefer solution where session manager takes care of this: at least just launch an app and restores its position, size and state (minimized, maximized, minimized to tray, etc). If application want and it is necessary it may implement more comprehensive inner state restore using Wayland protocol, but main functionality should not require this. 2437164 250 pocallaghan 2025-06-28 16:16:37 +0000 (In reply to Aleksey Kontsevich from comment #249) > (In reply to Brian Kaye from comment #247) > > The big problem is that the true solution needs to be done multiple times. > > That is at least once for each application instead of once for each session > > manager. I agree that each application needs to keep track of its own > > state(s) but the solution provided is really a step back. > > +1 ! Absolutely!!! > > I would prefer solution where session manager takes care of this: at least > just launch an app and restores its position, size and state (minimized, > maximized, minimized to tray, etc). If application want and it is necessary > it may implement more comprehensive inner state restore using Wayland > protocol, but main functionality should not require this. +1 That's essentially what I've been trying to say. 2437168 251 bdk 2025-06-28 16:50:31 +0000 Some applications I use (eg Dolphin, Firefox/Waterfox) already seem to restore their state independent of Wayland. I still do not understand that since X11 solved the session restore problem, why could that solution not be imported into Wayland or whatever the session restore process is now. If memory serves me, there was an entry made by the session manager on logout for each application to ~.config/session ( still seems to be used for dolphin and kwin). 2437172 252 lassi.vaatamoinen 2025-06-28 17:09:51 +0000 (In reply to Brian Kaye from comment #251) > I still do not understand that since X11 solved the session restore problem, > why could that solution not be imported into Wayland or whatever the session > restore process is now. I guess the short answer is something in the lines of: because Wayland was not meant to be the same bloatware as X11 is. And adding all the features in it would make it as inflexible as X11 was. But as Nate has already mentioned (I guess several times), the bug comment section is really about techincal discussion regarding the actual bug, not general. So I'd suggest moving the general dicussion to https://discuss.kde.org/. 2437325 253 imaginator 2025-06-29 18:48:02 +0000 (In reply to Lassi Väätämöinen from comment #252) > (In reply to Brian Kaye from comment #251) > > I still do not understand that since X11 solved the session restore problem, > > why could that solution not be imported into Wayland or whatever the session > > restore process is now. > > I guess the short answer is something in the lines of: because Wayland was > not meant to be the same bloatware as X11 is. And adding all the features in > it would make it as inflexible as X11 was. To compare one of the most productivity-enhancing features of modern desktops with "bloat" is somewhat beside the point, I'd say. And implementing such a key-feature surely wouldn't have made wayland "inflexible". That's ridiculous. Thus, another "short answer" might be: the Wayland-devs didn't care or weren't up to the task - despite a blueprint (XSMP) that's been around for more than 30 years. And BTW: if I were a QT- or KDE-developer, I'd be _very_ cautious to point fingers at others when it comes to "bloatware". I hope you're wise enough to refrain from asking for hard data. > > But as Nate has already mentioned (I guess several times), the bug comment > section is really about techincal discussion regarding the actual bug, not > general. So I'd suggest moving the general dicussion to > https://discuss.kde.org/. Had KDE-, QT-, or wayland-devs solved this problem after 4 weeks or 4 months or even a year, there wouldn't be a discussion at all. But after more than _4 years_ I guess some perhaps not so technical - but nevertheless mostly constructive - comments are quite understandable. And in case you have opened a thread for this topic on https://discuss.kde.org/: could you post the link, please? Thanks. Anyway - it's good that there is progress in this matter and that we've been informed about it. Thanks. 2437343 254 lassi.vaatamoinen 2025-06-29 19:33:22 +0000 (In reply to imaginator from comment #253) Well, here you go, here's one touching the topic, for example, on a quick search: https://discuss.kde.org/t/this-week-in-plasma-the-beginnings-of-wayland-session-restore-kde-blogs/32728 2437358 255 akontsevich 2025-06-29 20:44:05 +0000 What to discuss there?! You know our opinion, no sense to repeat it there as you'll ignore it same way like here, no sense to waste our time and effort. 2437366 256 4wy78uwh 2025-06-29 21:48:49 +0000 (In reply to Aleksey Kontsevich from comment #255) Asking that merely invites discussion here. Ask that at the linked Discussion thread. 2442051 257 shai 2025-07-21 19:38:42 +0000 (In reply to Nate Graham from comment #246) > (In reply to Lassi Väätämöinen from comment #245) > > From KDE perspective, the bug is fixed. It's the upstream that this depends > > on. So perhaps the upstream issue could be linked here. > > > > >this fix will actually reach no users before that date. > > > > What comes to this part, the real user-visible fix(es) will only show once > > the applications adopt this, which may be now, later, or never. So in that > > regard it doesn't make sense to keep this big open, as far as I see it. > > Yep, this is accurate and reflects the Bugzilla ticket lifecycle that KDE > uses. > > The next step is for client software (Plasma and apps) to implement support > now. So -- just to clarify -- are app-specific instances of this bug (e.g. https://bugs.kde.org/show_bug.cgi?id=461780 for konsole) supposed to stay open, or are they to be marked as duplicates of this bug (as has been done, it seems, in its earlier history)? 2444826 258 msdobrescu 2025-08-02 19:48:47 +0000 Sorry, I post here as I can't log into the discussion thread page. On 6.3.6, under Wayland, I can set to save the session and Dolphin is restored at startup, so it remains to implement session restore in Dolphin to set it up as the last time (tabs, URIs and so on). Question is: almost every common Plasma application throws a message at restart/shutdown time asking whether to close it. For Dolphin, under X11, the message is ignored and the restart/shutdown process is continued, but for Yakuake is blocker, so the process remains waiting for the user confirmation indefinitely. Under Wayland it is a blocker for Dolphin too (issuing a reboot command in command line reboots the system and the previous session is restored). If I click quit, I am not sure of the result at session restore. This feature stays in the way somehow and creates a lot of confusion. 2457250 259 nate 2025-09-24 19:29:01 +0000 *** Bug 509869 has been marked as a duplicate of this bug. *** 2463891 260 nate 2025-10-22 19:41:18 +0000 Bug 15329 is in progress, and that tracks the window position/geometry/virtual desktop element of session restore. This one is about what's left: where apps save and restore their window content and internal state. This has further to go before it'll be possible on Wayland. Thankfully it's less necessary, because apps with state worth saving are already capable of doing it on their own without needing to involve the window manager, and at this point, most already do. I'm re-opening this since the feature is clearly it's not implemented yet, but I'll also migrate some of the duplicate bugs to more appropriate places. 2506718 261 akontsevich 2026-03-28 13:51:52 +0000 Good news: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18#note_3375004 >The current protocol proposal looks very reasonable, and it helps to bring >the Wayland session closer to feature parity with X11. Regarding >XDG_CURRENT_DESKTOP, both ways are fine with us, with and without it, >but it seems a bit out of the scope for the protocol and somewhat an edge >case that doesn't seem worth caring about. AND https://invent.kde.org/plasma/kwin/-/merge_requests/8985 So should be there in KDE Plasma 6.7 in June!!! Chromium impl: https://chromium-review.googlesource.com/6329003 2509337 262 xaver.hugl 2026-04-10 15:36:12 +0000 *** Bug 473965 has been marked as a duplicate of this bug. *** 2510195 263 nate 2026-04-15 18:20:18 +0000 With https://invent.kde.org/plasma/kwin/-/merge_requests/8985, this has been implemented now! Of course getting support for this protocol in KWin isn't enough to make apps use it to save and restore their sessions; the next step is for toolkits, libraries, and apps to implement support themselves. But it's done on the KWin side, which is what this Bugzilla ticket was tracking. Marking as resolved! 2510201 264 akontsevich 2026-04-15 18:46:27 +0000 (In reply to Nate Graham from comment #263) > Of course getting support for this protocol in KWin isn't enough to make > apps use it to save and restore their sessions; the next step is for > toolkits, libraries, and apps to implement support themselves. It should work on KWin side for all the applications even they do not support it, in particular: - run the application saved in session - restore window position/size/state (minimized, maximized, in tray, etc) Inner application state should be managed in the app of course. 2510222 265 pocallaghan 2026-04-15 21:07:21 +0000 (In reply to Nate Graham from comment #263) > With https://invent.kde.org/plasma/kwin/-/merge_requests/8985, this has been > implemented now! > > Of course getting support for this protocol in KWin isn't enough to make > apps use it to save and restore their sessions; the next step is for > toolkits, libraries, and apps to implement support themselves. > > But it's done on the KWin side, which is what this Bugzilla ticket was > tracking. Marking as resolved! Great news. Thanks for all the work. Is this already in 6.6.4 or do we way for 6.7? I've bee(In reply to Nate Graham from comment #263) > With https://invent.kde.org/plasma/kwin/-/merge_requests/8985, this has been > implemented now! > > Of course getting support for this protocol in KWin isn't enough to make > apps use it to save and restore their sessions; the next step is for > toolkits, libraries, and apps to implement support themselves. > > But it's done on the KWin side, which is what this Bugzilla ticket was > tracking. Marking as resolved! This is great news. Is this in 6.6.4 or do we wait for 6.7? I've been using the experimental version (with ~/.config/environment.d/00-wl-xx-session-management.conf) for a couple of months and am pretty happy with it. Do I need to change anything? 2510230 266 kde 2026-04-15 21:51:27 +0000 6.7, and you'll be able to drop that .conf line. I'm surprised you're seeing any useful results given no app is reporting anything useful right now. 2510313 267 pocallaghan 2026-04-16 10:02:55 +0000 (In reply to David Edmundson from comment #266) > 6.7, and you'll be able to drop that .conf line. > > I'm surprised you're seeing any useful results given no app is reporting > anything useful right now. I'm getting windows restored to the right places and desktops, which was mostly what I originally complained about, so it's a win. There is one nit: when opening an app (e.g. from the Kicker) it seems to go to the last desktop it was on, rather than the one I'm currently looking at. This is quite annoying but I haven't tested rigorously. I'm waiting for the official release to see if it persists. 2510631 268 funtoos 2026-04-18 00:05:17 +0000 Since this bug is marked as resolved, I need a clarification. Are we able to restore the following for all apps without any other app specific fixes? 1. Which desktop? 2. What location? 3. What size? 4. Minimized? kwin should be able to do this for all applications without the app doing anything special, right? Is this part of the fix? Or this fix just gives the ability to store and restore this information, and applications need to be modified one by one for these 4 basic things? 2510723 269 pocallaghan 2026-04-18 20:59:29 +0000 (In reply to devsk from comment #268) > Since this bug is marked as resolved, I need a clarification. Are we able to > restore the following for all apps without any other app specific fixes? > > 1. Which desktop? > 2. What location? > 3. What size? > 4. Minimized? > > kwin should be able to do this for all applications without the app doing > anything special, right? Is this part of the fix? Or this fix just gives the > ability to store and restore this information, and applications need to be > modified one by one for these 4 basic things? As far as I know, no apps have yet been modified, but items 1-3 all work for me, I don't know about item 4 as I never use it. 2511060 270 fedin-ilja2010 2026-04-20 17:48:21 +0000 (In reply to Nate Graham from comment #263) > With https://invent.kde.org/plasma/kwin/-/merge_requests/8985, this has been > implemented now! > > Of course getting support for this protocol in KWin isn't enough to make > apps use it to save and restore their sessions; the next step is for > toolkits, libraries, and apps to implement support themselves. > > But it's done on the KWin side, which is what this Bugzilla ticket was > tracking. Marking as resolved! Was the wrong bug closed? Reading https://invent.kde.org/plasma/kwin/-/work_items/295, I have an impression that the MR fixes https://bugs.kde.org/show_bug.cgi?id=15329 rather than this bug while this bug would require some new API on KDE Frameworks level and will use portals via D-Bus? 2524993 271 pocallaghan 2026-06-20 10:50:26 +0000 (In reply to Patrick O'Callaghan from comment #267) > (In reply to David Edmundson from comment #266) > > 6.7, and you'll be able to drop that .conf line. > > > > I'm surprised you're seeing any useful results given no app is reporting > > anything useful right now. > > I'm getting windows restored to the right places and desktops, which was > mostly what I originally complained about, so it's a win. > > There is one nit: when opening an app (e.g. from the Kicker) it seems to go > to the last desktop it was on, rather than the one I'm currently looking at. > This is quite annoying but I haven't tested rigorously. I'm waiting for the > official release to see if it persists. Now using 6.7 on Fedora. As mentioned, windows and desktops are correctly restored when logging in. However if I explicitly start an app on Desktop A when its previous position had been saved to Desktop B, there is a brief flash on A and then it appears to vanish (it's actually now on B). This is confusing to the user. 2525011 272 193429 4wy78uwh 2026-06-20 11:31:57 +0000 Created attachment 193429 A Notification > niklassalminen@pm.me changed bug 436318 > > | What | Removed | Added | > |----------|--------------------------------------------|-------| > | See Also | https://bugs.kde.org/show_bug.cgi?id=15329 | | I'd say that having these linked is more useful than not. 2525265 273 bdk 2026-06-21 04:24:16 +0000 (In reply to Roke Julian Lockhart Beedell from comment #272) > Created attachment 193429 [details] > A Notification > > > niklassalminen@pm.me changed bug 436318 > > > > | What | Removed | Added | > > |----------|--------------------------------------------|-------| > > | See Also | https://bugs.kde.org/show_bug.cgi?id=15329 | | > > I'd say that having these linked is more useful than not. (In reply to Patrick O'Callaghan from comment #271) > (In reply to Patrick O'Callaghan from comment #267) > > (In reply to David Edmundson from comment #266) > > > 6.7, and you'll be able to drop that .conf line. > > > > > > I'm surprised you're seeing any useful results given no app is reporting > > > anything useful right now. > > > > I'm getting windows restored to the right places and desktops, which was > > mostly what I originally complained about, so it's a win. > > > > There is one nit: when opening an app (e.g. from the Kicker) it seems to go > > to the last desktop it was on, rather than the one I'm currently looking at. > > This is quite annoying but I haven't tested rigorously. I'm waiting for the > > official release to see if it persists. > > Now using 6.7 on Fedora. As mentioned, windows and desktops are correctly > restored when logging in. However if I explicitly start an app on Desktop A > when its previous position had been saved to Desktop B, there is a brief > flash on A and then it appears to vanish (it's actually now on B). This is > confusing to the user. I am using 6.7 on Fedora the only apps that are restored to the proper desktop are the ones that were on the desktop that was active at the time of the restart. All apps that belong on other desktops are restored to that same desktop and have to manually moved to the correct desktop. So doethe (In reply to Patrick O'Callaghan from comment #271) > (In reply to Patrick O'Callaghan from comment #267) > > (In reply to David Edmundson from comment #266) > > > 6.7, and you'll be able to drop that .conf line. > > > > > > I'm surprised you're seeing any useful results given no app is reporting > > > anything useful right now. > > > > I'm getting windows restored to the right places and desktops, which was > > mostly what I originally complained about, so it's a win. > > > > There is one nit: when opening an app (e.g. from the Kicker) it seems to go > > to the last desktop it was on, rather than the one I'm currently looking at. > > This is quite annoying but I haven't tested rigorously. I'm waiting for the > > official release to see if it persists. > > Now using 6.7 on Fedora. As mentioned, windows and desktops are correctly > restored when logging in. However if I explicitly start an app on Desktop A > when its previous position had been saved to Desktop B, there is a brief > flash on A and then it appears to vanish (it's actually now on B). This is > confusing to the user. I am using 6.7 on Fedora 44. I see no changes to the Desktops on my system. All applications are restored to the desktop that was active at the time of the restart. The other Desktops are empty. If multiple Konsole windows are open one one window is restored. Is marking the status as fixed simply mean that the support is available in Wayland and not that all the applications support the the feature? 2530318 274 funtoos 2026-07-09 06:24:06 +0000 Running 6.7.2 right now and session restore is not working even for basic apps like konsole windows. I get firefox and a single konsole window in one desktop. All other desktops are empty. I really thought we had it this time! What is supposed to have been fixed? 2530346 275 fedin-ilja2010 2026-07-09 09:37:50 +0000 It seems they closed the wrong report. Look, "Latest Commit" links to xdg-session-v1 support and then https://invent.kde.org/plasma/kwin/-/work_items/295 mentions that Wayland session management protocol is supposed to fix positioning (which is tracked by https://bugs.kde.org/show_bug.cgi?id=15329 and still open), not window content. 2530371 276 postix 2026-07-09 13:04:43 +0000 Since many have mentioned Firefox not restoring correctly, the project has it's own issue, which is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=2044701 ([Wayland] Implement xdg-session-management-v1) and which has been marked resolved fixed for Firefox 154. Current release is 152! 2530419 277 pocallaghan 2026-07-09 15:33:29 +0000 (In reply to postix from comment #276) > Since many have mentioned Firefox not restoring correctly, the project has > it's own issue, which is tracked here: > https://bugzilla.mozilla.org/show_bug.cgi?id=2044701 ([Wayland] Implement > xdg-session-management-v1) > and which has been marked resolved fixed for Firefox 154. Current release is > 152! Firefox has basically always worked for me, at least since I first opened this BZ report. 2530423 278 pocallaghan 2026-07-09 15:37:46 +0000 (In reply to Patrick O'Callaghan from comment #277) > (In reply to postix from comment #276) > > Since many have mentioned Firefox not restoring correctly, the project has > > it's own issue, which is tracked here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=2044701 ([Wayland] Implement > > xdg-session-management-v1) > > and which has been marked resolved fixed for Firefox 154. Current release is > > 152! > > Firefox has basically always worked for me, at least since I first opened > this BZ report. To clarify: window and desktop placement have only started working recently (from 6.6.x), but tab content has always worked. 154513 2022-12-11 19:54:05 +0000 2022-12-11 19:54:05 +0000 attachment-25640-0.html attachment-25640-0.html text/html 1192 edtoml PGRpdiBkaXI9Imx0ciI+QW5kcmVhcywgSSB3b3VsZMKgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLsKg IEkgc3dpdGNoZWQgdG8gd2F5bGFuZCBvbmNlIG11bHRpIG1vbml0b3LCoHN1cHBvcnQgc3RhcnRl ZCB3b3JraW5nIGFuZCBoYXZlIG5vdCBsb29rZWQgYmFjay7CoCBIZXJlLCBhdCBsZWFzdCwgdGhl IGNvbG9yIGlzIG1vcmUgdml2aWQgdXNpbmcgd2F5bGFuZCAoZWcgWCBsb29rcyB3YXNoZWQgb3V0 KS7CoCBBc2lkZSBmcm9tIGEgZmV3IGlycml0YXRpbmfCoGJ1Z3MgbGlrZSB0aGlzIG9uZSwgaXQg d29ya3Mgd2VsbC48L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJs dHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBGcmksIERlYyA5LCAyMDIyIGF0IDEyOjU2IFBNIEFu ZHJlYXMgSGFydG1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpidWd6aWxsYV9ub3JlcGx5QGtkZS5v cmciPmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+PGEgaHJlZj0iaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQzNjMxOCIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hv d19idWcuY2dpP2lkPTQzNjMxODwvYT48YnI+DQo8YnI+DQotLS0gQ29tbWVudCAjMzIgZnJvbSBB bmRyZWFzIEhhcnRtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86YW5kaWhhcnRtYW5uQGZyZWVuZXQu ZGUiIHRhcmdldD0iX2JsYW5rIj5hbmRpaGFydG1hbm5AZnJlZW5ldC5kZTwvYT4mZ3Q7IC0tLTxi cj4NCkkgZG9uJiMzOTt0IHRoaW5rIHRoZXJlIGFyZSBzbyBtYW55IFdheWxhbmQgdXNlcnMgb3V0 IHRoZXJlIGJlY2F1c2UgV2F5bGFuZCBoYXMgc288YnI+DQptYW55IHJlc3RyaWN0aW9ucyBhbmQg YnVncyBzbyBmYXIgKGFuZCBJIGRvbiYjMzk7dCBzZWUgYW55IHNvbHV0aW9uKS48YnI+DQo8YnI+ DQotLSA8YnI+DQpZb3UgYXJlIHJlY2VpdmluZyB0aGlzIG1haWwgYmVjYXVzZTo8YnI+DQpZb3Ug YXJlIG9uIHRoZSBDQyBsaXN0IGZvciB0aGUgYnVnLjwvYmxvY2txdW90ZT48L2Rpdj4NCg== 154515 2022-12-11 20:19:54 +0000 2022-12-11 20:19:54 +0000 attachment-30227-0.html attachment-30227-0.html text/html 2056 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPldlbGwgSSBkbyBsaWtlIGl0LCBpbiBmYWN0IEkmIzM5O20gc3RpY2tp bmcgd2l0aCBpdCwgYnV0IEkgZG8gbWlzcyBiZWluZyBhYmxlIHRvIHJlc3RvcmUgdGhlIG9sZCBz ZXNzaW9uLCBmb3IgbWUgaXQgbWVhbnMgbm90IGhhdmluZyB0byByZW9wZW4gZG96ZW4gb2YgcGRm cyBpbiBkaWZmZXJlbnQgb2t1bGFyIGluc3RhbmNlcyBvbiBkaWZmZXJlbnQgZGVza3RvcHM8L2Rp dj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFp bF9hdHRyIj5PbiBTdW4sIDExIERlYyAyMDIyLCAyMDo1NCBFZCBUb21saW5zb24sICZsdDs8YSBo cmVmPSJtYWlsdG86YnVnemlsbGFfbm9yZXBseUBrZGUub3JnIj5idWd6aWxsYV9ub3JlcGx5QGtk ZS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+PGEgaHJlZj0iaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcu Y2dpP2lkPTQzNjMxOCIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2J1Z3Mua2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4PC9hPjxicj4NCjxi cj4NCi0tLSBDb21tZW50ICMzMyBmcm9tIEVkIFRvbWxpbnNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVkdG9tbEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmVkdG9t bEBnbWFpbC5jb208L2E+Jmd0OyAtLS08YnI+DQpBbmRyZWFzLCBJIHdvdWxkIHJlc3BlY3RmdWxs eSBkaXNhZ3JlZS7CoCBJIHN3aXRjaGVkIHRvIHdheWxhbmQgb25jZSBtdWx0aTxicj4NCm1vbml0 b3Igc3VwcG9ydCBzdGFydGVkIHdvcmtpbmcgYW5kIGhhdmUgbm90IGxvb2tlZCBiYWNrLsKgIEhl cmUsIGF0IGxlYXN0LDxicj4NCnRoZSBjb2xvciBpcyBtb3JlIHZpdmlkIHVzaW5nIHdheWxhbmQg KGVnIFggbG9va3Mgd2FzaGVkIG91dCkuwqAgQXNpZGUgZnJvbTxicj4NCmEgZmV3IGlycml0YXRp bmcgYnVncyBsaWtlIHRoaXMgb25lLCBpdCB3b3JrcyB3ZWxsLjxicj4NCjxicj4NCk9uIEZyaSwg RGVjIDksIDIwMjIgYXQgMTI6NTYgUE0gQW5kcmVhcyBIYXJ0bWFubiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZl cnJlciI+YnVnemlsbGFfbm9yZXBseUBrZGUub3JnPC9hPiZndDs8YnI+DQp3cm90ZTo8YnI+DQo8 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD00 MzYzMTgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQzNjMxODwvYT48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtLS0gQ29tbWVudCAjMzIgZnJvbSBBbmRyZWFzIEhhcnRtYW5uICZsdDs8YSBocmVmPSJt YWlsdG86YW5kaWhhcnRtYW5uQGZyZWVuZXQuZGUiIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVm ZXJyZXIiPmFuZGloYXJ0bWFubkBmcmVlbmV0LmRlPC9hPiZndDsgLS0tPGJyPg0KJmd0OyBJIGRv biYjMzk7dCB0aGluayB0aGVyZSBhcmUgc28gbWFueSBXYXlsYW5kIHVzZXJzIG91dCB0aGVyZSBi ZWNhdXNlIFdheWxhbmQ8YnI+DQomZ3Q7IGhhcyBzbzxicj4NCiZndDsgbWFueSByZXN0cmljdGlv bnMgYW5kIGJ1Z3Mgc28gZmFyIChhbmQgSSBkb24mIzM5O3Qgc2VlIGFueSBzb2x1dGlvbikuPGJy Pg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFlvdSBhcmUgcmVjZWl2aW5nIHRoaXMgbWFp bCBiZWNhdXNlOjxicj4NCiZndDsgWW91IGFyZSBvbiB0aGUgQ0MgbGlzdCBmb3IgdGhlIGJ1Zy48 YnI+DQo8YnI+DQotLSA8YnI+DQpZb3UgYXJlIHJlY2VpdmluZyB0aGlzIG1haWwgYmVjYXVzZTo8 YnI+DQpZb3UgYXJlIG9uIHRoZSBDQyBsaXN0IGZvciB0aGUgYnVnLjwvYmxvY2txdW90ZT48L2Rp dj4NCg== 154516 2022-12-11 20:21:15 +0000 2022-12-11 20:21:15 +0000 attachment-30617-0.html attachment-30617-0.html text/html 2523 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPllvdSB3ZXJlIG5vdCByZXBseWluZyB0byBtZSBJIGd1ZXNzIC4uLjwv ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9Imdt YWlsX2F0dHIiPk9uIFN1biwgMTEgRGVjIDIwMjIsIDIxOjE5IHRpIGNvbnplcm8sICZsdDs8YSBo cmVmPSJtYWlsdG86dGljb256ZXJvMjAxMEBnbWFpbC5jb20iPnRpY29uemVybzIwMTBAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPjxkaXYgZGlyPSJhdXRvIj5XZWxsIEkgZG8gbGlrZSBpdCwgaW4gZmFj dCBJJiMzOTttIHN0aWNraW5nIHdpdGggaXQsIGJ1dCBJIGRvIG1pc3MgYmVpbmcgYWJsZSB0byBy ZXN0b3JlIHRoZSBvbGQgc2Vzc2lvbiwgZm9yIG1lIGl0IG1lYW5zIG5vdCBoYXZpbmcgdG8gcmVv cGVuIGRvemVuIG9mIHBkZnMgaW4gZGlmZmVyZW50IG9rdWxhciBpbnN0YW5jZXMgb24gZGlmZmVy ZW50IGRlc2t0b3BzPC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0i bHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU3VuLCAxMSBEZWMgMjAyMiwgMjA6NTQgRWQgVG9t bGluc29uLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+YnVnemlsbGFfbm9yZXBseUBrZGUub3JnPC9h PiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPjxhIGhyZWY9Imh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD00 MzYzMTgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2J1Z3Mua2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4PC9hPjxicj4N Cjxicj4NCi0tLSBDb21tZW50ICMzMyBmcm9tIEVkIFRvbWxpbnNvbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmVkdG9tbEBnbWFpbC5jb20iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+ZWR0b21sQGdtYWlsLmNvbTwvYT4mZ3Q7IC0tLTxicj4NCkFuZHJlYXMsIEkgd291 bGQgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLsKgIEkgc3dpdGNoZWQgdG8gd2F5bGFuZCBvbmNlIG11 bHRpPGJyPg0KbW9uaXRvciBzdXBwb3J0IHN0YXJ0ZWQgd29ya2luZyBhbmQgaGF2ZSBub3QgbG9v a2VkIGJhY2suwqAgSGVyZSwgYXQgbGVhc3QsPGJyPg0KdGhlIGNvbG9yIGlzIG1vcmUgdml2aWQg dXNpbmcgd2F5bGFuZCAoZWcgWCBsb29rcyB3YXNoZWQgb3V0KS7CoCBBc2lkZSBmcm9tPGJyPg0K YSBmZXcgaXJyaXRhdGluZyBidWdzIGxpa2UgdGhpcyBvbmUsIGl0IHdvcmtzIHdlbGwuPGJyPg0K PGJyPg0KT24gRnJpLCBEZWMgOSwgMjAyMiBhdCAxMjo1NiBQTSBBbmRyZWFzIEhhcnRtYW5uICZs dDs8YSBocmVmPSJtYWlsdG86YnVnemlsbGFfbm9yZXBseUBrZGUub3JnIiByZWw9Im5vcmVmZXJy ZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZzwv YT4mZ3Q7PGJyPg0Kd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2J1Z3Mu a2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJl ciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19i dWcuY2dpP2lkPTQzNjMxODwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0gQ29tbWVudCAjMzIg ZnJvbSBBbmRyZWFzIEhhcnRtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86YW5kaWhhcnRtYW5uQGZy ZWVuZXQuZGUiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+YW5k aWhhcnRtYW5uQGZyZWVuZXQuZGU8L2E+Jmd0OyAtLS08YnI+DQomZ3Q7IEkgZG9uJiMzOTt0IHRo aW5rIHRoZXJlIGFyZSBzbyBtYW55IFdheWxhbmQgdXNlcnMgb3V0IHRoZXJlIGJlY2F1c2UgV2F5 bGFuZDxicj4NCiZndDsgaGFzIHNvPGJyPg0KJmd0OyBtYW55IHJlc3RyaWN0aW9ucyBhbmQgYnVn cyBzbyBmYXIgKGFuZCBJIGRvbiYjMzk7dCBzZWUgYW55IHNvbHV0aW9uKS48YnI+DQomZ3Q7PGJy Pg0KJmd0OyAtLTxicj4NCiZndDsgWW91IGFyZSByZWNlaXZpbmcgdGhpcyBtYWlsIGJlY2F1c2U6 PGJyPg0KJmd0OyBZb3UgYXJlIG9uIHRoZSBDQyBsaXN0IGZvciB0aGUgYnVnLjxicj4NCjxicj4N Ci0tIDxicj4NCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgbWFpbCBiZWNhdXNlOjxicj4NCllvdSBh cmUgb24gdGhlIENDIGxpc3QgZm9yIHRoZSBidWcuPC9ibG9ja3F1b3RlPjwvZGl2Pg0KPC9ibG9j a3F1b3RlPjwvZGl2Pg0K 154521 2022-12-12 03:33:06 +0000 2022-12-12 03:33:06 +0000 attachment-13297-0.html attachment-13297-0.html text/html 1049 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPkl0IHdvdWxkbiYjMzk7dCB3b3JrIGZvciBtZSwgSSBuZWVkIHRvIHN3 aXRjaCBiZXR3ZWVuIGRpZmZlcmVudCBPU3MgYW5kIG5lZWQgdG8gcmVzdGFydMKgPC9kaXY+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0 ciI+T24gU3VuLCAxMSBEZWMgMjAyMiwgMjI6MjEgTWF1cm8gTW9saW5hcmksICZsdDs8YSBocmVm PSJtYWlsdG86YnVnemlsbGFfbm9yZXBseUBrZGUub3JnIj5idWd6aWxsYV9ub3JlcGx5QGtkZS5v cmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+PGEgaHJlZj0iaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dp P2lkPTQzNjMxOCIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2J1Z3Mua2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4PC9hPjxicj4NCjxicj4N Ci0tLSBDb21tZW50ICMzOCBmcm9tIE1hdXJvIE1vbGluYXJpICZsdDs8YSBocmVmPSJtYWlsdG86 bWF1cm9tb2xAdGlzY2FsaS5pdCIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+bWF1 cm9tb2xAdGlzY2FsaS5pdDwvYT4mZ3Q7IC0tLTxicj4NCihJbiByZXBseSB0byBGcmFuY2lzY28g Q3JpYmFyaSBmcm9tIGNvbW1lbnQgIzM3KTxicj4NCiZndDsgSXQgaXMgdG9vIG11Y2ggd29yayB0 byBvcGVuIGVhY2ggb2YgdGhlc2UgZmlsZXMgYWdhaW4gZXZlcnkgdGltZSBJPGJyPg0KJmd0OyBy ZXN0YXJ0IHRoZSBjb21wdXRlci48YnI+DQo8YnI+DQpFdmVyIGhlYXJkIGFib3V0IHNsZWVwIGFu ZCBoaWJlcm5hdGlvbj8gOy0pPGJyPg0KPGJyPg0KLS0gPGJyPg0KWW91IGFyZSByZWNlaXZpbmcg dGhpcyBtYWlsIGJlY2F1c2U6PGJyPg0KWW91IGFyZSBvbiB0aGUgQ0MgbGlzdCBmb3IgdGhlIGJ1 Zy48L2Jsb2NrcXVvdGU+PC9kaXY+DQo= 154527 2022-12-12 09:29:17 +0000 2022-12-12 09:29:17 +0000 attachment-19101-0.html attachment-19101-0.html text/html 2081 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPkkgaW5zdGFsbGVkIGt1YnVudHUgMjIuMDRMVFMsIHRoYXQgY2FtZSB3 aXRoIFdheWxhbmQsIGhvdyBjYW4gSSBnZXQgYmFjayB0byBYMTEtUGxhc21hLCB3aXRob3V0IHJl dHVybmluZyB0byAxOC4wNExUUyA/PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gTW9uLCAxMiBEZWMgMjAyMiwgMTA6 MTAgLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZyI+YnVnemls bGFfbm9yZXBseUBrZGUub3JnPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxhIGhyZWY9Imh0dHBzOi8vYnVncy5rZGUu b3JnL3Nob3dfYnVnLmNnaT9pZD00MzYzMTgiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQzNjMx ODwvYT48YnI+DQo8YnI+DQotLS0gQ29tbWVudCAjNDIgZnJvbSA8YSBocmVmPSJtYWlsdG86aW1h Z2luYXRvckBtYWlsYm94Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aW1h Z2luYXRvckBtYWlsYm94Lm9yZzwvYT4gLS0tPGJyPg0KKEluIHJlcGx5IHRvIEpvaG4gRSBmcm9t IGNvbW1lbnQgIzQwKTxicj4NCiZndDsgKEluIHJlcGx5IHRvIEZyYW5jaXNjbyBDcmliYXJpIGZy b20gY29tbWVudCAjMzcpPGJyPg0KJmd0OyAmZ3Q7IChJbiByZXBseSB0byB0aWNvbnplcm8gZnJv bSBjb21tZW50ICMzNSk8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2VsbCBJ IGRvIGxpa2UgaXQsIGluIGZhY3QgSSYjMzk7bSBzdGlja2luZyB3aXRoIGl0LCBidXQgSSBkbyBt aXNzIGJlaW5nIGFibGU8YnI+DQomZ3Q7ICZndDsgJmd0OyB0byByZXN0b3JlIHRoZSBvbGQgc2Vz c2lvbiwgZm9yIG1lIGl0IG1lYW5zIG5vdCBoYXZpbmcgdG8gcmVvcGVuIGRvemVuIG9mPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgcGRmcyBpbiBkaWZmZXJlbnQgb2t1bGFyIGluc3RhbmNlcyBvbiBkaWZm ZXJlbnQgZGVza3RvcHM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNhbWUgaGVyZS4g VGhpcyBidWcgaXMgdGhlIG9ubHkgcmVhc29uIHdoeSBJIGFtIG5vdCBydW5uaW5nIFdheWxhbmQu IEk8YnI+DQomZ3Q7ICZndDsgdXN1YWxseSBoYXZlIGFib3V0IGEgZG96ZW4gUERGIChva3VsYXIp IGFuZCBvdmVyIHR3ZW50eSB0ZXh0IChrYXRlKSBmaWxlczxicj4NCiZndDsgJmd0OyBvcGVuLiBJ dCBpcyB0b28gbXVjaCB3b3JrIHRvIG9wZW4gZWFjaCBvZiB0aGVzZSBmaWxlcyBhZ2FpbiBldmVy eSB0aW1lIEk8YnI+DQomZ3Q7ICZndDsgcmVzdGFydCB0aGUgY29tcHV0ZXIuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IElmIHlvdXIgd2luZG93cyBkb24mIzM5O3QgY2hhbmdlIHRvbyBtdWNoIHlvdSBj YW4gZmluZCBhIHdvcmthcm91bmQgb24gbXkgZHVwOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQ1NTkwMCIgcmVsPSJub3JlZmVycmVyIG5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2J1Z3Mua2RlLm9yZy9zaG93X2J1Zy5j Z2k/aWQ9NDU1OTAwPC9hPjxicj4NCjxicj4NCkluIG15IHZpZXcsIHRoZSBtb3N0IG9idmlvdXMg YW5kIHByb21pc2luZyAmcXVvdDt3b3JrYXJvdW5kJnF1b3Q7IGZvciBhbiBvcmRpbmFyeSB1c2Vy IGlzPGJyPg0KdG8gY29udGludWUgZW5qb3lpbmcgUGxhc21hLVgxMSB1bnRpbCBhbGwgbWFqb3Ig aXNzdWVzIGluIFBsYXNtYS1XYXlsYW5kIGFyZTxicj4NCmZpeGVkIGFuZCBpdCYjMzk7cyByZWFk eSBmb3IgcHJvZHVjdGl2ZSB1c2UuIDspPGJyPg0KPGJyPg0KLS0gPGJyPg0KWW91IGFyZSByZWNl aXZpbmcgdGhpcyBtYWlsIGJlY2F1c2U6PGJyPg0KWW91IGFyZSBvbiB0aGUgQ0MgbGlzdCBmb3Ig dGhlIGJ1Zy48L2Jsb2NrcXVvdGU+PC9kaXY+DQo= 154528 2022-12-12 10:02:02 +0000 2022-12-12 10:02:02 +0000 attachment-23823-0.html attachment-23823-0.html text/html 1077 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPlRoYW5rcyHCoDwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwgMTIgRGVjIDIwMjIs IDEwOjQxICwgJmx0OzxhIGhyZWY9Im1haWx0bzpidWd6aWxsYV9ub3JlcGx5QGtkZS5vcmciPmJ1 Z3ppbGxhX25vcmVwbHlAa2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48YSBocmVmPSJodHRwczovL2J1Z3Mu a2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD00 MzYzMTg8L2E+PGJyPg0KPGJyPg0KLS0tIENvbW1lbnQgIzQ0IGZyb20gPGEgaHJlZj0ibWFpbHRv OmltYWdpbmF0b3JAbWFpbGJveC5vcmciIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIi PmltYWdpbmF0b3JAbWFpbGJveC5vcmc8L2E+IC0tLTxicj4NCihJbiByZXBseSB0byB0aWNvbnpl cm8gZnJvbSBjb21tZW50ICM0Myk8YnI+DQomZ3Q7IENyZWF0ZWQgYXR0YWNobWVudCAxNTQ1Mjcg W2RldGFpbHNdPGJyPg0KJmd0OyBhdHRhY2htZW50LTE5MTAxLTAuaHRtbDxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIGluc3RhbGxlZCBrdWJ1bnR1IDIyLjA0TFRTLCB0aGF0IGNhbWUgd2l0aCBXYXls YW5kLCBob3cgY2FuIEkgZ2V0IGJhY2sgdG88YnI+DQomZ3Q7IFgxMS1QbGFzbWEsIHdpdGhvdXQg cmV0dXJuaW5nIHRvIDE4LjA0TFRTID88YnI+DQpJIHRoaW5rIHRoYXQmIzM5O3MgYSBxdWVzdGlv biBmb3IgdGhlIGtidW50dSBzdXBwb3J0IGZvcnVtIC8gbWFpbGluZyBsaXN0Ljxicj4NCjxicj4N Ci0tIDxicj4NCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgbWFpbCBiZWNhdXNlOjxicj4NCllvdSBh cmUgb24gdGhlIENDIGxpc3QgZm9yIHRoZSBidWcuPC9ibG9ja3F1b3RlPjwvZGl2Pg0K 164287 2023-12-19 10:46:11 +0000 2023-12-19 10:46:11 +0000 attachment-2084366-0.html attachment-2084366-0.html text/html 2145 ticonzero2010 PGRpdiBkaXI9ImF1dG8iPkNvdW50IG1lIGFtb25nIHRob3NlIHdobyBuZWVkIHJlbGlhYmxlIHNl c3Npb24gcmVzdG9yZSwgSSYjMzk7bSBzdHVjayB3aXRoIHh1YnVudHUgMjAuNCBhbmQgd2lsbCBz dGF5IHRoZXJlIHVudGlsIHNlc3Npb24gcmVzdG9yZSB3aWxsIHdvcmsgcHJvcGVybHnCoDwvZGl2 Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWls X2F0dHIiPk9uIFR1ZSwgMTkgRGVjIDIwMjMsIDEwOjA3ICwgJmx0OzxhIGhyZWY9Im1haWx0bzpi dWd6aWxsYV9ub3JlcGx5QGtkZS5vcmciPmJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij48YSBocmVmPSJodHRwczovL2J1Z3Mua2RlLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDM2MzE4 IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYnVn cy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD00MzYzMTg8L2E+PGJyPg0KPGJyPg0KLS0tIENvbW1l bnQgIzc2IGZyb20gPGEgaHJlZj0ibWFpbHRvOmltYWdpbmF0b3JAbWFpbGJveC5vcmciIHRhcmdl dD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPmltYWdpbmF0b3JAbWFpbGJveC5vcmc8L2E+IC0t LTxicj4NCihJbiByZXBseSB0byBOYXRlIEdyYWhhbSBmcm9tIGNvbW1lbnQgIzYyKTxicj4NCiZn dDsgVGhlIHBsYW4gcmlnaHQgbm93IGlzIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyAtIEZvciBQbGFz bWEgNi4wLCBpbXBsZW1lbnQgYSBzb3J0IG9mIGZha2Ugc2Vzc2lvbiByZXN0b3JlIHRoYXQgb24g bG9naW4sPGJyPg0KJmd0OyBzaW1wbHkgcmUtb3BlbnMgYXBwcyB0aGF0IHdlcmUgb3BlbiBvbiBs YXN0IGxvZ291dCwgYW5kIGNvdW50IG9uIGFwcHMgdGhhdDxicj4NCiZndDsgaGF2ZSBzdGF0ZSB3 b3J0aCBzYXZpbmcgZG9pbmcgdGhlIHNhdmluZyB0aGVtc2VsdmVzIChhbmQgbWFueSBhcHBzIGFs cmVhZHk8YnI+DQomZ3Q7IGRvOyBmb3IgZXhhbXBsZSBGaXJlZm94LCBEaXNjb3JkLCBEb2xwaGlu LCBLYXRlLCBLaWxlLCBFbGlzYS4uLikuPGJyPg0KJmd0OyAtIEZvciBhIGxhdGVyIFBsYXNtYSA2 IHZlcnNpb24sIGltcGxlbWVudCByZWFsIHNlc3Npb24gcmVzdG9yZSB0aGF0JiMzOTtzPGJyPg0K Jmd0OyBnb3Zlcm5lZCBieSBhIG5ldyBXYXlsYW5kIHByb3RvY29sIChvbmUgaXMgaW4gcHJvZ3Jl c3MpIGFuZCBtYWtlIEtERSBhcHBzPGJyPg0KJmd0OyBvcHQgaW50byBpdC48YnI+DQomZ3Q7IC0g QWZ0ZXIgdGhhdCwga2VlcCB0aGUgZmFrZSBzZXNzaW9uIHJlc3RvcmUgYW5kIHVzZSBpdCBmb3Ig YXBwcyB0aGF0IGRvbiYjMzk7dDxicj4NCiZndDsgb3B0IGludG8gdGhlIHJlYWwgc2Vzc2lvbiBy ZXN0b3JlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHNob3VsZCB1bHRpbWF0ZWx5IHByb2R1 Y2UgYSBiZXR0ZXIgVVggdGhhbiBvbiBYMTEsIHdoZXJlIG1hbnkgYXBwczxicj4NCiZndDsgbmV2 ZXIgb3B0ZWQgaW50byBzZXNzaW9uIHJlc3RvcmUgYW5kIHNvIGl0IHdhcyBzZW1pLXJhbmRvbSBh cyB0byB3aGljaCBhcHBzPGJyPg0KJmd0OyBnb3QgbGF1bmNoZWQgb24gbG9naW4uPGJyPg0KPGJy Pg0KQWxyaWdodCwgbWF5YmUgbXkgcXVlc3Rpb24gd2FzIGEgYml0IHRvbyBkaWZmaWN1bHQgdG8g dW5kZXJzdGFuZC7CoCBTbyBJPGJyPg0KcmVwaHJhc2UgaXQgYSBiaXQ6IHdpbGwgc2Vzc2lvbiBy ZXN0b3JlIGluIFBsYXNtYS02LVgxMSB3b3JrIF9yaWdodCBmcm9tIHRoZTxicj4NCnN0YXJ0XyBh cyBpdCBkb2VzIGluIFBsYXNtYS01LVgxMSBvciBub3Q/wqAgU29tZSBwZW9wbGUgZG9uJiMzOTt0 IGdpdmUgYSBkYW1uIGFib3V0PGJyPg0KV2F5bGFuZCBidXQgZG8gY2FyZSBhYm91dCByZWxpYWJs ZSBhbmQgY29tcGxldGUgc2Vzc2lvbiByZXN0b3JlLjxicj4NCjxicj4NCi0tIDxicj4NCllvdSBh cmUgcmVjZWl2aW5nIHRoaXMgbWFpbCBiZWNhdXNlOjxicj4NCllvdSBhcmUgb24gdGhlIENDIGxp c3QgZm9yIHRoZSBidWcuPC9ibG9ja3F1b3RlPjwvZGl2Pg0K 170201 2024-06-06 12:24:04 +0000 2024-06-06 12:24:04 +0000 attachment-3317129-0.html attachment-3317129-0.html text/html 2538 ticonzero2010 PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPgogIDwvaGVhZD4K ICA8Ym9keT4KICAgIDxwPjxmb250IGZhY2U9Im1vbm9zcGFjZSI+aGVyZSBJIGhhdmUgS3VidW50 dSAyMC4wNCBhbmQgPC9mb250PjxzcGFuCiAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9z cGFjZSI+PHNwYW4KICAgICAgICAgIHN0eWxlPSJjb2xvcjojMDAwMDAwO2JhY2tncm91bmQtY29s b3I6I2ZmZmZmZjsiPnBsYXNtYXNoZWxsCiAgICAgICAgICA1LjE4Ljg8L3NwYW4+IHdvcmtzIChh bG1vc3QpIHBlcmZlY3RseTo8L3NwYW4+PC9wPgogICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5Om1vbm9zcGFjZSI+LSBpdCByZW9wZW5zIG9rdWxhciwKICAgICAgICBrb25zb2xlcywga2F0 ZSwgdGh1bmRlcmJpcmQgYW5kIG11bHRpcGxlIGZpcmVmb3hlcyBpbiB0aGUgc2FtZQogICAgICAg IERlc2t0b3BzLCBzYW1lIGxvY2F0aW9uLCBvbiB0aGUgc2FtZSBmaWxlcyBvciB3ZWJwYWdlIDxi cj4KICAgICAgPC9zcGFuPjwvcD4KICAgIDxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTptb25v c3BhY2UiPi0gaXQgcmVvcGVucyBUZWtzdHVkaW8gaW4gdGhlCiAgICAgICAgd3JvbmcgZGVza3Rv cCB3aXRoIHRoZSBzYW1lIGZpbGVzIG9wZW48L3NwYW4+PC9wPgogICAgPHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+LSBpdCByZW9wZW5zIGd2aW0gYW5kCiAgICAgICAgUGFy YXZpZXcgd2l0aCBubyBmaWxlIG9wZW48L3NwYW4+PC9wPgogICAgPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5Om1vbm9zcGFjZSI+PGJyPgogICAgICA8L3NwYW4+PC9wPgogICAgPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+SSdtIHN0dWNrIHdpdGggPC9zcGFuPjxmb250 CiAgICAgICAgZmFjZT0ibW9ub3NwYWNlIj5LdWJ1bnR1IDIwLjA0IGJlY2F1c2UgSSBqdXN0IG5l ZWQgdGhpcyBmZWF0dXJlPGJyPgogICAgICA8L2ZvbnQ+PC9wPgogICAgPHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+PGJyPgogICAgICA8L3NwYW4+PC9wPgogICAgPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAwNi8wNi8yNCAxMjo1NCwgQXJtaW4gd3JvdGU6PGJy PgogICAgPC9kaXY+CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIgogICAgICBjaXRlPSJtaWQ6 YnVnLTQzNjMxOC0yNDkzMzQtcGNKU1JvMnRlZkBodHRwLmJ1Z3Mua2RlLm9yZyUyRiI+CiAgICAg IDxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+PGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQz NjMxOCI+aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQzNjMxODwvYT4KCi0t LSBDb21tZW50ICMxMTEgZnJvbSBBcm1pbiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZF IiBocmVmPSJtYWlsdG86ZGt4bHMyM0BnbWFpbC5jb20iPiZsdDtka3hsczIzQGdtYWlsLmNvbSZn dDs8L2E+IC0tLQpSZWdhcmRpbmcgdGhlIGFjdHVhbCBzZXNzaW9uIHJlc3RvcmUgZnVuY3Rpb25h bGl0eSwgSSBoYXZlIGp1c3Qgc3dpdGNoZWQgdG8KRmVkb3JhIDQwIGFuZCB0ZXN0ZWQgdGhpcyBh IGJpdC4gU28gZmFyLCB0aGUgZmFrZSBzZXNzaW9uIHJlc3RvcmUgd2FzIG5vdAp1c2VmdWwgYXQg YWxsIHNpbmNlIGl0IG9ubHkgbGF1bmNoZXMgdGhlIGFwcGxpY2F0aW9ucywgYnV0IHRob3NlIGFw cGFyZW50bHkgYXJlCm5vdCBjYXBhYmxlIG9mIHJlbWVtYmVyaW5nIHRoZWlyIHByZXZpb3VzIHN0 YXRlLgoKRm9yIGluc3RhbmNlLCBJIHJlYm9vdGVkIG15IG1hY2hpbmUgd2l0aCAxIEthdGUsIDIg T2t1bGFyIGFuZCAyIEtvbnNvbGUKaW5zdGFuY2VzIG9wZW4sIGFuZCB3aGlsZSBLYXRlLCAyIE9r dWxhciBhbmQgMiBLb25zb2xlIHdpbmRvd3Mgb3BlbmVkIGFmdGVyIHRoZQpyZXN0YXJ0LCBub25l IG9mIHRob3NlIG9wZW5lZCB0aGUgcHJldmlvdXNseSBvcGVuIGRvY3VtZW50IG9yIGNoYW5nZWQg dG8gdGhlCmRpcmVjdG9yeSB0aGV5IHByZXZpb3VzbHkgd2VyZSBhdC4gQmFjayBpbiBYMTEsIHRo ZSBzZXNzaW9uIHJlc3RvcmUgd291bGQgbm90Cm9ubHkgcmVvcGVuIHRoZSBhcHBsaWNhdGlvbnMs IGJ1dCBhbHNvIHJlc3RvcmUgdGhlIGFjdHVhbCBkb2N1bWVudHMgKGUuZy4KcmVvcGVuIHRoZSBQ REYgZmlsZSBpbiBPa3VsYXIsIGNoYW5nZSB0byB0aGUgZGlyZWN0b3J5IGluIEtvbnNvbGUsIG9y IHJlc3RvcmUgYQpzZXNzaW9uIGluIEthdGUpLgoKQXMgc3VjaCwgdGhlIGN1cnJlbnQgc2Vzc2lv biByZXN0b3JlIGRvZXNuJ3QgYWRkIGFueSB2YWx1ZSwgc2luY2UgSSBuZWVkIHRvCm1hbnVhbGx5 IG9wZW4gdGhlIGRvY3VtZW50cy9zZXNzaW9uIGFueXdheSBteXNlbGYuCgo8L3ByZT4KICAgIDwv YmxvY2txdW90ZT4KICA8L2JvZHk+CjwvaHRtbD4K 193429 2026-06-20 11:31:57 +0000 2026-06-20 11:32:12 +0000 A Notification [kwin] [Bug 436318] Support for real session save_restore for window content and state on Wayland 2026-06-20T10_30_59+01_00.eml message/rfc822 9537 4wy78uwh UmV0dXJuLVBhdGg6IDxiX21uMnRjNHRybnpydGk0M3dvbnJhX21xM3Rjb2xjZ2Jxd2VAcm9rZWp1 bGlhbmxvY2toYXJ0LmFkZHkuaW8+DQpYLU9yaWdpbmFsLVRvOiAiIkBbSVB2NjoyMDAxOmRiODo6 MV0NCkRlbGl2ZXJlZC1UbzogIiJAW0lQdjY6MjAwMTpkYjg6OjFdDQpBdXRoZW50aWNhdGlvbi1S ZXN1bHRzOiBtYWlsLnByb3Rvbm1haWwuY2g7IGRraW09cGFzcyAoR29vZCAyMDQ4IGJpdA0KICAg IHJzYS1zaGEyNTYgc2lnbmF0dXJlKSBoZWFkZXIuZD1hZGR5LmlvIGhlYWRlci5hPXJzYS1zaGEy NTYNCkF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IG1haWwucHJvdG9ubWFpbC5jaDsgZG1hcmM9cGFz cyAocD1yZWplY3QgZGlzPW5vbmUpDQogaGVhZGVyLmZyb209cm9rZWp1bGlhbmxvY2toYXJ0LmFk ZHkuaW8NCkF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IG1haWwucHJvdG9ubWFpbC5jaDsgc3BmPXBh c3MNCiBzbXRwLm1haWxmcm9tPXJva2VqdWxpYW5sb2NraGFydC5hZGR5LmlvDQpBdXRoZW50aWNh dGlvbi1SZXN1bHRzOiBtYWlsLnByb3Rvbm1haWwuY2g7IGFyYz1ub25lIHNtdHAucmVtb3RlLWlw PTIxMy4xMDguMTA1LjU3DQpBdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBtYWlsLnByb3Rvbm1haWwu Y2g7IGRraW09cGFzcyAoMjA0OC1iaXQga2V5KSBoZWFkZXIuZD1hZGR5LmlvDQogaGVhZGVyLmk9 QGFkZHkuaW8gaGVhZGVyLmI9Ik9ZOExFYmp0Ig0KUmVjZWl2ZWQ6IGZyb20gbWFpbC5hbm9uYWRk eS5tZSAobWFpbC5hbm9uYWRkeS5tZSBbMjEzLjEwOC4xMDUuNTddKSAodXNpbmcgVExTdjEuMyB3 aXRoDQogY2lwaGVyIFRMU19BRVNfMjU2X0dDTV9TSEEzODQgKDI1Ni8yNTYgYml0cykNCiAga2V5 LWV4Y2hhbmdlIFgyNTUxOSBzZXJ2ZXItc2lnbmF0dXJlIFJTQS1QU1MgKDQwOTYgYml0cykgc2Vy dmVyLWRpZ2VzdCBTSEEyNTYpIChObw0KIGNsaWVudCBjZXJ0aWZpY2F0ZSByZXF1ZXN0ZWQpIGJ5 IG1haWxpbjA1My5wcm90b25tYWlsLmNoIChQb3N0Zml4KSB3aXRoIEVTTVRQUyBpZA0KIDRnajhO NDBOcmd6OHkgZm9yIDwiIkBbSVB2NjoyMDAxOmRiODo6MV0+OyBTYXQsIDIwIEp1biAyMDI2DQog MDk6MzA6NTkgKzAwMDAgKFVUQykNClJlY2VpdmVkOiBmcm9tIG1haWwuYW5vbmFkZHkubWUgKG1h aWwuYW5vbmFkZHkubWUgWzEyNy4wLjAuMV0pIGJ5IG1haWwuYW5vbmFkZHkubWUNCiAoUG9zdGZp eCkgd2l0aCBFU01UUFMgaWQgMzFCRUUzODY5RSBmb3INCiA8IiJAW0lQdjY6MjAwMTpkYjg6OjFd PjsgU2F0LCAyMCBKdW4gMjAyNiAwOTozMDo1OSArMDAwMA0KIChVVEMpDQpSZWNlaXZlZDogZnJv bSBsZXR0ZXJib3gua2RlLm9yZyAobGV0dGVyYm94LmtkZS5vcmcgWzQ2LjQzLjEuMjQyXSkgYnkg bWFpbC5hbm9uYWRkeS5tZQ0KIChQb3N0Zml4KSB3aXRoIEVTTVRQUyBpZCBFN0U3MjEzMDAyRSBm b3IgPDR3eTc4dXdoQHJva2VqdWxpYW5sb2NraGFydC5hZGR5LmlvPjsgU2F0LCAyMA0KIEp1biAy MDI2IDA5OjMwOjU2ICswMDAwIChVVEMpDQpSZWNlaXZlZDogZnJvbSBwaG9lbmkua2RlLm9yZyAo cGhvZW5pLmtkZS5vcmcgW0lQdjY6MmEwMTo0Zjg6YTA6NjAwZTo6M10pIGJ5DQogbGV0dGVyYm94 LmtkZS5vcmcgKFBvc3RmaXgpIHdpdGggRVNNVFBTIGlkIDI0QTFEMzI4RDU1IGZvcg0KIDw0d3k3 OHV3aEByb2tlanVsaWFubG9ja2hhcnQuYWRkeS5pbz47IFNhdCwgMjAgSnVuIDIwMjYgMTA6MzA6 NTMgKzAxMDAgKEJTVCkNClJlY2VpdmVkOiBmcm9tIHd3dy1kYXRhIGJ5IHBob2VuaS5rZGUub3Jn IHdpdGggbG9jYWwgKEV4aW0gNC45NSkgKGVudmVsb3BlLWZyb20NCiA8YnVnemlsbGFfbm9yZXBs eUBrZGUub3JnPikgaWQgMXdhcmNqLTAwN0FyNy0xcCBmb3IgNHd5Nzh1d2hAcm9rZWp1bGlhbmxv Y2toYXJ0LmFkZHkuaW87DQogU2F0LCAyMCBKdW4gMjAyNiAwOTowNDoyMSArMDAwMA0KRGtpbS1T aWduYXR1cmU6IHY9MTsgYT1yc2Etc2hhMjU2OyBjPXJlbGF4ZWQvcmVsYXhlZDsgZD1hZGR5Lmlv OyBzPWRlZmF1bHQyOw0KIHQ9MTc4MTk0Nzg1OTsgaD1mcm9tOmZyb206cmVwbHktdG86cmVwbHkt dG86c3ViamVjdDpzdWJqZWN0OmRhdGU6ZGF0ZToNCiAgbWVzc2FnZS1pZDptZXNzYWdlLWlkOnRv OnRvOmNjOm1pbWUtdmVyc2lvbjptaW1lLXZlcnNpb246DQogIGNvbnRlbnQtdHlwZTpjb250ZW50 LXR5cGU6aW4tcmVwbHktdG86aW4tcmVwbHktdG86DQogIHJlZmVyZW5jZXM6cmVmZXJlbmNlczps aXN0LXVuc3Vic2NyaWJlOmxpc3QtdW5zdWJzY3JpYmUtcG9zdDsNCiBiaD1uYTdybkY5OXZVYW4w VkRFdkQra21WSWJ0SzU0bENQVC9uQk1pK0dhUDJ3PTsNCiBiPU9ZOExFYmp0TWo2eUtkcGZqVWdU WnFrUS9oc2FzL1JyMDRoM2tTNWRZdXg0eUM3eXZqSHlIWXpxUHloaTdRM2x6NEZ6WUMNCiBDNm9O MWtCY0haZFN2SUNsZGVZTEJLR092dklVa3hOcGRCWWVmcTk3YTljZFZPcnJWMkdETVJQcnppNXE3 R2NtUGxMUklLDQogV0FQeGNBcXNGOWNvU1JyNXhGVk1UM2RHMHVpeWFoRGlxcHUxbzUxQ2RERFZl UHNqNmxJNzJZMmFRUmlFelBhQnJpdmdKSw0KIHRDS0t0MURrN0JHNnFNTEpIelR4bzBGT2hjRVZ2 SUxPVkU2N01HVEpXM2lReUkwdnhXUzRYY2dVdVdrT2xBVlpKMURpckQNCiB4dEU0NFRCSHd1NEVF L3Y1czJJUXA2bGV4Sm4xeWNvMnpDTktQcHJTekkwaHV4ck9YMWFpVFBFV0l3MEFyQT09DQpGcm9t OiAiYnVnemlsbGFfbm9yZXBseSBhdCBrZGUub3JnIiA8NHd5Nzh1d2hAcm9rZWp1bGlhbmxvY2to YXJ0LmFkZHkuaW8+DQpUbzogNHd5Nzh1d2hAcm9rZWp1bGlhbmxvY2toYXJ0LmFkZHkuaW8NClJl cGx5LVRvOiA0d3k3OHV3aCtidWctY29udHJvbD1rZGUub3JnQHJva2VqdWxpYW5sb2NraGFydC5h ZGR5LmlvDQpTdWJqZWN0OiBba3dpbl0gW0J1ZyA0MzYzMThdIFN1cHBvcnQgZm9yIHJlYWwgc2Vz c2lvbiBzYXZlL3Jlc3RvcmUgZm9yIHdpbmRvdyBjb250ZW50IGFuZA0KIHN0YXRlIG9uIFdheWxh bmQNCkZlZWRiYWNrLUlkOiBGOmVjZDc5MWNiLTUxZGYtNGQzMS05YmVlLTdlMzlkYmE2MjdiYjph bm9uYWRkeQ0KTWVzc2FnZS1JZDogPGJ1Zy00MzYzMTgtMjM2OTcwLThib21BYjhtdnFAaHR0cC5i dWdzLmtkZS5vcmcvPg0KTGlzdC1VbnN1YnNjcmliZTogPGh0dHBzOi8vYXBwLmFkZHkuaW8vZGVh Y3RpdmF0ZS1vbmUtY2xpY2svZWNkNzkxY2ItNTFkZi00ZDMxLTliZWUtN2UzOWRiYTYyN2JiP2V4 cGlyZXM9MTc4NDUzOTg1NyZzaWduYXR1cmU9ZmI4NDI1Y2ExNTkxMGJjNWY5N2RlZDRlYTBlMTVk ZGE3NWY4Y2UwYmEyYTQwYTAzOTU0ZmRhNTg4ZDA4NThlYT4NCkxpc3QtVW5zdWJzY3JpYmUtUG9z dDogTGlzdC1VbnN1YnNjcmliZT1PbmUtQ2xpY2sNCkluLVJlcGx5LVRvOiA8YnVnLTQzNjMxOC0y MzY5NzBAaHR0cC5idWdzLmtkZS5vcmcvPg0KUmVmZXJlbmNlczogPGJ1Zy00MzYzMTgtMjM2OTcw QGh0dHAuYnVncy5rZGUub3JnLz4NClgtQW5vbmFkZHktQXV0aGVudGljYXRpb24tUmVzdWx0czog bWFpbC5hbm9uYWRkeS5tZTsgZGtpbT1wYXNzIGhlYWRlci5kPWtkZS5vcmcNCiBoZWFkZXIucz11 c2VycyBoZWFkZXIuYj1NWGtYUzdDQzsgc3BmPXBhc3MgKG1haWwuYW5vbmFkZHkubWU6IGRvbWFp biBvZg0KIGJ1Z3ppbGxhX25vcmVwbHlAa2RlLm9yZyBkZXNpZ25hdGVzIDQ2LjQzLjEuMjQyIGFz IHBlcm1pdHRlZCBzZW5kZXIpDQogc210cC5tYWlsZnJvbT1idWd6aWxsYV9ub3JlcGx5QGtkZS5v cmc7IGRtYXJjPW5vbmUNClgtQW5vbmFkZHktT3JpZ2luYWwtU2VuZGVyOiBidWd6aWxsYV9ub3Jl cGx5QGtkZS5vcmcNClgtQW5vbmFkZHktT3JpZ2luYWwtRW52ZWxvcGUtRnJvbTogYnVnemlsbGFf bm9yZXBseUBrZGUub3JnDQpYLUFub25hZGR5LU9yaWdpbmFsLUZyb20tSGVhZGVyOiBidWd6aWxs YV9ub3JlcGx5QGtkZS5vcmcNClgtQW5vbmFkZHktT3JpZ2luYWwtUmVwbHktVG8tSGVhZGVyOiBi dWctY29udHJvbEBrZGUub3JnDQpYLUFub25hZGR5LU9yaWdpbmFsLVRvOiA0d3k3OHV3aEByb2tl anVsaWFubG9ja2hhcnQuYWRkeS5pbw0KWC1Db21wbGFpbnRzLVRvOiBhYnVzZUBoZWxwLmFkZHku aW8NClgtUmVwb3J0LUFidXNlOiBhYnVzZUBoZWxwLmFkZHkuaW8NClgtUmVwb3J0LUFidXNlLVRv OiBhYnVzZUBoZWxwLmFkZHkuaW8NCk1pbWUtVmVyc2lvbjogMS4wDQpEYXRlOiBTYXQsIDIwIEp1 biAyMDI2IDA5OjMwOjU5ICswMDAwDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDtib3Vu ZGFyeT0tLS0tLS0tLS0tLS0tLS0tLS0tLS04YTVmN2VkZjVkMGU2NzE0YzNkYzIzZTEwYWZlMjRj Yw0KWC1QbS1TcGFtOiAweWV6Skk2WVNweUplYzkxenRGR2NqSXdvSnlMQ3ZYQlpjUW5paXNuT0VS SnQ5VFRWT1VkU1JRVWl3c2xPakxkRkpFTA0KIENOMGxTWFoxQkVsRVRqSWJwQXVMVHNWME1JaGtV ZnhVVGtSTzk5TVZGZjFkVFE5ME9CSkZWMVVpUXN3T2xpU3dYU1JGTk45RlRWUlROZA0KIEZRVWJq cElNMEZzVDFrSTBSRWxaU1gwZjAxVFRSVkJGaDBYVVFGUkk2VWlkekJXTEpDVGZaRVVFU01WOU9U MUYwNVRJcGpiczBGTWxJUQ0KIE45UVJsVFZOUUlwamJkQlRMU2Zpd052YzJpbVVjT0Fqc2pObkkz YmxKSTZaQ3NIME1JTm55N3BqSW1JakZsdmRHNmlJYklsbXU0OW1ZaQ0KIElpd3hmYld2Mk5jY1Vt aWlzbk9GVVBKSTZSQzNUTUxMSkNRRTlrVTFYU0JSSlJVSjFSUVQ0MGlzQWpPbElUSm90SWo1aTRN Tnd5aWlFMA0KIFVqT3NBOWtJbDFXSlpaOTFwdlptYmpJN3BCU0lsaTBRVE9zbmloMVdhMlpmVkZ0 Ym02U0laSWhtempGR2QxYW05NWxhVzEzUlhiVm1rMQ0KIEIzWHpYd0lZd01qenpBTUl3aWlwRldi RmJ6OEpmY0hrVzliWndXaXRKaU9XWXNsQnlNM3lTMExNSUQyd0VETWlOdzVJc2RDaG0xSWF4Vw0K IGZ5QjNNM1h5QklpYjJ1akFPTUFEdzNNek1ETXdBQTBNRDNUUU9NZ1QxaXdTTldicEZSbGJIZkhS ZVoxV2lrUldaV2FuNTF2WDJzR1ZaSQ0KIG9qaTA1V2FtWnZ4UXZZWHNYVmJkbEdzbjVXYVdkc0ZV MUxXdFhOTFl4V3Npd2lJRmN6OUZ0Y0d3am9JTEFqd3hjRE1UTjNBTXdORHlEQQ0KIE5OWVR5c0lE TW5JZkJCaGMzaVY5YllOWGx3b2pJakx3QWN4TUQzVEFOTk1Ed3lBRE5UTnlZSXNNRGZuQkljZDNw b05HZDNYdlJCb1gzbw0KIFhOYWE1V253b2pJakx3QUF6TXp4akFOTmdUNTFnVE9UTXhrSXNPRDFu SkliOWx1bDFXWWpJaW94c1lXbFdaTFlSWDF6Vm1jWEwxQk4zWA0KIDNqWFJhYUpDOXMwWGZuSXlO UWlhVzJpSU9ZTVQya1JXTlRObUpFMVpHM0RrT1lFMnczSURPVFlpY2ZYMD0NClgtUG0tT3JpZ2lu OiBleHRlcm5hbA0KWC1QbS1UcmFuc2Zlci1FbmNyeXB0aW9uOiBUTFN2MS4zIHdpdGggY2lwaGVy IFRMU19BRVNfMjU2X0dDTV9TSEEzODQgKDI1Ni8yNTYgYml0cykNClgtUG0tQ29udGVudC1FbmNy eXB0aW9uOiBvbi1kZWxpdmVyeQ0KWC1QbS1TcGFtc2NvcmU6IDANClgtUG0tU3BhbS1BY3Rpb246 IGluYm94DQpYLVBtLUxpc3QtSWRlbnRpZmllcjogQDR3eTc4dXdoQHJva2VqdWxpYW5sb2NraGFy dC5hZGR5LmlvDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tOGE1ZjdlZGY1ZDBlNjcxNGMzZGMy M2UxMGFmZTI0Y2MNCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L3JlbGF0ZWQ7Ym91bmRhcnk9LS0t LS0tLS0tLS0tLS0tLS0tLS0tOWVlZDgxNDQ0MTlmNjI0YWY2ZWQ0ODgzNTZiMWYzODcNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS05ZWVkODE0NDQxOWY2MjRhZjZlZDQ4ODM1NmIxZjM4Nw0KQ29u dGVudC1UeXBlOiB0ZXh0L2h0bWw7Y2hhcnNldD11dGYtOA0KQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogYmFzZTY0DQoNClBIUmhZbXhsSUhOMGVXeGxQU0ozYVdSMGFEb3hNREFsSUNGcGJYQnZj blJoYm5RN0lqNEtJQ0FnSUNBZ0lDQThkR0p2WkhrK0NpQWcNCklDQWdJQ0FnSUNBZ0lDQWdJQ0Fn SUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUR4MGNqNEtJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lEeDAN ClpDQnpkSGxzWlQwaWNHRmtaR2x1WnpveE1IQjRJREFnSVdsdGNHOXlkR0Z1ZER0M2FXUjBhRG94 TURBbElDRnBiWEJ2Y25SaGJuUTcNCklqNEtJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0E4YzNC aGJpQmpiR0Z6Y3owaWRtTmhjbVFpUGp4aElHTnNZWE56UFNKbGJXRnANCmJDSWdhSEpsWmowaWJX RnBiSFJ2T201cGEyeGhjM05oYkcxcGJtVnVKaU0yTkR0d2JTNXRaU0lnZEdsMGJHVTlJbTVwYTJ4 aGMzTmgNCmJHMXBibVZ1SmlNMk5EdHdiUzV0WlNJK2JtbHJiR0Z6YzJGc2JXbHVaVzRtSXpZME8z QnRMbTFsUEM5aFBnbzhMM053WVc0K0lHTm8NCllXNW5aV1FLSUNBZ0lDQWdJQ0FnSUR4aElHTnNZ WE56UFNKaWVsOWlkV2RmYkdsdWF3b2dJQ0FnSUNBZ0lDQWdZbnBmYzNSaGRIVnoNClgxSkZVMDlN VmtWRUlDQmllbDlqYkc5elpXUWlDaUFnSUhScGRHeGxQU0pTUlZOUFRGWkZSQ0JHU1ZoRlJDQXRJ Rk4xY0hCdmNuUWcNClptOXlJSEpsWVd3Z2MyVnpjMmx2YmlCellYWmxMM0psYzNSdmNtVWdabTl5 SUhkcGJtUnZkeUJqYjI1MFpXNTBJR0Z1WkNCemRHRjANClpTQnZiaUJYWVhsc1lXNWtJZ29nSUNC b2NtVm1QU0pvZEhSd2N6b3ZMMkoxWjNNdWEyUmxMbTl5Wnk5emFHOTNYMkoxWnk1aloyay8NCmFX UTlORE0yTXpFNElqNWlkV2NnTkRNMk16RTRQQzloUGdvZ0lDQWdJQ0FnSUNBZ1BHSnlQZ29nSUNB Z0lDQWdJQ0FnSUNBZ1BIUmgNCllteGxJR0p2Y21SbGNqMGlNU0lnWTJWc2JITndZV05wYm1jOUlq QWlJR05sYkd4d1lXUmthVzVuUFNJNElqNEtJQ0FnSUNBZ0lDQWcNCklEeDBjajRLSUNBZ0lDQWdJ Q0FnSUNBZ1BIUm9QbGRvWVhROEwzUm9QZ29nSUNBZ0lDQWdJQ0FnSUNBOGRHZytVbVZ0YjNabFpE d3YNCmRHZytDaUFnSUNBZ0lDQWdJQ0FnSUR4MGFENUJaR1JsWkR3dmRHZytDaUFnSUNBZ0lDQWdJ Q0E4TDNSeVBnb0tJQ0FnSUNBZ0lDQWcNClBIUnlQZ29nSUNBZ0lDQWdJQ0FnSUR4MFpDQnpkSGxz WlQwaWRHVjRkQzFoYkdsbmJqcHlhV2RvZERzaVBsTmxaU0JCYkhOdlBDOTANClpENEtJQ0FnSUNB Z0lDQWdJQ0E4ZEdRK2FIUjBjSE02THk5aWRXZHpMbXRrWlM1dmNtY3ZjMmh2ZDE5aWRXY3VZMmRw UDJsa1BURTENCk16STVDaUFnSUNBZ0lDQWdJQ0FnUEM5MFpENEtJQ0FnSUNBZ0lDQWdJQ0E4ZEdR K0NpQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNadVluTncNCk93b2dJQ0FnSUNBZ0lDQWdJRHd2ZEdRK0Np QWdJQ0FnSUNBZ0lEd3ZkSEkrUEM5MFlXSnNaVDRLSUNBZ0lDQWdQSEErQ2lBZ0lDQWcNCklEd3Zj RDRLQ2dvZ0lDQWdJQ0E4YUhJK0NpQWdJQ0FnSUR4emNHRnVQbGx2ZFNCaGNtVWdjbVZqWldsMmFX NW5JSFJvYVhNZ2JXRnANCmJDQmlaV05oZFhObE9qd3ZjM0JoYmo0S0NpQWdJQ0FnSUR4MWJENEtJ Q0FnSUNBZ0lDQWdJRHhzYVQ1WmIzVWdZWEpsSUc5dUlIUm8NClpTQkRReUJzYVhOMElHWnZjaUIw YUdVZ1luVm5Mand2YkdrK0NpQWdJQ0FnSUR3dmRXdytDZ29nSUNBZ0lDQWdJQ0FnSUNBZ0lDQWcN ClBDOTBaRDRLSUNBZ0lDQWdJQ0FnSUNBZ1BDOTBjajRLSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0Fn SUNBZ0lDQWdJQ0FnSUR4MGNqNEsNCklDQWdJRHgwWkQ0S0lDQWdJQ0FnSUNBOFpHbDJJSE4wZVd4 bFBTSnRZWEpuYVc0Nk1IQjRJR0YxZEc4Z0lXbHRjRzl5ZEdGdWREdHQNCllYZ3RkMmxrZEdnNk9E azJjSGdnSVdsdGNHOXlkR0Z1ZER0d1lXUmthVzVuT2pFd2NIZ2dNakJ3ZUNBaGFXMXdiM0owWVc1 ME8ySmgNClkydG5jbTkxYm1RdFkyOXNiM0k2STJZMVpqZG1ZU0FoYVcxd2IzSjBZVzUwTzNSbGVI UXRZV3hwWjI0NlkyVnVkR1Z5SUNGcGJYQnYNCmNuUmhiblE3YkdsdVpTMW9aV2xuYUhRNk1TNDFJ Q0ZwYlhCdmNuUmhiblE3Wm05dWRDMXphWHBsT2pFeWNIZ2dJV2x0Y0c5eWRHRnUNCmREdDNhV1Iw YURveE1EQWxJQ0ZwYlhCdmNuUmhiblE3WW05eVpHVnlMV3hsWm5RNklETndlQ0J6YjJ4cFpDQWpN VGt5TVRaaklDRnANCmJYQnZjblJoYm5RN1ptOXVkQzFtWVcxcGJIazZJSFZwTFhOaGJuTXRjMlZ5 YVdZc0lITjVjM1JsYlMxMWFTd2dMV0Z3Y0d4bExYTjUNCmMzUmxiU3dnUW14cGJtdE5ZV05UZVhO MFpXMUdiMjUwTENBblUyVm5iMlVnVlVrbkxDQlNiMkp2ZEc4c0lDZElaV3gyWlhScFkyRWcNClRt VjFaU2NzSUVGeWFXRnNMQ0FuVG05MGJ5QlRZVzV6Snl3Z2MyRnVjeTF6WlhKcFppd2dKMEZ3Y0d4 bElFTnZiRzl5SUVWdGIycHANCkp5d2dKMU5sWjI5bElGVkpJRVZ0YjJwcEp5d2dKMU5sWjI5bElG VkpJRk41YldKdmJDY3NJQ2RPYjNSdklFTnZiRzl5SUVWdGIycHANCkp5QWhhVzF3YjNKMFlXNTBP Mk52Ykc5eU9pTXpNak5tTkdJZ0lXbHRjRzl5ZEdGdWREdHZkbVZ5Wm14dmR5MTNjbUZ3T21KeVpX RnINCkxYZHZjbVFnSVdsdGNHOXlkR0Z1ZER0aWIzZ3RjMmw2YVc1bk9tSnZjbVJsY2kxaWIzZ2dJ V2x0Y0c5eWRHRnVkRHNpUGdvZ0lDQWcNCklDQWdJQ0FnSUNCVWFHbHpJR1Z0WVdsc0lIZGhjeUJ6 Wlc1MElIUnZJRHh6Y0dGdUlITjBlV3hsUFNKbWIyNTBMWGRsYVdkb2REbzENCk1EQWdJV2x0Y0c5 eWRHRnVkRHRqYjJ4dmNqb2pNVGt5TVRaaklDRnBiWEJ2Y25SaGJuUTdJajQwZDNrM09IVjNhRUJ5 YjJ0bGFuVnMNCmFXRnViRzlqYTJoaGNuUXVZV1JrZVM1cGJ6d3ZjM0JoYmo0Z0tGQjFjbkJ2YzJV NklDWnhkVzkwTzJoMGRIQnpPaTh2WW5WbmN5NXINClpHVXViM0puTDNWelpYSndjbVZtY3k1aloy ay9kR0ZpUFdGalkyOTFiblFqT240NmRHVjRkRDBvYjNCMGFXOXVZV3dsTWtNbE1qQmkNCmRYUWxN akJsYm1OdmRYSmhaMlZrS1RvdExFNWxkeVV5TUdWdFlXbHNKVEl3WVdSa2NtVnpjem9zTFUxNUpU SXdRblZuY3laeGRXOTANCk95a2dabkp2YlNBOGMzQmhiaUJ6ZEhsc1pUMGlabTl1ZEMxM1pXbG5h SFE2TlRBd0lDRnBiWEJ2Y25SaGJuUTdZMjlzYjNJNkl6RTUNCk1qRTJZeUFoYVcxd2IzSjBZVzUw T3lJK1luVm5lbWxzYkdGZmJtOXlaWEJzZVVCclpHVXViM0puUEM5emNHRnVQanhpY2o1RGJHbGoN CmF5QThZU0JvY21WbVBTSm9kSFJ3Y3pvdkwyRndjQzVoWkdSNUxtbHZMMlJsWVdOMGFYWmhkR1V2 WldOa056a3hZMkl0TlRGa1ppMDANClpETXhMVGxpWldVdE4yVXpPV1JpWVRZeU4ySmlQM05wWjI1 aGRIVnlaVDFoTW1aaE5XUTVPVEF6WmpKaE9URTNNbUU0WXpOa1pXRmgNClkySTFNV0V5WXpNNE1U QXpZVEZpTnpRMk9XVmpaR1l5WlRkbFpHUXlNemcxTUdWaFpUTXdJaUJ6ZEhsc1pUMGlZMjlzYjNJ Nkl6SmsNCk0yRTRZeUFoYVcxd2IzSjBZVzUwTzNSbGVIUXRaR1ZqYjNKaGRHbHZianAxYm1SbGNt eHBibVVnSVdsdGNHOXlkR0Z1ZERzaUlIUmgNCmNtZGxkRDBpWDJKc1lXNXJJaUJ5Wld3OUltNXZj bVZtWlhKeVpYSWdibTl2Y0dWdVpYSWdibTltYjJ4c2IzY2lQbWhsY21VOEwyRSsNCklIUnZJR1Js WVdOMGFYWmhkR1VnZEdocGN5QmhiR2xoY3dvZ0lDQWdJQ0FnSUR3dlpHbDJQZ29nSUNBZ1BDOTBa RDRLUEM5MGNqNGcNCklDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lEd3ZkR0p2WkhrK0NpQWdJQ0E4 TDNSaFlteGxQZ289DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTllZWQ4MTQ0NDE5ZjYyNGFmNmVk NDg4MzU2YjFmMzg3LS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tOGE1ZjdlZGY1ZDBlNjcxNGMz ZGMyM2UxMGFmZTI0Y2MtLQ0K