touch-packages team mailing list archive

[Alexey Chernov <1446865@xxxxxxxxxxxxxxxxxx>]

(In reply to Thomas Lübking from comment #24)
> (In reply to Alexey Chernov from comment #23)
> 
> > Comments like this clearly don't help
> Seriously, you asked for breaking clients because that's what you'd "like"
> to do - what did you expect to hear? That's simply not an acceptable stance.

No one here presents any absolutely true point, otherwise there were no
discussion. I just wrote my point of view and emphasized that it's just
mine and not some ultimate truth.

> > Never mentioned minor update or particular version. Please don't distort.
> So you meant to schedule this for Qt6?

No. I just stated that I didn't mention any particular version, no other
implications. As to your question, I'd prefer properly test the patch,
including success scenario for the default not-aware-of-session-
management application, and release it as soon as possible.

> > Users were already hit when the significant part of functionality important
> > for someone's every day use case is broken.
> Let's be honest: session restorage is apparently relevant for only a
> minority of users.

According to what? Your assumption? It's not too evident for me, sorry.

> Loosing your data is however relevant for everyone. And the latter is the by
> far more severe issue. Restarting applications is merely an annoyance,
> loosing your work is truely expensive.

Hey, how could session management be "apparently relevant for only a
minority of users", but fixes in its behaviour be crucial for a lot of
them? Don't you contradict with yourself in these two points?

Anyway, it's very subjective and I wouldn't argue on what's more
important. I agree that data loss is the worst thing which could happen.
I just think it doesn't mean it should result in some messy API or
library code when someone's relying on the undocumented side-effects.
Just because it will surely lead to more bugs and more data loss in the
future. It's just the bugs which should be fixed either in library and
its clients. It's better to fix them when no one really relies on the
stability too much. It looks like this time is now for KF5-based
application and environment.

> Also there's absolutely NO reason why we should not care about both - except
> that you'd "like" to break client code and risk data loss for some reason
> that completely escapes me.

No, that's just postponing and messing up the whole problem. If, as you
stated, almost no one implemented easy and pretty simple interaction
appeared in Qt5, even less would care of possible bugs and corner cases
of the workaround, more complex protocol with close event you propose.
There would be just another argument that it's just too messy, not to
mention already existing argument that no one uses session management.

> > Still better than a couple of API methods like "enableSpecifiedBehaviour()"
> 
> I fully agree on that proposal to be of little help - it will be mostly
> ignored or used w/o accounting the implications.

Ok.

> > Once again: we all could already apply the fix of Andreas and be busy fixing
> > the necessary applications rather than keep discussing here.
> 
> It does NOT only affect KDE applications, there're hundreds of Qt
> applications which might have adopted this pattern - or simply don't care
> about session management itfp.
> Also the proper order is to fix and roll out clients, *then* remove the
> deprecated upstream code. That's why "=> Qt6" for this approach.

Fully agree here, but we should confirm that nobody said in the
beggining that upstream changes were about to break session management
for KF5 applications. It was just broken. Since we have what we have,
there's no other way than to start fixing it on both sides. I think
nobody is against if it would be synchronized.

> > On the Qt6 release you would say that everyone already rely on the
> > workaround there was in Qt5 etc. etc.
> 
> No. Because you would tell people during Qt5 don't do this and don't rely on
> it because it's not gonna work with Qt6, so that when things are ported to
> Qt6, client code has to be fixed.

Oh, you're too optimistic here. Why it's still not fixed during porting
on Qt5? Only because it just works. It won't be fixed until it's broken
or would be planned to fix as we discussed above.

> Breaking it now and depending client behavior on whether it's linked against
> Qt 5.6 or Qt 5.7 is plain wrong and begging for trouble.

That's again due to your assumption that session management is of lower
priority. I'm pretty sure there would be packages that would require
just most recent Qt version, and it would be acceptable. What's wrong in
relying on changes in recent Qt release and informing the maintainer of
it with more strict requirement? There're backports if someone is
interested in special cases.

> > I just kindly remind your description of current Plasma 5 and it's
> > application state: https://bugs.kde.org/show_bug.cgi?id=341930#c30.
> Off topic? This was a global statement. Session management in particular is
> a different thing:
> few people seem to really care about restoring sessions.

Repeating it again doesn't make it proved, sorry :)

No, it's not off-topic, but an argument that it's generally normal to
break something in this state of stability. To get things simpler: I
think, it's normal to make this change in this changes time frame, you
think, it's too late and we have to wait for the next.

> > In a couple of years
> We'll have seen Qt6 and this removed, but even if not - it doesn't matter.
> The QGuiApplication code will have a "// TODO Qt6" comment and the client
> code does not care about why there's a close event (which might be rejected,
> thus not causing eg. deletion anyway)

In this way all the bugfixes should be postponed till Qt6 as someone
could rely on the buggy behaviour or side-effects. By the way, are you
completely sure your changes won't break any clients? What if someone
relies exactly on the current code?

> > The only arguable point is whether it's safe to have it fixed now or should
> > another (possible API-changing) workaround should be added instead.
> 
> No.
> Actually I propose to fix the "workaround" already present in
> QGuiApplication by turning "close()" into just sendind a close event (for
> that's actually the desired action) and by this fix session storage and
> maintain data protection with the present approaches.

It's still changes that should be taken into account both in SM server
and clients as long as it's neither "old" nor standard scenario. It's
just hotfixing for quite unclear reason.

> Breaking that behavior may happen for Qt6, anything else will be perceived
> as regression.
> 
> On a sidenote:
> QGuiApplication::commitDataRequest() may be the "preferred" hook, but
> there's actually nothing that explicitly forbids "fake a close in addition",
> notably since it will trigger similar, if not equal client code.
> Given the status quo, I'd probably even just remove the commitDataRequest
> signal in Qt6 and rely only on faking close events - why should client code
> have to care about two different "aboutToClose" signals? Sounds stupid to me.

Your own assumptions again, but I don't tend to consider them
irrelevant, so in constructive way: that's not so stupid, since
commitDataRequest doesn't mean anyone is quitting or closing windows,
but means some data interactions. In the opposite, close event or
aboutToClose do mean closing and quitting, but don't imply any data
interactions (as it's too late). When you close windows on commitData()
and interact with both user and SM server while you should close you
windows, it pretty much will lead to hurt and pain.

-- 
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