[nebulastudio-discuss] XML descriptions of Nebula classes to
provide better wrappers and editor integration
vadim at steelronin.com
Wed May 5 02:41:00 PDT 2004
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
> * 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
More information about the nebulastudio-discuss