The behaviour regarding `ListAttributes` was different depending on
whether an edge or a node was removed:
- if an edge was removed, the `ListAttribute` that was the destination
of that edge had its corresponding element completely removed;
- if a node was removed, the `ListAttribute` that was the destination
of one of the node's edges had its corresponding element reset, but not
removed.
With this behaviour, a user had different UIDs depending on whether
a single edge or the whole node had been removed where the UID should
always be identical.
Up until this commit, compatibility nodes (which necessarily had a version
or description issue) were ignored during the evaluation of UID conflicts,
as they had no UID.
This however created a bug, where already existing compatibility nodes
with inputs from nodes that triggered UID conflicts were losing their
input connections: when the node with the UID conflict was replaced with
a new compatibility node (with a UID conflict issue), the link was broken
and could not be resolved anymore as it lost any mention of the input
node's name. This was also valid for nodes without any compatibility issue
which had UID conflicted-nodes as their inputs.
Processing all the nodes in addition to those with a UID conflict issue
prevents this from happening: edges are correctly preserved.
This also fixes an issue that occurred when opening a project file that
contained nodes whose type was not recognized. Instead of raising an
"unknown node type" compatibility issue, "attribute is already connected"
errors were raised for the unrecognized nodes.
When loading the graph, once all the nodes have been created and the
links resolved, the computed nodes' UID can be compared with those
stored in the graph.
If a mismatch is detected, the node that presents the UID conflict is
removed from the graph and replaced with a CompatibilityNode, set with
`UidConflict`.
Nodes that come from templates are ignored as no UID is stored in
templates. Similarly, nodes that are already Compatibility nodes are left
out as they do not have a UID.
This commit adds an option to the "load" method, "publishOutputs", that
determines whether "Publish" nodes in a template project file should be
ignored during the graph's creation.
If "publishOutputs=True", then the "Publish" nodes from the template will
be added to the graph. "Publish" nodes in a project file that is not
a template will not be affected by this and will always be added to the
graph, as any other node.
This allows to have templates that are compatible with meshroom_batch,
which requires a "Publish" node when the --output option is specified,
while not having unneeded nodes in the UI or unneeded operations:
when --output is specified in meshroom_batch, "publishOutputs=True",
otherwise it will be set to False so that the "Publish" nodes are not
executed needlessly.
Non-default internal attributes need to be written in the templates,
but the "internalInputs" entry in the dictionary should not be written
at all if all the internal attributes are set to their default values.
Add two internal attributes, "Comment" and "Invalid comment", in
a specific "Notes" tab, which will contain any further internal
attribute. Internal attributes exist for all nodes.
- "pyCompatibility.basestring" are replaced by standard Python3 "str"
- "Sequence" and "Iterable" from "collections" are now directly imported
with "collections.abc"
When loading a new graph while the opened one was locally computing nodes,
computations were automatically stopped to be able to load the new graph.
However, the computing chunks' status were not being updated before
the graphs were switched up. This meant that opening that previously
computing graph again would lead to a display in which nodes appeared to
be computing although there was no ongoing computations.
For every node, the only information that is kept when saving a
template are the non-default input attributes' values as well as the
node's position.
The unit test checking the templates' nodes is updated to stop taking
outputs into account.
If several nodes are described in the clipboard and are supposed to
be connected with each other, reconnect them together, but do not
attempt to reconnect them to the graph they were copied from, even if
it is the current graph.
Add a specific option to save a graph as a template ("Save As
Template") in "minimal" mode.
This mode only saves, for each node in the graph, the input and
output attributes whose values differ from the default ones. Any
attribute that is not serialized in the saved template file is
assumed to have its default value.
If a conflict is detected on a node when opening the template
file, it is logged but solved automatically.
The goal of this minimal mode is to prevent template files from
needing an update every single time a modification (may it be
minor or major) is done on a node description. Templates can
thus follow node changes and still be usable.
Add an "Import Scene" (Ctrl+Shift+I) option in the File menu
that allows to select an existing .mg file and import it in the
current graph.
The imported scene will automatically be placed below the lowest
existing node along the Y axis.
When creating a node with a "paste" operation, place the node
on the mouse's position in the graph instead of default position (0,0).
If the mouse is placed on an existing node, the pasted node will be
placed on the mouse's position plus an offset so that the pasted node
does not directly overlap with the existing node.
Attempt to paste the clipboard's content in the graph when Ctrl+V is
pressed. If the clipboard contains a valid node description, add the
corresponding node to the graph.
Otherwise, do nothing.
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.
