If a cloud printer was connected, it would time out all the time. In some cases
it would do this in a single update loop (so connect and disconnect). Depending
on the machine of the user, this would either be visible or not at all.
This will now result in a job being put in the queue but not automatically printing, but there is at least a workaround for that.
Fixes Sentry issue CURA-14A.
This reverts commit 28f4d8513db7efce17bfd8b80fa7c8b237fd1c18.
The original revert was to revert an accidental merge from master to 4.7. This now reverts the revert on Master, so that we still have those changes on Master.
Here are a number of improvements to the translated texts that make it easier for the translators to translate them:
* Never include layout elements such as <ul> or <li> in the translated text. The translators don't know what to do with them. Instead, leave the tags out of the translated parts and then wrap them around it in Python.
* If there are replacement keys in the source text, explain all of them in the context.
* Use a name within the brackets, to make it clear from context what the brackets mean and to disambiguate multiple keys if there are multiple.
* No invisible whitespace (such as space at the end of a line).
* Use plural forms with i18ncp if applicable (or i18np if no context is necessary).
I also changed the catalogue variable to lowercase with underscores, as per our code style.
Even though the metadata of the machine was updated when it was
rediscovered, the new cluster id was not updated in all its references
(such as in the _remote_clusters and in the _um_cloud_printers dicts).
This commit fixes that issue by properly updating all the entries
that depend on the machine's cluster id.
CURA-7505
Since the host_guid is unique to the printer, it is more reliable for
identifying the cloud printers. This comes in handy when the cloud
printer is removed from the account and re-added. With the host_guid,
the printer that is added again can be properly identified as an
existing Cura cloud printer, and be linked to the original. To
achieve that, the META_CLUSTER_ID of the printer is updated with the
new one that is generated when the printer is added again to the
account.
CURA-7505
The autosync, which happens every 30 seconds, will now also inform the
connection status when the get request succeeds or fails, which is an
indicator of whether the internet is reachable.
CURA-7492
This has to be done in order to avoid weird actions taking place, such
as the user pressing to remove the printers while another sync is
happening.
CURA-7454
After 30 seconds a new sync will be initiated, which will alter the
conents of self.reported_device_ids, thus making the current message
deprecated. Therefore, it is best to have a maximum lifetime of 30
seconds.
CURA-7454
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
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.
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
