kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/20/2010 02:29 PM, Wayne Stambaugh wrote:
> On 12/20/2010 1:42 PM, Dick Hollenbeck wrote:
>> On 12/14/2010 04:49 PM, Wayne Stambaugh wrote:
>>> I made some ,inor changes to clarify inherited vs base part and changed
>>> LPID names reflect local naming convention as suggested by Dick.
>>>
>>> Wayne
>>
>> Wayne and others,
>>
>>
>> I coded the initial major portion of DIR_LIB_SOURCE this weekend.  I believe the design is still
>> holding water, so far.
>>
>>
>> The only thing that has come up is this age old issue of content in container, and names.
>>
>> Let me generalize, so you can see it is not specific to this design.
>>
>> Assume you have a C++ file, and you decide to put the name of the file INTO the file as a string.
>>
>> You load that C++ text file, and save it by another name.
>>
>> The file now lives in two *containers*. 
>>
>>
>>
>> 1) The text editor is a container, and it assigns a name to the text file in memory.
>>
>>
>> 2) The filesystem is a container, and it assigns a name to the text file on disk.
>>
>>
>> Each container has its own understanding of the name of the content (i.e. text file).  A
>> disagreement has happened.  And it is not about the name in the editor and the name on disk.
>>
>> It is about the name IN THE FILE, and the name in the editor and on disk.
>>
>>
>>
>>
>> Either of the two examples of "content (text file) within container" would suffice to make my point:
>>
>>
>>     as long as you put the name of the file in the file, there is always
>>     the potential for a disagreement between what the file's container
>>     thinks the content is named, and what the contained name says.
>>
>>
>> Therefore, we might want to re-think our Sweet token that we referred to as "NAME"
>>
>> (part NAME [extends LPID]
>> ..
>> )
>>
>> and either drop it, since the Sweet string will always be in some kind of container, or realize that
>> this is not *really* the name of the part, the container will always chose that.
> I actually considered this when I wrote the specification.  I don't remember
> why I chose to include NAME in the part syntax.  I think it's a great idea.
> Using the file name as the part name makes sense to me.
>
>>
>> A useful comprimize is to conceptually or actually change NAME to SHORT_DESCRIPTION, but if you have
>> a description elsewhere, a short description may not be needed at all.
> A description (short or otherwise) seems like a good candidate for a property.
>  I'm not sure if it should be a reserved property or a user definable property.
>
>> Think about it.  The only time when the container will not name the content, may be on the clipboard.
> Would you even need the name in the clipboard?  If you are pasting into another
> part file, it will take the name of the new part file.  You may need to name
> them when they become components in a schematic but that would be part of the
> schematic file format.
>
>> A fast answer is probably a wrong answer.  I've been thinking about it for a day and still need more
>> time to state the best solution.
> Let me know so I can update the specification.  I have already made the changes
> for providing pin and gate swapping flags to be passed to external tools.  I
> want to keep the specification synced with the code as much as possible to
> avoid confusion.
>
> Wayne

Another idea to consider, along with others until a decision is made, is:

put a comment into the file to act as a 'hint' only.  The hint is only consulted when the part is
outside its container.  Some cases are if you have it on the clipboard or it is printed out on
paper, or it in an email message.  Actually with email it might have a filename as an attachment. 
Ok, say you email it inline.

The hint might look like this, and the hint can be ignored by any tool not interested:

# partname: 7400
# other comments you might have put into the file.
:
(part [extends LPID]
:
)

PART::Format() could output it up at the top as a comment, if requested.


Regarding part "description", it seems like this is worthy of more discussion on its own at some
point.  A useful description block could be:

1) potentially more than one line.
2) shown in a multi-line panel [maybe only] during picklist usage.

I don't see it being like properties, all of which can go into the schematic view, but maybe I have
to just jam it into my head. 

Not urgent.  If I jam it now, something else will have to fall out to make room.

Dick