InitNode is an abstract class which is meant to be inherited
by all the initialization nodes (such as CameraInit), included
those that might be created by the user.
InitNode contains methods that can be reimplemented by the
children classes if necessary.
This abstract class allows to keep on using scripts such as
meshroom_batch without having to modify them specifically or
being limited to using a CameraInit node.
Duplicates used to be stored in a dictionary with an entry being
"parent node": "duplicated node". On occasions where a single
parent node was duplicated more than once, the latest duplicated
node erased the previous one(s), and these older ones were
"lost": after being created, there was no trace left of their
existence in the duplication operation. Undoing that duplication
operation was thus leaving these duplicated nodes out and not
removing them.
Duplicated nodes are now stored as "parent node": [list of
duplicated nodes] to keep track of all the created nodes,
effectively removing them upon an "undo".
When a project file is opened as such, its filepath is stored
and all its features are retrieved as a consequence. Templates
were hard-coded instead of opened as files, so there never was
any need to load their features.
Now that .mg files can be opened both as projects and pipelines,
we need to retrieve the features in both cases, whether the filepath
is stored (file opened as project) or not (file opened as template).
This can be useful to retrieve the layout contained in the .mg file
for the pipeline, for example.
Adding new properties and updating the call to previous ones.
Properties are now :
* label : getLabel
* fullLabel : getFullLabel
* fullLabelToNode : getFullLabelToNode
* fullLabelToGraph : getFullLabelToGraph
Same for the name.
Graph.markNodesDirty() is called in three different places:
- Attribute.requestGraphUpdate()
- Graph.addEdge()
- Graph.removeEdge()
However, addEdge() and removeEdge() are especially decorated to request a graph update so, with the old markNodesDirty() implementation, the update was done twice in a row.
We now call applyExpr before updateInternals is called (triggered by setupProjectFile and/or end of GraphModification).
So the input parameters expressions/connections are up-to-date (after applyExpr) when updateInternals will evaluate the input/output parameters.
Add possibilty to, while computing nodes:
add more nodes to the task manager,
edit, duplicate and remove nodes without breaking the tasks that are submitted