[lazarus] Progress

Jeffrey A. Wormsley daworm at cdc.net
Wed Sep 1 18:37:19 EDT 1999


On 9/1/99, at 4:23 PM, Michael A. Hess wrote: 

>If you think that you can make it do all of this well then great. We had
>this dicussion back in the beginning of the summer where we mulled over
>the possibility of writing directly to the XLIB or GDK. We all decided
>that it wasn't the way to go. Now all of a sudden everyone is talking
>about doing that again. If you go that way I feel that it will be
>extremely difficult to keep the indendence we have started with the
>InterfaceObject stuff. The only way to do it will most likely be to tie
>GTK or whatever API directly to the LCL.

It depends on what you are doing.  If a feature exists in toolkit A and B,
the Interface object can directly link to the toolkit.  If it doesn't exist
in toolkit C, then you may have to implement it in toolkit C, using toolkit
C's way of doing that, then link that to the Interface object.  If GTK has
no method of overriding the paint or draw of ANY widgets, then it is indeed
likely that this could never be done, which is what it seems you are saying
below.  If this is indeed the case, then if there is going to be platform
independence, ie: write once, run anywhere code, then the LCL will indeed
have to be written to the lowest common denominator, and I am afraid that
may reduce greatly the  intended audience of lazarus.  "You can write code
for all of these platforms!  But...  it is limited to simple, ugly apps
with none of the best features of any platform."  That doesn't make for
good ad copy, IMHO.

>Above you state that users will be able to create their own widgets. I
>don't deny that at all. They can always access the GDK on their own or
>talk directly to the GTK if they wish. In this case though you are
>talking about creating NEW code using LCL. A large part of the recent
>discussion was based on using EXISTING Delphi code. This existing code
>is based on the premise that you can override things like the paint and
>draw for the parent component and draw it how you want. But API's like
>GTK don't work that way and that is what I am trying to point out.

To use a particularly ugly (IMO) example, a TAnimatedBitButton, a button
with an animated GIF or some sort of self rotating imagelist for the glyph.
 With no override of the paint/draw, and no way to attach a timer to it,
this could not be done with LCL (ie: modify the component code from VCL to
LCL), but would have to be done in GTK native, Win32 native, QT native,
etc. if it was to be used in a platform independent app.  Or, if you are
lucky, you can derive a new button type, in each API, that has the needed
attributes, and then the VCL code that you had could be modified to use
these button classes (actually, just one, from the App's point of view, the
rest being hidden by Interfaces).  In either case, it is unlikely to be the
application writer that does this.  If they do, they have shifted from
being just an application writer to a lazarus developer as well.  At least,
we can hope they share that effort with the rest of us!

>Code written brand new using Lazarus and the LCL can extend the base LCL
>features by linking directly to the GTK and GDK themselves if they so
>desire. But there will be alot of existing that Delphi code that will
>only be usuable AFTER it has been modified to meet the feature set of
>the LCL.

In some ways, this shows how despite its many limitations, it is a good
thing that the VCL keeps a handle to the WindProc, and that it can be
overriden so that ANY windows message in existence can be handled.  Since
GTK only implements messages that are specifice to the widget, and does not
allow you to override the lowest level to add your own, it will make it
very hard to do a lot of things common in Delphi (at the component writers
level).  

Jeff.






More information about the Lazarus mailing list