[Development] Ref-counted quit

[Thiago Macieira]

On Monday, 2 de January de 2012 13.01.36, Stephen Kelly wrote:
> What does the 'delegate side' API look like?

Nothing. This object would be created and, when it's "closed", if it's the 
last window, the application should quit.

> Does your proposal require QGuiApplication or is QCoreApplication enough?

The class should be in QtGui. I don't mind it working without QGuiApplication.

But come to think of it, is there anything we can do in the windowing system 
to tell it that a particular window, even though from another process, is 
actually ours? So it's task-managed properly?

If we do that, then it's very likely to require QGuiApplication for the 
windowing system communication.

To support the case of integrated UI in Plasma, which don't have a dedicated 
window, then we may need to support a "windowless" mode too, in which the 
class is just an empty shell.

> How does the 'manager' process communicate to its delegates?

User's responsibility. This class is just a front-end you should manage to 
make sure you have a representation of the external window.

> Does that restrict my choice to a particular IPC mechanism?

No. How you communicate with the other process is your own problem and 
solution.

> Does the manager keep track of its delegates?

Good question. I guess it would depend on the windowing system, if we have a 
notification of remote windows being closed. I'd like it to be automatic, of 
course. Also, programmatically closing this object should send the appropriate 
close events to the remote window over the windowing system, if supported.

That does not preclude other kind of IPC mechanism.

> How is your proposal open to abuse (of the API - I don't mean from a
> security POV)?

Being clear what it's about should be deterrent enough.

If possible, I'd like the construction to involve having a window ID of some 
sort that ensures that it isn't easily abused.

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

It doesn't. I'd like to get some kind of window ID to ensure that

> Does your proposal actually solve any of the problems you say must be solved
> by the API?

Yes, it's clear what it is about: managing this application's state about out-
of-process windows.

If quit-on-last-window-closed is enabled, this window being in the open state 
will prevent the application from quitting. If the state is not enabled, then 
nothing happens either way.

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

Indeed, because I am asking for a good implementation and solution to be 
proposed *first*, before we can accept it. The burden is on whoever wants this 
feature in. I'm giving a proposal for people who may want it.

But it's not a QtCore feature, so it is actually outside of my area.

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

Of course it can. But then the ref/deref API wouldn't be public. It would be 
just an internal mechanism inside QGuiApplication, which probably already 
exists.

My problem is making *that* mechanism public. The API needs to be well-thought 
through. In order to do that, we need to have a good understanding of the use-
cases. That's what I was trying to promote.

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

I don't see a need to expose the actual integer count of windows. I really 
don't like "ref/deref" in QCoreApplication, as it doesn't make much sense. It 
sounds like the QCoreApplication object will be deleted when the count reaches 
zero, which isn't true.

You say I am discarding valid use-cases. Maybe I am. Please propose a counter-
alternative to what I have proposed. Start by not changing QCoreApplication's 
API -- a new class would be better.

You may also want to investigate how this would integrate with a concept like 
Android's "wakelock", which is a way for applications to tell the kernel that 
an on-going job is happening and the CPU should not completely suspend. That 
is, it may enter low-power states, but it cannot suspend operations 
completely. (TBH, it feels like a hack for not fixing application's that fail 
to remove their wake-up timers, but it's besides the point)
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/73c4fe21/attachment.sig>