[Lazarus] nonlcl basic issue: is codetools LCL dependent?

[Marco van de Voort]

On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:
> >> This is not compatible with other implementations, such as Kylix and
> >> fgGui, just to mention two.
> > It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?
> 
> You're right, in Kylix CLX Qt is hardcoded. Therefore it's different 
> from LCL scheme virtual/abstract - interface.

It's the same in the fact that you can't reappropiate the designer to non
built-in  <x>CL(X) libraries.

You can only use the designer with the built-in library, at best with a
different backend wacked under it.

But it is clear, this is about customized designer support. The "widget"
stuff talk put me of course (I actually realised a bit later)

> This makes it impossible to use the features of IDE Designer as it is 
> for a Kylix project.

True, but the incompatible threw me off, and the perspective on what
incompatible with Kylix means.

I never considered loading unmodified CLX projects a Lazarus designgoal.
More so because the last Kylix is already a decade old.

OTOH I have nothing against it. (I'm a bit careful with dragging fpgui in
it, since contrary to CLX, its persistence mechanisms and principles might
be different)

> If, with some kludges, you manage to use the IDE designer as it is, for 
> a Kylix project, it will only be aware of LCL methods and properties, 
> and you'll end up both with Kylix unsupported methods and properties, 
> and with Kylix required methods and properties dropped because 
> unsupported by LCL.

True.
 
> This sums up in being incompatible.

That is IMHO an unfortunate choice of words. It is not a general purpose
designer. It is not incompatible because it never strove to be. 

Anyway, all is clear now. At least it made me realize you meant reusing the
current designer for CLX and not add a different one. That might indeed be
doable since CLX inherits many of VCL/LCL's traits.