Regarding:
inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent *event)
{ if (event) event->spont = false; return self ? self-
>notifyInternal(receiver, event) : false; }
inline bool QCoreApplication::sendSpontaneousEvent(QObject *receiver, QEvent
*event)
{ if (event) event->spont
On Tuesday 13 January 2015 16:28:02 Thiago Macieira wrote:
[...]
> sendEvent is used by QCoreApplicationPrivate::sendPostedEvents, which in
> turn is the core of event dispatching in Qt (all event dispatchers'
> processEvents call it).
>
> As you can see from the code above, event delivery is stop
On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > Finally, note what happens if there's a thread trying to deliver events
> > *while* QCoreApplication is being shut down: notifyInternal() is probably
> > dereferencing a dangling pointer.
>
> Good point.
> But one might argue that th
On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > Finally, note what happens if there's a thread trying to deliver events
> > > *while* QCoreApplication is being shut down: notifyInternal() is
> > > probably
> > > derefer
On Monday 13 April 2015 13:23:29 Thiago Macieira wrote:
> On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > > Finally, note what happens if there's a thread trying to deliver
> > > > events
> > > > *while* QCoreApplicat
On Monday 13 April 2015 13:23:29 Thiago Macieira wrote:
> On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > > Finally, note what happens if there's a thread trying to deliver
> > > > events
> > > > *while* QCoreApplicat
On Monday April 13 2015 21:12:58 Thiago Macieira wrote:
Hello,
>> I'd like some opinions on whether we should try this or not.
>
>Note another problem: if a thread is running and delivering events while the
>QCoreApplication gets destroyed, the application will have several race
>conditions:
>
On Monday 13. April 2015 21.12.58 Thiago Macieira wrote:
> On Monday 13 April 2015 13:23:29 Thiago Macieira wrote:
> > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > > > Finally, note what happens if there's a thre
On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote:
> On Monday April 13 2015 21:12:58 Thiago Macieira wrote:
>
> Hello,
>
> >> I'd like some opinions on whether we should try this or not.
> >
> >Note another problem: if a thread is running and delivering events while
> >the QCoreApplicatio
On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote:
> Would it be feasible to make event loops started before and after
> QCoreApplication truly independent from notify() but all the others "join"
> in?
Not without race conditions.
if (self)
return self->notify(object, event);
On Tuesday April 14 2015 07:28:03 Thiago Macieira wrote:
>On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote:
>I don't know how to answer this since I have no idea what retain/release is
>and does. Can you explain?
OK, sorry, I thought you had sufficient knowledge of ObjC programming (from
On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
[cut]
> ObjC is so intricately linked to OS X, because from a few quick attempts it
> seems to be perfectly possible to use an ObjC++ wrapper class to extend the
> retain/release scheme to C++ classes.
>
> Is this clear enough?
Yes, thank
On Tue, Apr 14, 2015 at 6:27 PM, Thiago Macieira
wrote:
> On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
> [cut]
>> ObjC is so intricately linked to OS X, because from a few quick attempts it
>> seems to be perfectly possible to use an ObjC++ wrapper class to extend the
>> retain/releas
On Tuesday April 14 2015 08:27:57 Thiago Macieira wrote:
>C++ already has that, it's called reference counting. You may have heard we
>use it in Qt :-)
Well, reference counting can be used for many things (like deleteLater, I
presume) :)
>The problem here is that QCoreApplication is not refere
On Tuesday 14 April 2015 18:36:16 Robert Iakobashvili wrote:
> > The problem here is that QCoreApplication is not reference counted and we
> > can't change it without breaking *every* *single* *application*, since
> > this is what people usually do:
> C++ idiom with protected destructor
> enforces
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
2015-04-14 16:36 GMT+02:00 Thiago Macieira :
>
> 2) fix it by not passing through notify() outside the main thread. That's the
> solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6.
>
People rely on QCoreApplication::notify to provide a try/catch when
working with Qt and exceptions
On 2015-04-14 12:27, Thiago Macieira wrote:
> The problem is the public, *user* class if they derived from QApplication.
>
> If they've overridden notify(), then I need to know when the *user* class
> begins destruction so that we stop calling notify().
Would it be horrible to add a new method,
On Tuesday 14 April 2015 19:55:47 Julien Cugnière wrote:
> 2015-04-14 16:36 GMT+02:00 Thiago Macieira :
> > 2) fix it by not passing through notify() outside the main thread. That's
> > the solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6.
>
> People rely on QCoreApplication::not
On Tuesday 14 April 2015 14:37:25 Matthew Woehlke wrote:
> Would it be horrible to add a new method, e.g. shutdown(), which
> subclasses are required to call in their dtor? It won't fix existing
> applications, but it at least provides a mechanism to make things work.
Same answer as I gave to Juli
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 extr
On Tuesday 14 April 2015 21:26:40 René J.V. Bertin wrote:
> 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
On Tuesday April 14 2015 15:58:20 Thiago Macieira wrote:
> They may not have noticed they're broken, but they're broken.
Ok then
> > If those that break can be fixed with a simple invocation of a new
> > mechanism provided exactly
^
shatter into pieces
>
On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote:
> On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote:
> > Would it be feasible to make event loops started before and after
> > QCoreApplication truly independent from notify() but all the others "join"
> > in?
>
> Not without race cond
On 15/04/15 11:30, "Simon Hausmann"
wrote:
>On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote:
>> On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote:
>> > Would it be feasible to make event loops started before and after
>> > QCoreApplication truly independent from notify() but all the
Knoll Lars schreef op 15-4-2015 om 11:39:
> Well, I’d say we should try to see how much this is being used. I
> don’t think we ourselves use it at all. How much is this used in other
> projects? The central notify() hook is something I don’t like at all.
> It’s very easy to mess things up using
2015-04-14 20:39 GMT+02:00 Thiago Macieira :
>
> We removed the try/catch and replaced with stack objects that will unwind
> properly. If you're lucky, an exception will simply unwind QCoreApplication
> out of exec(), so a try/catch around exec() may work.
>
> But this is untested and unsupported.
On Wednesday 15 April 2015 15:01:29 Julien Cugnière wrote:
> > But this is untested and unsupported. DO NOT throw through the event loop
> > and DO NOT throw back to the signal-slot delivery mechanism. We will not
> > deal with bug reports that this does not work. I may accept patches that
> > fix
On Wednesday 15 April 2015 11:56:04 André Somers wrote:
> We use it in our applications. It is used indeed as a catch-all
> exception handler (I'm not a fan, but ok), but a useful use we also have
> that we use it as a debug device to get more insight into what events
> are send around the system,
2015-04-15 17:11 GMT+02:00 Thiago Macieira :
> Not exactly. It all depends on what you define to be "works". I don't consider
> resuming the event loop to be "works". I think that an uncaught exception
> should exit the event loop and cause the application to exit, so I consider
> your code above b
On Wednesday 15 April 2015 20:49:42 Julien Cugnière wrote:
> The idea is that we have threads which serve requests from other
> threads through the use of slots. When an exception is thrown during
> the processing of such a slot, it means the request encountered a
> fatal error and was aborted. But
2015-04-16 1:30 GMT+02:00 Thiago Macieira :
> My idea is to provide you with the ability to:
> - decide whether to catch or not
> - supply a handler that will be called if an exception is caught
> - decide whether a caught exception resumes execution or aborts the
>application (after your ha
On Thursday 16 April 2015 11:25:29 Julien Cugnière wrote:
> 2015-04-16 1:30 GMT+02:00 Thiago Macieira :
> > My idea is to provide you with the ability to:
> > - decide whether to catch or not
> > - supply a handler that will be called if an exception is caught
> > - decide whether a caught excep
On Wednesday 15 April 2015 08:20:31 Thiago Macieira wrote:
> Thanks André. The above contains two use-cases for overriding notify():
>
> 1) catching exceptions, logging and resuming work
> 2) debugging / inspecting events
>
So far, given the responses in the interest mailing list, it appears tha
On Thursday 16 April 2015 15:22:04 Thiago Macieira wrote:
> 1) deprecate use of notify() in auxiliary threads, with the functionality
> getting removed in Qt 6 (this is a documentation change only)
https://codereview.qt-project.org/110644
> 2) add a way for threads to individually enable delivery
35 matches
Mail list logo
