Bug 326893

I can confirm the described behaviour. I encounter the same using KDE 4.11.2 on Kubuntu 13.10

Me too confirm the behaviour. It did not happen with Kubuntu and KDE 4.10.
I have changed KDE set to start an empty session and added scripts with wmctrl command to start the applications on different virtual desktops on the starting of the system.

http://kde.6490.n7.nabble.com/Session-management-effectively-broken-td1538259.html

QApplication::isSessionRestored() is (still) always false for me (in KWin)
And I doubt that this is some recent development, since kwin relies on that function at least since 

commit 05507ee2939e4d5420f3c9599d00986906d61959
Author: Luboš Luňák
Date:   Sun Apr 29 17:35:43 2007 +0000

    branches/work/kwin_composite becomes new trunk kwin.

which is the root of our commit history...

Afaics, startkde/ksmserver however needed to start kwin with the "-session" switch (where the <session> parameter apparently can just be "0" - QApplicationPrivate assigns is_session_restored as long as there's the switch and some parameter (while session id and key will be naturally junk)

No idea whether or why that has ever been changed in startkde.

First noticed this a couple of subreleases ago in Arch.  Dolphin and Kmail always restored to the correct desktop, as did konsole.  Non-kde apps all restore to the desktop from which I initiate the shutdown.

Just installed openSuSE 13.1 with Thunderbird.  Konsole still opens on correct desktop, Chrome, Thunderbird and Firefox all open on the desktop I was using at shutdowm

The application can of course keep this info as well; it's just not maintained by kwin, as kwin is - as much as i can say - really never invoked ::isSessionRestored() == true

On 20/11/13 16:27, Thomas Lübking wrote:
> https://bugs.kde.org/show_bug.cgi?id=326893
>
> --- Comment #5 from Thomas Lübking <thomas.luebking@gmail.com> ---
> The application can of course keep this info as well; it's just not
maintained
> by kwin, as kwin is - as much as i can say - really never invoked
> ::isSessionRestored() == true
>
That does not make sense.  All prior versions of KDE always restored all
- including non-KDE - applications to the correct desktop.

This bug exhibits the effect of only restoring KDE applications, and
piles all others on top of each other on the last desktop in use at
shutdown.  How can a non-KDE app 'keep this info as well'?  This
misbehaviour is damaging to the reputation of the best desktop
environment there is.  Would I rather use a Mac? No- and I shudder at
the prospect of the horrible Gnome desktop, while Windows is beneath
contempt.

There has been nothing as good as KDE since I encountered KDE2.  Please
restore it to its full glory.

The kwin code didn't change since 2007...
No idea what else would have changed (fast grepping the startkde/ksmserver log didn't help)

Every application can of course store and restore it's virtual desktop - it's public information.

On 20/11/13 17:39, Thomas Lübking wrote:
> Every application can of course store and restore it's virtual desktop - it's
> public information.
You seem to be saying that the KDE devs have deliberately removed one of
its great features and expect every app out there to adapt to make up
for it.  I thought that the motivation for Matthias Ettrich was to
produce a uniform desktop environment - he was frustrated by every app
doing its own thing and doing it differently.  If all (non KDE) apps
must handle everything for themselves, what is the benefit of a desktop
environment over a window manager?

Whichever way you want to look at it, removing a great feature that has
been there for so many years is - if not a bug - a very retrograde step.
will KDE be going clunky and dumbed down like Gnome next?

I generally use KDE apps, but there are some things for which I must use
others - such as Chrome/Firefox/Opera/Gimp.  I used to love
demonstrating the benefits of Linux/KDE by showing how I not only had
multiple virtual desktops but ones that reinitialised when booting.  Now
I have a horrible mess where I cannot get at my KDE apps because of a
pile of non-KDE apps sitting on top of them

No idea what else would have changed (fast grepping the startkde/ksmserver log didn't help)
Try diffing between versions.  This is definitely a problem that should not have occurred.  If the code you are looking at hasn't changed since 2007 the problem must be elsewhere - in code that appeared in late 4.10 or in 4.11, I believe.  Unfortunately its beginnings in my Arch system were initially masked by a different problem that I had at the time.

> You seem to be saying that the KDE devs have deliberately removed
Please don't put stupid bullshit in my mouth. Thank you.
Nobody has even remotely suggested deliberate action.

Proof that it's not a kwin issue: run
kwin -session $(ls -1 "$(kde4-config --path config | cut -d':' -f1)session" | sed -e '/kwin/!d; s/kwin_//g')

(ensure that
ls -1 "$(kde4-config --path config | cut -d':' -f1)session"
actually lists your session data)

-> Session is properly restored.
Even adding that as KDEWM export to startkde doesn't help - kwin started through ksmserver does not receive those parameters and is started with isSessionRestored false

So much from my side - i've really no interest in further dealing with some ppl. around here.

I'm sorry that this thread degraded; Norman's comments were out of line.

FWIW, KDE applications are being restored to the correct positions; I could have swore that they weren't restored correctly when I filed this bug, but maybe I'm just crazy. (Perhaps I was just fooled by a combination of bug 317278 and non-KDE applications being restored incorrectly.)

Still, many non-KDE apps aren't being restored correctly; I tested a bunch of random ones and Firefox, Gerbv, Thunderbird, wxMaxima, DOSemu, Chrome, gitg, and inkscape have this problem. Some non-KDE applications did restore correctly, like LibreOffice Writer, xterm, GNU Emacs.

If the issue isn't with KDE, does anyone have thoughts on where the problem lies and whose attention we should bring this to? I guess I could file bugs with all the problem applications, but that doesn't sound like the right approach. I recall that these applications used to restore correctly, so I'd guess that they didn't all break at once; these issues probably have a common cause.

Did not mean to offend, but I was misled by Thomas's insistence on apps maintaining the information  for themselves.  I gained a false impression and apologise.

Thomas goes on to say:

Proof that it's not a kwin issue: run
kwin -session $(ls -1 "$(kde4-config --path config | cut -d':' -f1)session" |
sed -e '/kwin/!d; s/kwin_//g')

(ensure that
ls -1 "$(kde4-config --path config | cut -d':' -f1)session"
actually lists your session data)

-> Session is properly restored.
Even adding that as KDEWM export to startkde doesn't help - kwin started
through ksmserver does not receive those parameters and is started with
isSessionRestored false

So he has actually narrowed down the area at fault.  What now needs to be investigated is how ksmserver handles accessing and passing on session information.  The session information *is* getting through for KDE apps but not for non-KDE apps.

Created attachment 84138 [details]
kwin session file where restore of thunderbird on correct desktop fails

For me the issue of non KDE apps being restored to the virtual desktop loaded at startup started to appear with the release of 4.11.0. Before this everything was fine, with this new series firefox and thunderbird were always restored to the desktop active at start (which is identical to the one open at shutdown).

Interestingly the session file for KDE shows the applications firefox and thunderbird associated to the correct desktop each (firefox to 3 and thunderbird to 4). I attached my session file.

What should happen (got 4 virtual desktops):
1) Nothing on desktop 1.
2) Konsole on desktop 2.
3) Firefox, konversation, kopete and kaffeine on desktop 3.
4) Thunderbird on desktop 4.
5) Superkaramba on all desktops.
6) Plasma loaded and on all desktops.
7) At start restore to desktop 3.

