Proposal of a Widget Set independent Event Queue implementation

Widget Types

Lazarus provides a library of several "Widget Type" implementations that form an interface to the underlying OS-depending infrastructure.

As the name "Widget Type" suggests, here GUI elements - often called "Widgets" are handled. Some Widget Types use an external "Widget Set" libray that needs to be existing at the application's run time. Here we have "gtk" and "qt" (usually on Linux), "cocoa" (on Mac) and "Win32/Win64" (using the Widget Set API of the Windows OS). Moreover there are other Widget Types that don't use an external Widget Set such as "fpGUI" (directly accessing a "painting" API - such as "X11" - and creating the look of the GUI control elements in Pascal code) or "NoGUI" providing no usable runtime functionality at all.

The Widget handling needs two types of functionality: 1) providing an API to the application program for displaying the GUI Controls 2) firing application code Events when a GUI control is accessed by the user (e.g. by means of mouse or keyboard)

The Event Queue

The "Object Pascal" (Delphi like) way of application program makeup is called "event driven" programming. Here the program is completely created as a set of "Event Handler" procedures, that are called by the infrastructure (done in the run time libraries) when appropriate. With this, the program sleeps most of the time and gets active only when necessary, and - unless explicitly coded - no concurrency (multiple threads) occurs, preventing the necessity of protecting objects from mutual use, while providing a kind of cooperative multitasking within the application.

With Lazarus (and Delphi) these events are only available in the main thread of the Application and an "Event Queue" guarantees that all events that are originated by external processes (such as the user working with the GUI, a timer, a worker thread requiring attention of the main thread, ...) are scheduled one after the other in the order as they are fired.

Each event handler is a "run to completion" object. It is never preempted by another event but is known to run undisturbed until the procedure exits. If the application programmer want, (s)he can use "Application.ProcessMessages" to allow for handling all scheduled events while the running event handler is temporarily halted at this point of execution (i.e. calling all scheduled event handlers like subroutines.)

Obviously the Event Queue functionality is provided by the TApplication object, i.e. by the "Application" instance that is auto-created for the main thread of a user application by the initialization code in the LCL. Theoretically it is possible to enhance this proceeding in a way that a worker thread, too, can instantiate a TApplication object and thus get it's own message queue and thus allows to be programmed in an "event driven" as run to completion objects, as well. Of course the event queues of worker threads are not supposed to receive GUI events (which would ask for a reentrant implementation of many complex LCL functions), but it could receive TTimer events and events generated by other threads.

The Event Queue is done in different ways for the different OSes. Windows provides a "Message Queue" to user applications. In fact it provides a Message Queue with any of the application's windows, so an application can have multiple message queues. Accordingly the LCL (and the Delphi VCL) currently uses this Message Queue to implement the Event Queue for the application's main thread. Windows automatically places GUI events, generated from control elements in this window, in this queue. Application programs (the owner of the window as well as other applications) can schedule events by the "PostMessage" API call. Worker threads additionally can use slightly faster PostThreadMessage call.

Due to historical reasons

ToDo

Thread programming for SMP