This reverts commit 28f4d8513d.
The original revert was to revert an accidental merge from master to 4.7. This now reverts the revert on Master, so that we still have those changes on Master.
I don't know what it is with this one, but it's finding the wrong one. We specify through the prefix that it should search in the cura-build-environment first, but apparently it's not listening to that. As a result it's getting Python 3.6, and then stops because it can't find the headers for that version. It wouldn't need the headers in this case, but if it didn't crash here it would crash during the run time because libArcus and libSavitar have been linked to Python 3.5.
As the Limited will always apply on top of the others, so selecting the Distributed is
essentially the same as selecting the LimitedDistributed.
CURA-7555
As it will be applied by default in the Engine to ensure that libArachne will generate only the
required walls (based on the Wall Line Count setting).
CURA-7555
This reverts commit 458acb356f.
The change was wrong. The code refers to PrinterOutputModel.extruders which is not deprecated, not to GlobalStack.extruders (which is deprecated).
Fixes#8204.
Previously this was disabled because you should probably use the ZigZag pattern then. But I'm enabling it now because of two inconsistencies:
* The setting still works. So you can change the setting by switching to grid, triangles, cross or gyroid, then switch back to lines and still get connected support lines.
* The same happens with the infill patterns, where this setting is visible for the lines pattern.
Rather than changing the other two things (which involves changes to CuraEngine too to make it ignore the setting value for the lines pattern), I've opted to change it here and fix both inconsistencies at once. If I were to make the setting dysfunctional, it would also lead to user confusion, because they then need to discover that they need to change the infill pattern, which may look unlogical to them.
Fixes#8192.
Previously we would only look at the state, but that isn't the only thing it should look at.
It should override the value of a resolve if it's defined in user changes or QualityChanges.
Previously we would only look at the state, but that isn't the only thing it should look at.
It should override the value of a resolve if it's defined in user changes or QualityChanges.
Since the amount of times that the key is in there is orders of magnitude
larger, it's better to catch the exception when it doesn't (as that is
slightly faster)
