First use of 3.11's StrEnum in the code base I think -- anyway, Python autoboxes these (maybe even the old str,enum things as well, but irrelevant now), so there's nothing in the way of making this an enum and have type-_checking_ instead of type-_o_'s.
done as part of CURA-12624
Otherwise if the server (on the printer) gives back something that can be parsed into JSON, but _isn't_ the authorization digest info, the thing breaks.
part of CURA-12624
New rules means we have to put printjobs and such behind a little authentication, as these contain personally identifiable info. These two effected calls where found _outside_ of the API class where I thought to be able to fix it 100%. See also the TODO's in the neighbourhood -- but I'm not sure I can just do what those say (move the relevant methods to the API), as those methods to be moved are _inside_ the larger Cura SDK (and they're public) and the place where I'm meant to move them to (the ClusterAPIClient) is _not_ (as they're in a plugin).
part of CURA-12624
The new regulations make a decent amount of sense -- but just because we agree with them doesn't mean we'd implemented this yet. Anyway, information wich can be used to personally identify people should be kept behind (virtual) locks and bars. The new firmware will only allow certain operations _after_ a request has been made to the .../auth/request endpoint, and someone in the physical vicinity (of the printer) has pressed ALLOW on a popup (with the application and name of the requester shown, on the printers' UI). After that, _as long as you put the relevant Authorization Digest in your HTTP headers_ (and use at least SHA-256), you may proceed to make other requests without the printer-server flipping out with a FORBIDDEN error.
The current commit _should_ also still work with printers that still have old (well, current I guess...) firmware -- but I didn't test that yet.
CURA-12624
For fixing the paint-splatter issue Iswitched to a new way of drawing the polygon, which could result in missed strokes of pixels at the edge of (UV) polygons. This change should catch most of the remaining X% where that happened.
done as part of CURA-12662
It was using the old (well, relatively speaking ... from the start of development of the current paint-epic) getIntersectRatioViaPt (three times no less), which was massive overkill for what we're trying to accomplish here.
done as part of CURA-12662
Using the camera is more standard, and while it has some downsides ('smearing'/large skews on surfaces angled away from the camera) it seems to have the least quirks (or at least ones that users are used to already). -- Also the what was here previously was just wrong, I'm just saying it could in theory have been solved the way I originally wanted to, but that'd take a long time to get completely right and efficient.
part of CURA-12662
This fixes the issue that it wouldn't flood over the 'rim' whenever the endpoints of a stroke was wholly within one plane, but the stroke itself would overlapp another. Plus also handle click on single point and use transformed mesh consistantly.
part of CURA-12662
Various fixes applied; method of drawing changed a bit (use qpath, otherwise we can't fill, right-size the brush in various ways (w/h of UV-canvas taken into account, fix that 'stroke-coords' are _yet another_ coord system instead of the same as one of the existing) also, with the stroke; fix that it should have been a convex hull of the union, not a convex hull of the intersection -- also take the scale of the model into account (which we need to) (but this has a side-effect in that the brush is now always the same size, regardless of which size the object is -- makes sense, but not 100pct sure if wanted) -- various other things cleaned up etc.
part of CURA-12662
This prevents 'paint splatter', that is, previously, we had just a begin and an end point (actually we had a temp stopgap that iterated per triangle, but similar problems persisted), which we then mapped directly to UV and drew the stroke in that space. This causes the stroke to overlap parts of the UV-map that it didn't touch in 3D at all.
Now, we instead gather each triangle, map that to the estimated stroke plane, intersect the result with the stroke-shape, then map the resulting polygon back to UV-space.
At the moment this code isn't fully working yet -- but I solved all of the obvious things that can be wrong, and it could partially be that I based this branch off of a moment in time the other branch wasn't functionally properly.
part of CURA-12262
CURA-12660
The UV-unwrapping is now done in a background job, and the UI displays a waiting state. This fixes the issue where the user would start painting but the model was not ready yet, and the first stroke would be missing.
CURA-12660
This required a refactoring of the management of the active view. The previous behavior was that anyone could set the active view, depending on certain conditions. But now we also have a view that is set by a tool, so sometimes the actually set view would be incorrect. Now each Stage requests an active view, and each tool CAN also request an active view. Then the Controller decides which view should actually be active depending on the active stage and tool.
- anneal_type -> heating_zone: lines up the variable name with intent.
- Sort the variable inputs of the functions (annealing / drying)
- Add description for parameters in both functions (annealing / drying)
Changed some verbiage.
Update AnnealingOrDrying.py
Changes per the review, bug fixes, cleanup my code. Add more beeps.
Update AnnealingOrDrying.py
Fixed a typo
CURA-12660
The previous method actually doesn't work when Cura is packaged because the plugins paths change. This method is much safer, and uses the actual SolidView instance.
A new script. The user can hold the build plate and chamber temepratures to "anneal" a print. Optionally the heated be can be used to attempt to dry filament rolls.
