[nebulastudio-discuss] XML descriptions of Nebula classes to
provide better wrappers and editor integration
bruce at cubik.org
Tue May 4 08:08:20 PDT 2004
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
* 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
* 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.
More information about the nebulastudio-discuss