NAME

       NodeKit Classes -

   Classes
       class SoAppearanceKit
           The SoAppearanceKit class is a node kit catalog that collects miscellaneous appearance node types.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoBaseKit
       The SoBaseKit class is the toplevel superclass for nodekits.

       Node kits are collections of nodes and other node kits (from here on node kits which are part of some
       other node kit, will only be referred to as nodes or parts, see catalogs and parts), organized in a way
       that is convenient for its use. A node kit inherits SoNode and can thus be inserted into a scenegraph as
       any other node. "
   class SoCameraKit
       The SoCameraKit class is a node kit with a transform and a camera.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoInteractionKit
       The SoInteractionKit class is a base class for draggers.

       This nodekit class makes it possible to set surrogate paths for parts. Instead of creating new geometry
       for the dragger, it is possible to specify an existing path in your scene to be used for interaction. All
       picks on this path will be handled by the dragger. "
   class SoLightKit
       The SoLightKit class provides a kit with a transform, a light and a shape or subgraph.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoNodekitCatalog
       The SoNodekitCatalog class is a container for nodekit layouts.

       Nodekits store all their hierarchical layout information and part information in instances of this class.
       "
   class SoNodeKit
       The SoNodeKit class is used to initialize the nodekit classes.

       The sole function of SoNodeKit is to be just a placeholder for the toplevel initialization code for all
       nodekit-related classes. "
   class SoNodeKitListPart
       The SoNodeKitListPart class is a container node.

       This node is basically just a container node with these differences versus the other group nodes: "
   class SoNodeKitPath
       The SoNodeKitPath class is a path that contains only nodekit nodes.

       All other nodes are hidden from the user. "
   class SoSceneKit
       The SoSceneKit class collects node kits needed to set up a scene: camera, light and shapes.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoSeparatorKit
       The SoSeparatorKit class provides a typical set of nodes to influence a shape subgraph.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoShapeKit
       The SoShapeKit class provides templates to insert what is usually needed for shape nodes.

       Node kit structure (new entries versus parent class marked with arrow prefix): "
   class SoWrapperKit
       The SoWrapperKit class is a simple kit for wrapping a transform and a sub-graph.

Detailed Description

       Wrapping ones head around when, how, and why to create nodekits can be difficult in the beginning. When
       do you write a nodekit, and when do you write a custom node? It is easy to think in those terms in the
       beginning, but it is often not an either/or situation.

       The concept of nodekits is to modularize useful, potentially repeated sub-structures you have in your
       scene graph as it approaches some level of complexity. They are especially useful if you might need to
       rearrange the structure of the sub-structure in the future, which you probably will.

       On file, a nodekit is like a macro for the scene graph. The nodekit will not expose its internal
       structure, but when read in it will create the node structure internally. The node structure can even
       have optional parts that are only expanded if necessary.

       A nodekit will give you access to its 'slots' in the internal structure through its fields. Only those
       fields should be the user interface for the nodekit, the rest of the substructure should be completely
       automatic, derived from those slot fields.

       To return to the question on whether to implement a custom node or a nodekit, the answer is to think of
       what exactly is really custom about what you need to implement, and trim that down to the atomic level
       (but please stop trimming before you trim away all meaning). If there is nothing really custom in what
       you want to implement, then it is likely that implementing it as a nodekit is what you ought to do.
       However, if you do have to do somethingcustom that Coin doesn't support, then implement that part as a
       custom node, and then, if it seems worthwhile, implement the nodekit you need to bundle up this custom
       part with an auxiliary support structure to achieve what you set out to achieve.

       For VRML97, you have something called PROTOs, which is something similar to nodekits, except they are not
       very accessible from C++, as opposed to nodekits.

Author

       Generated automatically by Doxygen for Coin from the source code.

Version 4.0.0a                                   Wed Feb 26 2014                              NodeKit Classes(3)