[opensuse-kde] libqt5-qtbase Session Management Patches are not working
The following patches to qt55 are supposed to provide the missing data needed to allow a plasma 5 session to properly manage Qt5-based apps. Without these patches to qt55, only gtk and qt4-based apps are restored on login: 0001-Fix-QWidget-setWindowRole.patch 0006-xcb-set-SM_CLIENT_ID-property.patch These patches have,indeed, been applied to the openSUSE package, but are not actually functioning for some reason. openSUSE is still exhibiting the unpatched behavior. (i.e. only non-qt-based apps are restored on login). Would someone please look into this? I'm using 13.2, and have confirmed with a Tumbleweed user that they are seeing the same behavior, and it is most likely broken in Leap 42.1 as well. It would be a shame to have Leap 42.1 KDE debut with broken session management. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 10/12/2015 02:06 AM, mournblade wrote:
The following patches to qt55 are supposed to provide the missing data needed to allow a plasma 5 session to properly manage Qt5-based apps. Without these patches to qt55, only gtk and qt4-based apps are restored on login:
0001-Fix-QWidget-setWindowRole.patch 0006-xcb-set-SM_CLIENT_ID-property.patch
These patches have,indeed, been applied to the openSUSE package, but are not actually functioning for some reason. openSUSE is still exhibiting the unpatched behavior. (i.e. only non-qt-based apps are restored on login).
Would someone please look into this?
I'm using 13.2, and have confirmed with a Tumbleweed user that they are seeing the same behavior, and it is most likely broken in Leap 42.1 as well. It would be a shame to have Leap 42.1 KDE debut with broken session management.
No comment from anyone? Is the problem being investigated? At this point, it looks like RC1 will be released with broken session management. I realize everyone is really busy working on the release, but at least an acknowledgment of the problem would be appreciated. The stack of patches is getting so high I wouldn't be surprised if one of the recently added patches is conflicting with the session management patches. Did the session management patches work at any point in time, or were they just applied, but never tested? It would be nice if Qt would pick up the pace and incorporate some of these patches so openSUSE could rebase. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data giovedì 15 ottobre 2015 00:06:31 CEST, mournblade ha scritto: Hello,
No comment from anyone? Is the problem being investigated? At this
I'm unable to test this as I don't use session management, unfortunately.
management. I realize everyone is really busy working on the release, but at least an acknowledgment of the problem would be appreciated.
It's more like "everyone is busy". I'm speaking for myself and not for the whole team, but I had barely the time to help fixing the TW failures to get a new snapshot out. For the same reason I won't have the slightest chance to test Leap.
patches. Did the session management patches work at any point in time, or were they just applied, but never tested? It would be nice if Qt
I'll let the other team members chime in if they want, but as I said I don't think any if us uses session management. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
On Thursday, October 15, 2015 07:06:31 AM mournblade wrote:
On 10/12/2015 02:06 AM, mournblade wrote:
The following patches to qt55 are supposed to provide the missing data needed to allow a plasma 5 session to properly manage Qt5-based apps. Without these patches to qt55, only gtk and qt4-based apps are restored on login:
0001-Fix-QWidget-setWindowRole.patch 0006-xcb-set-SM_CLIENT_ID-property.patch
These patches have,indeed, been applied to the openSUSE package, but are not actually functioning for some reason. openSUSE is still exhibiting the unpatched behavior. (i.e. only non-qt-based apps are restored on login).
Would someone please look into this?
I'm using 13.2, and have confirmed with a Tumbleweed user that they are seeing the same behavior, and it is most likely broken in Leap 42.1 as well. It would be a shame to have Leap 42.1 KDE debut with broken session management.
No comment from anyone? Is the problem being investigated?
From openSUSE KDE team community members - no. AFAIK same answer can be applied to SUSE people, as well to KDE people upstream. TBH, i think only a few enthusiast that really miss, and use the session restore feature have invested time to fix the issues in Qt. We do have patches that should improve the situation, but to my knowledge they aren't declared as 100% cure. There are also many client/per application bugs left. I haven't seen any activity in this area recently in various project though.
At this point, it looks like RC1 will be released with broken session management. I realize everyone is really busy working on the release, but at least an acknowledgment of the problem would be appreciated.
The stack of patches is getting so high I wouldn't be surprised if one of the recently added patches is conflicting with the session management patches. Did the session management patches work at any point in time, or were they just applied, but never tested? It would be nice if Qt would pick up the pace and incorporate some of these patches so openSUSE could rebase.
I don't quite understand this section =) IIRC there are 2 patches in our qtbase package, one of which is commited upstream, and another one has a green light. Regarding testing, i myself only tried once or twice and noticed restoration is still random (or not random, but didn't notice the pattern). Normally, session restore is the first thing i disable when doing a clean install/testing stuff on clean config. As said above, only place where this can be resolved is upstream at Qt and possibly at KDE (on a application basis) Cheers, Hrvoje
No comment from anyone? Is the problem being investigated? From openSUSE KDE team community members - no. AFAIK same answer can be applied to SUSE people, as well to KDE people upstream. TBH, i think only a few enthusiast that really miss, and use the session restore feature have invested time to fix the issues in Qt. We do have patches that should improve the situation, but to my knowledge they aren't declared as 100% cure. There are also many client/per application bugs left. I haven't seen any activity in this area recently in various project though. I understand that it is outside of the scope of openSUSE KDE team to fix Qt bugs to make it work better with KDE. I was asking if the openSUSE KDE Team was investigating why the same patches applied to Fedora and reported to be working, seem to be non-functional as currently applied in openSUSE. KDE has closed the issue as fixed based on the reports of the patches working in Fedora.
I don't quite understand this section =) IIRC there are 2 patches in our qtbase package, one of which is commited upstream, and another one has a green light. Regarding testing, i myself only tried once or twice and noticed restoration is still random (or not random, but didn't notice the
I also understand that individual Qt5-based apps need to do some work to make sure document contents are restored properly. I wasn't addressing this level of functionality. As it stands, No Qt5-based app is restored in any state; not even with an empty document /in default state. pattern).
Normally, session restore is the first thing i disable when doing a clean install/testing stuff on clean config.
As said above, only place where this can be resolved is upstream at Qt and possibly at KDE (on a application basis)
I was referring to qt5 being very buggy, in general, and Qt being slow to incorporate submitted patches--not just the two patches addressing the session management. The pattern is not random. It may seem random that some Qt apps restore, and others don't, but if you look closer, you'll find that it is always the Qt5-based apps that fail to restore. Please let me know if you find ANY apps compiled against Qt5 that restore--I haven't found a single one. I'm not having any issues with apps compiled against Qt4 or gtk apps restoring. My question to the openSUSE KDE team is: why do the same patches verified to work in Fedora, not work in openSUSE as currently applied. KDE is no longer working on the problem any longer because they have marked the issue solved. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Donnerstag, 15. Oktober 2015, 21:17:07 schrieb mournblade:
The pattern is not random. It may seem random that some Qt apps restore, and others don't, but if you look closer, you'll find that it is always the Qt5-based apps that fail to restore.
That is not true. The pattern does indeed seem to be random. IME, sometimes *all* running KF5 applications are restored correctly, sometimes only a few of them, sometimes none.
Please let me know if you find ANY apps compiled against Qt5 that restore--I haven't found a single one. I'm not having any issues with apps compiled against Qt4 or gtk apps restoring.
The KF5 based Konsole is being restored sometimes here, as is the KF5 based kwrite or systemsettings5. I'm not sure I tried others yet. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 10/16/2015 08:57 AM, Wolfgang Bauer wrote
That is not true. The pattern does indeed seem to be random.
IME, sometimes *all* running KF5 applications are restored correctly, sometimes only a few of them, sometimes none.
...
The KF5 based Konsole is being restored sometimes here, as is the KF5 based kwrite or systemsettings5. I'm not sure I tried others yet.
That's interesting. I have been completely unable to get any KF5 app (including the ones you mentioned) to restore on login under any circumstances. I just did another round of tests and came back with a zero success rate again. I'm running 13.2. I assume you're running Tumbleweed. That might account for the difference. I'd migrate to Leap and check to see that that makes a difference, but I'm waiting for the nVidia repo to be posted. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
* mournblade
On 10/16/2015 08:57 AM, Wolfgang Bauer wrote
That is not true. The pattern does indeed seem to be random.
IME, sometimes *all* running KF5 applications are restored correctly, sometimes only a few of them, sometimes none.
...
The KF5 based Konsole is being restored sometimes here, as is the KF5 based kwrite or systemsettings5. I'm not sure I tried others yet.
That's interesting. I have been completely unable to get any KF5 app (including the ones you mentioned) to restore on login under any circumstances. I just did another round of tests and came back with a zero success rate again.
I'm running 13.2. I assume you're running Tumbleweed. That might account for the difference. I'd migrate to Leap and check to see that that makes a difference, but I'm waiting for the nVidia repo to be posted.
Tw and kalendar, yakuake and konsole always restore for me. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag, 16. Oktober 2015, 17:46:34 schrieb Patrick Shanahan:
Tw and kalendar, yakuake and konsole always restore for me.
What's "kalendar"? If you mean KOrganizer, it's probably still the KDE4 version. Yakuake is still KDE4 based too, konsole is indeed a KF5 application (in TW). But as I mentioned, konsole/KF5 is saved/restored only randomly here. This is a problem with KF5 applications only. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag, 16. Oktober 2015, 16:36:29 schrieb mournblade:
I'm running 13.2. I assume you're running Tumbleweed. That might account for the difference. I'd migrate to Leap and check to see that that makes a difference, but I'm waiting for the nVidia repo to be posted.
No, I´m running 13.2 as well (Plasma 5.4.2, Frameworks 5.15, Qt 5.5.0), sorry for forgetting to mention that. As the behavior is quite random, it may be a timing issue. So, any difference in the system timing (e.g. slower/faster hardware) can also change the behavior I suppose, that could range from totally breaking it or even make it more reliable, possibly. What I can say so far (after some testing) is, that the problem is not in *restoring* the session. This seems to work reliably. But applications that are not restored, are not even written to ksmserverrc. Creating an entry manually there, makes that application start on login (reliably, AFAICT so far) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 10/16/2015 05:01 PM, Wolfgang Bauer wrote:
No, I´m running 13.2 as well (Plasma 5.4.2, Frameworks 5.15, Qt 5.5.0), sorry for forgetting to mention that.
As the behavior is quite random, it may be a timing issue. So, any difference in the system timing (e.g. slower/faster hardware) can also change the behavior I suppose, that could range from totally breaking it or even make it more reliable, possibly.
What I can say so far (after some testing) is, that the problem is not in *restoring* the session. This seems to work reliably. But applications that are not restored, are not even written to ksmserverrc. Creating an entry manually there, makes that application start on login (reliably, AFAICT so far) Thanks for pointing me in the right direction. I just did some more testing, and found some encouraging results.
You're absolutely correct about the problem occurring at save-time rather than restore-time. The problem is not even with the session-saving code per se. It seems to be working fine in isolation. The problem only occurs when the session-saving code is called automatically at logout. It's either some kind of timing issue, as you suggested, or the session-saving code is conflicting with other processes running at logout-time. I've noticed frequent kdeinit5 seg faults at logout when sessions are set to autosave and one or more kf5 apps are open, but only when both these conditions are true. If I go to systemsettings5-->startup_and_shutdown-->desktop_settings and change the setting from "Restore Previous Session" to "Restore Manual Session.", and then remember to choose "Leave-->save_session" from the app launcher widget each time before I log out, all KF5 apps are restored perfectly, exactly where I left them, every time. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag, 16. Oktober 2015, 21:23:22 schrieb mournblade:
You're absolutely correct about the problem occurring at save-time rather than restore-time. The problem is not even with the session-saving code per se. It seems to be working fine in isolation. The problem only occurs when the session-saving code is called automatically at logout. It's either some kind of timing issue, as you suggested, or the session-saving code is conflicting with other processes running at logout-time. I've noticed frequent kdeinit5 seg faults at logout when sessions are set to autosave and one or more kf5 apps are open, but only when both these conditions are true.
Well, I'm not sure about all details, but AIUI ksmserver signals each application to write its state to ~/.config/session/, and only then adds a command to restart the corresponding application to ksmserverrc. So if an application crashes while storing the state, it probably won't get restored. The bug report I linked to mentions that the session storing code (in Qt5) seems to be called when the window is already closed. Trying to access a non- existing window (to get some window properties e.g.) will of course cause the application to crash, so this might indeed be the actual reason for the problem. Other indications for this: - Kmix5 is _reliably_ restarted AFAICT even with Autostart turned off (i.e. by the session management). This lives in the system tray and doesn't have a window open in the first place. - I do see "BadWindow" errors during logout in ~/.xsession-errors-:0 on my system, closely resembling the number of open KF5 applications on logout. So, I suppose we'd need to find out why this happens and fix the crashes to have reliable (automatic) session management... Btw, I'm not sure I looked at the right place, but it seems Fedora does not include those two patches you mentioned in their current Qt 5.5 packages at all. One of them is included upstream, but not the other one. Sure that this still works in Fedora? Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Tuesday 20 October 2015 17:35:57 Wolfgang Bauer wrote:
Am Freitag, 16. Oktober 2015, 21:23:22 schrieb mournblade:
You're absolutely correct about the problem occurring at save-time rather than restore-time. The problem is not even with the session-saving code per se. It seems to be working fine in isolation. The problem only occurs when the session-saving code is called automatically at logout. It's either some kind of timing issue, as you suggested, or the session-saving code is conflicting with other processes running at logout-time. I've noticed frequent kdeinit5 seg faults at logout when sessions are set to autosave and one or more kf5 apps are open, but only when both these conditions are true.
Well, I'm not sure about all details, but AIUI ksmserver signals each application to write its state to ~/.config/session/, and only then adds a command to restart the corresponding application to ksmserverrc.
So if an application crashes while storing the state, it probably won't get restored.
any news on this? I'm not sure, but could it be a race condition when multiple instances of a single application try to write their session data? Most of the time I see e.g. my dolphin windows restored if it is just one - as soon as I have more than one open during logout, noone will be restored. Sometimes I feel that as soon as I open a second window no window is restored after re-login - even if I just leave one window open (but I do need to verify that) Nico
Am Donnerstag, 19. November 2015, 01:42:07 schrieb Nico Kruber:
any news on this?
Sorry, no. Not yet.
I'm not sure, but could it be a race condition when multiple instances of a single application try to write their session data?
It definitely is some kind of race condition IMHO, but I don't think it's related to multiple instances of a single application. Rather Qt5 may close the window before the application saves its state, or something like that. I will investigate this as I wrote, but it needs time. As it's kind of random, it doesn't make it easier to debug. It may depend on your system though, I have the impression that the slower the system is, the less likely the problem happens. My experience is that it doesn't happen in my VMs with Tumbleweed and Leap e.g., of course they run a bit slower so that might "fix" it. I can reproduce it on real hardware though (running 13.2). Only randomly, but not too seldom. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Donnerstag, 19. November 2015, 23:13:30 schrieb Wolfgang Bauer:
Am Donnerstag, 19. November 2015, 01:42:07 schrieb Nico Kruber:
any news on this?
Sorry, no. Not yet.
Actually there seems to be some work going on currently to fix this: https://bugs.kde.org/show_bug.cgi?id=354724 At least since yesterday the bug report contains a detailed analysis of what's going wrong. So there is hope, I'd say... ;-) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Dienstag, 24. November 2015, 16:10:21 schrieb Wolfgang Bauer:
Actually there seems to be some work going on currently to fix this: https://bugs.kde.org/show_bug.cgi?id=354724
PS: People interested in the topic should probably follow this current mailing list thread as well: http://marc.info/?l=kde-core-devel&m=144832700109449&w=1 Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
PS: Am Donnerstag, 15. Oktober 2015, 21:17:07 schrieb mournblade:
KDE is no longer working on the problem any longer because they have marked the issue solved.
There is a still open bug report against Konsole, which mentions that the same problem exists with KWrite as well: https://bugs.kde.org/show_bug.cgi?id=349481 Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 10/16/2015 07:58 PM, Wolfgang Bauer wrote:
PS:
KDE is no longer working on the problem any longer because they have marked the issue solved. There is a still open bug report against Konsole, which mentions that the same
Am Donnerstag, 15. Oktober 2015, 21:17:07 schrieb mournblade: problem exists with KWrite as well: https://bugs.kde.org/show_bug.cgi?id=349481
Kind Regards, Wolfgang
It's rather unfortunate that the bug-filer assumed the problem was an app-specific problem. The bug has been assigned to the Konsole devs, and has been sitting there with no action since June. I assume that the bug-filer didn't realize that all the other KDE apps he was leaving open and having restored successfully at login were still Qt4-based. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (6)
-
Luca Beltrame -
mournblade -
Nico Kruber -
Patrick Shanahan -
Wolfgang Bauer -
šumski