The new version of KiCAD is a fact.

[Monkeh]

So the guy proclaiming the release can't or won't do a front page post about it, can't or won't tag the repos, and doesn't know how to get the documentation organised?

Profoundly dysfunctional development.

It's an open-source project.  If there is an area that you think needs attention, why don't you roll up your sleeves, and join the project to "fix" the things that you think need to be fixed?  I'm sure that they could use the help from an expert such as yourself.

Uh, right, that's totally how it works.

[janoc]

Uh, right, that's totally how it works.

That's exactly how it works. Unless you are willing to pay someone to do it, of course. Criticizing something but then expecting someone else to do the work so that you can benefit from it for free sounds somehow fair to you?

Pouring non-constructive dismissive scorn on a volunteer run project with zero budget because someone doesn't do things to your standards is making only you look bad, not the project, I am afraid. Why are you even bothering to comment on a project you don't like and don't use? Enjoying trolling much?

FYI, I have built the current Kicad yesterday here and it works just fine, thank you very much. Far cry from "dysfunctional development", IMO.

[Monkeh]

Uh, right, that's totally how it works.

That's exactly how it works. Unless you are willing to pay someone to do it, of course. Criticizing something but then expecting someone else to do the work so that you can benefit from it for free sounds somehow fair to you?

Let me just walk right in and take over. It works that way, totally.

And no, I'm not expecting anyone else to do anything for my benefit.

Pouring non-constructive dismissive scorn on a volunteer run project with zero budget because someone doesn't do things to your standards is making only you look bad, not the project, I am afraid. Why are you even bothering to comment on a project you don't like and don't use? Enjoying trolling much?

Pouring? That tiny little drop? I made an admittedly unnecessarily harsh comment out of surprise at how they handled a release. I will now pay for it for the rest of my life, because I am truly evil.

I actually have great hope for KiCAD, every other option has severely disappointed me with no sign of improvement. KiCAD might get somewhere. Last time I tried it, it wasn't there, but it was on the move at least.

[bson]

I mean KiCAD assigns symbol "pin 1" to footprint "pin 1".  Other packages allow you to link symbol "pin1" to footprint "pin2", or if you have multiple footprints (say DIP and QFN), allows you to assign symbol "pin 1" to DIP footprint "pin 1" but symbol "pin 1" to QFN footprint "pin 2", without changing the names, so the associations change within the library not within the project.

I think this is how things are done simply because it's how things are done historically.  But in reality, the only mapping between pin function and pin number is in the footprint.  There is no reason to propagate the pin number past this; there is no reason to have pin numbers on the schematic whatsoever.   The schematic should be a logical/functional description, not a physical one.  I should be connecting pin A0 to ground in the schematic, and it shouldn't matter one iota what pin it's on in the package as far as the schematic is concerned.  The parts then should be grouped into functionally equivalent families.  As an example, a "hex inverter" can be a family from which you pick a logic family and package to suit your needs.  The logic family is picked in the schematic (because it has an immediate functional impact), the packaging in the layout (because it's a physical consideration).  If the packaging matters functionally, then it's picked in schematic and the layout gets locked to that one.  At least that's how I think it should work.  IMO.  Yours may differ.

[nctnico]

I mean KiCAD assigns symbol "pin 1" to footprint "pin 1".  Other packages allow you to link symbol "pin1" to footprint "pin2", or if you have multiple footprints (say DIP and QFN), allows you to assign symbol "pin 1" to DIP footprint "pin 1" but symbol "pin 1" to QFN footprint "pin 2", without changing the names, so the associations change within the library not within the project.

I think this is how things are done simply because it's how things are done historically.  But in reality, the only mapping between pin function and pin number is in the footprint.  There is no reason to propagate the pin number past this; there is no reason to have pin numbers on the schematic whatsoever.   The schematic should be a logical/functional description, not a physical one.  I should be connecting pin A0 to ground in the schematic, and it shouldn't matter one iota what pin it's on in the package as far as the schematic is concerned.  The parts then should be grouped into functionally equivalent families.

You can debate this in lengths but for fault finding, debugging and repair it just is easier to represent a part like it is in the package. It makes it unnecessary to look at the outline of a package to figure out where a pin is. In many cases seeing where ground/power pins are make it easy to find a certain pin on large packages. In general this works best for packages with 2 rows of pins (like SOIC) or square packages (like TQFP).

[Wilksey]

I think it depends on the component, I find it extremely useful for example, when assembling a board to see which pin a particular function of a transistor is on, I can tell pin 1 from the package itself, but not necessarily which one is the "collector" unless I look up the datasheet, if the pin numbering is on the schematic, which I usually have in front of me, not the layout artwork, I can use it as a quick reference.

Works for me!