This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
This reverts commit 27701f7653. After discussion with Nallath we've decided that it wasn't that noticeable and could temporarily display wrong names in the interface. We've decided to undo it for now.
Contributes to issue CURA-6932.
Conflicts:
cura/Machines/MaterialManager.py -> File was deleted in Master but I changed things for the lazy loading.
cura/Machines/Models/BaseMaterialsModel.py -> I clarified documentation on a line above a place where a timer was added in between.
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.
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.