kicad-developers team mailing list archive
Mailing list archive
Re: Eeschema Default Library Field Names
Brian Sidebotham <brian.sidebotham@...>
Mon, 1 Mar 2010 22:17:13 +0000
On 1 March 2010 21:23, Wayne Stambaugh <stambaughw@...> wrote:
> Brian Sidebotham wrote:
>> I have been looking at doing a patch to allow a list of default field
>> names to be defined for eeschema's libedit.
>> Problem: When creating new components with additional information,
>> such as ordering codes and manufacturer part numbers, etc. you will
>> currently need to edit the field names yourself for every component.
>> This can quickly become tiresome.
>> You could start with a blank part that has been saved to a library
>> with the field names defined, but this means that you cannot use the
>> New Component mechanism in libedit to create a new component.
>> Proposal 1: Would be for me to do a couple of patches to eeschema to
>> add this support to the project file structure:
>> (a) Add Default Field Name support in the project file (e.g.
>> DefFieldName0=Manufacturer, etc.)
>> (b) Add Editing of the default field names in the GUI.
> I like proposal 1 personally because that is how I work. It would be
> nice if your default field name editor was capable of applying the
> changes to existing components in a schematic as well as any new
> components. Even better would be a simple grid editor with fields as
> columns and components as rows so that you could populate your user
> defined fields in mass instead of one component at a time. I'm just
> throwing these ideas out to get people thinking about it.
Thanks for the quick response. The default field names will be applied
to old and new components via the field edit dialog that Dick has
already written. This is used when you [E]dit a component in the
schematic, and when you are creating a new component.
At the moment, this dialog sets the default field names by simply
making a string out of Field and the field number (N) as a suffix.
I propose that instead, a list of default names is created as a
project preference and read much like the library name list. If there
is no custom default name, we can still drop back to the standard
default of FieldN.
The grid based editor as you suggest would be a great, that would make
stuffing these fields with values a lot less tedious. Handy when a
part number field depends on the components value, etc.
This is actually a bit of a pre-cursor to me wanting to add heavy
symbol support into KiCad, which also really requires aliases to be
improved too. I think Jean-Pierre has been doing some work in this
area, trying to get rid of the .mdc library files.
> The problem
> with making changes like this is that what works for me doesn't
> necessarily work for others. You made right decision asking the group
> for input. If no one screams too loudly, take that as permission to
Yes I appreciate people don't always think alike. Best to get some
opinions now before I start prepping a patch. Perhaps some of the
guy's looking into the new library have some opinions. Thanks.
>> Proposal 2: Would be to use a default .sym (single component) file,
>> much like the standard kicad.pro file that is distributed with KiCad
>> for the default project settings. This would allow someone to edit any
>> of the component attributes, and would be more in keeping with how
>> KiCad currently handles it's default values.
>> Does anyone have any preferences, or other ideas?
>> I think that proposal 2 is probably better for the project as it
>> offers more potential functionality without the need to repeat a lot
>> of these settings in the kicad.pro template file. Any changes to the
>> symbol structure will also be immediately reflected in this file
>> without the need to add more handlers to the project file structure.
>> Best Regards,