What was interesting is that firefox and thunderbird had no /usr/bin/ prefix in their wmcommand?= entry. But changing that one had no effect on thunderbird being shown on the wrong desktop instead of on desktop 4.

Randomly returning:
a) I did and do not insist that applications would store this data, but said they *can* re/store this data as well (comment #5)
b) nobody has said the issue would not be with KDE. It *is* with KDE - apparently with the way KWin is invoked by the session manager.
c) please be aware that FF/TB are about the worst clients to test this, for Mozilla is /very/ eager to get them in sight and for this purpose either tries to move them to the current desktop or change the current desktop whenever it feels like. For clean testing, i suggest a client like xterm.

xterm was restored correctly. (I tested a number of applications and noted in comment 12 which did and did not restore correctly.)

Let me know if there are more applications I should test.

This is a two level issue (was for me)

1. ps ax | krep kwin
  556 ?        Sl     0:11 /usr/bin/kwin --replace -session 10d3d76761000138940825800000024960000_1389410931_93899

If there's no "-session <key>" parameter, you're facing a condition where kwin is started w/o being asked to restore the window attributes from the last session.

Happened to me because ksmserver is very picky about reloading stuff.
If the stored restart/command does not fit the expected WM command, it will just call the configured WM w/o any further parameters (including session control)
(Here, "kwin" is a script to call /usr/bin/kwin, thus leading to mismatching "kwin" ./. "/usr/bin/kwin" comparism)

