If the default was 0, then the if statement would evaluate as False and it would not make them visible until you closed and re-opened the panel.
Contributes to issue CURA-7211.
[CURA-5767]
The backend can't handle per mesh-group settings (as opposed to per mesh settings)
when sequence was in one-at-a-time mode. The problem is that the extruder train is
in between the per-meshgroup-settings (child-of) and per-mesh-settings (parent-of).
For any per-mesh-group settings, the possibility exists that they'll be overridden
by settings we always set (and that need to be set) per extruder. Changing this
would require the engine-architecture to change, and _all_ settings would need to
be thouroughly retested. As this was a too extensive change, it was decied just to
disable the per-meshgroup settings when printing one-at-a-time (too).
The issue was originally reported as:
'"Printing Temperature Initial layer" setting per mode does not work'
several instances need to be created.
- In the ThreeMFWorkspaceReader we need to create some temporal
instances of Preferences that makes it not singleton anymore.
- The current preferences are kept in the Application class and so all
the calls to the preferences are changed to get the preferences from
Application.
- The method getInstance in Preferences is kept as deprecated since some
external plugins.
**The diagnosis:**
The issue arrises from the fact that while the original object is subscribed to be validated, that subscription is only created by setting it as a settings override object. A clone of that object, while still a settings-override object, never gets subscribed because it's not explicitly set with the tool.
**The solution (?):**
I moved all the validation stuff over to SettingOverrideDecorator.py, and use its onSettingChanged() function to trigger the validation. Unfortunately, I can't use the timer because of some limitation with QTTimer and threads. So it's _a bit laggy in some places, and I'd be open to tips about how to fix this. It does work reliably though.
The issue Andreea found was caused by the fact that the object was unsubscribed from setting validation while still having the illegal value, because the setting (and its illegal value) was removed AFTER unsubscribing. Thus the illegal value got "saved" until the next time you added that setting and set the correct value.
