touch-packages team mailing list archive

[Thomas-luebking <1446865@xxxxxxxxxxxxxxxxxx>]

> 5. I completely don't like the proposed way to preserve the compatibility with (4) and make 
> the use case of broken session management client implementation legal and default, but 
> also try to allow proper-written apps to still survive somehow, adding some strange 
> workarounds to Qt as closing all the windows, but not too much, or API properties to enable 
> proper processing of SM messages.

No ofense, but what you "like" is completely irrelevant.
You propose to intentionally break clients by library changes in some minor update, to teach developers to do right, but while you might aim their face, you're gonna hit the users (and probably yours)

We had that (I kindly remind of the qDeleteAll fix ...) and it cooked up
hell.

commitDataRequest hardly shows up in lxr.kde.org, what means it's
probably not used at all and aboutToQuit (which isn't used but could
come to rescue) isn't used too much either.

The BY FAR! omnipresent pattern is to listen to queryClose() which is called/emitted on -guess what- close events from KMainWindow.
And that's for pretty much sure why the (wrong) behavior in QSessionManager exists.

Is this behavior correct? No.
Does this matter? NO!

It's ok to spam a #warning that this behavior is shit and deprecate and
kill it for Qt6 and we might even bail out (aka "fix") KMainWindow
applications NOW by invoking queryClose() on
QGuiApplicationPrivate::commitData() but regardless, we MUST assume this
to be a global default pattern that applications (also beyond KDE) rely
on (also because it's absolutely natural to intercept closing to save
data and not think of closing on session end could be something entirely
different - actually the illegal behavior happens to be the most sane
one...)

Now, *actually* closing windows to test interaction on session end is of
course just as wrong - if the user cancels the logout by such incident,
we should not have closed random other windows before (letting alone
that it causes this but) - therefore I frankly do not understand what's
so complicated about just faking a close event to serve the present
"save your stuff" pattern in a majority in clients without causing the
destructive close itself which may not only be a bit premature, but also
triggers this bug.

It's the least invasive solution that does not require everyone to
signal "yes, i can sessionmanagement" (what's not gonna happen) and we
don't risk loosing the users data (or breaking the ability to cancel the
logout)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1446865

Title:
  KDE5/Qt5 does not support session restoration

Status in KDE Base Workspace:
  Confirmed
Status in Qt:
  New
Status in plasma-workspace package in Ubuntu:
  Confirmed
Status in qtbase-opensource-src package in Ubuntu:
  Confirmed

Bug description:
  KDE5/Qt5 does not support proper session restoration.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/kdebase-workspace/+bug/1446865/+subscriptions