kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/24/2010 3:44 PM, Dick Hollenbeck wrote:
> On 06/24/2010 02:19 PM, Wayne Stambaugh wrote:
>> In preparation for the forth coming changes to the component library
>> file format, I would like to make some changes in the design of the
>> component library object format and the component library editor behavior.
>>
>> The current component library design creates aliases as a stand alone
>> objects that reference the actual component object.  The component
>> object also keeps a copy of the alias information (strings) in a
>> wxStringArray. 
> 
> 
>>  It seems to me that an alias has no meaning without the
>> associated component and keeping a copy of the alias data in the
>> component object is redundant.  I propose that the component object
>> maintain the list of it's alias objects and only components are added to
>> the library object.  
> 
> The above 2 sentences seem to contradict each other.  Can we assume that
> last one is what you intended?

Oops!  You are correct it is the last one.

> 
> If so, you will need a fancy iterator interface on the library object to
> bring out these aliases as full fledged components for calling code,
> no?  Otherwise aliases get a demotion in the grand scheme of EESCHEMA.

I don't know how fancy it will need to be.  The only thing I know that
aliases are used for in EESchema is listing and searching for
components.  Searching components list of aliases would not be any more
complex than searching the library for an alias.

> 
> 
>> This should greatly simplify the design of both the
>> library component and library classes.
>>
>> The current component object design is also reflected in the behavior of
>> the library editor.  As it now stands, the library editor does not
>> delete a component that has aliases.  It renames the component to the
>> first alias that references it and removes the alias from the library.
>> In order to actually delete a component from a library, all it's aliases
>> must be deleted first.  I propose changing the library editor to
>> actually delete the component and all it's aliases when clicking the
>> delete component button and use the component properties dialog for
>> adding, removing, and editing aliases.
>>   
> 
> This is a large demotion for aliases.  Whoever coded the original UI
> behavior (Jean-Pierre?) might be expected to voice some concern over
> this.  Aliases suddenly become less than full fledged components from a
> UI perspective.  I am not sure what the purpose of an alias is, if not
> to be available at the UI for use as an equivalent to a component. 
> Maybe you can make up for this some other way...

Aliases aren't really full fledged components in the current design.  In
other words, there is no drawable object (pins, rectangles, arcs,
fields, etc.) information in an alias.  Aliases are simply some
description strings and a pointer to a component.  Moving the aliases
into the associated component means that component libraries will only
contain components not components and aliases.  From a users point of
view, there will be no difference in the alias and component
information.  Only the internal representation will change.  I'll
certainly wait for JP to comment.

> 
> 
> Please get this stewing also:
> 
> I think we should also eventually kill off the notion of a library
> search path, and implement Lorenzo's idea about
> 
>     <logical library>.<component_name>
> 
> when we store things in the schematic.
> 
> https://bugs.launchpad.net/kicad/+bug/575810/comments/11
> 
> I don't like to feel like I have to win the lottery to have eeshema find
> the component I put in my schematic.  Two times in the last 2 years, I
> have pulled up my schematics and had my components mysteriously changed
> right out from underneath me.  Bug 575810 is real, but could be dealt
> with at a later point in time, or now if it saves writing yet another
> conversion program later.

I've been bit by this one as well.  I already have this documented in
the new component library file format document I've been working on.
Hopefully I'll finish up this document in another week or so.
Initially, this will not be of any use with the current schematic file
format.  I was planning on fixing it when the schematic file format is
moved to the DSN lexer.

Wayne

> 
> 
> Dick
> 
> 
> 
>> If no one has any objections, I would like to make these changes before
>> beginning work on the new file format to make sure the current file
>> format information is preserved.  Once these changes are committed and
>> there doesn't appear to be any issues using the current file format,
>> I'll submit a blueprint with an initial DSN file format proposal so we
>> can hash out the details.
>>
>> Wayne
>>   
> 
> 
> _______________________________________________
> 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
>