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

Giuliano Colla giuliano.colla at fastwebnet.it
Sun Jun 22 12:13:02 CEST 2014


Il 21/06/2014 17:18, Mattias Gaertner ha scritto:

> [..]

> There are at least two possible solutions:
>
> 1. The quick and dirty solution:
> You use the LCL forms and controls. The IDE is extended with some
> hooks, so you can redirect from the LCL to your units.
> Pro: Less work, you get some basic results quickly.
> Con: The RTTI is wrong. The Object Inspector cannot show your
> own properties. The property editors will show LCL values (e.g. TColor
> will show the list of LCL color constants). Icon and bitmap data are
> read/written in LCL format, which may be unreadable by your units. etc.
I'm not too much interested in a quick and dirty solution, unless it can 
be a first step, just to gain a better understanding of all the 
internals wizardries.
> 2. The clean solution:
> You write your own mediator component classes. For example a
> TButton, TForm, TPanel, TListBox, etc.
> Con: the IDE needs to be extended to handle multiple component classes
> with the same name (only one is active at a time, based on the project). You have to write painting code for the mediator TButton, TPanel,
> TListBox, etc.
> Pro: the RTTI is correct and so the Form/Source relation works, the
> Object Inspector shows all your properties and only your properties and
> you have full control. You can write good property and component
> editors.
>
That's the way I'd like to go. A more general support of non-LCL 
widgetsets would be a not only a good long term solution for my project, 
which in my ambitions would be not just to support Kylix legacy but to 
rewrite step by step all widgets thus getting free of license issues. 
More important, it could be useful to the Lazarus project as a whole. It 
could be used to revive the pretty much dead CustomDrawn project, it 
could provide a better way to support FPGui, etc. It's quite likely that 
in any widgetset one can conceive, a form will have a TForm class, a 
button a TButton class, etc.

My problem, right now is: where do I start from? Which units should I 
start looking at?

Currently, if I understand properly, everything is set up in main.pp. 
Then, when loading a project, palette visual components without an 
editor hook are only hidden, but nothing is removed from 
LazarusResources. It's unclear to me to what extent LCL related 
resources should be kept there when handling non-lcl widgets.
In principle I see many possibilities:
1) Splitting LazarusResources in more pieces: GlobalLazarusResources 
(from non widgetset related packages),  LCLLazarusResources 
(IDE-required, if any) and WSLazarusResources (specific Widgetset 
resources).
2) Adding and removing entries from LazarusResources as a function of 
each individual project package dependency.
3) Adding an extra entry to each resource, to specify to which category 
it belongs (Global, LCL, nln-LCL).
But without a better knowledge of what is using what it's impossible to 
make a choice.

Thank for any suggestion.

Giuliano





More information about the Lazarus mailing list