 |
-
New component TCastleTransformDesign allows to reference a
xxx.castle-transformfile inside a parent design. This way you can define a composition ofTCastleTransform(includingTCastleScene) inside anxxx.castle-transformfile, and reuse it multiple times.It is similar to the existing TCastleDesign for user interface.
-
New example examples/advanced_editor shows:
-
Instantiating multiple times UI design with
TSerializedComponent,TCastleDesign -
Instantiating multiple times transform design with
TSerializedComponent,TCastleTransformDesign -
Registering custom components (project-specific) to be available in editor
-
-
Finally, an important bug with using custom components in the editor on Unix was fixed.
Right now if custom component somehow link back to units that make use of CastleWindow, then the compiler will complain about CastleWindow unit not found when try to rebuild the editor. Is there a proper way to avoid it without having to rely on ifdefs?
Not really, I’m afraid (at least, not in a clean way).
In order to work within the editor, the component must work with TCastleControlBase (LCL way to put CGE on Lazarus form), as entire editor is based on LCL. And you cannot link to CastleWindow in LCL applications (the CastleWindow
Applicationtries to talk with window manager, which is incompatible with LCL trying to do the same).You could hack
tools/build-tool/data/custom_editor_template/castle_editor.lpito add there dependency oncastle_windowin<RequiredPackages>. It may then work (at least it will compile)… as long as what CastleWindow in initialization will not actually conflict with LCL, for which there’s no guarantee.So to be stable, I would say you have to
Avoid depending on
CastleWindow. Almost everything in the engine should be possible without referencing it. If you need a particular feature let me know, maybe I can add it (e.g. toTUIContainer, that largely “abstracts” the differences between TCastleWindowBase and TCastleControlBase).Or use ifdefs, as you mention.