Difference between revisions of "Talk:Proposal of a Widget Set independent Event Queue implementation"

From Free Pascal wiki
Jump to navigationJump to search
Line 1: Line 1:
 
== Purpose of nogui ==
 
== 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. [[User:Vincent|Vincent]] 23:38, 13 January 2011 (CET)
 
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. [[User:Vincent|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. [[User:Mschnell|Mschnell]] 15:04, 14 January 2011 (CET)
  
 
== Event Queue in the LCL ==
 
== Event Queue in the LCL ==

Revision as of 16:04, 14 January 2011

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)

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)