On 8/2/2016 12:56 PM, Andy Peters wrote: > >> 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.
You are correct. A symbol (power or otherwise) is not a component. It is a symbolic representation of a component or anything else that needs to represented that is useful when designing PCBs. Power symbols are useful for ERC. What about net ties? There is no component involved with a net-tie yet it has a footprint that represents the user's desired connection pattern in a PCB. I've seen other EDA products allow for virtual (in BOM but not in netlist) symbols for creating BOMs that include hardware that are not directly part of the PCB. Sure, we could represent each of those objects differently both internally and what we present to the user but they are all so similar in scope that the symbol concept makes sense. If we want to present these "special" symbols to the user as something else, I'm fine with that but I'm not sure how useful that is but internally they can still be represented as symbols. > > 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
