On 1 March 2010 21:23, Wayne Stambaugh <stambaughw@...> wrote:
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.
Hi Wayne,
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
proceed.
Wayne
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.
Brian.
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.
------------------------------------
Yahoo! Groups Links
