[lazarus] Widget vs. Platform Independence

[Samuel Liddicott]

> -----Original Message-----
> From: Jeff Wormsley [mailto:daworm at cdc.net]
> Sent: Thursday, September 30, 1999 02:39 PM
> To: lazarus at miraclec.com
> Subject: Re: [lazarus] Widget vs. Platform Independence
>
> >Again please show me how this would work with the GTK signal method.
>
> GTK signals are just function callbacks, correct?  Instead of
> being redirected through a messaging system, they are called
> directly by the widget.

This helps me see where we are confused.
Thanks.

Michael I am saying we should take the GTK callback handlers we now have
(you wrote them?) and have THEM call .wndproc instead of .dispatch.

> A GTK "windproc" could be set up be creating an object at
> component creation time that had all of the callbacks for that
> component, assign the appropriate ones to the widget, then when
> the widget called the callback (sic) it would send a LCL message
> with SendMessage.

This would work too.  I had imagined.

sed -e "s/\.dispatch/.wndproc/g" as the solution.

> The LCL message would be recieved by the
> "WindProc" and handled appropriately.

Most of which would call .dispatch almost right away.

> This differs from the
> current implementation by adding a layer to the component that
> handles the messages before dispatch, rather than having the
> Interfaces unit handle it directly.

yep.  Nice abstraction.

> In the Win32 world, the interfacing object would be slightly
> different.  Instead of having the callbacks, it would have a
> "true" (in the Windows sense) WindProc routine.  This routine
> would recieve the windows messages, translate them to LCL
> messages, and send them to the "WindProc" of the component.
>
> This way, all messages recieved by the component are the same,
> regardless of widget set or platform.

that is what I mean, but the reason for wanting this is not to support the
windows widget set (tho as Michael says he doesn't want to be widget-set
dependant I would think he woould want this), but because too many delphi
program depend.

> Something like this:
>
> LCL Object (GTK)
>    WindProc
>        CallBackObject
>
> LCL Object (Win32)
>    WindProc
>        MessageTranslator
>
> The difference between the CallBackObject for GTK and the
> MessageTranslator for Win32 would be hidden in the Interfaces
> unit, which maintains the widget and platform independence.   So
> a more accurate diagram would be:
>
> LCL Object (GTK)
>    WindProc
>        Interfaces (GTK)
>            CallBackObject
>
> LCL Object (Win32)
>    WindProc
>        Interfaces (Win32)
>            MessageTranslator
>
> There are two drawbacks that I can see to this.  One, is it adds
> an extra layer to every widget set used.  I really don't see that
> as huge, but it is there.  Second, the CallBackObject and
> MessageTranslator will likely be different for each component, or
> at least component class, which will mean a lot of work
> generating them, on top of the normal component work.  Especially
> difficult will be mapping each widget set into a generic LCL set
> of behaviors.  It will mean programming to the lowest common
> denominator of all supported widget sets.  I believe that is the
> price you pay for widget set independence.

It is, as I made clear in earlier discussions; but I don't see we need that
much abstraction in implementing this.  The current gtk until (which
intergaces GTK to LCL) which receives the callback can just call .wndproc
and all will be fine.

> Don't take the above as a recommendation on how to do things.  It
> is just an example of one way that should be feasable.  I have
> started again on another method, which is making Win32 look like GTK.

Good luck.

Sam