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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
