kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Brian Sidebotham wrote:
> Hi,
> 
> 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.

Brian,

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

Wayne

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