[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionS
From:       Thomas Lübking via KDE Bugzilla <bugzilla_noreply () kde
Date:       2016-01-31 18:00:56
Message-ID: bug-354724-17878-VnDhFe8c5p () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=354724

--- Comment #42 from Thomas Lübking <thomas.luebking@gmail.com> ---
So, looking into the Qt sources a bit more it seems that

a) Session management is FUBAR in Qt5 and actually was likewise FU in Qt4 -
adding the proposed flag will only restore the completely FU condition of Qt4,
ie. allow clients (KDE) to workaround the brokeness ...
b) this actually *only* seems to affect the xcb platform
("GuiApplicationPrivate::commitData()" is only called by
"QPlatformSessionManager::appCommitData()" which is only called by
"sm_performSaveYourself(QXcbSessionManager *sm)" in QXcbSessionManager)

Restoring the Qt4 state however won't cut it: KApplication is deprecated and
there's no Guarantee for a KMainWindow around. Also every "plain" Qt5 client
that can be found on KDE users desktops (qupzilla, trojita, ... whatever) won't
be covered.

If you "seem to be the expert on session management" we need to define a
roadmap out of this mess, or it's never gonna happen.

What do you think about this process:

1. emit commitDataRequest()
2. at this point either the logout should be canceled (requires API addition on
QSessionManager to wire up sm_cancel; internal requirement only though. Maybe
kept in d_ptr contexts) or there thould be no windows with
QWidget::isWindowModified() or modal transients around since that indicates
some user interaction should have taken place but didn't
3. If we detect missing interaction, spam a QMessageBox and inform/ask the
user:
   "It looks like the application should have intercepted the logout request,
but didn't. Do you wish to cancel the logout and explicitly save data? Since
this is an application bug and this failsafe check will be removed with Qt6,
please file a bug against the application."
4. If this still didn't cancel the logout, start closing windows depending on
an application attribute (see below) and a trumping environment variable
QT_CLOSE_WINDOWS_ON_LOGOUT_REQUEST (to pass the user ultimate control over the
behavior)
5. Remove attribute, failsafe check and (actually even documented, we can NO
WAY just remove this in Qt5) window closing in Qt6


I'd go for the application attribute since indeed there's little point in
adding functions to implement a short-term workaround.
Actually, I might even be in favor of a dynamic property
(QObject::setProperty()) since it will spare the clients compile time checks -
we an add this to KFooBar now, even though Qt 5.6 (or whatever) is not on the
horizon.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]