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.
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.
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.
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.
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.
Formerly this probably wasn't translated because it's like a name or term. But now it definitely needs to be translated.
Contributes to issue CURA-8107.
Co-authored-by: Jaime van Kessel <nallath@gmail.com>
It's now documented and written down in human terms. Since it doesn't involve encoding contours as 0-width paths any more, the rendering should also be a bit faster.
Contributes to issue CURA-8107.
The actual package name internally will still have the spaces.
People were using this to get ahead in the sorting of packages, which is a little unfair. This doesn't make that impossible, but prevents it for the most part.
So there is an issue with keyring w.r.t. frozen installs (maybe also local). If you have pywin32 installed, it works fine locally. Take a note here, that a variant of this package, pywin32-ctypes, a rudimentary version of that package that works wholly within python, is already installed as its a dependency for keyring on windows. Due to an unknown reason, when running it fails to detect this, so some workaround is needed, _or_ the 'normal' pywin32 package should be installed. However, problems occurred when attempts where made to install pywin32 via cx_freeze. Then the actual workaround was encountered (https://github.com/jaraco/keyring/issues/468), which _should_ hopefully let use use the keyring on windows without needing the 'full' version of pywin32.
CURA-7180
