My gripes/suggestions/feedback as a #KiCad newb so that I don't forget to turn them into either feature/issue reports or PRs. A thread.
Application-wide:
- I often have trouble seeing the grid ticks. I have not found a setting to adjust their color/contrast.
- The difference between LTR and RTL drag-select wasn't very discoverable. Long after I read it in the manual, I noticed that the cursor changes depending on which way. But I guess that wasn't very noticeable. More visual cues I guess, maybe different highlight color?
I often want two instances of the footprint editor or symbol editor side-by-side, and having to open a while other KiCad instance is clunky.

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.

In the PCB editor it's way too easy to accidentally get off-grid. Snap-to-things-other-than-grid is way too aggressive. I should be able to set how I want a component to align to the grid, and then have it snap that way when I drag it.
Automatic DRC exceptions for trace width and clearance close to footprints where the DRC constraints cannot be met (eg USB differential-pair traces often need to be way thicker than the pads on the USB connector allow, you have to get them thin and close right at the connector).

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.

(note: I've long considered "wizards" to be a UX anti-pattern) The wizards should be regular tools. Instead of a wizard to initialize a footprint with a row of pads with fixed pitch, there should just be a tool for aligning pads and adjusting their pitch.
Oh, back to the schematic editor: It's basically impossible to click on a net-tie; I always have to do a RTL drag to select it.
I didn't notice this with 9.0.3, but with 9.0.4 sometimes my ERC exceptions randomly go away? (And then I just don't stage those few lines in *.kicad_pro changing, and then `git reset` the *.kicad_pro file after I commit)

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.)

In the schematic editor, if I changed text alignment via the "Properties" sidebar, it often does not-what-I-clicked.
It'd be nice if the #KiCad schematic editor supported 'U' to select the rest of a wire, the way it does for traces in the PCB editor.
There are lots of inconsistencies in the #KiCad standard symbol and footprint libraries, including KLC violations, including violations that `check_{symbol,footprint}.py` catch. This isn't a criticism of the library maintainers, it's just a note of a good place to start contributing.

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

#KiCad

F4.2 Pin 1 should be located at the top left

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.

Library Conventions | KiCad EDA
I wish the #KiCad schematic editor's symbol browser had better way of showing which symbols extend others. Like a toggleable tree-view. More than once I've chosen a generic symbol, and later realized that there's a specific symbol for my part; it'd be cool if I could do a tree-view-expand on generic symbols to see symbols that extend it (similar to the multi-part-symbol tree view).
Also, I wish #KiCad had a better way of just having alias symbols without doing an "extends" and duplicating a bunch of metadata. (example in the standard library: "RJ45" is an alias of "8P8C")
Right now you can't `extend` a symbol from a different #KiCad library. It'd be awfully convenient to some workflows if you could. But it could easily break. I guess when you extend a symbol, it should include a copy of the base symbol, the way that schematic files do when you use a symbol?
The #KiCad KLC saying that through-hole footprints should be centered on pin 1 instead of the geometric center like SMD footprints is an annoying inconsistency.
The KLC uses the old names "F.SilkS" and "B.SilkS"; in KiCad 9 they're "F.Silkscreen" and "B.Silkscreen".

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.

If my PCB has groups, "update from schematic" sometimes messes up groups in surprising ways.

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).

In the PCB editor, if I move something by cut/paste, then it is no longer tied to the schematic, and the next time I sync-from-schematic, the parts will vanish and it will ask me to re-place them.
I want a hotkey for breaking traces.
The use of random UUIDs everywhere and the rules for when they are re-generated are annoying for merge-conflict and reproducible-build reasons. I recognize that it's a hard problem and that there might not be a better solution. But it's still annoying.
In the #KiCad "Symbol Fields Table" editor (schematic editor -> "Tools" -> "Edit Symbol Fields..."), the "Filter" text box only filters on the "Reference" column, which is the only column that I have never wanted to filter on.
@lukeshu that is rooted on industry rules.
And most likely won't change in KLC.
I just had the related KLC issue closed today after a few years. You can find more info there.
https://gitlab.com/kicad/libraries/klc/-/issues/26
Origin of THT connector footprints (e.g. DB25) shpuld not be Pin1 (#26) · Issues · KiCad / KiCad Libraries / KiCad Library Conventions · GitLab

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...

GitLab
The inconsistencies of various RJ45/Ethernet jacks in the symbol library are particularly frustrating to me right now.
Wishlist: one file per symbol in eeschema libraries. (lp:#1842206) (#2490) · Issues · KiCad / KiCad Source Code / kicad · GitLab

Original report created by Maxthon Chan (xcvista)

GitLab