As explained in the block of documentation, we can't find the variants because there is no guarantee that the variants have been loaded by the time that the metadata of materials is deserialised and we don't know their IDs either (so no lazy loading). This registers a function to be called upon completely loading the metadata, which runs a query on the metadata to find the variant by its definition and name. A bit hacky but I see no better solution.
Contributes to issue CURA-4243.
This prevents us from having to make an expensive findContainers call if it's not necessary, and also prevents us from unnecessarily loading the subcontainers in a loop during loading.
Contributes to issue CURA-4243.
My IDE shows the str(inst) representation of an object when indicating what value is in there. This makes it easier to find stuff. It'll also make debug prints more clear than the default <XmlMaterialProfile.XmlMaterialProfile.XmlMaterialProfile object at 0x12345678> stuff of Python.
Contributes to issue CURA-4243.
We only need the metadata of these machines (now that the ID is in the metadata). We won't need all of those machines because some of them are not added.
Contributes to issue CURA-4243.
Since we now return all metadata at once from every file, we don't need this any more. We need to side-load the metadata anyway.
Contributes to issue CURA-4243.
Because the setName function checks if the name is equal to the previous name, but at that point the previous name doesn't exist.
Contributes to issue CURA-4243.
CURA-4451
- Add upgrade script for 3.0. to 3.1
- Upgrade old stack files so they will use "empty_quality" as the
"Not Supported" quality profile.
- Increase SettingVersion to 4
We shouldn't write the name or ID, who are now in the metadata.
Also we should load the name and ID properly from the file.
Contributes to issue CURA-4243.
Because their implementation changed, these would have been implemented in some other way. Instead I use the getters and setters which are inherited from the parent class and therefore are already updated.
Contributes to issue CURA-4243.
CURA-4270
Technically, this is not right. This is just to postpone a time bomb...
The XML material profile needs a setting number instead of getting it
derived from the schema version.
Otherwise we fall back to the manufacturer in the machine definition. If that fails too, we fall back to Unknown (rather than an empty string).
Contributes to issue CURA-4157.
