[Lazarus] What is the future of NoGUI widget set?

[Michael Schnell]

On 01/27/2011 09:48 AM, Sven Barth wrote:
>
> Wouldn't a clean "nogui" implementation allow to use this message loop 
> stuff for other widgetsets as well? Instead of refactoring the other 
> (in use) widgetsets first, start with a nearly unused widgetset and 
> then refactor the other ones if that one works.
>
Many Widget Types provide "Event Queue" implementations to provide 
inter-Thread-Notification like Application."TThread.Synchronize", 
"QueueAsyncCall" (plus the "Windowish" Message stuff), merging theses 
Main-Thread-Events with the GUI events generated internally by the 
Widget Type code.

Of course with Windows this needs to be done on top of the Windows 
Message API, but with other OSes a queue needs to be implemented in code.

I feel that additionally to the currently non-Alpha Widget Types 
(Windows, gtk2, qt, cocoa) several more Widget Types are useful and 
supposedly will be improved and/or created ("active NoGUI" being one of 
them, "fpGUI" is already on the run). And most will need an Event Queue 
(-Class) with a very similar functionality and implementation (using an 
OS or Widget set API and (if necessary) merging the events with the GUI 
events)

Thus, IMHO, a Widget Type independent central implementation of this 
class (servicing Application."TThread.Synchronize", "QueueAsyncCall", 
and the "Windowish" Message stuff <plus TThread.Queue, which we know 
from Delphi ) would make more sense than doing yet another implementation.

(Once this is done, the existing non-alpha Widget Type can be updated to 
use it - if somebody cares, which should be quite easy if the new 
centralized stuff is done by reusing the existing code from - say - gtk.)

-Michael