Node kits are nodes that organize their children into a particular structure. This structure is defined by parts in a catalog. To define a new node-kit class, the main task is to create a catalog for the class (in addition to the standard tasks for deriving a “regular” node). Once a catalog is established, the rest of the functionality, such as setPart(), getPart(), and createPathToPart(), is provided by the base class for all node kits, SoBaseKit( C++ | Java | .NET ).
SoBaseKit( C++ | Java | .NET ) is a direct descendant of SoNode( C++ | Java | .NET ). Therefore, when creating new node kits, you follow the standard procedure for creating and using new classes of nodes, except that you use the node-kit macros in the file SoSubKit.h. (Since you have to derive from at least SoBaseKit( C++ | Java | .NET ), you never need to include this file directly.) The SO_KIT_HEADER() macro declares type identifier and naming variables and methods that all node-kit classes must support. It also defines the private variable nodekitCatalog and a protected virtual method for retrieving it, getNodekitCatalog(). It defines the static method getClassNodekitCatalog() as well. The SO_KIT_SOURCE() macro defines the static variables and methods declared in the SO_KIT_HEADER() macro. Other macros useful in creating new node-kit classes are mentioned in the following sections.
Beyond this, most of the work for making a node kit focuses on creating the node-kit catalog. This catalog is a static variable and is therefore shared by all instances of the class. Whenever a user requests that a part should be added or retrieved (through getPart(), setPart(), and so on), the node-kit catalog is consulted. The node-kit catalog for any given class is created once when the first instance of that class is created.
Creating a new node kit requires these steps:
Select a name for the new node-kit class and determine what class it is derived from.
If the node kit has fields, define and name each field.
Design each part in the catalog. Use the SO_KIT_CATALOG_ENTRY_HEADER() macro to declare a name for the part in the header file (see Section 7.2, “Defining and Naming Catalog Entries”). The parts themselves are described in the constructor.
Define an initClass() method to initialize the type information (see Section 7.3, “Initializing the Node-Kit Class”).
Define an exitClass() method to clean up the type information. In the exitClass() routine of your class, use the macro SO__KIT_EXIT_CLASS.
Define a constructor (see Section 7.4, “Defining the Constructor”).
Implement actions, if necessary. Typically, you won't need to implement additional actions for a node kit. You may, however, want to redefine the setDefaultOnNonWritingFields() method (see Section 7.8, “Writing Information About Parts”).
Implement a copy() method if the node kit contains any non-field instance data (see Chapter 2).
Implement an affectsState() method if this method cannot be inherited from the parent class (see Chapter 2).