Starting at "the top", class CcPartEditor implements the shell window for the Part Editor. CcPartEditor is a subclass of abstract class CcEditorShell. CcEditorShell provides state and services common to CcPartEditor and CcGeometryEditor (The primary difference between the Part and Geometry editors is the types of tools that each provides).
CcEditorShell holds the parent node of model being edited in instance variable "targetParent". Any shapes that are added to the scene are added as children of the targetParent (See Figure 16). The descendents of the targetParent are considered to be "the 3D model" and these are the objects in the scene graph that actually get written to disk when work is saved.
Figure 16. The scene graph and target 3D model for CcEditorShell
Key Collaborations
(Note: Additional information about the classes described here can be found in class comments).
CcEditorShell provides a single perspective view of the model being edited (See Figure 3). The perspective view is created from the default view resource of class CcEditor. Within the #createComponents method of CcEditorShell, an instance of CcEditor subclass CcPerspectiveEditor is created and associated with this view. The CcPerspectiveEditor instance is held in the editor shell’s "mainEditor" instance variable.
CcEditor provides the bulk of the modeling behavior for CcEditorShell. It uses a CcOpenglPresenter/CcOpenglView pair along with an instance of CcRenderManager to render the scene graph. A second render manager is also created to highlight selected objects (See CcEditor>>initialize).
CcEditor manages a collection of CcTool subinstances that allows the user to manipulate the model in various ways. Only one tool is active at a time. The editor delegates most of the work involved in tool activation and tool-view interaction to an instance of CcToolManager (held in ivar "toolMgr"). The tool manager is a central figure in the modeler framework (See Figure 17).
Figure 17. CcToolManager and collaborating objects
A CcToolManager is associated with a single instance of CcOpenglPresenter. The tool
manager uses an instance of CcMouseManager to coordinate the routing of mouse events,
generated by the presenter/view pair, to the currently active tool. A CcStateManager is
used to maintain a history of the model’s state so that changes can be undone and
redone. An instance of CcSelectionManager maintains the list of scene graph nodes and
components that are currently selected.
To perform work, the tools themselves need certain pieces of information held by the tool manager such as the current set of selected objects and information about the CcOpenglPresenter from which events originate. Thus, a tool maintains a reference to its tool manager.
Tool Types
Abstract class CcTool has two abstract subclasses: CcInteractiveTool and CcOneShotTool. CcInteractiveTool provides behavior for manipulating target objects based on input from either the mouse or from forms-based data entry. CcOneShotTool is intended for tools that can execute based on a single set of input parameters (e.g., collapse a face into a point). One shot tools do not accept input events from the mouse.
Tool-View interaction
When the user selects a tool from the Part Editor menu, the tool is set as the "current tool" within the tool manager of the main editor. When an interactive tool is made current (or "activated"), it registers itself with the mouse manager in order to receive notification of mouse events.
An interactive tool receives three distinct messages from the mouse manager corresponding to events "mouse button pressed", "mouse moved with button pressed" and "mouse button released". This sequence, starting with the pressing of the left mouse button and ending with its release, is referred to as an "input session".
When the left mouse button is pressed, the tool receives the message #leftButtonPressedOn:event:. The first message argument is a CcComponentSelectionSet which contains the collection of qualified components (CcQualifiedComponent) that the mouse pointer was over when the left button went down. This information gives the tool the opportunity to either prepare itself for further input (e.g., mouse movement) or to reject the input session outright if the objects contained in the selection set aren’t appropriate for the type of work the tool performs. If the session is rejected (by the method answering false), no further messages will be sent to the tool by the mouse manager.
As an example, subinstances of CcAxisTool are designed to work with the Part Editor’s axis handle (the orthogonal red/green/blue arrows in Figure 3). Axis tools should only accept input from the mouse if the mouse button was pressed while over one of axis handle arrows. Therefore, one of the things that a CcAxisTool does as part of the #leftButtonPressedOn:event: is to ensure that one of the axis handle arrows is included in the selection set (See CcAxisTool>>canAcceptMouseInput:event).
In response to a "mouse moved with button pressed" event, the mouse manager sends the current tool the message #leftButtonPressedMoved: (this message is only sent if the tool had previously accepted the input session by answering true from #leftButtonPressedOn:event:). The argument in this case is a mouse event. This is normally where the tool will actually manipulate the target object (usually determined from the list of selected components in the selection manager). The manipulation is typically some function of the offset between the current mouse location and the location where the "mouse button down" event occurred.
Finally, in response to the "mouse button released" event, the mouse manager sends the tool a #leftButtonReleasedOver:event: message. Like the #leftButtonPressedOver:event: message, the arguments here are a selection set containing the qualified components under the mouse pointer when the button was released and the mouse event. The tool performs any necessary post-manipulation processing and answers true if it accepts the event. In the case of CcInteractiveTool, true is answered only if the target object was actually changed during the input session. For example, the target may not have changed if there was little or no movement of the mouse between the "button pressed" event and the "button released" event.
Another point worth mentioning is the default behavior that occurs if the current tool decides not to accept the input session. Instead of simply discarding the input session, the mouse manager may have been configured with a default action (a block) that is evaluated if the current tool doesn’t process the session. In the case of the tool manager, the mouse manager is initialized with a default action that attempts to select or deselect the object under the mouse pointer (see CcToolManager>>initialize). This makes it possible for objects to be selected with the mouse regardless of the tool that is currently active.
Saving State
To allow operations to be undone and redone within the editor, tools make use of CcMememto instances and the tool manager’s state manager to save the state of the object being manipulated. Copies of the target object(s) state are saved just before manipulation starts and just after the manipulation completes (see methods #saveInitialState and #saveFinalState on class CcTool).