We can't change this index to an integer, because varying variables can't be integer, even though this variable will only really be tested on vertex level. Not sure if varying was the right choice, but I don't want to change that.
This prevents a crash, probably only occurring on certain GPUs.
Contributes to issue CURA-8657.
Polygons don't change when in layer-view. There's already an analogous elementCount property anyway, so a vertexCount property can't do much harm. Just keep in mind that when the polygons are altered, it should be either done via build, or the lineMeshXXXCount methods should be used instead.
Instead of re-uploading the mesh each time the range changes, handle the range in the shaders with the new draw-range parameters. This does however, mean the range has to be in vertices, not in elements. This necessitates some changes to the simulation-view, and some added bits deeper in the base code. Mainly, since each time the type of a line changes, there is an extra vertex, there needs to be a type-change count available to get from 'paths' to range indices.
- Remove unused imports of xlink.
- Remove comments about which application originally wrote the text file. It's untrue because PyCharm edited it, etc.
- Remove unused IDs.
- Remove unused colours for icons rendered with RecolorImage.
- Remove useless x and y positions on 0, which is the default.
- Remove useless style setting the background to transparent.
- Remove useless whitespace in the path d attribute, and remove the then-useless XML space preserving attribute.
- Remove unused groups.
- Remove unused CSS classes.
Contributes to issue CURA-8342.
We created a new set of icons for Cura. These icons had to be reverted though because they weren't working out in the interface for the last release yet.
This unreverts them, basically adding them back hoping that we'll get them fixed in time for the next release.
Contributes to issue CURA-8342.
Revert "Revert "Fix merge conflict""
This reverts commit bb20e3307f43edc1ff53cb154d2351ddfe39e158.
Revert "Revert "Merge pull request #9716 from Ultimaker/CURA-8010_new_icons""
This reverts commit 70e4e9640e561e18a12870f30c905203ce8ccee7.
Revert "Revert "Fix typo in icon name""
This reverts commit 38ce22ba7c3f40b971bc6e1e0a8e776ca9d51512.
Revert "Revert "Add list for deprecated icons""
This reverts commit 119a957e7f978dbf1ddbcb3b0005bf38e8fed943.
Revert "Revert "Add Function icon""
This reverts commit 760726cf0bb953bb1b0fc277b448f419d4bd2544.
Revert "Revert "Switch out inherit icon""
This reverts commit 26afff609381e2004d194c280f504b6226859bd3.
Revert "Revert "Merge branch 'CURA-8205_Introduce_new_icons_in_Cura' of github.com:Ultimaker/Cura""
This reverts commit 6483db3d47ee052c1a966cdee3af7190577a5769.
Revert "Fix incorrect icons"
This reverts commit 02a4ade2a50a943ff36fd4895bdc9261cf2133eb.
We want to keep it this way so people can still make plugins work for older versions of Cura, like 3.6, where the 'api' field with just a single major version, instead of the 'supported_sdk_versions', which can be either a version-string like '7.6.0' or a list of version strings.
The max value was being calculated as the product of the max line width, max layer thickness
and max feedrate but it should be calculated as the maximum of the products of the width,
thickness and feedrate for each individual line. i.e. calculate the flow for each line
and use the min and max values of the flows.
Previously the icons were organized according to "size" which could prove to be confusing.
This commit fixes that by organizing them according to "detail_level".
CURA-8010
Subdivided the new icons in 3 size categories. As requested by UX
Used the company naming scheme for uniformity and easy recognition.
Known issues:
- Top/Bottom category wasn't taken into account by UX at the time. Since
this is a recent addition. Both the Walls and Top/Bottom will be updated.
- Cloud/Network connection icons 12px don't render correctly. Due to the
theme-ing.
- Extruder Icons do not render correctly.
CURA-8010_new_icons
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.
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).
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.
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.
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.
