Big fan of the schematic and symbol editors, very few notes (beside the app-wide ones)
It's be nice if I could have dragging a symbol change parallel "S" wires to parallel "Z" wires without getting them all jumbled.
Sometimes the symbol editor wants to make me drag things a multiple of the grid instead of to the grid. Like if the grid is 0.5mm and something is at 0.51mm I can drag it to 0.01mm or 1.01mm but not 0mm or 1mm or 0.5mm.
PCB and footprint editors:
Biggest thing is plz stop segfaulting
And doing glitches that are probably the same root as segfaulting. Some complaints might actually be memory corruption bugs causing weird behavior, so...
Dragging multiple footprints isn't algorithmically any different than dragging 1 footprint with multiple pads. Plz make them behave the same.
I have an old thread about trace-moving behavior.
The footprint editor feels like a PITA, but I'm (mostly) not sure how I'd fix that.
The grid is mostly useless because often the mechanical reality of the part doesn't conform to a grid.
I want to be able to put in dimension constraints, like I did for mechanical parts in whatever CAD we used in middle-school shop class. (Related to the grid being useless?)
Have defaults that match the KLC.
Whether I use multiple lines or a polyline, I always feel like I made the wrong choice.
Oh, and I know there's already an open ticket about "you should be able to have footprint libraries as a single file, and symbol libraries as a folder", but +1 to that, symbol libraries as a folder would be great.
(Also, the ".pretty" directory-suffix for footprint libraries is a weird name. ".kicad_fp_lib" would make much more sense.)
A KLC violation that `check_footprint.py` doesn't catch and it seems like would be easy to add is F4.2 "Pin 1 should be located at the top left" https://klc.kicad.org/footprint/f4/f4.2.html
Footprints should be oriented such that Pin 1 is located in the upper left corner (IPC-7351). Exceptions Where footprints cannot be oriented with pin 1 in the top-left quadrant, pin 1 should be aligned to the top Two-terminal footprints should be aligned with pin 1 on the left side Multi-purpose connector footprints should be oriented horizontally, with pin 1 on the left side, for easier comparison and alignment with the matching connector.
I recognize that autorouting is a Hard Problem. But I think for better footprint dragging (both better than what exists, and better than the "just do what the schematic editor does" that I requested) doesn't need to solve the general case of autorouting.
Most of the time when I'm dragging something, I know how I want the traces to move. I don't want the autorouter to solve something for me, I want the link from my brain to KiCad to be higher bandwidth; I've already solved the thing.
1/3
This is a UI problem, not an algo problem.
Many times in my career I've found problems that are NP hard, and people working (maybe including me) very hard on good approximations; using SAT solvers and things. But then I realize that the better solution is to rework the problem to not have to solve NP.
I don't mean "better" as in accepting that we can't solve NP and doing the best we can, I mean "better" in that the end result is actually better than if we solved NP.
I think this is that.
2/3
I'm not sure yet, but I think the UI solution might be a physics-ish "shove". We're pretty used to pushing things around IRL; I think it might be an intuitive way for us to push more intent-information to KiCad.
3/3
Netclass rules in the #KiCad PCB editor apply inconsistently?
Like it'll show that the netclasses I expect are applied "PWR_SH_GND and Default", and PWR_SH_GND sets a "Track Width" to 1.5mm, and yet I see "Width contraints: min 0.1600 mm; opt 0.2000mm (from netclass 'Default')".
So far when I've seen this, also setting min clearance fixes it? But this time it doesn't? So I'm totally at a loss as to where the observed behavior is coming from.
In the #KiCad PCB editor, the direction of angles is different between "rotate" and when using polar coordinates. Rotate angles go counter-clockwise, polar coordinate angles go clockwise (in the Shift-M dialog, anyway).
I suspect this is related to the Y-axis being flipped between the file format (positive is up) and the UI (positive is down, but I think there's a setting to change it).
DSUB connectors exist within a mechanical context that is often just as important as making the PCB pin connections. I argue that the reference point of a DSUB...