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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
