The empty string as hotend ID is interpreted as there being no hotend, since this is what the UM3 returns in that case.
Contributes to issue CURA-3161.
When the time passes normally it doesn't trigger this signal but just go on counting, but when the pre-heat starts or cancels it updates via this signal. This is handy for the future, when we want to update the remaining time from the printer information. However for now it is also nice because we can make the pre-heat timer dependent on this signal so we know when to have it running. This fixes the problem that the pre-heat seems to have been cancelled in the GUI when you switch away the tab, because the timer running is now dependent on the property rather than always false.
Contributes to issue CURA-3161.
If it's held inside the device that has two advantages: It's being held per-device, so switching connection doesn't stop the timer. And also, the logic is no longer in the GUI.
Contributes to issue CURA-3161.
The extruder name is asked from the extruder manager, so that the signal from extruder manager properly updates it once the new name is available.
Contributes to issue CURA-3161.
It is a no-op implementation that gives a warning. I'd rather give an exception and have that handled by whatever calls it, but this is how the other methods here do it.
Contributes to issue CURA-3161.
This may trigger a few extra updates, but allows us to use signal
compression in the postponesignals context manager, which greatly
improves performance.
It's not even necessary to check otherwise. Requesting an extruder stack would give None anyway, which would give errors.
Contributes to issue CURA-3291.
We need to listen for changes on all extruder stacks because the values might change and therefore the validation states might change. The value of a different extruder stack could change if you change a global value that has impact on a per-extruder value via inheritance, or in this case if a limit-to-extruder property specifies that the setting should be changed on a different stack. It could change on the stack that is not active in either case.
This might have some performance impact, but it is very small. Other than layer_height there aren't many global settings that have impact on multiple extruders via inheritance. And via limit-to-extruder there will typically only be one changed value which you want to update for. Changing layer height will be a bit slower though.
Contributes to issue CURA-3291.
The default value for the limit_to_extruder property is -1. So no need to check if the property exists. Just check if it is positive.
Contributes to issue CURA-3291.
The order of operations was a bit weird. This made the code unclear and also required an extra check in an if-statement. This is simpler and theoretically even a bit faster.
Contributes sorta to issue CURA-3291.
