NodeBox 2 for NodeBox 1 users

This page is for NodeBox 1 users -- the faithful, die-hard early adopters. The ones that realize there's world beyond what Adobe is spoon-feeding you into the exciting realms of Processing, vvvv, Context Free Art, Scriptographer, NodeBox and others. The NodeBox team is proud to have you on board of what promises to be an exciting journey. We adore you and want to make the transition to a new way of working as painless as possible.

It's just Python

One thing to realize is that all NodeBox 1 code that doesn't call into NodeBox directly continues to work without change. All code that only uses standard Python libraries will have no problem being used in the new version.

NodeBox 2 uses a different implementation of Python, called Jython, that is identical to the default CPython implementation. Jython is a production-quality implementation supported by Sun Microsystems. It's current version is 2.5.1, the same version we use in NodeBox 1.

Thinking about objects

The main difference between the old and new approach is that you no longer issue direct drawing commands. Instead, NodeBox 2 scripts are more like a factory assembly line. At each stage of the line a node generates new output that is then processed, or filtered, by other nodes. Just as in an assembly line, objects flow in one direction - starting from one or more inputs towards one or more outputs.

Each node consumes and produces one type of data. The same data that goes into a node also comes out of that node. For most nodes this is not an issue: a "transform" node takes in geometry and returns a transformed copy of that same geometry. Nodes that do conversion from one type to another require a different approach -- they have a node reference field that links the input from a different type to themselves.

The kind of objects that flow through this system are "semi-fixed". That is, we have some ideas of what might travel through the system and provide support for those types of objects, but you're free to use your own. The types of objects traveling through the system don't need to be graphical: support for tables of data is planned.

The NodeBox Graphics Object Model provides an overview of what data can travel through the system. Most types seem familiar but some are new:

• Grob — The GRaphic OBject is the top level object. It is not the same as the top level object for a graphical scene (that's the Canvas), but is the highest level in the object hierarchy. It provides the minimum functionality an object must implement to be considered "graphical". It has operations such as "draw yourself", "inherit state from the graphics context", "return your bounding box" and "transform yourself".
• Canvas — The canvas contains all other objects and can be considered the top level container. Canvases contain images, text and geometry.
• Image — An image provides pixel data. Support for working with images and is very limited and nowhere near the level of support we had with Core Image.
• Text — Contains a piece of text together with typographic information: font, size, alignment, etc.
• Geometry — The top level object for all vector data. A geometry object is a group of paths. It cannot contain other Geometry, only path objects. Since a path can only have one color, geometry allows you to store vector data with many colors.
• Path — A path contains contours: the individual elements that make up a path, and that merge according to the winding rules. Paths have one fill/stroke color and stroke width, so every contour in a path has the same color.
• Contour — We're almost there! A contour contains the actual points, the data that make up the path. Contours can be open or closed.
• Point — A point represents the coordinates for a path segment. Points can have a type: it can represent a line (LINE_TO), a curve (CURVE_TO) or a handle on a curve (CURVE_DATA). For more information, see the documentation on the Point class.