Bug 341930 - Session management in porting preproc branch
Summary: Session management in porting preproc branch
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: git master
Platform: Arch Linux Linux
: VLO minor
Target Milestone: 5
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/123...
Keywords:
: 341336 342086 343843 344856 348566 349135 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-15 22:54 UTC by Guillaume DE BURE
Modified: 2016-03-10 06:31 UTC (History)
33 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: ReviewRequest+


Attachments
update to review #123580 patch (1.74 KB, patch)
2015-05-15 21:27 UTC, Stefan Becker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume DE BURE 2014-12-15 22:54:42 UTC
When starting a new session (after reboot or logout), applications that were left open on various Activities / Desktops are all restarted on the first Activity, on the first Desktop, instead of being restarted on their previous location.

Reproducible: Always

Steps to Reproduce:
1. Place some applications on various Activities and Desktops
2. Logout or Restart
3. Login in the same session as in 1

Actual Results:  
Applications are all restarted on Desktop 1 in first Activity

Expected Results:  
Applications should have been restarted on the same Desktop and Activity as they were when session was quit.

Plasma Desktop 5.1.1 using Frameworks 5.5.0
Comment 1 Guillaume DE BURE 2015-01-27 21:50:32 UTC
Still there in 5.2. Is there anything I can do to help ? Anyone else noticing this ?
Comment 2 Ivan Čukić 2015-01-28 10:21:38 UTC
Unfortunately, this is not something that we have the control over with the X session protocol.

If we get something else in place, this might be fixed, but that is not going to happen any time soon.
Comment 3 Guillaume DE BURE 2015-01-28 12:06:53 UTC
Thanks for the feedback, Ivan. Does it mean Wayland should be preferred to X for this issue ?
Comment 4 Ivan Čukić 2015-01-28 14:23:23 UTC
No. The only benefit of Wayland here is that we will need to implement the sessions in a new way. Which will benefit both X and Wayland.

The problem is that non-KDE applications will probably never support this. Gnome people have decided they do not care about sessions (AFAIK).
Comment 5 Anders Lund 2015-02-02 17:30:47 UTC
Confirmed.

This works in KDE 4, so how can it be different in KF 5? Same X.org afaik...
Worse, this renders activities useless. Even windows from a closed activity is opened in the wrong place.
Comment 6 Anders Lund 2015-02-02 20:26:17 UTC
Ivan, what does it matter what gnome people thinks? this affects kde applications (as well).
Comment 7 Ivan Čukić 2015-02-02 20:52:27 UTC
> This works in KDE 4, so how can it be different in KF 5? Same X.org afaik...

Will see whether something has changed. For me, it did not work on 4 as well. Will see to bring this up to the level it had in kde 4.
Comment 8 Anders Lund 2015-02-02 22:03:17 UTC
Thank you Ivan! You rock!
Comment 9 Thomas Lübking 2015-02-03 01:40:04 UTC
Virtual desktop and activities are stored in the kwin session data - the client has no word in this.

