Prior to this commit, nodes with a varying number of chunks were initialized with an empty list of chunks (as expected), but with a global status that was set to `SUCCESS` instead of `NONE`. This caused issue on the graphical side as `SUCCESS` is interpreted as the status for nodes that have been successfully computed.
Add 2 default entries to the command line variables:
- `nodeCacheFolder`, which contains the location of the cache folder
- `nodeSourceCodeFolder`, which contains the location of the file
describing the node
The desc.Node.onCreated callback is a hook in the Node API for developers to
write custom behavior on a node first initialization.
By being called in the core.Node constructor, this was triggered in several situations
that don't match this idea and with unpredictable side effects (graph loading, node re-creation on undo...).
* Make `onNodeCreated` callback an explicit method on desc.Node.
* Remove the call to node descriptor's `onNodeCreated` callback outside core.Node constructor.
* Trigger this callback on explicit node creation (adding new node to graph, init a graph from a template).
* Deserialization: Replace the logic that defaulted the node type version to "0.0" when unspecified,
and assume that unspecified version on a node is targetting current node type version.
* Serialization: Only serialize node type versions for which a version info is available.
* Test suites:
* Add helper context manager to manually override the version of a given node type.
* Add new unit tests to cover version conflicts handling is various scenarios.
When creating a compatibility description for an unknown attribute, do not
consider a link expression as the default value for a File attribute.
This is breaking how the link expression solving system works, as it's resetting
the attribute to its default value after applying the link.
If that expression is kept as the default value, it can be re-evaluated several
times incorrectly.
Added a test case that was failing before that change to illustrate the issue.
Propagate attribute value changes downstream using `valueChanged` signal
emission, instead of calling `_onAttributeChanged` directly.
This does not change the current core behavior, but it triggers the
property notification signal when in UI mode.
This makes changes happening upstream properly reflected in downstream nodes.
When converting the `StatusData` to a dictionary, only data attributes
should be stored in said dictionary. With Qt6, the `objectNameChanged`
signal, of type `SignalInstance`, is added to the dictionary. It needs
to be removed manually as it is not JSON-serializable. Otherwise,
the nodes cannot be computed anymore.
Move the attributeChanged callback logic within Node, as this
is a Node level mecanism (callbacks being declared on the node desc).
This commit also moves the attribute valueChanged signal outside of
the Attribute's constructor.
This seems to be the root cause to undesired side-effects breaking Qt's evaluation
system, data model access and consequently Meshroom's UI.
This will allow to simplify node descriptions as most of the attributes
are generally invalidating. Only non-invalidating attributes will need
to state explicitly `invalidate=False`.
For output attributes, which must not be invalidating, `invalidate` will
be automatically set to `False` at the attribute-level if it is set to
`True` in the description.
The UID system based on a UID index is removed and replaced by a single
UID per node.
Attributes will be included in the UID computation if the `invalidate`
is set to `True` in their description. This replaces the `uid=[]` /
`uid=[0]` element of the description.
If a node's description contains invalid operations in its `onNodeCreated`
method, exceptions are thrown without being caught and cause Meshroom
to crash.
These calls are now safely tried and any encountered exception is handled.
If the edges of a node to submit include an `InputNode` (which cannot
be computed), then that node should be excluded from the list of edges
to process as if that node had already been computed.
This allows to submit any type of graph involving `InputNode` to the farm.
For dynamic output attributes, the UID does not depend on the attribute
value.
In particular, when loading a project file, the UIDs are updated first,
and the node status and the dynamic output values are not yet loaded, so
we should not read the attribute value.
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.
