> The database specifies the path to the symbol to use. There is no broken connection. If you update the underlying symbol, updating a database symbol that uses it will get the updates.
That requires modifying the footprint in the standard footprint library. That's the exact problem I'm pointing out. The workflow, as it is, is flawed: - If you modify the system footprint, then all other designs using that can never update from the library, because of risk of breakage. - If you modify the system footprint, even if only use that footprint in one design, then you can update that schematic from the library, but you can never safely update your system library without breaking a design. - There is no clean way to support two different schematics that use arrange the pins of, say, a microcontroller differently. Any method you choose with the current design loses the ability to update either component, schematic, or library at some level. By providing a way of creating a new library component that inherits all its parameters from another component, but provides its own symbol, then you can tailor each symbol to each of your schematics and all of them will still get parameter updates safely. On Wednesday, July 15, 2026 at 12:27:36 PM UTC-5 [email protected] wrote: > > But it's not clear to me how a user of a read-only httplib/dblib is able > to locally override the symbol without copy/pasting the symbol into the > local project, which breaks the connection to the controlled library, > losing any updates, and resulting in rot. That's the specific issue I'm > trying to address. > > The database specifies the path to the symbol to use. There is no broken > connection. If you update the underlying symbol, updating a database > symbol that uses it will get the updates. > > > In a company or other forma development setting, the parameters are > the critical controlled portion; the symbol may not even be under librarian > control > > That may be your opinion/workflow but I would say it is not common. In > general both the parameters and the symbol graphics are controlled, and > this is the workflow supported by database/http libraries. > > On Wed, Jul 15, 2026 at 12:26 PM Dave F <[email protected]> wrote: > >> Hi Seth, >> >> Thank you so much for taking the time to respond. >> >> I may be missing how the http/dblib does this. Of course the maintainer >> of the lib can select any symbol. But it's not clear to me how a user of a >> read-only httplib/dblib is able to locally override the symbol without >> copy/pasting the symbol into the local project, which breaks the connection >> to the controlled library, losing any updates, and resulting in rot. >> That's the specific issue I'm trying to address. >> >> It's very common to need a slight changeup of a provided symbol, but not >> acceptable to sweep all those local variations back into the controlled >> library. In a company or other forma development setting, the parameters >> are the critical controlled portion; the symbol may not even be under >> librarian control; in the case of a library that uses the standard kicad >> symbols, for example. >> >> For example, My schematic may need the pins of a microcontroller arranged >> to match my own circuit organization. There's no reason to sweep that back >> into the httplib, and unfortunate for me to sever the tie to the httplib to >> get that convenience. >> >> There are cases in which a note goes with the part, not the schematic. >> For example, alternate special mounting method for a common sensor. Yes, >> it can go in the schematic, even though it it would not use the variant >> mechanism there. But for, say, safety devices that can use the sensor in >> one of two configurations. Storing the note and other params with the part >> is less error-prone than requiring the user to add the extra notes in every >> new design. >> >> I agree, 'variant of' is not a great choice. 'derived from' is much >> better, and, in my opinion, much more appropriate to what I am describing >> than to a shared symbol with different parameters. In my opinion, the >> gravity should be on the parameters, not the symbol. I'm trying to think >> of a better option. >> >> Dave >> >> On Wednesday, July 15, 2026 at 10:56:21 AM UTC-5 [email protected] >> wrote: >> >>> Hi Dave- >>> >>> Just some quick feedback. >>> >>> 1) The http/db lib already does this. It is literally one of the >>> features that motivated the dblib development. >>> 2) The term "variant" is already taken. >>> >>> For the applications you list, variants already allow annotation >>> differences for the same part in schematic variants. And symbol body >>> styles largely cover the use case where you want alternate geometry and pin >>> layouts for different circuit functions. >>> >>> Unless I misunderstood your proposal, it sounds like all of your use >>> cases are already covered by existing KiCad functionality. Could you >>> review the current KiCad v10 behavior and let us know if there are specific >>> functionality points that are lacking? >>> >>> Seth >>> >>> >>> >>> Seth Hillbrand >>> *Lead Developer* >>> +1-530-302-5483 <(530)%20302-5483> >>> Long Beach, CA >>> www.kipro-pcb.com [email protected] >>> >>> >>> On Tue, Jul 14, 2026 at 2:14 PM Dave F <[email protected]> wrote: >>> >>>> The library model provides a "derived symbol" that reuses a symbol from >>>> a reference library (like the kicad distributed libs) and allows the user >>>> to modify fields. This works great for a hobbyist workflow where you lay >>>> out a circuit with placeholder symbols, then fill in the values. >>>> >>>> But many users will prefer to work from a curated library of orderable, >>>> BOM-able parts, often in a dblib or an http lib. For these users, the >>>> curated fields are valuable and their immutability is a benefit. But >>>> sometimes a symbols tweak, or even a new symbol, is needed for clean >>>> layout. Kicad has no mechanism for preserving the values but changing out >>>> the symbols and pins. >>>> >>>> It is possible to copy and paste a curated library part and update the >>>> symbol locally, but then the derivative part is subject to rot, stagnating >>>> while the source part can be updated in the library to add new fields, >>>> such >>>> as lifecycle status, etc. >>>> >>>> I propose a "variant of" library feature, which is the inverse of >>>> "derived from". It attaches the immutable fields from a library part to a >>>> user's symbol and pin design. >>>> >>>> This is useful in many applications such as: >>>> >>>> - Arranging microcontroller, fpga, or buffer pins to match the >>>> function of a circuit >>>> - matching a part to the style of an existing design >>>> - breaking a symbols into multiple units (This is often done for >>>> simple analog and logic parts, like amplifiers, buffers, flip-flops, >>>> but >>>> many complex chips may come as a lumped symbol >>>> - Annotating different treatment of the same part in schematic >>>> variants, for automatic inclusion of notes in the BOM >>>> >>>> I'm working on a patch to implement this. The behavior is: >>>> >>>> - The patch adds a 'variant of' selector just below the 'derived >>>> from' checkbox in the new part dialog. >>>> - The new part can have any name >>>> - The new part cannot mutate any of the source part's parameters, >>>> but can add new parameters >>>> - If the variant-of part adds a parameter that conflicts with a >>>> parameter in the source part, the source part parameter wins. >>>> - position of the field text does not count as mutation >>>> - the variant part automatically inherits updates from the source >>>> on loading (if the source is connected) >>>> - A part place in the schematic is never updated automatically. A >>>> schematic part can be updated from the variant in the library just the >>>> same >>>> any other part. >>>> - The variant can have new fields as needed. These are not >>>> affected by update of the inherited fields >>>> >>>> The change does involve a file format change, not only for libraries, >>>> but for schematics, so it's not trivial. But I believe it would be a >>>> valuable addition to version 11. >>>> >>>> I am planning to submit a patch, but would be grateful for feedback. >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "KiCad Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/aa1e18bf-18cf-4542-9dbe-14234e3371cbn%40kicad.org >>>> >>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/aa1e18bf-18cf-4542-9dbe-14234e3371cbn%40kicad.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "KiCad Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/76e89244-704b-42e6-a2ab-7a24982f6510n%40kicad.org >> >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/76e89244-704b-42e6-a2ab-7a24982f6510n%40kicad.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/54556d70-18a6-48be-8196-813ed2435855n%40kicad.org.
