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
Still there in 5.2. Is there anything I can do to help ? Anyone else noticing this ?
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.
Thanks for the feedback, Ivan. Does it mean Wayland should be preferred to X for this issue ?
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).
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.
Ivan, what does it matter what gnome people thinks? this affects kde applications (as well).
> 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.
Thank you Ivan! You rock!
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)
> 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.
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 :)
I'll see whether it can work now. @Thomas Lübking Thanks for investigating this!
*** Bug 343843 has been marked as a duplicate of this bug. ***
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.
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 !
before I log out: what's the commandline of the kate process that should have restored the document?
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
Well, that implies the global session management is intact, but kde apparently didn't port it (correctly) just as much as kwin did not.
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.
*** Bug 344856 has been marked as a duplicate of this bug. ***
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.
(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!
Any update on this? I am also effected by this and would like to see a fix :)
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 :)
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.
I did start playing around with it, but I don't expect it to be in 5.3.
This bug is still there in Plasma 5.3.0 KF 5.9.0 (Kubuntu 15.04 + backports).
*** Bug 341336 has been marked as a duplicate of this bug. ***
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.
> 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
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.
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.
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.
Unfortunately, I haven't spent much time on it, so feel free.
>>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.
(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 !
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.
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)
(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.
(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... ;-)
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.
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
Importance is NORMAL?!?! Whole session management is broken and this has "NORMAL" importance???
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.
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/
@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.
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.
(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*
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
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.
*** Bug 348566 has been marked as a duplicate of this bug. ***
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
I agree with Guillaume that this should be fixed, as it dramatically reduces the usability of sessions and activities.
(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 :)
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
*** Bug 349135 has been marked as a duplicate of this bug. ***
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
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
*** Bug 342086 has been marked as a duplicate of this bug. ***
> 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
(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.
(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.
(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?
See comment #52 for the upstream Qt patch reviews
> 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?
(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)
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)
(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!
(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.
>> 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)
(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)
(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 ... :-\
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.
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
https://bugs.kde.org/show_bug.cgi?id=354724 still reproduced!
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.
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
(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.
(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 ;-(
https://git.reviewboard.kde.org/r/126311/ workaround monkey patch, hope others could fix it in right way ;-)
Can we please concentrate the discussion on bug #354724 to not "pollute" this one w/ OT content?
This is now a problem again. Plasma 5.5.4, kwin 5.19.0. Please reopen.
In how far? The code didn't change at all.
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
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.
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
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.
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
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)
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)