← Back to team overview

kicad-developers team mailing list archive

Re: Default Field names patch

 

On 06/14/2010 04:39 AM, Werner Almesberger wrote:

Werner,

You have good reading comprehension.  I make only a few clarifications
below.

> 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:
>   

"template" aka "wanted", not "wanted" aka "template".  The distinction
is important since I have started coding it, and the source reflects the
latter term.

> - 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,
>   
first available slot for a template fieldname is F4, but you realize
this F nomenclature is a relic of the file format, the user never sees
this F4, F5, .. stuff.
> - 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.
>   
Template fieldnames can be assigned to F4 and higher.  And I think all
fieldnames must be unique, so the two property editors must enforce this
by showing Template fieldnames when they don't already exist in the
component/symbol.
> "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.
>   

User defined fieldnames may be present in any symbol/component that is
resident in either schematic or library, and start at F4.  Template
fieldnames are merely used in the 2 property dialogs, and if a non-blank
field is entered, then such template fieldname becomes a user defined
fieldname and is saved into the symbol.
> 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 ?
>   
The quantity of template fieldnames should not be limited, and therefore
"2" is not the limit.
> - you mentioned visibility (in schematics) options. If the "wanted"
>   field names and the user-defined field name disagree on the
>   visibility, who wins ?
>   
User defined.  That is an instance specific override.
> - would "wanted" fields also be carried in schematics (.sch file),
>   much like "user-defined" fields get copied from symbols into their
>   instances in schematics ?
>   
Anytime a field is entered into a property editor and the name shown for
that field is not a default name, then in such case the fieldname must
also be recorded into the symbol (either in the library or in the
schematic, according to which editor is invoked), and such fieldname is
thereafter considered a user defined fieldname according to the
definitions we have gravitated to here.

> - 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.
>   

All user defined fieldnames are retained until you delete them from the
containing symbol.

> - 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 ?
>   

A template fieldname is shown in the property dialogs only.  Thereafter,
should you enter a non-blank value, that same name is recorded with the
value into the symbol and saved off into the symbol, at which point I
think we are then calling it a user defined fieldname (that has the same
name as the template fieldname, because the template fieldname was
"copied" and made into a user defined fieldname).


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

You can strip user-defined fieldnames using an external text processing
engine like SED.  This may be material for a future Feature Request, but
I will not be coding it as part of this work scope.


> 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.
>   

Yes, along with starting time and dress code.

> 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.
>   

Then you can leave your template empty.

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

That's OK, you do not have to use it.  It is worth it to me to add it,
and I have made a commitment to Brian to make his investment fruitful.

Dick


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




Follow ups

References