On 06/26/2014 07:38 PM, Mattias Gaertner wrote:
If you mean for TTimer: Yes, I'm waiting for your patch.
Meaning what ?
I can send you a testing application (that does nit use the LCL but just
fpc) if you just want to see it working.
For doing a "Patch" to the LCL, some more prerequisites are needed:
- do we want something at all if it is not usable with the "released"
version of fpc (see discussion in fpc-devel)
- can we do an extension to the current "noGUI" Widget Type
. - here: do we want to add a "sub-WidgetType) similar to
"fpGUIPlatform") to allow for selecting old and the new behavior so that
no incompatibility problems can come up.
- or do we need a completely new Widget Type "AciveNoGUI", preventing
any incompatibility problems for current noGUI users.
. - here the IDE somehow needs to know about this I have no Idea how to
implement this.
So? Program a queue.
IMHO this is not appropriate.
There already is a queue in the RTL that needs to be handled, as same is
fed by TThread.Synchonize (and TThread.Queue) user accessible functions.
Hence an additional queue would need merging the queue outputs and
handling the waiting and waking for both Queues simultaneously. This
(waiting and waking regarding the additional queue) needs arch depending
code (as done in the GUI based Widget Types). But the NoGUI Widget Type
is done for small embedded projects. here arch-independence, low latency
and low processor demand is critical.
They implement a second queue besides the one the RTL implements for
TThread.
Probably they have several.
IMHO it is not a very nice concept to merge queue outputs. This of
course has historical reasons with the existing GUI based widgets sets.
IMHO it would be better top merge the queue inputs and hence waiting and
waking is central.
(A concept to do this would be a central Event Queue implementation in
the RTL that always is used by the LCL Widget sets. Of course with the
Windows widget set this technically can't be done, as you need to use
the OS Message Queue. To provide for this, the RTL's Queue would need to
allow for overriding the appropriate input and output functions to allow
for using a (single) external queue such as the Windows message queue.
Ok. You have the tools, you have a proof of concept, now program it
and create a patch.
Of course I am happily up to do that :-) .
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
