kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 23 September 2010 01:35, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> On 9/22/2010 10:25 AM, Lorenzo Marcantonio wrote:
>> On Wed, 22 Sep 2010, Dick Hollenbeck wrote:
>>
>>> A) I don't find alias support to be particularly valuable, especially in
>>> the presence of good library browsing capability.
>>
>> I actually like it a lot, since I can skip a rename (i.e. 1N4004 alias
>> for DIODE). Any other kind of indirection, or sharing would be likely
>> useful if aliasing were considered too 'primitive'.
>
> There is nothing preventing you from creating a generic DIODE component.
>  With proper cut and paste, simply copy the DIODE component and paste it
> into a library as 1N4004.  You get the best of both worlds.  The
> advantage of components is that you can define all the relevant fields
> such as footprint to eliminate the need to us CvPCB to assign footprint
> to each component.  You could even create manufacturer specific
> component libraries that include URL's to the data sheets and spice
> models.  You currently cannot do this with aliases.

I am also thinking that alias's could be removed. As above, you can
currently do this copy by opening the generic DIODE component and then
editing it's value.

This means that a library of resistors would not have a common symbol
to edit in order to change all of the component symbols. (I think I
got the terminology correct there!?). However, most libraries that are
heavy and contain derivatives of a common part will be generated by
script anyway. It's very easy to setup a script to do this.

Previously it was a problem (or psuedo problem) that the value +
component name fields were inexplicably tied together, but with the
default fields now available I do not think this is a problem for a
heavy library system anymore. The value can be the component name
(e.g. RES_3K3_1206_1PC, etc.) and another field can be used to hold
the actual value units. The XML intermediate file format for BOM's
makes that much more workable now. So I think that could stay as is.

>>
>>> B) EESCHEMA's library browser needs to be strong.
>>
>> At least for picking a part to edit. Is ridiculous to use the browser
>> and then type the name in the editor.
>>
>>> C) Copying is not sharing.  Sharing is when a single edit affects
>>> multiple parts.  There is not a significant value in "sharing" graphical
>>> symbols between part specific components, particularly if it were
>>> possible to simply copy a graphical symbol through the clipboard.
>>
>> Sharing is useful for consistency IMHO.
>
> Copy and paste minimizes the need for shared components.  Since the
> library files are plain text, global search and replace in your favorite
> text editor can be used to make changes to a library with a lot of
> identical component drawing definitions.
>

The only thing to mention about sharing is that it can have an
advantage, and is the only positive I can think of for aliases. Again
it is due to a heavy library system. Take for example a library of
resistors which perhaps contains one parent symbol which has the
graphical elements of a resistor and a datasheet reference for the
resistor family, and a list of aliases with different values +
manufacturer part numbers.

In the schematic, to change the value of a resistor with such a heavy
library system you need to delete the part, and select another part to
replace it because other meta data like the manufacturers part number
will change with the value. With the aliases, it would be possible to
introduce a substitution rule where changing the value could keep the
part up to date, or warn that the value is unavailable. Without
aliases, changing the value of discrete components like this is going
to be much more cumbersome in heavy library's.

It is likely though that this problem could be overcome in other ways
that do not require the use of aliases. It could for example be a
library flag that is set to indicate that all parts in the library are
interchangeable. Like I say, most of these types of library's will be
generated by script anyway, and not by hand.

Best Regards,

Brian.