Restoring the screen after KDE restarts

[Duncan]

Dave Close posted on Sat, 19 Sep 2026 13:23:39 -0700 as excerpted:

> I'm running the latest Fedora 44 fully updated on X11 with KDE 5
> (kf5-plasma-5.116.0-5.fc44.x86_64.rpm and related packages). I typically
> have at least eight virtual desktops active.
> 
> Years ago, probably with an earlier version of KDE, when I would shut
> down KDE and restart it (usually in conjunction with a reboot), KDE
> would restore all the active windows to their previous positions on the
> appropriate desktops. For the last few years, that doesn't happen.
> Instead, most windows are positioned on one of the desktops, usually the
> last one visible before the shut down, and a few are opened multiple
> times with different geometries.
> 
> I've been patiently waiting, hoping that KDE developers would eventually
> address this issue. Now, with the recent rash of new kernels related to
> security issues discovered by AI models, I seem to be booting much more
> often than before. This leads to enough frustration for me to post here.

You may know this (perhaps all too well) and I'm nearing a month late 
responding, and also... fairly, some of this is ranting... but FWIW...
If you'd rather skip the old versions and security rant, skip to the *** 
below (or even to the **** a couple paragraphs later if you want to skip 
the initial explanatory and transition), which has a more direct answer to 
your reliable session restore question.

**

While a distro may still choose to support it and of course users may 
still install and run the older packages, KDE 5 is rather behind current 
and as a whole hasn't been supported by KDE for some time -- a few months 
ago they even dropped the CI builds of the last few straggler still kde5 
supporting apps that required kde5 frameworks so they could drop the kde5 
frameworks from the CI machines and reclaim the space and build times to 
better support newer releases.

Maybe someone in the community is doing what the Trinity desktop effort 
did (and continues to do, they're still doing release) with kde3, pulling 
the old sources, forking them, and continuing to update them after 
upstream considers them ancient git history (kde3 was of course still svn, 
but I can't imagine even trinity not switching to git by now...).

And of course I haven't even mentioned yet that upstream qt5 support was 
dropped long before kde5 was dropped, and it was in fact kde that was 
continuing the qt5 support and releases, which of course have been done 
for awhile now too.

So it seems... rather curious... that someone's so concerned about all the 
long undiscovered kernel security issues AI is digging up that they're 
rebooting much more frequently to get the new kernels, but are still 
running long dead and out of security support not only kde5, but the even 
longer dead and out of support qt5 it depends on.  How many security bugs 
would AI be finding in them if it looked, and perhaps more practically 
*IS* finding in current versions, that get patched, while the very same 
now known and exploitable by all and sundry security issues remain -- now 
known and must-be-considered-exploited -- in the old versions?

I get being worried about security, but be consistent about it then.  Of 
course as I said distros may still choose to "support" it, but are *they* 
doing all those backports?  What if they miss one that ends up being the 
way some blackhat gets access to your systems?  Are they going to make you 
whole, somehow hiding all the data you lost to the hack that's now out 
there on the dark-net if you don't pay the data-ransom?  Maybe they'll 
simply pay the data-ransom for you?  Oh, you said Fedora, not Red Hat 
Enterprise Linux... so you're not paying for that level of support (unless 
you have third party insurance or a third party support contract for it, 
which is I suppose possible), so I suppose not.

So I'd suggest in all likelihood... either you need to worry about 
security and do all those reboots for new kernels, but *also* need to 
consider the age and security-support (of course along with the bugfix 
support that triggered the original post) of your other software... or 
your situation isn't quite that security-critical and you can afford to 
wait on the other software, and skip some of those kernel-security-update 
reboots too.  As is... I seem to remember a meme having to do with a fancy 
expensive locked gate... without so much as a fence attached to it, so 
people just walk around the gate.

***

Meanwhile, while older X11-based kde6 *is* still supported and currently 
getting updates, it's not where the development focus is (and FWIW I run 
most of my kde from live-git using the gentoo/kde packages for that 
purpose, and regularly review the git logs as well as discussion on 
several of the development lists, so I know "a bit" about current focus).  
In fact, even back in the late kde5 development era the devs were focusing 
on "wayland first features; we're continuing X11 support but not doing 
features unless they can be done on wayland and implemented on X11 without 
too much additional trouble."  But while with late kde5 wayland was 
already the kde dev focus and it did work to some degree kde5 (I ran it so 
I know!), kde's wayland support didn't and couldn't really mature until 
kde6 since it depended on qt6 with its own much more mature wayland 
support.  Tho it still took some time after the initial kde6/qt6 porting.

