A list of properties that should be persisted when the app closes, and restored the next time it's launched.
A list of properties that should be persisted when the app closes, and restored the next time it's launched. A common example of a persistent is the zoom/magnification level of the viewer. Be sure to add any relevenant properties to this list in your Viewer subclasses!
Returns the XML representation of this viewer's properties, suitable for saving into a file.
Returns the XML representation of this viewer's properties, suitable for saving into a file.
Reset the visualization.
Reset the visualization. An optional operation; subclasses must override this method or else it does nothing.
The (Cog4) fields this viewer is visualizing.
Zoom in/out step size
Zoom in/out step size
Updates the visualization based on the contents of data
.
Updates the visualization based on the contents of data
.
Updates the visualization based on the contents of data
.
The src
argument was orignally meant to reference the
kernel/field/object that generated the data, in order to support
composite visualizations (that is, viewers that produce a visual based on
the data from several different sources), but launching such viewers in
the current UI is clunky at beset, so this feature isn't used. Viewers
that only visualize a single field's data can probably safely ignore this
arument (and indeed, most of the current ones do).
The field or object that generated the data
argument
New field data that needs to be rendered by this viewer
Parses the XML tag produced by the propertiesTag
method and restores
any saved valued to this Viewer.
Parses the XML tag produced by the propertiesTag
method and restores
any saved valued to this Viewer.
An experiment to see if I can't set up a visualization that combines the data from two fields into a single visualization.
The idea stems from Matthew + Ben's tracker app, where they had to render a circular target on top of a webcam feed. Originally, that required a lot of hacking and pixel twiddling; but with the right probe framework, it should be simple to define a viewer that does the same sort of thing, e.g. by interpreting the contents of fieldA as an image and the contents of fieldB as the coordinates of a target that needs to be overlaid on top.
---
Sudden realization - how do we actually build one of these in response to user input? They can only click on one field at a time...