when leaving my KED/plasma session, its is saved.
on restore, one window is restored not one, but multiple times.
How can I delete these additional windows in the stored sessions?
I didn’t find the place where the information is stored.
You’re using X11, right? I wonder if this is an intentional upstream misfeature to nudge X11 users onto Wayland. It’s been happening here a very long time, since last year at least.
yes, I’m using X11, and this only happens to the window of an old X11 application.
Let’s welcome more of these conspiracy theory starters. Even masking this insinuation with an “I wonder if” doesn’t help making it less than an unfounded inisinuating accusation.
3 Likes
but the fact that the problem occurs only for an old X11 application might(!) be relevant
It might be. I would suggest creating a fresh user, and do some testing with that new user’s Plasma X11 and Plasma Wayland. Even repos involved might play a role, show zypper lr -d.
Remember Hanlon’s razor.
Not everybody is out there to get you. 
X11 is probably just not very popular anymore in the KDE devs world; it may simply be very neglected in favor of Wayland.
1 Like
This may very well be the case. Session management is probably very different between X11 and Wayland.
| KDE Plasma stores the saved application session restore state in the file ~/.local/state/plasmasessionrestorestaterc
https://share.google/aimode/b9wwYjT4FusZ0EwAY
If you can’t remove that one window that you want to get rid of, removing the file may be an option. Better move it to a safe location first.
1 Like
Considering the Upstream KDE project has already yeeted all the X11 code out of kwin, plasmashell, and the rest of the desktop, in preparation for the 6.8 release, you would be correct.
There’s no conspiracy happening here, and it gets really tiring seeing certain people claim there is.
3 Likes
This behavior sprung out of apparent nowhere long ago, but may have been after the announcements that X11 support termination would arrive with 6.8, and that non-blocking X11 bugs were no longer worth the attention of developers.
It happens to me on all my remaining 6.7 installations, including one that was a fresh installation 6 months ago. As I typically don’t leave much open on session exit, apps I’m sure get multiplied are limited to Xterm and File Commander (a GTK app direct from its author of >30 years that I’ve been using since OS/2 2.1).
TBC, those extras left open on session exit increase in number on next session open, with all on the primary display, and #1 virtual desktop, so only by apparent accident do any show up in their previous window position.
Similar problem in:
# inxi -GS
System:
Host: ab250 Kernel: 6.8.0-138-generic arch: x86_64 bits: 64
Desktop: KDE Plasma v: 6.7.4 Distro: KDE neon 24.04 User Edition noble
Session just opened with 1 Konsole window, 2 FCL windows, 1 Quick Settings window, and 9 Welcome - Kate windows, none of which located in position in which were open on session exit, and FCL not on virtual desktop 4 and display 3 where I use it.
- number of the windows does not increase
- position is arbitrary
- they are located on the active workspace after login, not on the one they were used on
- only for one application
this file contains here only the names of the programs, but not the actual call of the program with options.
where are these stored?
A text editor, for instance, would save the names of the loaded files and would reload them when you log in again. Another major advantage of the new protocol is the support for a clean and safe logout procedure even if the users decides not to restore the session next time. The protocol gives applications the possibility to interact with the user if they are in danger to lose some data, and to cancel the shutdown process if necessary.
In other words, everything but the basics is something the application itself needs to take care of; it needs to implement certain methods to save and restore the session. By convention, Qt / KDE applications save their settings to somewhere below ~/.config/<org-name>/<app-name>. But this is only a convention, not enforced.
See also the link and the examples there.
BTW I couldn’t find a timestamp in those docs; they may be up to date, or they might be 20 years old. This is a common (but sloppy) thing with online docs; it’s the bane of all developers.
1 Like
this misses my point.
imagine I open a program like
ximageviewer image.jpg
after loging out and in again, the image is displayed .
the file ~/.local/state/plasmasessionrestorestaterc however only contains something like
[7]
appId=ximageviewer.desktop
so the information to open the file image.jpg must be stored somewhere else by the system (and not the program ximageviewer itself): where?
~/.local/state/<nameofyourapphere>rc
There are as example the last opened pictures or states of app saved.
~/.local/state/plasmasessionrestorestaterc lists the last open windows/apps whatever. But the dedicated state is saved as example in the same directory ~/.local/state/ but with the app name.
there is no such file for my application under that directory.
the directory contains some files, but not for all applications of the session,
Where is this application from? It seems not from an official openSUSE repo?
ximageviewer is just a made up name as a replacement
It would really help if you would work with real output and examples. In this way, users can try to reproduce your issues or search for the informations you missed…
1 Like