If multiple instances of Cura are running or Cura is restarted, it now properly syncs the remaining pre-heat time with the printer, so that all instances display the proper time.
There's still a bug in here that pressing cancel has no effect the first time since the remaining pre-heat time is updated immediately from the printer before the command to cancel got through remotely. I'll see what I can do to amend that. Also, cancelling is not yet synced.
Contributes to issue CURA-3360.
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 previous implementation just emitted the signal twice, once in setTargetBedTemperature and once in _setTargetBedTemperature. I've made the private one actually set the temperature.
Contributes to issue CURA-3161.
We want to allow floats in the interface since the interface needs to be agnostic of what device it is connected to. But the UM3 API only allows integers, so we still need to round it to the nearest integer.
Contributes to issue CURA-3161.
It rounds to 3 digits. The specification of the feature in the API doesn't mention how detailed the temperature and duration can go, but thousands seems more than enough. This also eliminates pesky problems with the JSON brackets in the format function.
Contributes to issue CURA-3161.
From OutputDevice.py:
"output device subclasses are completely free to implement writing however they want, though you should emit writeStarted and related signals whenever certain events happen related to the write process."
