[lazarus] Setting callbacks

[Michael A. Hess]

Alexandre Grenier wrote:
> 
> I think all this is due to a lack of managagement and structure
> planning!

I don't think it is totally fair to say this. I will admit we might not
be using a complex plan but that is exactly what Megido tried to do and
it fell flat. Also, Lazarus has changed and flowed in it's design and
goals since it was started. In the beginning it was being coded strickly
for use with GTK. Then we looked at coding to use Glade. Then we decided
to make it completely API independent. Then we setup the messaging
scheme toward that end. Then we motified that to more closely parallel
how messaging is done in Win32 and Delphi. If you look at the code we
started with around 7 months ago and look at what is being done now it
is completely different. I personally think it is this lose managagement
and flexible structure which has allowed us to progress as far as we
have with this project.

> Instead of getting something (anything!) working, perhaps Marc's
> example should be followed, and it would be a very high priority
> to plan and complete the base classes first.

Well in fact for the most part the base classes have been written along
time ago. We have had the various dialogs available, most of the
standard controls, Lables, Buttons, Menus, Tabs, etc. The problem is
that as the final goal changes as in the case now where we have focused
on getting tools like mwedit to work with minimal changes, we need to go
back down into those base classes and rework that code that had
previously been working OK.

> Perhaps doing so in a way that will simplify using higher level
> inheriting classes as well as creating new ones, but while keeping
> extreme flexibility already offered by the OO design.
> 
> Perhaps developping the base classes in parallel with let's say a
> TButton, and once all is simplified and optimized for that, create
> something a bit more complex.. and adapt the base classes as well as
> TButton for the changes.. after a few components, the base classes
> should have the exact structure they need to accomodate the whole LCL.

I understand what you are saying but then I wonder if you have looked at
some or any of the base classes found in the LCL and the FCL on which we
are building our code. It is very tight and complex allowing for the
inheritence you mentioned. Had we stuck with the straight GTK model we
could have had working tools long ago. But by chosing the flexible model
and now building it so that it can more closely port Delphi code we just
need to go back into those base classes to change how messaging and
things like that are dealt with.

All I have been trying to say is that please don't be confused or think
that the LCL isn't being build on a good foundation, aka. base classes.
It is and has been and in fact very little has changed in the TControl,
TComponent, TObject classes for months. What has changed is the color
paint we have been deciding to paint the blocks making up the
foundation. Very soon the mwedit tool will be able to be used as an IDE
base which will allow us to work even better on building the Forms
Editor tool.

OK. I'll get off my soapbox now.  :-)

-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com