Sadly I'm not in a position to donate code but I would donate some cash. Is there some place to do that online?
I know everyone thinks "their bug" is the most important, but in this case I'm right... really! :) I am serious about the suggestion to put these proposed features in front of some working EEs, people who do layout for a living, and ask them to help you rank the priorities. I realize no one who does this professionally is going to switch from Altium [yet], but I think you might be surprised what floats to the top in such an exercise.
The push-and-shove stuff is awesome, and is going to save a LOT of time in layout, but in my experience (using a build from last year), the via issue is more than just a time waster. If I knew I could get the result I want, by spending 10x or 100x of the time it would take in another layout package, this would not be such a problem. But when I tried to string the vias along a track as suggested, pcbnew would delete old vias somewhat unpredictably whenever I tried to move things around later. It also would not allow adjacent vias to touch, which is another show-stopper. (E.g., often when placing your array of grounding vias under a QFN package, they will need to touch in order to satisfy the PCB house design rules and still have enough vias.) For my next project I will need to use some vias in an LVDS diff pair, and I am guessing the code will insist on having the vias centered on the traces, which will not allow me to get the impedance matched correctly. These are just a few of the problems, off the top of my head. I have pretty much accepted the fact that the boards I create with KiCAD will be electrically inferior.
Basically, until vias are treated as first-class objects which can exist independently of any net, this is going to be a problem. IMO it is one of the few things gEDA got right, i.e. they take it as a given that the vias, and all copper generally, will stay wherever the user placed them; then, they run a connection engine to figure out which nets are actually connected to one another, and whether or not this matches the netlist. There may be a better way to do it, but it needs to allow equivalent flexibility w.r.t. via and copper polygon placement.
I am still curious if the footprint-as-via technique, mentioned above by Mansour, will let you cover the whole thing with soldermask. That might be the best workaround in the short term.
Thanks Orson,
Sadly I'm not in a position to donate code but I would donate some cash. Is there some place to do that online?
I know everyone thinks "their bug" is the most important, but in this case I'm right... really! :) I am serious about the suggestion to put these proposed features in front of some working EEs, people who do layout for a living, and ask them to help you rank the priorities. I realize no one who does this professionally is going to switch from Altium [yet], but I think you might be surprised what floats to the top in such an exercise.
The push-and-shove stuff is awesome, and is going to save a LOT of time in layout, but in my experience (using a build from last year), the via issue is more than just a time waster. If I knew I could get the result I want, by spending 10x or 100x of the time it would take in another layout package, this would not be such a problem. But when I tried to string the vias along a track as suggested, pcbnew would delete old vias somewhat unpredictably whenever I tried to move things around later. It also would not allow adjacent vias to touch, which is another show-stopper. (E.g., often when placing your array of grounding vias under a QFN package, they will need to touch in order to satisfy the PCB house design rules and still have enough vias.) For my next project I will need to use some vias in an LVDS diff pair, and I am guessing the code will insist on having the vias centered on the traces, which will not allow me to get the impedance matched correctly. These are just a few of the problems, off the top of my head. I have pretty much accepted the fact that the boards I create with KiCAD will be electrically inferior.
Basically, until vias are treated as first-class objects which can exist independently of any net, this is going to be a problem. IMO it is one of the few things gEDA got right, i.e. they take it as a given that the vias, and all copper generally, will stay wherever the user placed them; then, they run a connection engine to figure out which nets are actually connected to one another, and whether or not this matches the netlist. There may be a better way to do it, but it needs to allow equivalent flexibility w.r.t. via and copper polygon placement.
I am still curious if the footprint-as-via technique, mentioned above by Mansour, will let you cover the whole thing with soldermask. That might be the best workaround in the short term.