And of course current development has dropped X11 kde sessions entirely 
(X11 apps are still supported via xwayland and there's enough legacy X11 
apps that shouldn't be going away for... I'd say maybe a decade??? it'll 
be quite some time anyway, tho of course there's some limits to that 
especially with apps where a major part of the purpose was taking 
advantage of X11 features like the ability to spy on the input stream of 
any X11 app that turned out to be security issues because that means they 
can spy on password imput too), allowing dropping of a whole slew of old 
compatibility code while kde-wayland continues to improve.

****

Which finally leaves me in a position to directly answer your question.  A 
big reason session support was left partially/mostly broken for so long 
was because insufficiencies in the old X11 session solutions (like the 
ability to restart all the konsole windows where they had been, but with 
no way to bring back the history of what was actually *in* all those 
konsole windows, that Konstantin mentioned in his reply) were beginning to 
pile up, and with wayland on the horizon, nobody was interested in doing 
the hard work twice, both for the new wayland and its session protocol 
extension, AND to bring the soon-to-be-legacy X11 session protocol into 
the modern age as well.

And, you should be happy to read, I can indeed report that current KDE has 
made leaps and bounds progress in this area, as it implements support for 
both the (relatively) new wayland session extension, and qt-and-kde-
specific solutions beyond that extension where the current version of the 
wayland session extension and protocol isn't entirely fleshed out yet.

So they are indeed making *big* progress in this area now, after 
admittedly so long without, but you won't get it with the now out of 
support kde5, and you won't even get it with older kde/plasma/frameworks/
qt 6, because the support is newer than that.  Which again means you can 
run your older version if that's what you prefer (and/or what your 
preferred distro prefers), but there are tradeoffs to that choice, one of 
which is that you don't get the newer features like the new and much 
*much* improved session restore support.

(Meanwhile, while kde wayland support was good enough for me even back in 
the later kde5 era, honestly, the feature that remains lacking for me as 
compared to long ago kde on X11 versions, is proper kde-level with 
integrated kde-level graphical-interface scripted input and dynamic window 
sizing/positioning support, as was available in old-time X11 kde via 
khotkeys and friends, tho that too was broken for quite some time (since 
the end of the kde4 era??) and thus was removed as a blocker for removing 
kde/plasma X11 session support.  Because of the lax security of X11 third-
party X11 tools such as xdotool and wmctrl could fill that gap while still 
on X11, and wayland does have some in some ways much more limited (tho in 
other ways less limited, it hooks into the kernel-level event-dev input 
interface so isn't limited to the GUI...) alternatives such as ydotool on 
the input side, but that's lacking anything like the GUI configuration let 
alone KDE integration of khotkeys and friends, and other than the static-
config kwin window rules which don't address dynamic window sizing and 
positioning needs at all, I've yet to find *anything*, kde or third-party, 
to replace the scriptability and thus dynamic-repositioning/resizing 
ability, of wmctrl and some of the windowing functionality of xdotool.  So 
it's not all roses without thorns, but I'm honestly really *really* amazed 
at kde/plasma's recent progress overall, and have learned to either work-
around (ydotool input scripting) or do without (dynamic window resizing/
repositioning) a few corner-case features... hopefully temporarily, of 
course.  Just saying, it's not perfect, nothing is, but it works for me if 
in some cases that means I've bent to it not it to me.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman