[lazarus] Widget vs. Platform Independence

[Jeff Wormsley]

On 30.09.99, at 9:12 AM, Michael A. Hess wrote: 

>Do we have a syntax problem in our communication??? A definition of
>terms problem or what??
>
>I thought I clearly stated above that we are trying to code the LCL so
>that it doesn't need any given widget set library. We want it to use a
>variety of libaries. Since these libaries are becoming more and more
>available on Win32 as well that also makes it platform independent. So
>exactly where am I stating that I, "don't really want widget set
>independance"?

Just to jump in a sec, while that does give "platform independence" it is a very sub-optimal solution, since you have to distribute the widget set DLL's with every win32 app.  Vey VB'ish there (but then again, even Delphi succombed to the 'package' thing).

>> let wndproc dispatch.
>
>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.  

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.  The LCL message would be recieved by the "WindProc" and handled appropriately.  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.

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. 

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.

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.

Jeff.