Go to:
Attributes.
For an architectural overview of edits, see documentation in
editsDocumentation.txt, in the DataModel/Edits directory.
Concrete TeditsOwner that provides persistency of edits for a partition.
The purpose of the TdnEditsManager is to provide persistency of edits
through its dataEdits attribute, and provide a node for edit
application, being derived from TeditsOwner. There will be zero or one
TdnEditsManager node per partition. It cannot be a default node, as it
is not a singleton.
Outside of activation, only the top-level edits manager node is
writable. All nested edits managers are read-only. However, during
activation, we must allow the addition of edits to both top-level and
nested edits managers via the API so that plugins that choose not to use
Maya FileIO can still insert edits that are persisted in their own
format.
The per-partition edit manager node is lazily-created. This creation
can be triggered by:
1) The scene assembly addEdits API.
2) Maya file I/O (reading in .ma and .mb files).
3) Interactive creation of an edit in a scene. In this case, the edit
manager node is created in the root partition.
Note that the presence of a TdnEditsManager node in a partition does not
imply that its list of owned edits is non-empty: even though the edits
manager node is created on addition of an edit, this edit can be removed
through a TeditIterator. Therefore, a non-empty edits list cannot be a
TdnEditsManager invariant, and the presence of a TdnEditsManager is not
a valid test for the presence of edits.
It is the intention that TdnEditsManager be the only concrete
implementation of TeditsOwner. Its design is intended to support file
referencing edits, in the eventuality of migrating file referencing to
use TeditsOwner.
Node name | Parents | MFn type | Compatible function sets |
---|
editsManager | node
| kEditsManager | kBase kNamedObject kDependencyNode kEditsManager |
Attributes (1)
edits
Long name (short name) | Type | Default | Flags |
---|
|
edits
(edt )
| scene edits | nullptr |     |
|