The validity can't be tested using the built-in validator since that one checks if there are no settings that 'override' non-existing settings. And some of the settings overridden in an extruder are not in the inheritance stack since fdmextruder doesn't inherit from fdmprinter.
We'll check though that all settings that are overridden don't override a default_value while there is a value, and whether they don't have IDs.
This makes a few things slightly simpler as well since it now parameterises the tests with the entire path of the definition file so we don't have to reconstruct that in every test.
I don't know why the CI system was only complaining about it several commits later. Could be troublesome.
Fixes a bug introduced by 1284d9fe8d726e46b556caa8f2f390dc7d65220c.
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.
When going through the list of tests for many printers to fix them, it's then easier to go through the failed list. They will appear in the same order as in my IDE. Just a bit of an ease of life thing without any real cost.
Done during Turbo Testing & Tooling.
Turns out that the JSON objects extend from dict, so this works.
Also turns out that strings have a __getitem__. Who knew?
Done during Turbo Testing & Tooling.
This should not be done anywhere since the default_value won't have any effect then. We disregard CuraEngine's command line method here but that's infeasible with those profiles anyway.
Done during Turbo Testing & Tooling.
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.
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.
It's not behaving as expected here. For instance, Ultimaker 3 wasn't specifying has_machine_materials and thus only the base materials would get loaded, but clearly the Ultimaker 3 has materials specialised for it.
Whether or not a printer has materials specialised for it is now determined by whether the specialisations exist in the material files. So we don't need the metadata entry any more. It seemed to have not been in use anyway, except by one printer which specified that has_machine_materials is true. I've now made it behave as if it's always true.
Contributes to issue CURA-6831.
These are used by the code. Otherwise there would be an AttributeError of 'intent' not existing, and the quality type in the quality node wouldn't match because it's a magic mock.
