[lazarus] LCL circles

[Mattias Gaertner]

On Thu, 24 Oct 2002 16:07:24 -0400
"Andrew Johnson" <aj_genius at hotmail.com> wrote:

> On Thu, 24 Oct 2002 12:52:25 +0200
> "Mattias Gaertner" <nc-gaertnma at netcologne.de> wrote :
> >
> >Hi all,
> >
> >After successfully breaking a circle in the LCL, I checked some other
> >circles.
> >There were five, that were very easy to break without loosing any
> >compatibility.
> >
> >These are at least three other, which have to be checked:
> >
> >stdctrls.pp <-> forms.pp
> >
> >interfacebase.pp <-> Dialogs, Forms, StdCtrls, ExtCtrls, Graphics,
> >Buttons
> 
> Okay.. The Dialogs is pointless. it serves no purpose as far as I can
> tell, Stdctrls is used by the generic drawtext I wrote because of 
> DeleteAmpersands, this can be fixed by moving DeleteAmpersands to the 
> generic interfaces code. Everythings else is pretty much all my fault.
> And I do not know how to fix it yet.
> 
> Basically the rest is used by my generic PromptUser & RequestInput
> forms. To make Message Dialogs Interface Dependent,  I copied the code
> from message dialogs into these routines so they could be overriden by
> interfaces, as I have started with GNOME, and planned on doing with
> Win32. But for the generic routines, I couldn't figure out how else to
> do them since the lower level functions I would have used on Win32
> aren't available, so I have to use the LCL components directly just as
> in Dialogs, which of course create the loops. If you can figure out
> how to fix this please tell me! Its been bugging me since I did it,
> but I couldn't see any way around it, and still don't.

PromptUser and RequestInput are our own creations and have no
counterpart in the VCL. So, we can do what we want. Both functions now
simply call handlers instead of doing everything on their own.
And because both shows dialogs, I moved the code to dialogs.pp. Andrew I
renamed your TMessageBox from interfacebase to TPromptDialog. Can we
join TMessageBox and TPromptDialog?

I also broke the stdctrls.pp <-> forms.pp circle by implementing it the
same as the VCL do it: ugly. But it is fully compatible now.

Then I broke some minor circles, also fully compatible and moved
DeleteAmpersands to the new lclproc.pas. I also accelerated this
function and hope it does the same as before.

The only circles left are:

actnlist <-> forms   
actnlist <-> menus   
controls<->forms
the trick circle Interfaces.pp <-> LCL

Any volunteers for actnlist?

The controls<->forms circle can be broken (fully VCL compatible). But it
would reduce readability, so I think we should keep it.

The trick circle Interfaces.pp <-> LCL:
I guess, only the developers know about this one and its purpose, so
here is the story:

The LCL is the basic component set. The widget interfaces (gtk, gnome,
win32) lie above the LCL and use directly the LCL units. And the LCL
communicates to the interfaces via the abstract TInterfaceBase object.
This object is created in interfaces.pp. When compiling the LCL the
interfaces.pp of the abstract directory is used.
When compiling one of the real interfaces (e.g. gtk) the abstract
interfaces.ppu in the lcl/units directory is deleted and a gtk-specific
interfaces.ppu is created in lcl/units/gtk.
When you compile an LCL application the compiler finds 'forms' in the
uses section and loads lcl/units/forms.ppu, which uses 'interfaces'. But
this time the compiler uses the interface specific
lcl/units/gtk/interfaces.ppu, which would normally be impossible,
because this is a forbidden pascal unit circle:  forms -> interfaces ->
gtkint -> forms

The advantage of this trick is:
- In the program source (.lpr) you don't need to add 'interfaces'.

The disadvantages of this trick are:
- The interfaces.pp must be compiled several times to make sure, 
  that the compiler syncs all units. This is the reason, why you
  can't add lcl and lcl/interfaces/gtk to the unitpath.
- The compilation is somewhat tricky and so the Makefiles are
  more complicated. 
- Forcing the compiler to create a forbidden pascal circle is IMHO
  a bad example for coding.

I hope this was not too negative. I don't want to offend someone,
because of coding style. This is open source, so everyone can write if
he/she thinks that something can be done better.


Mattias