When removing a printer, the files in %appdata%/cura/<version>/
/definition_changes/ remained intact. This commit fixes that by
making sure that the definitionChanges are removed before removing
the machine.
When the "Printers removed from account" message pops up, it will give
the option to the user to remove all the printers that are not linked
to his/her account from Cura. Since this action removes all
configurations, it first pops a confirmation question box, and if the
user insists, these printers are purged from Cura.
Note: In order to properly delete all the files, the printers have to
be activated first before they are removed, or else some extruder
files in %appdata%/cura/<version>/user and %appdata%/cura/<version>/
extruders remain.
CURA-7454
Gracefully handle the case where the machine manager is requested to
delete the last machine in Cura. In this case, instead of deleting
everything of this machine and still keep it as an active machine,
the machine manager will set the active machine to None.
The QML files which depend on the active machine were changed to
properly handle themselves when there is no active machine.
CURA-7454
This commit adds an additional AddPrinterPagesModel in Cura that does
not have the "Cancel" button in the "Add Printer" page. To achieve
that, the AddPrinterPagesModel is modified so that its initialize
function decides whether or not it will add the cancel button.
If Cura ends up in a state without an active machine, the AddPrinters
dialog will open up using the showAddPrintersUncancellableDialog signal
and display the new "Uncancellable" (is this a word?)
AddPrinterPagesModel, so that the dialog cannot be dismissed.
If Cura is closed at that point, the next time it is initiated, if the
user is logged in and there is no ActiveMachine, then instead of
displaying the entire WelcomePages wizard, it will show the
uncancellable AddPrinterPagesModel, forcing the user to add a printer.
CURA-7454
Previously the print job was sent with multiple PUT requests. This was necessary since the request was made with the Python Requests library, which freezes the interface while it's running. By breaking the upload up in chunks, it would at least periodically keep updating the interface (4 times per second or so, depending on your internet speed and Ultimaker's). Later on, this was replaced by a QNetworkRequest which doesn't freeze the interface in a refactor, but it was still broken up in chunks.
Recently that was again refactored to use Uranium's HttpRequestManager, which under the covers also uses QNetworkRequest. This also doesn't freeze while uploading, which is good. However for some reason the second chunk would always give a QNetworkReply::ProtocolUnknownError, which is a bit of a catch-all error for any HTTP status codes not supported by Qt. I was not able to figure out what was really going wrong there, but it has something to do with the content-range header and making multiple requests.
Instead of fixing that, I've removed the chunking. This simplifies the code a lot and doesn't have any implications for the user, since it still doesn't freeze the interface while the network request is ongoing. It should be slightly faster to upload, and reduce load on the server too.
However the disadvantage is that the original bug is probably still there if it was a bug in the HttpRequestManager. If it was a bug in the ToolPathUploader I probably deleted the bug here.
Contributes to issue CURA-7488.
Surround the serve_forever function of the web server with a try-catch
on Windows, in order to avoid printing the entire (useless) traceback.
Now a warning message is be displayed in the log instead.
The behavior is untouched in other platforms
So that the actions that can be performed by the message buttons
can properly access the list and take the necessary steps to achieve
their purpose.
CURA-7438
The meta data entry was rename to be more representative of its
function. In addition, the bool metadata entry is now properly
handled using the parseBool function.
CURA-7438
When a cloud printer is no longer received from mycloud, it is safe to
assume that the printer is removed from the account. In such a case,
the new function _devicesRemovedFromAccount(..) will retrieve all the
devices that are to be removed (i.e. they are added in Cura but they
do not exist in the clusters received from mycloud) and will remove
their output device. In addition the function will generate a message
that mentions all the devices that were no longer linked to the
account.
In order to achieve that, the Cloud/CloudOutputDeviceManager is
enriched with the dictionary self._um_cloud_printers that contains all
the currently existing cloud-enabled devices that were previously added
in Cura. In addition, the meta-data field "removed_from_account" is
added to all the cloud-enabled Cura devices to distinguish the ones
actually linked to the current account.
With these additions, the cloud devices that are removed from the
account will be automagically re-linked to it once the devices are once
again retrieved from mycloud for the specific account.
CURA-7438
This way the tooltip text can be re-evaluated every time we hover over
the instead of only once when the active machine is updated. With this
change, the text will be updated properly when there is a change.
CURA-7438
I have no idea why i thought a listview was needed for this when
this was made. The data shouldn't be flicable, so it makes way more sense to
use a row layout
CURA-7480
