[Development] Ref-counted quit

Olivier Goffart olivier at woboq.com
Mon Jan 2 11:35:31 CET 2012


On Sunday 01 January 2012 23:21:33 Thiago Macieira wrote:
> On Friday, 30 de December de 2011 08.12.58, Stephen Kelly wrote:
> > As the current API is a low-level API, you can put any front-end API you
> > wish on top as an alternative. I'm not convinced that would solve any
> > problems though. I don't think you've proposed a concrete enough
> > front-end API to evaluate.
> 
> No, because I was trying to collect the use-cases first.
> 
> > > 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.

Because kmail has bugs do not mean the feature is invalid.

non-guis jobs can be background save and stuff like that that we need to end 
before quitting. It usually do not last very long, but the window can be ready 
closed.

Also, there is all the kind of jobs with out of proccess ui (i did not say 
window), for example, you can only see the progressbar in plasma if you click 
on the right area.


Also, there is the case of the console applications.


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

Which need a refcount anyway.





More information about the Development mailing list