[Development] Ref-counted quit

[Stephen Kelly]

On Monday, January 02, 2012 10:51:31 Thiago Macieira wrote:
> > 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.

Not just remote windows being closed. In this usecase there is not one window 
per running job. It might be just an entry in a QListView. So sending a close 
event to the delegate through the windowing system might not make sense.

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

Being clear about what ref/deref is 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.

What if I use my own winId? 

delegate = new Delegate(myWidget->winId(), this);

Would that be abusing the API?

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

Also solvable by simply using different method names for ref/deref, or 
creating a simple class to wrap those methods. Your winId proposal has no 
advantage over that.

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

The current patch and proposal is a patch to QCoreApplication, so as far as 
it's currently under discussion, it is on your plate. I don't think your 
gui/window system idea has real benefits beyond adding complexity.

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

class QApplicationAutoQuitter
{
  QApplicationAutoQuitter(QObject *parent = 0)
  {
    qAppPrivate->refBikeshed(); 
  }
  ~QApplicationAutoQuitter()
  {
    qAppPrivate->derefBikeshed(); 
  }
};

But of course that's still also open to all kinds of bugs because someone 
could new the class and not delete it. I'm not certain it's any 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)

That sounds not in scope of what I'm proposing.

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/e2e21dc0/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/e2e21dc0/attachment.sig>