Now the job can determine if we can continue with slicing or not and if
not, why not.
This also means we can now show a message when we cannot find any
slicable objects.
Contributes to CURA-1278
Contributes to CURA-1278
* settings_rework: (224 commits)
Improve slice trigger documentation
Import Cura in materials preferences page so we can use the active definition id
Add layer height to high quality profile so we have something that changes
Update example XML material to use the right product names
Filter available materials by the machine definition
Show the add machine dialog when we do not have an active machine
Create machine-specific material containers for machine specific overrides in XML material files
When creating a new container stack, add empty containers for things where we cannot find containers
Add preferred variant, material and quality to UM2+ definition
Account for global container stack being None in the backend plugin
Use the global stack instance variable and account for it potentially being None
Store the global container stack as an instance property
Added wildcard to filtering
Per object settings filter now uses correct bool types (instead of strings)
Removed stray = sign.
Fix creating print job name
Disable asynchronous loading of SettingItem when Qt Version < 5.5
Document QTbug
Properly serialise all settings to g-code file
Document GCodeWriter class
...
Instead of traversing the setting definitions ourselves, let the stack do it. This code should be reusable for other places where we want to get certain properties of all settings, hopefully.
Contributes to issues CURA-1278 and CURA-1588.
This was printing all settings that were being sent to the engine. Could've been useful, actually. Maybe I'll re-add it in the form of a log.
Contributes to issues CURA-1278 and CURA-1588.
The setting is used to group items for one-at-a-time printing before they're sent to the engine. This properly gets the setting value under the new setting system.
Contributes to issues CURA-1278 and CURA-1588.
I'm going to rename this function to be able to send per-extruder and per-object settings with different functions later on. This updates the call to the function to use the new one.
Contributes to issue CURA-1278.
I was going further with this, but then it was decided that we need to do this later but I won't throw away this bit of documentation when I have it anyway.
Contributes to issue CURA-1278.
See issue Ultimaker/CuraEngine#240
The intent of this change it to allow token replacement in start/end
gcode similar to the old Cura. Tokens are of the form
{material_bed_temperature} where the name is any setting name that is
passed to the engine.
Control the backend's generation of temperature commands via new
settings material_bed_temp_prepend and material_print_temp_prepend based
on whether there are temperature tokens in the printer profile's start
gcode.
This change will generate the same temperature gcode as FffGcodeWriter
at the head, if none of the temperature tokens are present in the
machine profile. Otherwise, they're suppressed via the prepend settings.
Also, set fdmprinter.json so that all that inherit from it default to
having the gcode temperature prepend also wait for temperature. Profiles
can override these settings: material_bed_temp_wait and
material_print_temp_wait
This PR intends to change both Cura and CuraEngine. However, it is safe
to sequence with the Cura change first which will do token replacement
(if present), but will fail to supress the temperature prepends.
This way it can be properly threaded (with a generous sprinkling of
"yieldThread") so we do not block the UI when slicing starts.
Contributes to CURA-358