Session management is branched in "#if KWIN_QT5_PORTING" which is currently defined 0 in kwinglobals.h (but I don't know why atm. either)
Comment 10 Martin Flöser 2015-02-03 07:05:06 UTC
> Session management is branched in "#if KWIN_QT5_PORTING" which is currently defined 0 in kwinglobals.h (but I don't know why atm. either)

When I started the porting Session management was broken in Qt and made the code not compile. That's why it's in an ifdef. Apparently nobody cared so far to port it since then.
Comment 11 Guillaume DE BURE 2015-02-03 11:31:48 UTC
I can confirm it worked in 4 for me as well. Looking forward to see this back, it's one of the killer features of the Plasma Desktop, IMHO :)
Comment 12 Ivan Čukić 2015-02-03 11:38:42 UTC
I'll see whether it can work now. 

@Thomas Lübking
Thanks for investigating this!
Comment 13 Thomas Lübking 2015-02-06 10:51:23 UTC
*** Bug 343843 has been marked as a duplicate of this bug. ***
Comment 14 Ivan Čukić 2015-02-20 18:15:10 UTC
Can anyone test whether the session management works in, for example, kate:
 - open a document
 - log out
 - log back in
 - kate should be open *with* that document inside

Why kate? It properly saves the session information for me, but I do not see it restored - the application gets started, but empty.
Comment 15 Guillaume DE BURE 2015-02-20 21:19:18 UTC
Hi Ivan,

I can confirm that behaviour, kate is restarted, but without the doument opened. This is still on 5.2 through Archlinux packages. Did you want us to test on master ? Cause I'm not proficient enough to build the plasma desktop from git :(

Thanks for your efforts on this !
Comment 16 Thomas Lübking 2015-02-21 21:59:47 UTC
before I log out: what's the commandline of the kate process that should have restored the document?
Comment 17 Ivan Čukić 2015-02-21 23:33:23 UTC
This is what I get from ps aux | grep kate
/opt/kf5/usr/bin/kate -session 10d372616b000142456137800000121810009_1424561394_855171

And, the file 
.config/session/kate_10d372616b000142456137800000121810009_1424561394_855171
does exist
Comment 18 Thomas Lübking 2015-02-22 01:17:48 UTC
Well, that implies the global session management is intact, but kde apparently didn't port it (correctly) just as much as kwin did not.
Comment 19 bill p. (aka google01103) 2015-03-01 17:54:37 UTC
Would this also cause my restored sessions windows to not be placed in their previous locations on the desktop but to be placed according to the initial placement as defined in systemsettings -> window behavior -> window behavior -> advanced -> placement.
Comment 20 Thomas Lübking 2015-03-05 11:29:21 UTC
*** Bug 344856 has been marked as a duplicate of this bug. ***
Comment 21 Graham P Davis 2015-03-27 17:46:27 UTC
Just upgraded to 5.2.2 and still got this problem. This makes Plasma-5 unusable as far as I'm concerned. Any chance of the "importance" level being shifted up a notch or so?

I can also confirm that the problem doesn't exist on the same machine and same user.
Comment 22 Graham P Davis 2015-03-27 18:03:57 UTC
(In reply to Graham P Davis from comment #21)
> Just upgraded to 5.2.2 and still got this problem. This makes Plasma-5
> unusable as far as I'm concerned. Any chance of the "importance" level being
> shifted up a notch or so?
> 
> I can also confirm that the problem doesn't exist with KDE4 on the same machine and
> same user.

Inserting "with KDE4" makes a lot more sense. Deary me!
Comment 23 Ömer 2015-04-04 00:28:19 UTC
Any update on this?
I am also effected by this and would like to see a fix :)
Comment 24 Guillaume DE BURE 2015-04-14 23:18:01 UTC
Just upgraded to 5.2.95, and bug is still there. Any chance of seeing this fixed before 5.3 is released ? Can I help with some testing or anything else ?

Thanks :)
Comment 25 Martin Flöser 2015-04-15 06:10:26 UTC
It needs someone who cares about session management (not me) to remove the ifdefs from KWin and port it to the new API in Qt 5. Given that this hasn't happened for over a year, I doubt it will happen this week to make it into 5.3.
Comment 26 Ivan Čukić 2015-04-15 07:24:56 UTC
I did start playing around with it, but I don't expect it to be in 5.3.
Comment 27 Laurent Bonnaud 2015-04-28 17:53:10 UTC
This bug is still there in Plasma 5.3.0 KF 5.9.0 (Kubuntu 15.04 + backports).
Comment 28 Thomas Lübking 2015-04-28 20:39:21 UTC
*** Bug 341336 has been marked as a duplicate of this bug. ***
Comment 29 mournblade 2015-04-28 23:05:09 UTC
I just updated to plasma5 from kde 4.x and was shocked to see session management across desktops completely broken  in what is supposed to be the third major "stable, non-beta" release.  I thought, I'd learned my lesson from the premature release of 4.x and waited 9 months to try, but apparently didn't wait long enough.  I've been using KDE for 8 years, but have moved to another desktop until this issue gets resolved.  It's disturbing to learn that the devs have apparently lost interest in session management.
Comment 30 Thomas Lübking 2015-04-28 23:40:16 UTC
> what is supposed to be the third major "stable, non-beta"

No, it's not.
Plasma 5 is not nearly ready for productive use and there also still major bugs in (released) Qt5 versions.

It's "reliable and usable enough™" for everyday testing (you can install it next to other desktop environments, some distros allow to aside it next to KDE4) and development on it and you're encouraged to do so, but there still be monsters (worse than this, the QScreen::handle() bug killed my ksmserver today...)

Somebody tells you different: he's lying. Period.
The numbers are marketing bs. Has been the same w/ KDE4 & KDE3.

/disclaimer: personal opinion
Comment 31 Robert Kaiser 2015-04-29 01:26:25 UTC
This is a bug reporting system, not a discussion forum. Please refrain from any "me too" comments or other stuff that doesn't help to move the actual implementation of a fix forward. Thanks.
Comment 32 Martin Flöser 2015-04-29 06:04:20 UTC
Thanks Robert for your comment! Just to make it more clear: if I get whining here, I'm not motivated working on it. Now I also go to answer why I don't care about session management: because I do not restart the session, I restart the session whenever the system freezes, so session management is nothing which suits my workflow, nothing I could work on and get it right, because I don't even know how it's supposed to work.
Comment 33 Thomas Lübking 2015-04-29 08:16:33 UTC
That said, I started to look into it last night.
Ivan, how far have your efforts gone so far?
Otherwise I think I can have a patch by the end of the week.
Comment 34 Ivan Čukić 2015-04-29 08:42:24 UTC
Unfortunately, I haven't spent much time on it, so feel free.
Comment 35 John Andrew McInnes 2015-04-29 20:36:32 UTC
>>if I get whining here, I'm not motivated working on it. <<

Huh. I hope you don't take it personally. I got the same response an another bug I reported. This newer generation of opensource coders seems to be very touchy... KDE is awesome thanks for working on it.

>>Now I also go to answer why I don't care about session management: because I do not restart the session, I restart the session whenever the system freezes, so session management is nothing which suits my workflow, nothing I could work on and get it right, because I don't even know how it's supposed to work.<<

You never logout??? You understand what the bug is right? We login, and windows are not where we left them, all over the place, or missing.
Comment 36 Guillaume DE BURE 2015-04-29 21:08:11 UTC
(In reply to Thomas Lübking from comment #33)
> That said, I started to look into it last night.
> Ivan, how far have your efforts gone so far?
> Otherwise I think I can have a patch by the end of the week.

Thomas, thanks so much for looking into this, and thanks Ivan for your efforts :)
If there is anything I can do to help (mostly testing, because this is way beyond my coding abilities), please ask !
Comment 37 Wolfram Köhn 2015-04-30 09:38:07 UTC
Who on earth has driven the Kubuntu-maintainers to switch to Plasma 5 so early, if it's "not nearly ready for productive use" as Thomas said ?
In their currently released Upgrade to 15.04 there is no way to stick to kde 4, so people should be warned  to upgrade !
Maybe this Bug is also the cause for Bug346768 I reported.
I'm using KDE for many years and am perfectly satisfied with it so thanks to all developers, it's not your fault. Kubutu messed it up.
Comment 38 Thomas Lübking 2015-04-30 10:01:57 UTC
It's not the same bug, but related - session management somewhat "largely" changed and was not or not sufficiently ported (I ran pretty much through the code yesterday and then figured that for some reason the sessionKey() changes _very_ early during the application start, so right now kwin reloads the "wrong" session config. Got to figure where it changes tonight ;-)

So please notice that even if (optimitically: when) this bug closes, that does NOT mean session management in KF5 apps would completely work as it does in KDE SC4.
I assume the vast majority of clients needs to be ported by hand (ie. eg. konsole is oc. responsible for managign its tab layout, this is nothing the WM could even possibly do)
Comment 39 Martin Flöser 2015-04-30 11:08:21 UTC
(In reply to Wolfram from comment #37)
> Who on earth has driven the Kubuntu-maintainers to switch to Plasma 5 so
> early, if it's "not nearly ready for productive use" as Thomas said ?
> In their currently released Upgrade to 15.04 there is no way to stick to kde
> 4, so people should be warned  to upgrade !

that should be obvious - users should stick to LTS and AFAIK an LTS doesn't offer the upgrade. User's choice: you can have the latest and greatest (e.g. 15.04) or stay with the more stable offering.
Comment 40 Robert Kaiser 2015-05-03 21:45:30 UTC
(In reply to Martin Gräßlin from comment #32)
> because I do not restart the session, I
> restart the session whenever the system freezes, so session management is
> nothing which suits my workflow, nothing I could work on and get it right,
> because I don't even know how it's supposed to work.

Actually, it would be awesome if we'd have session management that works similar to Firefox and actually restarts your programs when the system freezes or crashes... ;-)
Comment 41 Johann Streitwieser 2015-05-04 12:14:07 UTC
This bug is still there in Plasma 5.3.0 (Kubuntu 15.04 + backports).

When I starting a new session (only after reboot, not after idle state ), applications that were left open on various Activities are all restarted on the first Activity or get lost, instead of being restarted on their previous location.

Reproducible: Always

Steps to Reproduce:
1. Place some applications on various Activities (by me 4 application on 4 activities)
2. Restart
3. Login in

Application are on the first Activity or they are not started again.
The this issue on Kubuntu 15.04 with plasma 5.2 and 5.3 (from backport).

Hope this can help.
Comment 42 Stefan Becker 2015-05-15 21:27:21 UTC
Created attachment 92631 [details]
update to review #123580 patch

- add proper discard command for the kwin session file
- make sure kwin doesn't leave behind temporary session files
Comment 43 Daniele Orlandi 2015-05-18 16:54:37 UTC
Importance is NORMAL?!?!

Whole session management is broken and this has "NORMAL" importance???
Comment 44 Daniele Orlandi 2015-05-18 17:52:48 UTC
Thomas Lübking, your childish behaviour is an insult to everyone who is affected by this bug, lost time, got frustrated and finally found out this kind of consideration.
Comment 45 Rex Dieter 2015-05-18 18:05:18 UTC
There is constructive work being made (for example, in https://git.reviewboard.kde.org/r/123580/ ) to address this issue.

I think you both need to take a break from this bug, and let me remind everyone of:
https://www.kde.org/code-of-conduct/
Comment 46 Kai Uwe Broulik 2015-05-18 18:06:45 UTC
@Daniele: Please refrain from insulting others, this is a bug tracker, not a discussion forum. There are also other more significant issues than this missing feature; frankly I don't know anyone in the core dev team that actually uses it. Nonethtless, you could have followed Stefan's example who, instead of complaining, just provided a couple of welcome patches that will be part of the next release.
Comment 47 Graham P Davis 2015-05-18 18:20:38 UTC
A fix to this was supplied in openSUSE Tumbleweed via the KDE:Frameworks5 repo. Unfortunately, it had to be withdrawn. Very disappointing for me as I'd had a week working happily with the "fixed" P5 without seeing any problems that weren't there before. Now I've had to switch back with KDE4 until the fix is fixed.
Comment 48 Thomas Lübking 2015-05-18 18:28:11 UTC
(In reply to Daniele Orlandi from comment #44)
Despite nobody here really cares about those flags you're of course absolutely right:
If, as you pointed out, the "whole session management" is broken, it really doesn't matter whether KWin restores the window attributes in this disfunctional environment.
So I simply fixed that state for you.

PS:
if you just wanted to make a point- and informationless "I have an uninformed opinion" post, we invented Facebook to spare the rest of the internet this kind of spam.

PPS:
next time maybe spend 5 seconds on reading across the bugreport before posting *anything*
Comment 49 Stefan Becker 2015-05-25 11:55:39 UTC
FYI: issued being tracked by Qt:

* WM_WINDOW_ROLE missing: https://bugreports.qt.io/browse/QTBUG-45484
* SM_CLIENT_ID missing: https://bugreports.qt.io/browse/QTBUG-46310
Comment 50 Stefan Becker 2015-05-25 21:50:59 UTC
I have now applied on my F22 machine the kwin fix and the Qt fixes. kwin now stores the window information for KF5 apps to its session file. For most windows restoring during login works correctly, but at least for konsole I have seen that sometimes the "iconified" state is not correctly restored.

I would appreciate reviews on the Qt fixes so that we can get them merged.
Comment 51 Thomas Lübking 2015-06-02 10:15:25 UTC
*** Bug 348566 has been marked as a duplicate of this bug. ***
Comment 52 Stefan Becker 2015-06-08 17:02:35 UTC
Latest QT5.5 fixes can be found here

* https://codereview.qt-project.org/#/c/113806/
* https://codereview.qt-project.org/#/c/113901/

With both fixes applied ontop of F22 window position/iconized state save *and* restore seem to work on my machine
Comment 53 Philipp Verpoort 2015-06-12 14:05:22 UTC
I agree with Guillaume that this should be fixed, as it dramatically reduces the usability of sessions and activities.
Comment 54 Guillaume DE BURE 2015-06-12 17:43:08 UTC
(In reply to Philipp Verpoort from comment #53)
> I agree with Guillaume that this should be fixed, as it dramatically reduces
> the usability of sessions and activities.

Philipp, I am confident this will be fixed soon, thanks to the work of Stefan and others :) Just be patient so that his patches are merged and packaged for your distro.

@Stefan, please correct me if I'm wrong, and thanks for the fixes :)
Comment 55 Stefan Becker 2015-06-13 17:48:17 UTC
FYI: all session management fixes are now available through official F22 packages:

* kwin-5.3.1-2.fc22
* qt5-qtbase-5.4.2-2.fc22
Comment 56 Dr. Boris Neubert 2015-06-14 16:07:58 UTC
*** Bug 349135 has been marked as a duplicate of this bug. ***
Comment 57 Thomas Lübking 2015-06-17 22:19:44 UTC
Git commit 3442664609284ea201d50f6da27222c706a75c8e by Thomas Lübking.
Committed on 17/06/2015 at 22:18.
Pushed by luebking into branch 'master'.

port session management to KF5

REVIEW: 123580

M  +1    -2    main.cpp
M  +3    -0    main.h
M  +5    -4    main_x11.cpp
M  +55   -31   sm.cpp
M  +0    -13   sm.h
M  +8    -14   workspace.cpp
M  +7    -2    workspace.h

http://commits.kde.org/kwin/3442664609284ea201d50f6da27222c706a75c8e
Comment 58 Roland Pallai 2015-06-22 23:40:08 UTC
I still have some session problem on latest Fedora 22. I selected konsole as product but recently found it's affecting kwrite too, maybe related to this ticket.

https://bugs.kde.org/show_bug.cgi?id=349481
Comment 59 Bhushan Shah 2015-07-03 15:44:35 UTC
*** Bug 342086 has been marked as a duplicate of this bug. ***
Comment 60 Sergio 2015-07-06 08:13:55 UTC
> I don't care about session management: because I do not restart the session, I restart the session whenever the system freezes

Under these premises, it would be a matter of clarity to state from the main KDE web page that KDE development mainly focuses on single user workflows and that the desktop support for multiuser environments can at best be casual. Would have saved most of the whining here.

> That should be obvious - users should stick to LTS and AFAIK an LTS doesn't offer the upgrade. User's choice: you can have the latest and greatest (e.g. 15.04) or stay with the more stable  offering.

Unfortunately, it is not this simple. It is not LTS -> 15.04, so you stay with LTS and you are done. It is LTS -> 14.10 -> 15.04.  Those who switched from LTS to 14.10 had no information at all that they would have been compelled into Plasma 5 while "there are still monsters" (in Thomas' words). Conversely, they got reassured multiple times about the fact that Plasma 5 would have been offered as a technical preview side to side with Plasma 4 until it was ready, and that the Plasma 3 -> Plasma 4 transition mistakes would have been avoided.

In any case, now that the damage is done, let's try to limit it as much as possible. Can someone help identify:

- if wily's qt 5.4.2 contains the same fixes that are in the Fedora package mentioned above and if it can be safely backported to vivid in a ppa

- what additional patches are needed on top of the kwin package contained in the kubuntu kde backports ppa, to see if a fixed package can be shipped in a further PPA
Comment 61 Thomas Lübking 2015-07-06 08:41:03 UTC
(In reply to Sergio from comment #60)
> KDE web page that KDE development mainly focuses on single user workflows
Session restorage has nothing to do with single/multiuser questions.
It's about session restarts, not about multiple sessions.

> - if wily's qt 5.4.2 contains the same fixes that are in the Fedora package
> mentioned above and if it can be safely backported to vivid in a ppa
See comment #49 and comment #52 on the Qt patches.
They're not in Qt upstream - not even reviewed.

> what additional patches are needed on top of the kwin package contained in the kubuntu kde 
> backports ppa, to see if a fixed package can be shipped in a further PPA
I don't know what's in "backports ppa", but you'll need either KWin >= 5.4.0 (not yet released) or https://git.reviewboard.kde.org/r/123580/ + the forementioned Qt patches (for Qt5/KF5 clients - otherwise only Qt4/gtk/etc clients are properly restored by kwin)

For client internal issues (what especially also includes "restarting Qt5 applications" when "restoring the last session" itfp) I'm not aware of any present patches.
Comment 62 Martin Flöser 2015-07-06 08:55:56 UTC
(In reply to Sergio from comment #60)
> > I don't care about session management: because I do not restart the session, I restart the session whenever the system freezes
> 
> Under these premises, it would be a matter of clarity to state from the main
> KDE web page that KDE development mainly focuses on single user workflows
> and that the desktop support for multiuser environments can at best be
> casual. Would have saved most of the whining here.

The personal opinion of one KDE developer doesn't impact KDE in a way that we need to put warnings on KDE web pages. Luckily KDE is a large enough group of people that others step up and work on what they consider as important.
Comment 63 Robert Kaiser 2015-07-06 13:54:02 UTC
(In reply to Thomas Lübking from comment #61)
> See comment #49 and comment #52 on the Qt patches.
> They're not in Qt upstream - not even reviewed.

Forgive the question, but what needs to happen to get those into a Qt release? Are those steps underway? Any idea how long that usually takes?
Comment 64 Rex Dieter 2015-07-06 14:11:15 UTC
See comment #52 for the upstream Qt patch reviews
Comment 65 Sergio 2015-07-06 17:27:34 UTC
> Session restorage has nothing to do with single/multiuser questions. It's about session restarts, not about multiple sessions.

True. But if you have a single monitor and a single keyboard to share between multiple users, you have people stopping and starting sessions all the time. The only condition where you do not need that is when you have a single user, who can just lock or suspend the machine when he is not using it, I guess. Session restart is the "suspend" of the poor man who has to work on a multiuser system sharing the seat.

Apart from that, thanks to Thomas and Martin for the pointers and the clarifications about the patches. Let me recap to see if I understand correctly:

1) One definitely needs commit 3442664609284ea201d50f6da27222c706a75c8e on kwin. Can it be expected to apply over stable kwin 5.3.1? If so, backporting onto kubuntu kwin should be relatively easy.

2) Furthermore, one needs to patch QT5 with:

0001-Forward-QWidget-windowRole-to-QPlatformWindow.patch

from https://bugreports.qt.io/browse/QTBUG-45484, that can be safely backported to 5.4.1 as shipped by kubuntu vivid (has already been done by a Fedora developer). And

0002-xcb-set-SM_CLIENT_ID-property.patch

from  https://bugreports.qt.io/browse/QTBUG-46310. Which I do not know if is expected to apply cleanly on 5.4.1 (does anyone know btw?).

Is this all?
Comment 66 Thomas Lübking 2015-07-06 17:44:15 UTC
(In reply to Sergio from comment #65)
> > Session restorage has nothing to do with single/multiuser questions. It's about session restarts, not about multiple sessions.
> 
> True. But if you have a single monitor and a single keyboard to share
> between multiple users, you have people stopping and starting sessions all
> the time.
No?

You can start several sessions simultaniously - I frankly don't know whether KDE would even allow to start a session for a new user without locking the current one.

The only problem would be if you're short on resources and/or have no swap device and/or a process of one user starts running wild.
(Might be interesting to stop all processes of the non-current user when switching sessions?)
But under normal conditions, it's no problem.

> 1) One definitely needs commit 3442664609284ea201d50f6da27222c706a75c8e on
> kwin.
yupp.

> Can it be expected to apply over stable kwin 5.3.1?
The patch can be used functionally - whether you'll run into an unresolvable patch conflict (patch not knowing how to apply this, you'll have to help), I can't say for sure (but don't expect so)

> 2) Furthermore, one needs to patch QT5 with:
> 0001-Forward-QWidget-windowRole-to-QPlatformWindow.patch
Not necessarily - the *really* important thing in this context is SM_CLIENT_ID (but it certainly won't hurt)

> from  https://bugreports.qt.io/browse/QTBUG-46310. Which I do not know if is
> expected to apply cleanly on 5.4.1 (does anyone know btw?).
Trying > guessing ;-)
(But I think Stefan actually wrote it on top of 5.4.1)

> Is this all?
This will still NOT prevent Qt5 clients from not restarting at all (they somehow randomly fail to be recorded by the sessionmanager, likely killing themselves on the "session about to end" signal or whatever)
Comment 67 David Lang 2015-07-06 18:58:11 UTC
Thomas, if you start lots of sessions without anyone logging out, you quickly run out of system resources for all the running apps.

But even with a single user on a laptop, I have to deal with the pain or restarting sessions regularly because the laptop doesn't stay plugged in all the time and doesn't have an infinite battery.

Personally, I prefer that Firefox/Chrome not startup until I tell them to because I may not have network connectivity and 40 firefox windows with a couple hundred tabs all reporting "connection failed" is not useful.

The fact that KDE4 would detect when firefox was running at shutdown (even when I start it manually from a shell window) is a bug as far as I'm concerned. Go ahead and restart apps that I started through the KDE menu, but don't try to detect apps that I start from the command line and then start them automatically (especially when you do so without the command-line parameters I provided)
Comment 68 Robert Kaiser 2015-07-06 19:45:06 UTC
(In reply to David Lang from comment #67)
> The fact that KDE4 would detect when firefox was running at shutdown (even
> when I start it manually from a shell window) is a bug as far as I'm
> concerned.

And a feature as I'm concerned.

(In reply to Thomas Lübking from comment #66)
> This will still NOT prevent Qt5 clients from not restarting at all (they
> somehow randomly fail to be recorded by the sessionmanager, likely killing
> themselves on the "session about to end" signal or whatever)

Hrm, if Qt5-based apps (like the KDE apps) don't start up by default and only old KDE4 ones do, that's an argument for not updating yet at all, sadly. Are there bugs filed for that?

(In reply to Rex Dieter from comment #64)
> See comment #52 for the upstream Qt patch reviews

Hard to make out for me how this is progressing. I hope it does.


All that said, thanks a lot to Thomas and Stefan (and anyone else helping) for the great work you have done and are doing there!
Comment 69 Thomas Lübking 2015-07-06 21:26:15 UTC
(In reply to David Lang from comment #67)
> Thomas, if you start lots of sessions without anyone logging out, you
> quickly run out of system resources for all the running apps.

Risking a little OT, "which"?
RAM? => https://wiki.archlinux.org/index.php/Swap

The only actual problem can, as mentioned, be at some point a slowdown due to CPU overload by misbehaving processes (and while I don't think kdm or sddm or even logind support this, this could in theory be covered by stopping processes for all users that do not hold the current session)

> But even with a single user on a laptop, I have to deal with the pain or
> restarting sessions regularly because the laptop doesn't stay plugged in all
> the time and doesn't have an infinite battery.
Hibernate?

In case it's not clear, this is from my position *not* a discussion on whether session management should better work again at some point (it certainly should, for there *are* reasons to log out, eg. to reboot the kernel or shutdown to have the system fully encrypted/stashed)
It's just that multiuser environments (or battery limitations - unless you wait too long ;-) don't somhow enforce session restarts at all, so please don't try to make that your argument for working session support. It's factually wrong.
 
> The fact that KDE4 would detect when firefox was running at shutdown (even
> when I start it manually from a shell window) is a bug as far as I'm
> concerned.
It's actually a setting ("kcmshell5 smserver", also on SC4 for "kcmshell4", but I'm not 100% sure whether the module was named smserver than as well) and really completely unrelated.

> Go ahead and restart apps that I started through the KDE menu,
> but don't try to detect apps that I start from the command line
That's unfortunately indistiguishable.

> start them automatically (especially when you do so without the command-line
> parameters I provided)
That's actually a client bug, for it tells the smserver about the command it wants for a restart.
Comment 70 David Lang 2015-07-07 21:15:12 UTC
>> Go ahead and restart apps that I started through the KDE menu, but don't try to detect apps that I start from the command line

> That's unfortunately indistiguishable.

only if you only do this by looking at what's running at the time you shutdown.

If something is started from the KDE menu, then you can track that you started it and the user hasn't exited it. restart those apps.

But if you are actually trying to restart all apps, then you are failing miserably. I routinely have many apps running in terminal windows that don't get restarted, as well as a few GUI apps (almost none KDE/Gnome apps) that don't get restarted. Other apps that get restarted are missing the context (what files they had open, etc) my terminal windows get started, but beyond them and the browsers, not a lot more (and currently all the terminal windws get shoved onto the first screen.

>> Thomas, if you start lots of sessions without anyone logging out, you quickly run out of system resources for all the running apps.

> Risking a little OT, "which"?
> RAM? => https://wiki.archlinux.org/index.php/Swap

swap is horrible to use, and it's still easy to run out of swap. You actually don't want to have tens of GB of swap because the system will become unusable if it is used. I run my systems with very little swap (I only have one machine with more than 2G of swap, even if the system has hundreds of GB of RAM). I've actually had a machine with 128G of RAM that only had 120G of disk. My VMs for work typically have 40G of disk or so, even if they have 32+G of RAM

disk space may be cheap, but only if you don't need to add a drive for it and aren't using expensive storage (price the per-GB cost of EMC storage for example, especially if you include replication of the storage)
Comment 71 Thomas Lübking 2015-07-07 21:58:08 UTC
(In reply to David Lang from comment #70)
> only if you only do this by looking at what's running at the time you
> shutdown.

Nothing is tracked or something.
There's a session protocol and clients can support it and call for a restart or not.
They can notably define *how* they want to be restarted (commandline).

Even if it was not: restarting only clients that were launched through a specific interface is a pretty much instant fail. Should we care about kickoff? krunner? plasma panels? what about 3rd party dockers? Should we estrablish a protocol that each and every runner/docker/whatever needs to support? Let alone the mess that this would cause for less integrated environments as well as the most obvious question, *why* to discriminate processes that were started from eg. konsole. (Eg. I *very* often launch kwrite instances from konsole)
 
> But if you are actually trying to restart all apps
As pointed out: it's configurable and you're free to start with a blank session or an explicitly stored one.

> then you are failing miserably.
Thank you - But maybe better read into the topic next time.

> I routinely have many apps running in terminal windows that don't
> get restarted, as well as a few GUI apps (almost none KDE/Gnome apps) that
> don't get restarted.
As mentioned, clients either support this (dead old) protocol or not. Qt5 is apparently buggy itr. and atm.

> Other apps that get restarted are missing the context
> (what files they had open, etc)
The apps get a signal "the session is gonna end, save your stuff" and a signal "session restarted, your last id was 123456" - what they do with that is their thing and not job of the session manager.

========== OFF TOPIC ============================================

> swap is horrible to use
swap is slow, yes, but unless some process runs wild, the logged out user will quickly get swapped out in favor of the active users processes (notably when stopping processes)
Since the user isn't logged in, he doesn't care.

> I've actually had a machine with 128G of RAM that only had 120G of disk. My VMs for work 
> typically have 40G of disk or so, even if they have 32+G of RAM

Sorry, but personal design decisions do not form a concept.
Naturally a multiuser (for multiseat you obviously need tons of physical RAM) system would be designed different (hard quotas and sufficient swap space to protect user processes agains other users processes causing OOM)
Comment 72 Thomas Lübking 2015-07-07 22:28:51 UTC
(In reply to Robert Kaiser from comment #68)
> Hrm, if Qt5-based apps (like the KDE apps) don't start up by default and
> only old KDE4 ones do, that's an argument for not updating yet at all,
> sadly. Are there bugs filed for that?
None that I could find, but I found https://bugreports.qt.io/browse/QTBUG-28228 which suggests that all session management was entirely uniplemented before Qt 5.2 ... :-\
Comment 73 Laurent Bonnaud 2015-11-29 10:31:42 UTC
This bug is marked as "RESOLVED FIXED" whereas with plasma 5.4.3 and Qt 5.4.2 in Kubuntu 15.10 no application is restarted on login.
Comment 74 Thomas Lübking 2015-11-29 10:53:42 UTC
KWin is not responsible for restarting applications.
This bug was *only* about not restoring window manager attributes (position, virtual desktop, etc.) on session restorage.

There're fundamental bugs in Qt5 that prevent (both, correct and entire) restoring of Qt5 applications, see

* https://codereview.qt-project.org/#/c/113806/
* https://codereview.qt-project.org/#/c/113901/
* http://marc.info/?l=kde-core-devel&m=144832700109449&w=1
Comment 75 Leslie Zhai 2015-12-09 07:07:54 UTC
https://bugs.kde.org/show_bug.cgi?id=354724 still reproduced!
Comment 76 Thomas Lübking 2015-12-09 08:22:51 UTC
As pointed out in comment #74 this is a completely unrelated issue.

Session management in Qt5 was and is broken and won't (read: "can't") be fixed by kwin for sure, there're considerations to work around *parts* of that in ksmserver, but neither that discussion belongs into this bug.
Comment 77 Leslie Zhai 2015-12-10 08:37:43 UTC
Hi Thomas,

Thanks for your reply ;-)

1. Qt5 v5.5.1 has integrated the patch for QTBUG-46310 to fix xcb: set SM_CLIENT_ID property issue, and I have applied the patch for QTBUG-45484 to fix Fix QWidget::setWindowRole issue.

2. As Andreas suggested, I patched the kxmlgui to Remove QCoreApplication::setQuitLockEnabled(true) from KMainWindowPrivate::init()

But ksmserver still failed to restore the applications (based on Qt5) session nor even chromium! and Gtk based applications, such as pidgin, thunderbird, are ok.

> there're considerations to work around *parts* of that in ksmserver
After discussed with Andreas, he pointed out my fault - I wrongly argued that it might be libSM's issue. 
so I parsed the files under $HOME/.config/session/, filter the window manager - kwin, then call startApplication() after parsing [Session: saved at previous logout] configuration to restart application.

in plasma-workspace/ksmserver/startup.cpp, line 393, based on plasma-workspace v5.4.3 tag

As you said it is just a workaround or monkey patch, for example, kwrite could not open previous documents when restore the session.
But thanks for your help again ;-)

Regards,
Leslie Zhai
Comment 78 Thomas Lübking 2015-12-10 17:45:55 UTC
(In reply to Leslie Zhai from comment #77)

> 2. As Andreas suggested, I patched the kxmlgui to Remove
> QCoreApplication::setQuitLockEnabled(true) from KMainWindowPrivate::init()

Read his mail closer :-P

Removing that won't help you, since the "true" state is the default QGuiApplication behavior.
The bug needs to be fixed in Qt to not commit suicide (by closing all windows) after comitting the session data.
You do *not* want to QCoreApplication::setQuitLockEnabled(false), resp. QGuiApplication::setQuitOnLastWindowClosed(false) because that will keep windowless processes around.
 
> session nor even chromium!
No idea about chromium, but it might simply suicide as well.
Comment 79 Leslie Zhai 2015-12-11 02:20:47 UTC
(In reply to Thomas Lübking from comment #78)
> (In reply to Leslie Zhai from comment #77)
> 
> > 2. As Andreas suggested, I patched the kxmlgui to Remove
> > QCoreApplication::setQuitLockEnabled(true) from KMainWindowPrivate::init()
> 
> Read his mail closer :-P
we discussed here https://bugs.kde.org/show_bug.cgi?id=354724 he pointed out my fault ;P


> 
> Removing that won't help you, since the "true" state is the default
> QGuiApplication behavior.
> The bug needs to be fixed in Qt to not commit suicide (by closing all
> windows) after comitting the session data.
> You do *not* want to QCoreApplication::setQuitLockEnabled(false), resp.
> QGuiApplication::setQuitOnLastWindowClosed(false) because that will keep
> windowless processes around.
then reported to QTBUG? please paste the QTBUG link, thanks a lot!


>  
> > session nor even chromium!
> No idea about chromium, but it might simply suicide as well.
totally no idea why ;-(
Comment 80 Leslie Zhai 2015-12-11 07:44:31 UTC
https://git.reviewboard.kde.org/r/126311/ workaround monkey patch, hope others could fix it in right way ;-)
Comment 81 Thomas Lübking 2015-12-11 08:20:14 UTC
Can we please concentrate the discussion on bug #354724 to not "pollute" this one w/ OT content?
Comment 82 Anders Lund 2016-02-25 18:33:35 UTC
This is now a problem again. Plasma 5.5.4, kwin 5.19.0. Please reopen.
Comment 83 Thomas Lübking 2016-02-25 20:22:02 UTC
In how far? The code didn't change at all.
Comment 84 Anders Lund 2016-02-27 20:21:13 UTC
torsdag den 25. februar 2016 20.22.02 CET skrev du:
> https://bugs.kde.org/show_bug.cgi?id=341930
> 
> --- Comment #83 from Thomas Lübking <thomas.luebking@gmail.com> ---
> In how far? The code didn't change at all.

I got a update for plasma, maybe that have solved it, I'll note on next 
restart.

--
Kindly,
Anders
Comment 85 Thomas Lübking 2016-02-27 21:55:11 UTC
You'll neeed "kwin_x11 --version" to be 5.4.x
Notice that KWin is *not* responsible for re-launching applications. That's a bug only "fixed" (worked around) very recently in Qt 5.6 and KF5 5.20 (both unreleased yet)
This bug is about correct window postions and such.
Comment 86 Anders Lund 2016-03-02 09:13:01 UTC
lørdag den 27. februar 2016 21.55.11 CET skrev du:
> https://bugs.kde.org/show_bug.cgi?id=341930
> 
> --- Comment #85 from Thomas Lübking <thomas.luebking@gmail.com> ---
> You'll neeed "kwin_x11 --version" to be 5.4.x
> Notice that KWin is *not* responsible for re-launching applications. That's
> a bug only "fixed" (worked around) very recently in Qt 5.6 and KF5 5.20
> (both unreleased yet)

Ok, I'll try using activites again some other time...

Kindly,
Anders
Comment 87 Thomas Lübking 2016-03-02 09:30:57 UTC
This bug isn't about activities either.
Maybe attend to forum.kde.org and describe your issue? Maybe there's a bug filed, maybe not - but it sounds it's not this one.
Comment 88 Anders Lund 2016-03-02 10:10:45 UTC
onsdag den 2. marts 2016 09.30.57 CET skrev du:
> https://bugs.kde.org/show_bug.cgi?id=341930
> 
> --- Comment #87 from Thomas Lübking <thomas.luebking@gmail.com> ---
> This bug isn't about activities either.
> Maybe attend to forum.kde.org and describe your issue? Maybe there's a bug
> filed, maybe not - but it sounds it's not this one.

This bug (or one that was merged with it) was posted to address this exact 
issue: When loading the plasma desktop session, windows from all activities 
are launched in the current activity.

--
Kindly,
Anders
Comment 89 Thomas Lübking 2016-03-08 00:28:14 UTC
Is the activity the only un-restored attribute?

There are two things that could happen here:
1. The stored activity doesn't exist in the restored session
2. "yet" (ie. the window is restored and the activity some ms afterwards)

To rule out "1", please compare the output of

   qdbus org.kde.ActivityManager /ActivityManager/Activities ListActivities

before logging out and after re-logging in.

In case they're equal, we'll likely face "2" (a timing related issue that will only have worked "by luck" in the past) - otherwise the problem is in restoring the activities (there're some forum complaints about plasmashell always restarting with default plasmoids which might point into that direction)
Comment 90 Anders Lund 2016-03-10 06:31:00 UTC
This seems to work again since last update. :-)

tirsdag den 8. marts 2016 00.28.14 CET skrev du:
> https://bugs.kde.org/show_bug.cgi?id=341930
> 
> --- Comment #89 from Thomas Lübking <thomas.luebking@gmail.com> ---
> Is the activity the only un-restored attribute?
> 
> There are two things that could happen here:
> 1. The stored activity doesn't exist in the restored session
> 2. "yet" (ie. the window is restored and the activity some ms afterwards)
> 
> To rule out "1", please compare the output of
> 
>    qdbus org.kde.ActivityManager /ActivityManager/Activities ListActivities
> 
> before logging out and after re-logging in.
> 
> In case they're equal, we'll likely face "2" (a timing related issue that
> will only have worked "by luck" in the past) - otherwise the problem is in
> restoring the activities (there're some forum complaints about plasmashell
> always restarting with default plasmoids which might point into that
> direction)