[Lazarus] nonlcl design basic issue

[Mattias Gaertner]

On Mon, 16 Jun 2014 00:59:12 +0200
Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:

>[...]
> Thanks a lot. That's more or less what I was aware of, and having it 
> confirmed by your authority makes me more confident, but I was secretly 
> hoping that you'd pull out of your hat a third way, with just pro's and 
> no con's :-( .

Well, depending on your design you can make the cons small.
And eventually the IDE gets new tools to help with the cons.

Third way:
Implement your mediator widgetset independently of your widgetset,
sharing only some base types and functions.
Pro: No switching, less searching.
Con: Duplicating getters/setters and basic logic.

 
>[...]
> So I think I'll go the first way, which should affect only design time, 
> but shouldn't change my run-time widgets.
> 
> One more thing: with a design-time-only package including the Designer, 
> and a run-time-only package not including it, will I avoid to pull into 
> my executables the IDE Designer stuff, and all the LCL-related stuff? 

Yes. Your project only pulls in stuff if you use the stuff in the uses
clauses.
A dependency in the project inspector only pulls settings and search
paths.

> Any hint to avoid pitfalls?

Many Kylix classes have the same name as the LCL ones. All streamable
classes must have unique names and you can not disable the LCL.
You have to change the classnames or the IDE component palette and
reader must be extended.

Mattias