[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Execution replay for Qt/KDE applications
From: "Oliver Oppitz" <o.oppitz () web ! de>
Date: 2004-10-22 11:57:45
Message-ID: opsf9sujspli378s () smtp ! web ! de
[Download RAW message or body]
Date: Thu, 21 Oct 2004 21:43:53 +0200
From: David Faure <faure@kde.org>
Subject: Re: Execution replay for Qt/KDE applications
To: kde-devel@kde.org
Message-ID: <200410212143.55441.faure@kde.org>
Content-Type: text/plain; charset="utf-8"
> On 21 Oct 2004 09:19:46 -0000, <kde-devel-request@mail.kde.org> wrote:
> There is no such doOtherThings() thing in the Qt event loop.
> The event loop waits for events.
Ok, there's a better sample:
"Another Look at Events", by Jasmin Blanchette
http://doc.trolltech.com/qq/qq11-events.html :
"Conceptually, the event loop looks like this:
while (!exit_was_called) {
while (!posted_event_queue_is_empty) { //LOOP A
process_next_posted_event();
}
while (!spontaneous_event_queue_is_empty) { // LOOP B
process_next_spontaneous_event();
}
while (!posted_event_queue_is_empty) { // LOOP C
process_next_posted_event();
}
}
"
The code sample illustrates the point better. Depending on the timing a
posted event will either be handled in Loop A or Loop C. And in between A
and C, the spontaneous event handlers will execute and modify the state of
the application. Therefore the timing when to post an event does matter...
Regards, oliver
PS: Formally doOtherThings() can do "anything", even handling events like
Loop B, C... But I have to admit my example was not good, probably
misleading even.
--
----------------------------------------------------------------------------
"To dare is to lose foothold a moment
not to dare os to lose one self" by S.Kierkegaard
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic