← Back to team overview

kicad-developers team mailing list archive

Re: Component library object change proposal.

 

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?

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.


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


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.


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
>   




Follow ups

References