Talk:Proposal of a Widget Set independent Event Queue implementation
Purpose of nogui
It would be best to refactor the current code, so that there is no need for a nogui widget set anymore. The nogui widget set sole purpose is to be able to use some constants from the forms unit (mrOk for example) and to include the forms unit into a console application without linking errors. The goal is to make nogui obsolete as soon as possible. Vincent 23:38, 13 January 2011 (CET)
Instead a new "active" NoGUI Widget Type should be provided for embedded applications that does not use (and require) a GUI binding but does have an Event Queue and does allow for Event driven programming, TTimers, and Thread communication in a "normal" way. Mschnell 15:04, 14 January 2011 (CET)
Event Queue in the LCL
AFAIK, all event queues in the LCL are provided by the widget set. The LCL does not have own event loops, but only hooks into the widget set's event loop. If there were a pascal based event loop, it would not belong in the LCL, but in a TCustomApplication descendant in the FCL or in a third party component library (FPGUI?). The LCL.TApplication would probably not descend from TCustomApplication descendant, because it does not need a pascal based event loop. Vincent 23:38, 13 January 2011 (CET)
Even if this is true (it is with Windows, as here the Widget Set API and the OS-API is just the same, and the "Message Queue" is done by Windows and thus it's a good idea to use it as the LCL Event Queue, but Linux and Mac Widget Sets do have an Event Queue done in their Pascal code. As far as I found, these Widget sets do callbacks to notify the application of GUI events and thus the application can (or even needs to) implement it's own Event Queue if it needs one. The "Loop" provided with these Widget sets is necessary, as the program flow always needs to be returned to the widget set, to allow the GUI controls to stay active without user program actions. Mschnell 14:57, 14 January 2011 (CET)
In fact it's obvious that QT and similar X-based widget sets do somehow queue the GUI events. But as they (AFAIK) do dedicated callbacks for each control element and don't use a central dispatch point this seems to be quite invisible to the application program, while Windows provides all GUI evends in an obviously queued order, in a single API call ("WaitFor..Object") of the Lazarus application. Mschnell 17:10, 17 January 2011 (CET)
Title of page misleading
Given the reason of the above paragraph, the article title is misleading. It suggest that the Event Queue in Lazarus LCL will be improved. This is not the case or even desirable. A better title would be A proposal of a Event Queue implementation in Pascal. Vincent 23:38, 13 January 2011 (CET)
Done Mschnell 17:11, 17 January 2011 (CET)