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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
