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

[Bruce Mitchener]

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.
    * 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.

What else might we want to see?

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?
    * Should we move docs out of the _cmds.cc files in favor of putting
      it here and letting autodoc.py use this information?

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