> That requires modifying the footprint in the standard footprint library
No it doesn't? We were talking about symbols and now you're talking about footprints, but I still don't understand the point you're trying to make. > If you modify the system footprint [...] If you modify a system footprint, period, the correct workflow is to save your modified version into your non-system library (which can be a shared team-managed library) > There is no clean way to support two different schematics that use arrange the pins of, say, a microcontroller differently. The clean way is to create two different schematic symbols. However in my opinion best practice (especially for teams/organizations) would be to not change around the pin layout of symbols on a per-project basis. On Wed, Jul 15, 2026 at 4:39 PM Dave F <[email protected]> wrote: > > > 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/CA%2BqGbCDKqP3AxhAh7HVfj%3D-BMULzK1_EpeYJ0Td1RQ%2BVgCc1hg%40mail.gmail.com.
