[Development] Ref-counted quit

[Stephen Kelly]

On Sunday, January 01, 2012 23:21:33 Thiago Macieira wrote:
> > > To fix the front-end API we need to find out what the use-cases are
> > > that we're trying to solve. So far, I've only heard one: preventing
> > > an application from quitting while it has out-of-process windows
> > > open.> 
> > We have been discussing other use cases for some time.
> > 
> > There's also the non-gui Akonadi case (which is running many jobs which
> > are of no interest to the user), and the case the cleanup cases aseigo
> > brought up on the review request.
> 
> I've reported a few bugs[1][2][3] today against KMail and Akonadi that are
> directly or indirectly connected to background jobs. I didn't do this on
> spite: it's just that today is January 1st, which is my yearly "archive the
> emails" day. Those are the issues I've run into today and I simply decided
> to report, as they included data loss.
> 
> So colour me biased if you want. I am discarding "non-gui jobs" as a valid
> use-case.

I don't know if biased is the word, but I don't think veto-ing an API or 
calling the entire use-case invalid because you have hit some application bugs 
or user interaction bugs is justified. That seems very odd to me. The bugs you 
filed are bugs in the user interaction design of the applications. They are 
not bugs which come from the KGlobal::ref/deref API. I doubt you can design an 
API which can force better user interaction design in applications.

By the way, an overly restrictive API which you are hinting at would certainly 
also be broken in other ways and would just be worked around anyway, I expect, 
if needed. 

Or KGlobal::ref/deref will still be around in KF5 and your bugs will have to 
be fixed by *actually* fixing the bugs *anyway* - eg by adding UI for the jobs 
and fixing the underlying bugs that make the move fail etc. The low level 
ref/deref API does not pre-forbid or prevent showing UI for whatever 
represents a refcount bump.

> 
> > > Are there more?
> > > 
> > > If there are not, then we can create an API for that one use-case.
> > 
> > Can you propose an API that satisfies all available use-cases so far?
> 
> We only have remaining the out-of-process window. 

Either you didn't address asiegos comments from the review request or I missed 
it.

And I'm still not convinced that's the only use case. You're the one that 
needs convincing though.

> So the API I'd propose is
> similar to that of a QWindow, similar to that of an QX11EmbedContainer too.
> If you open a window in a certain way and you manage that, then keeping
> track of windows that are not in your process should be similar.
> 

*shrug* Sounds complicated and restrictive. I also can't picture the 
implementation. 

Taking QX11EmbedContainer as the example, you seem to propose that that would 
be the API for the 'manager' to manage the 'delegates'. 

What does the 'delegate side' API look like? 
Does your proposal require QGuiApplication or is QCoreApplication enough? 
How does the 'manager' process communicate to its delegates? 
Does that restrict my choice to a particular IPC mechanism? 
Does the manager keep track of its delegates? 
How is your proposal open to abuse (of the API - I don't mean from a security 
POV)? 
How does the 'manager' ensure that the delegate is actually showing UI and 
that the UI and user interaction design of the application is sane? 
Does your proposal actually solve any of the problems you say must be solved 
by the API?

I'm having to guess a lot here because I don't think you've given enough 
information about how what you are proposing will actually work and who will 
implement the (complex, as per my guesses) code.

I still say lets have our cake and eat it too. Your proposal can be 
implemented on top of ref/deref. 

QtCore is yours to maintain though, so if you don't change your mind then 
that's the end of it.

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/23ad0424/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/23ad0424/attachment.sig>