On Mon, 11 Oct 2010, Michael Schnell wrote:
On 10/11/2010 01:15 PM, Michael Van Canneyt wrote:
1. Make sure you make something that can be integrated with the FPC
rtl/FCL.
This would supposedly be doable be based on MSE's code. But it would need to
include quite a lot of MSE code lines, as the Event queue type is nicely
structured and derived form more basic queue types that would need to be
used.
it would not be really easy to test it as it does not synchronize with GUI
events when used with Lazarus.
I thought the one of the points was to have a message queue also when there
is no GUI ? This should be testable, no ?
2. Once that is done and it is performing as expected, it should not be
hard
to convince the Lazarus people to use it.
I doubt that, as it would need to replace the basic event management in all
Widget sets, They even two manage complete different KDE Widget Type code
bases because they don't want to take the risk of breaking old code when
having it use using common functions with the new KDE Widget Type. Moreover
all other Widget Types (GNU, Mac, fpGUI) have their own implementation of an
Event queue in Pascal code, and the Windows Widget Type uses the OS'es
Message queue. Replacing all of them with the methods provided by the RTL
would be necessary (and GUI events would need to be merged in the way all but
Windows Widget Set code does)
That's what I meant with a paradigm shift.
If of course you expect to achieve a total shift in paradigm, then you'll
be disappointed, because Delphi compatibility is paramount.
Of course Delphi code would need to run in the same way as it does at the
moment, I don't think this is difficult to be achieved.
I beg to differ. From my perspective, people bring up issues, you bring up
the event mechanism in one of the replies.
Only if I the event mechanism is the only I see how to solve the problem.
In that case, you see this quite often. Or, maybe more accurate, more than I
would.
At least, it would be a start. Now there is nothing, so we cannot even
verify that your mechanism is indeed a superior mechanism, as you claim.
In fact Lazarus does provide Windowistic Messages from a thread to the Main
Thread as a basic event mechanism. I did test this some months ago and it did
work fine. But it seems to be broken for Linux (KDE) with the current svn
version. "My mechanism" is superior in that it would be usable without a GUI
(that is why I did the work on that some months ago) and would be implemented
in a centralized way independent of the GUI and thus the code should be
better manageable.
Regarding functionality it _could_ be better: Windowish messages provide
three free queued 32 Bit parameters to the event handler procedure. An
implementations like Delphi's "TThread.Queue" would provide no parameter (but
self). A decent event queue _could_ be implemented like an an RPC scheduler
and provide any number of marshalized queued parameters.
While I agree that an object is a clean approach, for most purposes, an
object is simply unnecessary overhead, because it requires additional heap
storage.
A simple implementation for something like TThread.Queue would need to do a
queue of recored with a pointer to the procedure and it's self pointer. A
more advanced implementation would additionally need marshalized parameters.
Maybe a sensible approach is doing a queue of three words: procedure pointer,
self pointer and additional pointer. This would allow for (1) reproducing
TThread Queue and (2) allow for parameters on the heap with the additional
pointer pointing at same. If we want to reproduce the Windowish Message stuff
(for Delphi compatibility) I suppose it would be good to use four Integers as
queue records (avoiding the term Object).
Since integer is 32-bit, and you'd need 64-bit for pointers, you'll need to
test what size windows messages have.
Once more: please provide a patch.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
