kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

Le 13/09/2010 22:16, Wayne Stambaugh a écrit :
....

> I'ld rather not get off topic but I think I may have found one as I have
> wrestled with a problem for several weeks and with at least two false starts.
> The problem stems from the current design of CMP_LIBRARY and it's ownership of
> LIB_ALIAS and LIB_COMPONENT objects and the interdependency between them.  My
> original attempt was to make CMP_LIBRARY own LIB_COMPONENT objects and
> LIB_COMPONENT own it's associated LIB_ALIAS objects.  This made both searching,
> indexing, and modifying the library and editing components much more complex
> than the current design so I abandoned it as one of my goals was to simplify
> the current design.  I finally decided that CMP_LIBRARY should only own
> LIB_ALIAS objects.  I created an addition LIB_ALIAS object for the root
> LIB_COMPONENT(more on this below).  I added a boost::shared_ptr for the
> LIB_COMPONENT pointer in each LIB_ALIAS that references it and I added code in
> the LIB_ALIAS destructor to keep the LIB_COMPONENT name up to date.  When the
> last LIB_ALIAS that references the shared LIB_COMPONENT is deleted, the
> LIB_COMPONENT object goes out of scope and is automatically deleted.  This
> makes sense to me as LIB_ALIAS objects no meaning without an associated
> LIB_COMPONENT.  It also made the code for updating the CMP_LIBRARY object very
> simple.  Access to the underlying LIB_COMPONENT object is always done though
> LIB_ALIAS::GetComponent().  I know your thinking why create an alias with the
> same name as the component?  This change will allow for future expansion, if we
> want to support custom fields in aliases for the so called heavy weight
> libraries (if I am correctly understanding what the library development folks
> are requesting).  This will probably make more sense when I submit the
> blueprint for the new component library file format which should be in the next
> week or so.  Except for the additional boost header files, the changes to the
> current BZR version are pretty minimal in keeping with my preference to making
> small incremental changes to the existing code.  I could submit a patch or
> publish my branch if you would like to take a look at it.  If you have any
> suggestions that can improve this design, I would be more than happy take a
> look at it.
>
> Wayne

Here is just an idea:
Because handle aliases is tricky, remove them.

I believe the library could handle only 2 kind of items in memory:
- A LIB_COMPONENT (currently like a LIB_ALIAS: having its name, fields, key words, doc) but no graphic info
_ A lIB_SHAPE (currently the graphic items section of a LIB_COMPONENT) having a shape_name
	 and handling all graphic data (body and pins, number of parts per package)
	 but no fields, key words, doc ..  which are only in a LIB_COMPONENT
         lIB_SHAPE have no link to LIB_COMPONENT, just their name that appear in some LIB_COMPONENT.

The complexity of the current code is due to the link between a root component
(which can be see as LIB_COMPONENT plus a lIB_SHAPE) and aliases, which is removed here.

Each component could have a link to a LIB_SHAPE.
Mainly the name of the LIB_SHAPE, and a pointer on it just to quickly draw the component.
(Could be NULL, and initialized only on request, the first time it is used)
When created a new LIB_COMPONENT the corresponding LIB_SHAPE name could have the name of the new component.
Adding an ALIAS is just creating a new component sharing the loaded shape.
Removing an ALIAS is just deleting a component (not the shape).

In libedit, creating the list of alias in just collect LIB_COMPONENT items sharing the same shape.
(a simple linear sweep of the library), and load the shared shape in the editor.
Removing an ALIAS is easy because there is no dependence between components, and saving a list is not tricky.
(components have no dependency)

A special case is removing the component having the same name as the shape ( the first created component )
Just find the next component sharing the shape, and rename the shape with its name,
and update all components sharing this shape.
But this is also a very simple linear sweep.

A shape will be deleted only if there is no component "pointing" this shape.
(After deleting a component, the linear sweep of the library can easily handle this)

I believe this is not a lot of changes inside the Eeschema code and a lot of tricky code could be removed.


--
Jean-Pierre CHARRAS