There was the problem that you'd click on pre-heat, so locally it would display the time-out. Then a package came in with the out-dated print status saying that the printer is not pre-heating, so the pre-heat was cancelled on Cura's side. Then the next status update came in saying that the pre-heat is now busy, so the pre-heat is resumed on Cura's side. So the button was flicking back and forth once after pressing. This commit makes Cura ignore any status updates that come while the put-request is still going on, because they may be outdated. It'll appear nicer to the user, mostly.
Contributes to issue CURA-3360.
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."
