internalAttributes are managed on the Meshroom side, not at the node
level. So there is no reason to call the upgrade of internalAttributes
on the node description.
Add new type of ChoiceParam that changes dynamically according to other
values.
When value of an attribute is changed onAttributeChanged is called,
allowing to have unique reaction within node files.
Also add of callDesc function to be able to have other functions such as
onNodeCreated at creation of node.
For instance, on the Meshing node "outputMesh" param expression is:
value="{cache}/{nodeType}/{uid0}/mesh.{outputMeshFileTypeValue}",
So the extension here should not contains quotes.
We have the problem of spaces in file paths, choices (like colorspace),
etc.
An empty list is not send to the command line.
An empty string is send to the command line as "".
Add new unit test to ensure it follows the expected rules.
Chunks of that node that are already in the `SUCCESS` state will not be
updated, and those that are `SUBMITTED` but not `RUNNING` will be reset
to `NONE`.
If a node has a user-set label (defined through the internal attributes
of the node), its default name (the one that is displayed if no label
has been set) will be displayed next to it.
This allows to find quickly the correspondence between the node's label
and its type / how it is referred to in the current graph's file.
The `UidConflict` is not detected per se within the node factory as a
node's UID cannot be computed accurately from there, since its expressions
(which may impact the UID computation) have not been resolved yet.
Instead, the `UidConflict` is detected externally, and the information
is transferred to the node factory, which will create a corresponding
compatibility node with the regular process.
The created `UidConflict` compatibility node will be handled by the
Compatibility Manager like any other compatibility node.
When a node with viewable output attributes is loaded, the combo box of
the 2D Viewer lists these attributes. As some of these attributes are
enabled or disabled, they need to be added or removed from that list,
without needing to load another node first, or to unload the node.
This commit connects the signal that is emitted when an output attribute
with a viewable output is enabled or disabled to the slot that reloads
the currently loaded node (and thus updates the list).
By default, an attribute that belongs to the UID group 0 is taken into
the node's UID computation independently from its value, as long as it is
enabled.
When such an attribute is added to a node's list of attributes, it
automatically invalidates all computations made for this node prior to
its addition.
This commits adds a new attribute property, "uidIgnoreValue". This property
determines whether the attribute must be taken into consideration during
the node's UID computation: if the value of the attribute is the same as
"uidIgnoreValue", then it should be ignored; otherwise, it should be taken
into account. By default, "uidIgnoreValue" is set to "None", meaning that
any attribute that may be considered during the UID computation will be
taken into account.
In the context of the internal attributes, "uidIgnoreValue" is set to empty
string, so the "invalidation" attribute will not automatically
invalidate 100% of the nodes from existing graphs until its value is set
to a non-empty string.
The "label", "color" and "comment" properties are not constant anymore,
their changes in value are notified with the internalAttributesChanged()
signal, like the "invalidation" property.
This implies that the connection on "internalAttributesChanged" on the
QML side is not needed anymore.
"hasAttribute" was previously never called before attempting to
access an attribute. With the addition of internal attributes, we
want to check the attribute's/internal attribute's before accessing
it to avoid KeyError exceptions. "hasAttribute" (and the newly added
"hasInternalAttribute") would not parse the attribute's name before
checking for its existence, meaning that errors could be generated for
list or group attributes as their checked name could contain other
elements (e.g. "featuresFolder[0]" for a ListAttribute named
"featuresFolder").
Setting this attribute allows the user to change the color
of a node, either by directly providing an SVG color name or an
hexadecimal color code, or by picking a color with the selector.
