Commit graph

8923 commits

Author SHA1 Message Date
Kostas Karmas
c67b4ee3a0 Remove unused function 2021-04-22 15:08:47 +02:00
Kostas Karmas
86bfb3a5aa Fix incompatible mypy type 2021-04-22 15:08:07 +02:00
Kostas Karmas
bc408a5a67 Fix mypy issues with the DigitalLibrary plugin 2021-04-22 15:00:42 +02:00
Jaime van Kessel
b21c9a3b24
Merge branch '4.9' of github.com:Ultimaker/Cura 2021-04-21 09:51:38 +02:00
Kostas Karmas
d972c505d0 Initial commit for the DL 2021-04-20 11:30:49 +02:00
Kostas Karmas
ae595affc3 Merge branch '4.9' 2021-04-19 14:16:29 +02:00
Remco Burema
f22e223d72
Merge branch 'master' into libArachne_rebased 2021-04-16 18:17:04 +02:00
Kostas Karmas
00ade8be3a Fix crashing if the quality_type_to_apply is None
Fixes sentry issue CURA-24D
2021-04-16 16:35:44 +02:00
Kostas Karmas
df5c52d1c6 Fail gracefully if writing the backup to a temp file crashes
Fixes sentry issue CURA-21W
2021-04-16 15:55:06 +02:00
Ghostkeeper
0d29610899
Catch environment errors when restoring back-ups
There could be an environment error when saving that file because of access rights or insufficient disk space. Catch that error and display an error message to the user. The log then contains more information on exactly why it failed, but the user just knows it fails.

Fixes Sentry issue CURA-21W.
2021-04-16 14:14:21 +02:00
Ghostkeeper
acb0c57026
Merge branch '4.9' 2021-04-16 12:05:22 +02:00
Ghostkeeper
544b267447
Merge branch 'CURA-8004_fix_wrong_uploaded_print_job_cache' into 4.9 2021-04-16 12:05:06 +02:00
Ghostkeeper
972e024a43
Add typing for get/setShowTravelMoves
This one was missing. The rest already seems to have typing.
2021-04-15 19:31:57 +02:00
Ghostkeeper
cd551555ef
Merge branch 'master' into layer_view_statistic_limits_only_visible 2021-04-15 19:30:56 +02:00
Remco Burema
1eb1a943b2
Process supposed to stop when already sending a job.
When using the visibility of the progress bar to detect if a job is already being sent, then make actually sure the progress bar is visible the moment the job starts, not at some unspecified time later in a method that might not even trigger if there is already a mesh ... so it's unlikely to even work, since the thing it was intended to prevent _very_ likely has the same mesh anyway.

CURA-8004
2021-04-15 16:53:01 +02:00
Kostas Karmas
ebdd21410e Merge branch '4.9' of https://github.com/Ultimaker/Cura into 4.9 2021-04-14 17:20:42 +02:00
Kostas Karmas
361bd8c6b1 Don't crash if the returned error has no title
Fixes sentry issue CURA-23P
2021-04-14 17:20:02 +02:00
Ghostkeeper
adb5f28aaf
Filter out disallowed characters from job name
Took a while to figure out exactly what to do here. But the task itself is simple.
The Ultimaker software apparently doesn't accept special characters here. The regex here is exactly the inverse of the regex that they use to accept job names.

Done as a 5 minute fix.
2021-04-14 16:56:17 +02:00
Remco Burema
4c5dac0dfd
Improve logging, UX for cloud-upload-errors.
One of the reasons this bug (see parent of this commit ... or the issue nr if you have internal access) was so vague is that A. the user was insufficiently prompted, and B. no one could find anything in our logs.

CURA-8004
2021-04-14 14:30:42 +02:00
Remco Burema
9227c303c6
Fix 'uploaded print-job cache' set before the mesh upload.
Since we use that to detect when the mesh is already uploaded, and thus can be reprinted, this could cause problems, since, while we do properly set it to None when an error is returned, if the request never returns to us, or if a reprint is started while the mesh is still uploading, the print-job cache could be set while the mesh wasn't actually there yet. Which could in theory have maybe caused the problems we see.

CURA-8004
2021-04-14 13:59:21 +02:00
Ghostkeeper
4fc91d4f6d
Add notification to connect the printer even if the printer is not network-connected
There could be other methods of connecting than the network connectivity of the UM3NetworkPrinting plug-in. For instance, perhaps other network connection plug-ins can provide information in this monitor stage. Or the user might want to use a USB cable.
I'm explicitly quite vague about how it should be connected because this label should work for all types of connections except UM3NetworkPrinting.

