[Lazarus] Even more radical suggestion regarding Event Queues

[Michael Schnell]

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.)

With Windows, this problem does not appear, as non-GUI events are 
scheduled by a PostMessage() or PostThreadMessage() API call, that 
automatically wake up the target-thread.

So a more radical way of Event handling with Linux could be worth 
considering.

The Widget Set could be assigned to a dedicated thread, while it's 
callbacks are transferred to the main thread via the application's 
message queue (that is implemented anyway) by Application.QueueAsyncCall().

The Pro being:
  - The Main thread is completely independent of the GUI, the sleeping 
and waking of the main thread can be done with pure Linux means, 
automatically scheduling the GUI- and the non-GUI- events appropriately, 
while the GUI thread does it's work undisturbed by that.
  - no necessity to permanently run (poll) the Widget Set loop, reducing 
the overall CPU time
  - the Widget Set code (running in another thread) can run on another 
CPU in an SMP system (very common nowadays), thus providing more 
performance both for the GUI and for the application itself.

The obvious Cons being:
  - much work for developing the code and testing it
  - adding another level of complexity to the code for the LCL's GUI 
controls due to inter-thread data transfer when calling GUI functions 
and when taking GUI callbacks.

-Michael