kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/22/2010 9:58 AM, Dick Hollenbeck wrote:
> 
> I'd like to emphasize:
> 
> 1) the need to think this through now, right when we are contemplating a
> new file format, and

Since I already have a preliminary component library file format
document nearly complete, now would be a good time to get as much input
up front as possible to prevent wasting time and effort doing things over.

> 
> 2) we need to define terms early, so we can actually have a conversation
> that can be understood.

I suggest we use the term symbol to reference what we currently refer to
as a component and use component to reference what we currently refer to
as an alias.  I think it more accurately describes the current file
format and certainly anything I would propose for the new file format.
I always felt the term alias was not very clear.  To me 74LS00, 74HCT00,
7400, etc. are components.  I've never used a 74HCT00 alias on a board
before.  I like the term symbol to represent how a component is drawn
including pins, lines, arcs, etc.  Until we agree on terminology, I
suggest we continue to use the terms alias and component as they are
currently defined to avoid confusion.

> 
> 
> -------------
> 
> 
> My opinions, for a program like EESCHEMA in general:
> 
> A) I don't find alias support to be particularly valuable, especially in
> the presence of good library browsing capability. 

Doing away with the concept of aliases would certainly simplify the code
for component library and component object.  The current design of
having multiple aliases referencing a single component makes adding them
to and removing them from the library way more complicated than it
should be.  I also think it would be clearer to the user.

> 
> B) EESCHEMA's library browser needs to be strong.
> 
> 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. 

If we implement proper copy and paste into the component library editor,
supporting shared components becomes much less important.  The down side
is that it will make the file size larger.  Given that the typical hard
drive size for a laptop is 500MB I just don't see that as an issue.

> 
> D) Project specific library support is important, and could be the
> domain where symbols become part specific.
> 
> 
> ----------
> 
> To me, 2) should be our highest priority, and it could almost read like
> a few entries from a dictionary.

I have a few:

symbol - The graphical and/or electrical representation of a component.
 Think everything between DRAW/ENDDRAW in the current file format.

field - The default and user defined text values that describe a
component such as value, reference designator, footprint, etc.

component - The combination of default and user defined fields and a
symbol that get imported into a schematic.

library - One or more components along with some meta-data to describe
the library.

Wayne

> 
> 
> Dick
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>