[Development] Allowing event delivery prior to and after QCoreApplication

René J.V. Bertin rjvbertin at gmail.com
Tue Apr 14 21:26:40 CEST 2015


On Tuesday April 14 2015 09:27:34 Thiago Macieira wrote:
> On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote:
> > This may be an open door, but couldn't you change the application's entry
> > point (or provide an alternative entry point like KDE does with kdemain).
> > That gives you an extra layer around what the user sees as the main
> > function. 
> 
> I don't see how that is beneficial to anything here. It's at best a no-op.

Having a layer above the user main should give you more manoeuvring room to perform house keeping tasks. Whether that's of use here is a different question.
It does seem though that it would allow you to stop calling notify() once the user main has returned. That won't catch cases where the Q*Application instance is deleted before main returns, but maybe those cases are less frequent.

> The problem is not the d pointer or the private class.

Wasn't saying it was.

> Same answer as I gave to Julien: if we can't force applications to call it,
> they won't and we can't rely on it being used. And if we do, it's source-
> incompatible.

Between a rock and a hard place one could opt for a compromise. You're planning to introduce changes to QtDBus that may break things. Applications that don't break because of it don't need a solution. If those that break can be fixed with a simple invocation of a new mechanism provided exactly for that purpose, isn't that good enough?

R



More information about the Development mailing list