2. Beyond that (well, now that session restorage works in principle), apparently clients like at least TheGimp do not set/restore SM_CLIENT_ID - neither directly, nor on their leader window.
SM_CLIENT_ID is the relevant property for session restorage, but KWin has some heuristics to match the session data to the new window anyway.

I assume this broke by making the wmClientMachine detection asynchronous, see bug #308391 - "and the case of session management is" not ultimately so "very academic" since WM_CLIENT_MACHINE is $(cat /etc/hostname) - not the stored "localhost"

tl; dr:
Those windows do actually simply not support session management, but nevertheless there's a regression in KWin's workaround for that.
         -> (2) is a KWin bug, (1) is ebkac


@Martin
The intended patch is to drop client machine comparism on session restorage heuristics (to cause the academic problem ;-)

FTR, this is *far* more complex.

1. hostname resolution matches arbitrarily ie. depends on threading, what mostly depends on whether the resolution is cached by the system etc.

2. eg. "chromium" has some junk (not valid utf-8) character trailing the WM name (here) - so it fails on that test as well

3. eg. qupzilla does not even make it into session storage, ie. the window closed before kwin was told to save the session

Only hostname mismatch would be a new problem - everything else *must* have been present before 4.11

For the "WM_COMMAND contains junk" issue we'd have to check  whether that's part of getStringProperty() or the property is really "broken" - and in the latter case loose the heuristics
I've atm. no idea on how to deal with the "i'll just piss off early" case - we cannot record windows that have already gone.

Git commit 2d156caaf93291514723e3f811d25e534f88ac23 by Thomas Lübking.
Committed on 11/01/2014 at 11:50.
Pushed by luebking into branch 'KDE/4.11'.

cut spurious \0 byte from string properties

added with 26c263cc1de9cf0af66c12d0d746cd8ae7b1744a
FIXED-IN: 4.11.6
REVIEW: 114963

M  +4    -1    kwin/utils.cpp

http://commits.kde.org/kde-workspace/2d156caaf93291514723e3f811d25e534f88ac23

Git commit cad8faa9ed14b7ee4f3a9928d2ff955aecfa0b3c by Thomas Lübking.
Committed on 11/01/2014 at 11:52.
Pushed by luebking into branch 'KDE/4.11'.

remove clientMachine from session handling

since the hostname is resolved asynchronous, testing it can easily fail
FIXED-IN: 4.11.6
REVIEW: 114963

M  +0    -4    kwin/sm.cpp

http://commits.kde.org/kde-workspace/cad8faa9ed14b7ee4f3a9928d2ff955aecfa0b3c

Shouldn't this issue be closed?

Let's say "fixed what was fixable"
Early leaving clients are violating the session protocol and as we recently figured Qt4 & Qt5 are completely broken itr and were only covered by KApplication/KMainWindow in Qt4; Qt5 situation is "evolving" (ie. there's now a flag that allows clients to override the broken-by-default behavior)