GraphViewer
Related Docs:
object GraphViewer
| package structure
The compute graph being debugged.
Implements the toolbar for cogdebugger.ui.structure.GraphViewer.
Implements the toolbar for cogdebugger.ui.structure.GraphViewer. Includes buttons for chossing between a horizontal or vertical layout, and for switching between the simple graph view or the Drill-Down view.
Take action in response to the user clicking something in our displayed graph.
Take action in response to the user clicking something in our displayed graph.
The object associated with the clicked graph element (a vertex or edge)
True if the user left-clicked the graph, false otherwise
Re-execute the layout algorithm on the currently displayed graph view.
Re-execute the layout algorithm on the currently displayed graph view. This method has no effect if the graph's current layout engine is not an com.mxgraph.layout.hierarchical.mxHierarchicalLayout.
Presents a graphical representation of the structure of a Cog ComputeGraph, i.e. a display of its fields and their inputs and outputs.
Each (probed) field in the compute graph is represented as a single vertex in a directed graph. Each field is then connected to its inputs and outputs via directed edges. Forward edges in the graph are rendered in one color, while recurrence or "backward" edges are rendered in another.
Clicking a field vertex or edge raises an cogdebugger.ui.structure.InteractiveGraphEvent that other debugger components (such as cogdebugger.ui.Desktop) may react to.
The graph viewer operates in one of two modes: the default simple mode simply shows everything at once - each vertex represents a (probed) field, every input/ouput it has is represented by an incoming/outgoing edge. The second mode, referred to as the Drill-Down view, tries to compact the visual presentation by taking advantage of any module structure defined in the input Compute Graph.
The module hierarchy of a cmpute graph is implied from the organization of its fields and other classes. Essentially, each class instance that contains fields is considered a module, including the top-level compute graph instance itself (for many of the short example apps, this top-level module is the only module). The name of a module is not based on the class name, but rather the val/var name to which it is first bound. Consider the following pseudo-code:
The above code defines a ScalarField
aFieldwithin a ModuleA instancemodA, which is itself within a ComputeGraph instance. Keep in mind that modules and fieldsa are named after the val/var to which they are bound. The long name of a field includes its path in the app's module structure. The full name of the singular field in the above compute graph is 'modA.aField'.In the Drill-Down view, only a single module is "in focus" at a time. The children of that module (fields and other modules) are displayed as well as inputs and outputs to the module. Clicking a field raises an event as in the simple graph viewer, but clicking a module makes that module the new focus and redraws the display. A toolbar at the top of the display allows for focusing the parent of the current module or jumping back to the top level.