The new lazy loading requests different functions from the registry so we need to mock that out.
Also fix the manual insertion of things into the lazy-loaded mapping.
Contributes to issue CURA-6793.
This is just something I encountered. Could be that some profiles got corrupted. In my case, I had a bug in Uranium that I fixed later.
Contributes to issue CURA-6793.
Also fix unnecessary emitting of switching extruder tabs.
This should improve performance a lot. I tested a lot of things and am convinced that it didn't break anything. But the automated GUI tests and QA team should be the final arbiters of that...
Contributes to issue CURA-6793.
We had changed it for all printers back when we changed the prime tower position to a formula, but since then we've been getting new printer definitions that were made from templates floating around with the old structure.
We should really have an automated test for this.
Discovered during review of #6518.
The default value here would not be used. Override must be `value` not `default_value` solves #6491 for BIBO but other printers may also be affected by #6491.
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.
When switching printers, it would first emit the global container changed signal which connects to _onGlobalContainerChanged, then update stuff in the extruder manager, then manually call _onGlobalContainerChanged again to update some other stuff with the new data from the extruder manager. This was prohibitively expensive, so this prevents that.
Another double or triple emit of the activeExtruderChanged was removed in the extruder manager when creating the extruders for a printer: It would first set the extruder number to 0, possibly emitting the signal, then emit the signal just to be sure since the extruder itself changed (rather than just the number), and then change the extruder number to the preferred extruder, possibly again emitting a signal. Now it just sets the extruder number to the preferred extruder and always emits the signal once (either through setting the extruder number or manually afterwards).
Contributes to issue CURA-6793.
The extruders are added when changing printers anyway, and we call this change signal upon start-up. So one of them is going to do unnecessary work.
Contributes to issue CURA-6793.
