kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/08/2010 07:41 AM, Wayne Stambaugh wrote:
> On 10/7/2010 6:26 PM, Dick Hollenbeck wrote:
>   
>>     
>>> (part REFDES is PLID
>>>   (at X Y)
>>>   (rot 0)  # make this optional, defaulting to zero
>>> )
>>>   
>>>       
>>
>> Schematic component instantiation:
>> ---------------------------------
>>
>> I don't know that "part" is best, and there may be a better name.
>>
>> But what I see from this, unless there are holes in the concept, is that
>> there need be *NO location information* in what we have been calling the
>> component, nor any rotation information.
>>
>> That can be introduced in the part C++ PART class for the very first
>> time.  The graphics primitives in the component have their coordinates,
>> but those coordinates are relative to the component's origin, not any
>> thing beyond that.
>>
>>
>> The component is located and rotated [and mirrored] when it is
>> instantiated within a part.
>>     

This class PART is now backwards, see text below.  Class COMPONENT now
points to a PART, and is imply an instantiation of a PART.

>>
>> class PART
>> {
>>     COMPONENT* component        // points into the parts list
>>
>>     POINT pos;
>>
>>     wxString  reference;
>>
>>     int angle;
>> }
>>
>>
>> Something like that.  Maybe also mirroring support at the PART level. 
>> The get bounding box function delegates to the COMPONENT, and offsets
>> and rotates the result of that box to the region on screen.
>>
>> Are part and component properly named?
>>     
> I can't really think of a better one.  Generally speaking, you think in terms
> of adding components to your schematic not parts.  At the user level you should
> use the term component but internally you could differentiate by defining
> components similar to the way we do now which is LIB_COMPONENT ( your
> COMPONENT) and SCH_COMPONENT ( your PART ).  But I'm not sure this is any better.
>
> Wayne
>   


Well as you may have seen, I started down the path of PART for what
lives in the LIBRARY or PARTS_LIST, and COMPONENT for what lives in the
schematic.  I think this is consistent with the generic XML export, but
perhaps a swap from what has been discussed on this list recently.  (But
after all, how can you not put a PART in a PARTS_LIST?)

My next commit will have quite a bit more in it, class PARTS_LIST, class
COMPONENT (mostly as a place holder for you) along with an architecture
diagram, and doxygen docs. 

The PARTS_LIST is a difficult concept to grasp from words alone,
especially the difference between its role within its containing
schematic, vs. its role for another schematic.
The diagram and text in my next commit will clarify this, and be spit
out as a cohesive Doxygen *.html file set.

There should be enough at that point to mostly capture the ideas, and to
start coding.  I keep hammering on the idea that with the new design,
libraries can actually read only entities.  Why share something that is
not re-usable as is?   This is a departure from the way some folks are
currently thinking, no doubt.  But the PARTS_LIST comes to the rescue as
the modification arena.

Dick