Bug Reports

I've worked with @Mihir to understand the issues with the calculateTraceWidth() function that appears to now be deployed by default on all traces. I've added a rule of net[current] and while that has stopped exploding traces, there are still issues occuring where I drag from one component pin, use the W key to step to max trace width and then when I drag the trace and click to stop it and then continue the trace, the next part of the trace immediately returns back to the smallest size trace. I hope the attached images shows this clearly where Net 58 is now effected and we can see that calculateTraceWidth is being used to determine the width. I got to be honest, my layout has 3 traces widths set and my preference is that these are respected in terms of max trace width.

If you set the same asset to 3 pads with Scale 0.01, 0.02 and 0.03 Then you will get pads with sizes: 3.7mm, 15mm and 33.7mm https://www.loom.com/share/7889cdc173fa4cc59457fb2403dcae20?sid=17203b08-4a01-4f2a-afc5-0810dbbab6c7

The rendering of the menu images cover each other. It would be nice to fix this overlap in windows. Also could we make it available to collapse the left hand side copilot bar maybe a hamburger button?

I got a UID error while trying autolayout

error logs windows overlapping with no option to move

In one project this appears to work ok, but in the one attached, selecting a trace and changing the layer results in the trace being disconnected and transformed (either rotated or translated to a new location).

Entering the custom Stackup edit dialog to change the name of a layer results in all traces previously tied to the layer to be removed. The expectation is that the traces would simple change their assigned layer names and remain in place.

With every element-touch saving in place, when a save duration takes several seconds, element selection has no effect - which can lead to accidentally moving the last selected element. With the short saves and the same issue occurring, this can make the UX very stuttered and really jarring. Specifically with selection and transforms, you may need to implement a buffer and look for idle to update the save cache of element locations.

In PCB view, rotating components using the hotkeys [ ] has some components transforming enormous jumps, sometimes into blocks of other components making it really challenging to work zoomed right in. Perhaps a matrix rotation error somewhere - my preference is for the rotation to occur at centre origin of bounding box.