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
...
This makes for ugly g-code files, true, but at least the functionality of saving settings is useful now: It's traceable. Could've implemented this somewhere else too, but this is fine for now.
Contributes to issue CURA-1278.
The settings that are serialised at the end of the g-code are now the serialised global container stack. That's fairly useless since the serialised version of a container stack just lists the IDs of the containers in the stack, not the settings themselves. One of these containers is likely a current_profile container and that's all the information you'll get from that serialisation.
Contributes to issue CURA-1278.
E.g. higher than maximum_value. This seems to work okay but is largely untested because switching to advanced mode gives a segfault.
Contributes to issues CURA-1278 and CURA-1588.
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.
They have all been checked for correctness now. While I was doing that, I documented their working as far as I could understand.
Contributes to issues CURA-1278 and CURA-1588.
I was reading through these to check if they'd still work. They should still work, but since I went through them I went ahead and documented them too.
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.
We don't save the file name any more. The engine doesn't need any machine-specific definitions at the moment, so we can always just send FDMPrinter.. This may later change, but later we will also send a serialised JSON rather than a file name so then we won't need the file name any more.
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.
This was a concurrency issue: If the slicing was very fast, it could finish slicing before the listener was connected to the message of being finished. Therefore, we should connect to being finished before we even start the start-slice job.
Contributes to issue CURA-1278.