Fixes #9444.
2021-04-12 12:11:50 +02:00
Jaime van Kessel
f4f1dce941
Merge branch '4.9' of github.com:Ultimaker/Cura 2021-04-12 11:21:22 +02:00
Jaime van Kessel
43cc5fbca9
Add constant marker to supportsPrintJobQueue 2021-04-12 10:14:44 +02:00
Remco Burema
e2135088b9
Merge branch '4.9' 2021-04-09 09:49:44 +02:00
Remco Burema
7f6133ca94
Merge pull request #9535 from Ultimaker/CURA-8093_Check_client_scope_when_upgrading_from_4.8
CURA-8093: Check client scope when upgrading from 4.8
2021-04-09 09:48:55 +02:00
Ghostkeeper
b3c03b8771
Merge branch 'master' into libArachne_rebased
Conflicts:
	resources/texts/change_log.txt -> 4.9 got added while we added the Arachne change log as well. I put 4.9 below the Arachne info.
2021-04-08 13:49:52 +02:00
Kostas Karmas
dca0612ee7 Add descriptive comment for deleting the user auth data
CURA-8093
2021-04-08 12:49:33 +02:00
Kostas Karmas
72080a3cca Delete the auth data on upgrade from 4.8 if the scope doesn't match
If the user account scope is outdated, delete it when upgrading from 4.8 to 4.9. This means that
the user will have to log in again, to make sure they get the correct account scope.

CURA-8093
2021-04-08 12:46:52 +02:00
Jaime van Kessel
8e106b2f5b
Merge branch '4.9' of github.com:Ultimaker/Cura 2021-04-08 12:05:26 +02:00
Jaime van Kessel
d49a90029f
Fix final set of typing issues 2021-04-07 14:03:35 +02:00
Jaime van Kessel
00a360aca6
Don't overload types in AMFReader
The typing really doesn't like it if we first let a variable be a list and then
an numpy array
2021-04-07 11:32:09 +02:00
Ewald Kleefstra
15b30de90b Added relative extrusion mode support for PauseAtHeight.py script 2021-04-07 10:58:36 +02:00
Kostas Karmas
39e9dcd4f5 Fix VersionUpgrade48to49 crashing if there is no "categories_expanded"
If the 4.8 is started from a clean install and no category gets expanded in the settings panel,
then the "categories_expanded" key will not exist in the [cura] preferences in cura.cfg.
As a result, when the 4.9 gets started in this specific case, the version upgrade 48 to 49 will
produce a crash and will be considered as "failed", which will then lead to cura requesting from
the user to go from the entire onboarding flow instead of landing on the "What's new" pages (even
though everything else has been properly updated).

This commit fixes that by checking whether the "categories_expanded" key exists in the cura.cfg.
2021-04-06 16:37:06 +02:00
Kostas Karmas
b2b258d357 Fix add script button list not working in MacOS
Fixed by using the qt quick controls 2

CURA-8127
2021-04-06 14:53:20 +02:00
Ghostkeeper
95297f0410
Merge branch '4.9' 2021-04-06 13:30:03 +02:00
Ghostkeeper
08be77adad
Increment SDK version to 7.5.0
The Cura 4.9 release will have expanded functionality. If you have a plug-in that uses this functionality, marking it as using SDK 7.5.0 will notify older Cura releases that they can't use that plug-in.
2021-04-06 13:28:08 +02:00
Kostas Karmas
081b0b23a4 Fix setting the time_remaining_method in the versionUpgrader
The DisplayProgressOnLCD script was changed and the "time_remaining" was split into two settings:
the "time_remaining" and the "time_remaining_method". If the "time_remaining" was enabled, the
"time_remaining_method" should be set to "m117".

The VersionUpgrader48to49 was changing the "time_remaining" to "m117" instead of changing the
"time_remaining_method", which was leading to the "time_remaining" having a wrong value and not
being interpreted as a boolean.

This commit fixes that by setting the "time_remaining_method" into "m117" when the "time_remaining"
was True.

