> On Aug 2, 2016, at 8:30 AM, Chris Pavlina <[email protected]> wrote: > > Moving this to a new thread. > >> On 8/2/2016 7:16 AM, Chris Pavlina wrote: >>> My implementation had a large number of symbols, would have allowed >>> user-supplied arbitrary symbols if I had finished it, and automatically >>> selected a symbol based on net name _exactly_ as Clemens suggested. All >>> of these issues are solved. >> >> How difficult would it be to apply the same selection criteria for power >> symbols? The more you explain what you have done with power label the >> more it seems like you could have done the same thing with power >> symbols. This would save implementing a new object and the file >> formatting to support it. Maybe I'm missing something here but I just >> don't see how a new label type that looks like a power symbol is >> different from a power symbol that already provides the same functionality. > > It provides the same functionality. I just think it's more consistent > from the user's perspective - see my comment earlier about them /being/ > labels, functionally speaking - and not that much more trouble to > implement.
One user’s perspective (mine). A power symbol is NOT a component. It doesn’t have a footprint, it doesn’t go on the BOM. So it should not be in a component (symbol) library. It really is (or at least should be) nothing more than a specialized global net label. -a _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
