Q100397: Glossary of UI-related terms in Katana
This article gives definitions of the most important terms related to Katana's UI and the underlying mechanisms powering it.
Please also see the following articles for definitions of further terms:
Q100325: Katana Core Terms
Q100388: Glossary of rendering-related terms in Katana
Value Policies: In general, Value Policies in Katana provide data for display in widgets in Katana's UI. Value policies provide a layer in between underlying data sources, such as parameters of nodes in the node graph document, and UI widgets in tabs like the Parameters tab. There are different types of value policies, tailored to specific data sources and specific use cases.
The Python base class for value policies is QT4FormWidgets.AbstractValuePolicy. Value policies take care of translating from events in the underlying data sources to Qt widget events, for example to repaint widgets after a parameter's value has been changed using a NodegraphAPI call.
Parameter Policies: Parameter Policies in Katana are value policies that provide a layer in between parameters of nodes in the node graph document and widgets in the Parameters tab. Those widgets show values of parameters, and can be used to edit those parameter values. Parameter policies are most relevant when developing parameter UIs for custom types of nodes, for example SuperTools, using Python scripting APIs. For examples how this can be used in SuperTools, please see the respective Editor.py files of the example SuperTools shipping with Katana under
The Python base class for parameter policies is UI4.FormMaster.BaseParameterPolicy. It is derived from the AbstractValuePolicy class. A parameter policy is typically created for a specific parameter of a specific node by passing a NodegraphAPI.Parameter instance that represents the respective parameter to the UI4.FormMaster.CreateParameterPolicy() function. This returns an instance of a class that is derived from the BaseParameterPolicy class.
Attribute Policies: Attribute Policies in Katana provide a layer in between attributes of locations in the scene graph and widgets in the Attributes tab that show values of those attributes.
Attribute policies are created internally by Katana to provide attribute data for display in the Attributes tab when locations in the Scene Graph tab are selected. There's rarely a need to create attribute policies manually.
The Python base class for Geolib3-based attribute policies is UI4.FormMaster.FnAttributePolicy.AttributePolicy. It is derived from the AbstractValuePolicy class.
GenericAssignParameterPolicy: GenericAssign Parameter Policies (GAPP) in Katana are parameter policies that provide a layer in between GenericAssign-powered parameters of nodes in the node graph document and widgets in the Parameters tab. They can be seen as a hybrid between parameter policies and attribute policies:
GenericAssign aspect: GAPPs receive the results of cooking the scene graph that is produced by nodes upstream of the respective GenericAssign-powered node by way of a built-in Geolib3 Client that receives events from the Geolib3 Runtime. This is similar to how attribute policies provide data from attributes of scene graph locations for display in the Attributes tab.
Parameter policy aspect: GAPPs provide cooked attribute data for use in parameter widgets in the Parameters tab. This is similar to how parameter policies provide data from parameters of nodes for display in the Parameters tab.
Freezing and Thawing: Freezing means that Katana-specific events that are normally processed when underlying data changes are temporarily ignored. It applies to value policies, and to tabs in Katana application windows. This ensures that they're not needlessly updated when changes are made to the node graph document or when scene graph location data is cooked, for example in the case that widgets or tabs are not actually visible to the user.
Thawing of value policies or tabs is the reverse of freezing: after the processing of Katana-specific events has temporarily been suspended, or has never been started before, thawing means that processing of such events and updating UI components as a result is resumed or started.
Freezing and thawing is implemented by registering and unregistering handlers for specific Katana event types, depending on whether the respective value policies or tabs are frozen.
Typically, when the user switches from one tab to the next in a pane inside of a Katana window, the previously visible tab is frozen, and the newly visible tab is thawed. Thus, no widgets in the now hidden tab are updated in response to Katana events, but widgets in the newly visible tab are.
When working with parameter policies in the context of parameter UIs for custom types of nodes, for example SuperTools, it is important to note that Python callback functions need to be added to such a value policy in order to be notified when the underlying value of the policy changes. If no such callbacks are added to a value policy, the value policy is considered frozen. For more information, please see the descriptions of GenericAssign, GenericAssignParameterPolicy, and Lazy Evaluation (in the Katana Core Terms Glossary).
ScenegraphManager: The ScenegraphManager Python module is part of the Nodes3DAPI Python package. It maintains a single instance of a Scenegraph class that is responsible for tracking a number of Working Sets that maintain the open, closed, selection, and pinning states of locations in Katana's scene graph. The Scenegraph instance can be retrieved by calling ScenegraphManager.getActiveScenegraph(). The instance can then be used, for example, to access the list of paths of scene graph locations that are currently selected:
sg = ScenegraphManager.getActiveScenegraph() print(sg.getSelectedLocations())
The Scenegraph class also maintains a history of selected scene graph locations (via an internal SelectionHistory class), for the purpose of allowing users to step through the history via the History Forward and History Backward commands in the Viewer tab.
We're sorry to hear that!Please tell us why.