On 10/18/2010 09:57 AM, Michael Van Canneyt wrote:
How else can you do this ? Each widget system uses it's own
mechanisms, the LCL must somehow unify this, and they did. To remain
delphi compatible, they based the 'public interface' on the Windows
mechanism.
"Windows" is the only OS that provides an Event "Message" queue to the
running applications (in fact Windows even does provide it to any
thread, while Delphi and Lazarus only provide means to use it in the
Main Thread). With all other "Widget Types" (that allow for Event Driven
programming) the Event queue is done in pascal code in the LCL (or MSE
library). All these Widget Types are binding to a GUI Tool set that uses
call backs to fire the GUI events. Theses GUI events need to be
scheduled together with Timers and thread based events, so an Event
Queue is implemented in Pascal code.
A decently versatile central Event Queue implementation (best: in the
RTL) would be usable for all Widget Types. With Windows it needs to be
checked if this leads to a performance degradation (using user space
code instead of doing some additional system calls might in fact even
improve the performance, but with all other Widget types the resulting
code flow should be quite similar and thus performance should stay the same.
There was no
point in adding an additional layer in between.
I explained several points that could be improved by this in the mail
above to which Adem replied with the multiple "good"s :) .
That they succeeded in doing so is quite an achievement.
Yep. I am very happy that there have been all these knowledgeable and
helpful people that made th current implementation work !
But the forking of the Event Queue code of course is a result of
historical reasons and not of a previous plan. I am sure if the same
people had been in a position to do a plan for the current extent of the
LCL before starting the first line of code they would decide to do a
central Event Queue implementation.
Martin doesn't care about Delphi compatibility.
This is true, but IMHO it's not really relevant. The makeup of the
message queue does not harm nor force Delphi compatibility. A decent
Event Queue can schedule Windows-Compatible GUI events and
Delphi-compatible "Procedure... Message" (e.g. by emulating Windows
Messages), schedule parameter-less Events (for Delphi compatible
"Synchronize" and "TThread Queue". Additionally it can schedule any
"advanced" GUI events another Widget Type might ask for.
This is his decision, and
allows him more freedom in his choice of event system, and he has
maximised
the options he had.
In fact I did a deep look at his Event Queue implementation when I
ported it to Lazarus/Linux. I did not see anything that would prevent
Delphi compatibility but the use of the identifier name "TEvent". Upon
my request, Martin already changed this name in is snv, so that I could
do the porting just by copying unmodified snippets of his (then) current
svn code, as was my intention.
You are free to prefer his code over the LCL. Open source is about
having the choice.
Yep, if I would prefer his complete system (which I don't for obvious
reasons as stated above) I would just use it, but do not wish for an
additional ninth implementation of the event Queue mechanism for a
non-GUI Widget Type (that was my original intention) forking whatever
code available.
This would increase the said Open Source nightmare that currently
prevents doing a (IMHO viable) improvement.
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
