On 6/14/2010 5:39 AM, Werner Almesberger wrote: > 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.
I like being able to embed this information into my schematics. By embed I mean create a hidden field so it doesn't clutter my schematic. I can create a complete bill of materials (BOM) for each project. If I am careful, I can create a BOM which can be imported into a inventory control system (or any other program that can import CSV) with minimal effort. I could use an external file and merge this information with a BOM containing the default field information but this is extra work and error prone. Having a template of field names for every project I create guarantees that I have the exact same fields defined for every component. Wayne > > 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
