[Lazarus] nonlcl design basic issue

[Giuliano Colla]

Il 15/06/2014 19:57, Mattias Gaertner ha scritto:
> On Sun, 15 Jun 2014 18:45:27 +0200
> Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>
>> [...]
>>   1. Surrounding with appropriate $IFDEF LCL / $ELSE the sources of my
>>      widgetsets to differentiate what should be visible at design time
>>      from what should be visible at run-time.
> Pro: code navigation is easier (e.g. jumping between
> active implementation and interface)
> Con: you can only work in one part at a time (many codetools will only
> work in the active IFDEFs). You have to switch often the active build
> mode.
>
>
>>   2. Going the same way as LCL, and taking advantage of an "interfaces"
>>      unit, which provides the actual implementation of virtual methods.
> Pro: You don't need build modes.
> Con: You often have to search the implementation of abstract base
> methods.
>
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 :-( .

FYI My widgets are a port to fpc of the Kylix widgetset, which I never 
contributed because of license issues, but which are already pretty much 
debugged. I can use Lazarus IDE to compile them, and to compile 
applications using them. What I miss is the ability of taking advantage 
of Lazarus IDE for visual design, because of many differences in properties.

My goal, now that I should have some time to spare, is to be able to 
take advantage of Lazarus IDE, to use it's gorgeous features, and to get 
rid of Delphi's, requiring a 2.4 Linux kernel, in order to support some 
one hundred or so applications written with Kylix. Playing with IDE 
designer shouldn't take as long as converting all of them to Lazarus, 
and, most of all, should be much more fun.

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? 
Any hint to avoid pitfalls?

Thanks again,

Giuliano