This prevents ambiguities between `NodePlugin` objects that have been
registered (and are thus instantiable) and those that belong to `Plugin`
objects but have not been registered.
The states of nodes were not valid the first time they were loaded, but
became valid after any topological update (such as creating or removing
a node or edge).
The reason was that the loading of the graph was done before setting the
project path (and thus the cacheDir). So the status files of the nodes
were not available during the graph creation and were not updated at the
end of the load.
Now we set the filepath/cache first, so everything is right from the
start.
"isComputable" is renamed as "isComputableType": this function is only
about the Meshroom Node type and not about the computability in the
current context.
Even if we are in compatibility mode, we may has access to the nodeDesc
and its information about the node type.
When we stop the process of a node with multiple chunks, the Node
function will call the stop function of each chunk.
So, the chunck status could be SUBMITTED, RUNNING or ERROR.
Reoganization
- BaseNode: is the base class for all nodes
- Node: is now dedicated to python nodes, with the implentation directly
in the process function
- CommandLineNode: dedicated to generate and run external command lines
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.