kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/3/2010 1:47 PM, Dick Hollenbeck wrote:
> 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.

I like the concept.  It would be great if it could be designed with some type
of logical library naming to solve our component look up problem as well.  This
way we get a useful feature like hyperlinking and solve an existing problem
with a single implementation.

Wayne

> 
> 
> 
> 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
> 
> 
> _______________________________________________
> 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
>