[Lazarus] Even more radical suggestion regarding Event Queues

[Henry Vermaak]

On 20 January 2011 11:59, Michael Schnell <mschnell at lumino.de> wrote:
> After some more thinking about the issue:
>
> Obviously doing Event Queues with the current Linux based Widget Types is
> not easy to do (in the way it is done right now). In some revisions
> PostMessage does not work at all, in some revisions
> TApplication.QueueAsyncCall does not work as expected, in some revisions
> TThread.Synchronize does not work as expected (While TThread.Queue is not
> implemented at all).
>
> As far as I understand, (e.g.) the gtk (2) Widget Set is used by a "loop"
> (repeated call or callback) that alternately runs the Widget Set code and
> the application program code, while the widget set code (additionally)
> performs callbacks into the application program code when a GUI event is
> fired by the user's interaction.
>
> Now, at some point the code (GUI Thread) needs to go to sleep if nothing is
> to be done. It seems like the Widget Set is done in a way that it
> automatically wakes up the GUI Thread when user interaction is detected and
> thus the appropriate Callback is done and seemingly as a consequence, the
> "loop"ed code in the application program is executed, too, resulting in
> execution of all events scheduled up till now.
>
> This results in the problem, that waking up the program whenever an event is
> to be handled that is not generated by the Widget Set, is not that easy to
> do. (Especially regarding that doing too much polling will degrade the
> overall performance.)

No, it's very easy to do.  At least gtk and qt has dedicated functions
to do just this (g_main_context_wakeup() and QEventLoop::wakeUp()).
Lazarus just has to do this after QueueAsyncCall (I do this manually
myself for the moment).

Henry