kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/01/2010 03:42 PM, Wayne Stambaugh wrote:
> Since the discussion has died down on the library structure.  Here is a recap
> of the discussion.
>
> 1) The current concept of component will be replaced by symbol which is the
> graphical representation of a component.
>
> 2) The current concept of aliases will be replaced by component which will
> contain it's own fields but can share a symbol with other components to save
> memory.
>
> 3) Symbols may be shared among all components within a library definition.  In
> other words, symbols will not be shared across libraries.
>
> 4) Merge the separate document file (.dcm) information into the new library
> file format.
>
> 5) Drop support for creating components with alternate body styles (DeMorgan).
>   


I had some ideas about hyperlinks.  This would be the ability to jump to
another component, while viewing a first component, from within the
library viewer based on a "hyperlink".  Hyperlink usages:

1) a "see also" type of link
2) ability to bind DeMorgan alternates into the current component even
through they might exist in an entirely different library or different
component in same library.


The hyperlink is a familiar concept from the web browser, and I have
some fairly well developed ideas on how to structure the hyperlinks
themselves if and when they are needed.  Suffice it to say that in my
concept of them they can jump into another library or into the same library.



Also, I think we need to remember that most folks do not modify the
"standard libraries", but rather only:

a) the "personal libraries", and hopefully in the future
b) the "project specific" library, i.e. the schematic specific "parts list".


This is an important thing to remember, because it reduces the
importance of certain wish list items.

For example, since I cannot edit the standard libraries, why is it
important that an edit in the symbol there change all my components?  I
cannot edit the standard library symbol, so it is moot.

I have to control the symbol, take responsibility for its form by
copying it into a) or b), then I can edit it.  The scope of a symbol's
affect on components outside of one library is a discussion point. 


In a classical use case, I might have one personal library, and as many
parts list libraries as I have unique projects.  This is what I would
foresee being my usages habits.  One personal library, and multiple
parts list libraries.  So in my particular case, the ability of a symbol
to effect the presentation of components in more than one library is not
at all important.  (Excuse me for being judgmental so early in what is
basically still brainstorming.)


Dick