CURA-8110
2021-04-06 11:38:28 +02:00
Ghostkeeper
71b217c624
Fix colour calculations if spectrum is entirely one value
If the range of the colour spectrum is 0, i.e. there is only one value for the current colour spectrum, then this would previously give a division by 0 in the shader, causing the final colour to become black. This is unexpected and makes the layer view hard to read. Instead, we'll now use the middle of the range then.
This was likely a problem for a long time but only really became visible due to the colour spectrum now showing only the range of values for the visible structures. Previously it was a problem e.g. for layer thickness if all layers had the same thickness (i.e. initial layer height == layer height).
2021-04-03 17:29:33 +02:00
Ghostkeeper
6209a08121
Fix accidentally always taking 0th line along
The input array here is 2D, but always 1 by N long. The output of where then gives a tuple of two arrays, one indicating the Y positions and the other the X positions. The X positions were therefore always 0. The amin and amax functions were then always taking this index 0 along in their results, regardless of whether the line at that index was visible at all or not.
This will also improve performance since it's checking the limits now only for half as many indices.
2021-04-03 17:19:24 +02:00
Ghostkeeper
9b1941a4a2
Don't crash if there are no visible lines in a polyline 2021-04-03 17:07:01 +02:00
Ghostkeeper
b5bc4aecd5
Reset color scheme limits before every recalculation
This prevents previous measurements from influencing the colour scheme. Essentially previously it was showing the colour scheme based on all lines you had ever seen, rather than just the line types you were currently seeing.
2021-04-03 16:56:36 +02:00
Ghostkeeper
9f902f7a7a
Update colour scheme limits if visibility changed the limits
If the user makes certain structures visible or invisible, and this then causes the limits of the colour scheme to change, this now triggers the layer view to be re-rendered and updates the legend in the simulation view menu component.
2021-04-03 16:49:04 +02:00
Ghostkeeper
424f037dca
Trigger recalculation of colour scheme limits when visibility changes
While it's now correctly triggered to recalculate, it doesn't correctly update yet in the interface. We'll need to resolve that next.
2021-04-03 16:30:10 +02:00
Ghostkeeper
28f8da8f7b
Move calculation of simulation spectrum limits to separate function
This is just a refactor that shouldn't have any influence on the behaviour.
It is a necessary prerequisite to be able to trigger the updating of the layer view colour spectrum more frequently, i.e. if the visible line types change.
2021-04-03 16:16:02 +02:00
Ghostkeeper
8d13cfb5d6
Make limits in colour scheme depend on the visible line types
This way, if travel moves are not currently visible in the layer view, the travel moves don't get counted with the limits to determine the colour spectrum to grade each line with. Quite often, travel moves had a much greater speed than other moves, like 120mm/s instead of the fastest printed line 60mm/s. This caused all of the layer view to be pushed into the lower end of the spectrum. It makes it hard to distinguish the differences in speed and line width because travel moves influence the spectrum so much. This way, the travel moves only influence the spectrum if they are visible. If they are visible, it might be relevant to the user. Otherwise, the user gets the full spectrum to differentiate between all the line widths and speeds.

This currently doesn't update correctly yet. That is something we'll need to fix.
2021-04-03 16:03:20 +02:00
Ghostkeeper
fd6dbd3ede
Draw simulation view lines with a constant colour for the entire line
All of our current layer view colour schemes are properties of a line, not of a vertex. The line has a single feedrate, a single line type, a single layer thickness, a single material colour and a single width. This is even limited by the g-code specification itself, which is unable to represent lines with varying line width. However, we store this information in the vertices, the vertex data being the only data sent to layer view since layer view is sent as polylines to the shader.

This change makes the entire line take on the colour scheme of the vertex where its representative data is stored. This data is intended for the line, not just for that vertex, so it makes sense that the entire line listens to the data of the correct vertex, not just the nearest vertex of the line's endpoint.
2021-04-03 15:40:14 +02:00
jelle Spijker
27fc435724
Bumped up stack version to 5
CURA-8110_upgrader
2021-04-02 15:02:38 +02:00
jelle Spijker
ebc4f45da6
Revert "Removed the upgrader for the machine and extruder stack"
This reverts commit 4707560d
2021-04-02 14:45:16 +02:00
jelle Spijker
72478994ec
Bumped up the Preference version to 7
reverted the SettingVersion to 16

CURA-8110_upgrader
2021-04-02 14:41:52 +02:00
jelle Spijker
4707560dcb
Removed the upgrader for the machine and extruder stack
It is known that will cause some user scripts to default behaviour.
But this is accepted behaviour, and the benefits of not upgrading
the Cura Application version outweigh this.
2021-04-02 14:03:37 +02:00