[nebulastudio-discuss] XML descriptions of Nebula classes to provide better wrappers and editor integration

[Vadim Macagon]

Bruce Mitchener wrote:
> Hello everyone,
> 
> Currently, nwrapper looks at the data present in nClass and nCmdProto to 
> generate wrappers.  This gives it access to:
> 
>    * class names
>    * class hierarchy information
>    * script method names, currently all lowercase.

Except for nOpende :)

>    * script method arg information:
>       * basic type of each arg, but without semantic information
>         (so, vector4, not 'color')
> 
> And that's really about it.
> 
> We could use having a much richer data representation for generating 
> richer and higher quality bindings, especially if we go further and want 
> the bindings to contain documentation to fit into their environment, etc.
> 
> A rough shot at the information that I'd like to see:
> 
>    * Class names
>    * Class hierarchy information
>    * Class documentation, from script docs rather than the
>      C++ docs.
>    * Which package/target the class is in (kernel, scene, nmap, etc)
>    * Script methods of the object:
>       * Script method names with Nebula-style proper capitalization so
>         that a wrapper can modify capitalization to match the target
>         language.
>       * Script method documentation
>       * Script method arg information:
>          * Basic type of each arg (as before)
>          * Name of each arg
>          * Semantic type of arg (color, etc.).
>    * Properties of the object:
>       * Name of the property
>       * Documentation on the property
>       * Name of the getter/setter methods (and therefore if it is
>         read-only (no setter)).
>       * Basic type of the property (int, float, vector4, etc)
>       * Semantic type of the property (color, etc). These would be
>         used by NebulaStudio to determine which potential editors
>         to use on the value.

Well didn't pay much attention, time is scarce atm, but I probably agree 
with the above.

> What else might we want to see?

I'll give it some thought later :)

> Is there a good XML format that already exists for encoding this sort of 
> information about an object system that we can/should use?
> 
> This ends up bringing up a couple of other questions:
> 
>    * Should we eventually use this information to generate the _cmds.cc
>      files rather than have duplicated data?

Yes. I've thought about using XML for the next generation of a class 
builder. The problem is since the XML is an intermidiate format where do 
we store the C++ code that actually implements the script commands? 
Generating empty shells isn't going to be good enough since that's what 
the existing class builder does and when you want to add a new script 
command later on it's the same old copy pasting again. Could the C++ 
code be stored in the XML?

>    * Should we move docs out of the _cmds.cc files in favor of putting
>      it here and letting autodoc.py use this information?

Err, well if we start using XML could store the docs anywhere... 
actually the same stuff as I said about for the C++ code applies to the docs

> We'll also need to determine how we want to make this information 
> available to Nebula Studio.  I suspect that it would be just fine for it 
> to load the XML files and maintain its own representations rather than 
> requiring that a wrapper make it all available at runtime (with the 
> subsequent costs and overheads).
> 
> This will probably also provide the encouragement that we appear to need 
> to merge the tinyxml library into CVS as Radon Labs has done.
> 
>  - Bruce