[Lazarus] nonlcl basic issue: is codetools LCL dependent?

[Michael Schnell]

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