kicad-developers team mailing list archive

[Werner Almesberger <werner@xxxxxxxxxxxx>]

Let me see if I got all the bits in your description:

"default" field names:
- are hard-coded (or equivalent) into KiCad,
- can be overridden by "wanted" or "user-defined" field names.

"wanted" aka "template" field names:
- are assigned by a global (user-wide or even site-wide) configuration,
- are also carried in a symbol (.lib file),
- override "default" field names in the sense of, say, F2 not being
  shown when "wanted" field names are defined for F2,
- if a "wanted" name for a field (e.g., F1) appears in both the global
  configuration and the symbol file, both are shown in dialogs.

"user-defined" field names:
- are something we have today,
- are assigned on a per-symbol instance basis,
- are carried in the schematics (.sch file),
- override "wanted" field names.

I think you didn't mention the case of per-symbol field names, which
I suppose would still be around.

A few questions:

- which of the up to two "wanted" field names would a user-defined
  field replace ? Or would it be shown (in dialogs) in addition to
  the "wanted" names ?

- you mentioned visibility (in schematics) options. If the "wanted"
  field names and the user-defined field name disagree on the
  visibility, who wins ?

- would "wanted" fields also be carried in schematics (.sch file),
  much like "user-defined" fields get copied from symbols into their
  instances in schematics ?

- what happens if content with the same purpose gets assigned to
  different fields ? E.g., if a a symbol you import has "manu1" or
  "manufacturer" in F3 while your company uses "manufacturer" in
  F4.

- could one also create a "wanted" field in a symbol (.lib file)
  explicitly for the purpose of export, without having to change
  the local global (duh) configuration ?

  Likewise, could one strip "wanted" fields for export ?

Regarding names, it seems that "wanted" aka "template" would reflect
conventions at the level of an organization. This also highlights
the issues one may have to consider when crossing organization
boundaries.

I'm not so sure having this type of organizational fields in the
schematics is really a good idea. The examples you gave
(manufacturer, vendor (= distributor ?), even cost) are all things
that generally should not be part of schematics.

So, I wonder if this is really going in the right direction. But
maybe I misunderstood the use case ?

Regarding names, if I got the use case right, could something like
"organization-specific" and "component-specific" make the purpose
clearer ?

- Werner