brian wrote:I am sorry if what I said isn't clear enough.
nothing to be sorry about, I was not trying to say that what you said is wrong, just that I don't get how a one way propagation of data is related to DRC. For e.g. in Proteus if I want to change what gate I'm using on 74hc14 I have a single click and I will change the gate used. The change will be on pcb and on schematic after that single click. Same with Altium. With KiCAD I have to go back to schematic, reconnect the gate, save netlist, open in cvpcb, check, save netlist, reload netlist back in pcbnew (and hope nothing bad would happen - ok this is irrelevant to this story) and I'm done. You are right, not 15 steps, only 5 and each of them is more then one click - compared to a single click in Proteus/Altium. Ok, that might be a lot of "work" to be implemented in KiCAD.
I *do* agree 100% that this 5 additional steps are worth the few hundred $$ Proteus cost (295GBP for 1000 nodes in netlists limit, 395$ for 2000 nodes in netlists limit, 1225GBP for unlimited everything option so yes, expensive, not unobtainable but very expensive, especially compared to FOSS tool like KiCAD!!). What I *do not* agree is that "this is the proper way to do things".
Nor I understand how this "one way street" helps with DRC. I'm not being "smart ass" here, it is a question I'd like to figure out answer to as there's obviously something I'm looking at wrong here, and I don't agree it's because "it is not working the way I expect it to". Most apps don't think how I expect them to - thing is that I want them to be able to do what I need them to, and then you open the manual and read *how* to do it. Problem I see with KiCAD is that stuff is not doable (where every pro tool make it happen) and then ppl tell me "that's how it supposed to be done" ?!
brian wrote:the people who wrote it aren't crazy.
I had a pleasure of meeting many open source legends because of the work I do and all my colleagues are open source developers, and I can say that I do not know a single open source developer that isn't crazy. I see that as a positive thing as "regular" ppl are boring and never able to achieve anything worth mentioning, and most of them would be insulted on what you just say :D :D :D
I know you don't like it but I get the impression it is mostly because it doesn't work like you expect. If you can afford Altium great, it is a better tool, but most of us cannot.
I can afford it, but I don't want to. I got me a small licence of Proteus as I like it and it's cheaper, Altium is 1000-6000$ compared to 250$ Proteus is starting at (limited to 500 nodes in netlist). I spent already more then 200 hours with kicad trying to use it and I got used to it. Schematic capture is not as nice but works and I can now make a schematic "almost" as fast as with Proteus. Problem starts when you want to go further from schematic...
brian wrote:But there are applications where you might want to mismatch the pin and footprint count.
That is "exception", meaning you need that in under 30% cases. So why not allow filtering by pin count and then add a "hit me with everything" button instead of filtering by name ?! Killing the usability to allow "exceptions" to be covered by basic behavior is never a good idea. Exceptions are called exceptions for reason. But that's another story
brian wrote:The best solution remains explicit filtering.
Why not have filtering on all properties of the footprint, if you can filter by name, why not by pin count too?
Choosing footprints is a nasty part of every cad program. Many have some serious limitations (kicad is not close to what some limit you with). It is a lot of work and we all know how foss apps are made ... I see a huge potential in KiCAD but I also see a lot of, what I see as, misdirection's and fanaticism. As I said - I don't mind the "it's not implemented now, and is not planned for near future as we have more important things to deal with" answer. And I agree 100% that, for e.g. back annotation or filtering footprints by no of pins is far from being priority. What I do not agree with is "filtering by pin count is not how you should assign your footprint because sometimes you want to use part that has different pin count" and stuff like "back annotation is wrong".
You said that this way DRC is preserved. That is something that sounds like an argument that might explain why back annotation is wrong. Cool, but I don't see it. I would like argument explained so I can rethink my position and maybe agree with the assessment I'm presented with.