Converted doxygen style comments to reStructuredText style in the files
found in Cura/cura/Model directory recursively using the script
dox_2_rst.py (provided in the Uranium repo). Comments were manually
checked and changed if needed.
Note: dox_2rst.py struggles with decorated functions.
We don't want to use it outside of the mapping. This mapping should be transparent.
We are still using it from our tests though but that's fine. Tests are allowed to touch private fields.
Contributes to issue CURA-6793.
It's not an InstanceContainer but a DefinitionContainer.
Also, when checking with the ID, it'll short circuit to the dictionary look up by ID. Then it's faster to directly check without specifying what type of container it is to prevent another nested function call.
Contributes to issue CURA-6793.
The findContainerStacks() will list all container stacks and lazily load them. However this lazy loading is done on the thread that's calling it. The lazy loading will create GlobalStack objects, which are QObjects. The QML code then can't access those QObjects because they are created on different threads. So now instead we'll do the find query on the main thread but all the rest on the background thread.
Contributes to issue CURA-6973.
Should be completely transparent. It'll fail the unit tests though because it now pretends that all printers have machine nodes.
Contributes to issue CURA-6793.
Otherwise the iteration can happen in any arbitrary order (due to the dict) and this can cause the result to not match to the desired combination of configurations per extruder.
Contributes to issue CURA-6600.
Because global_stack.extruders.values can be returned in any order, the configurations matching with the lists doesn't always give a result.
It happened to work on my computer with the test, but there is no guarantee of that.
This is probably also going wrong in other places. I don't think we should use the .extruders property anywhere really!
Contributes to issue CURA-6600.
Get the quality changes group back from whichever one is actually active on the stack. This prevents the two from getting out of sync, which makes the code easier to maintain.
Contributes to issue CURA-6600.
The speed improvement didn't work.
It still doesn't seem to have a lot of effect. Maybe it's not the creating of the tree that causes this slowdown?
Contributes to issue CURA-6600.
We want to make sure that this tree is constructed during start-up after all containers have been registered, so we call getInstance() there once. If you need the tree before that, the tree will not yet have been filled and you won't get complete information, so you'd need to listen for updates.
The singleton is there so you don't need to go via CuraApplication.
Contributes to issue CURA-6600.
This sets up a few new classes, subclasses of ContainerNode.
This is intended to simplify the current structure in the QualityManager.
Contributes to issue CURA-6600.
