kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

| 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

My current leanings are:

1) for (part NAME), leave it in the grammar, but change it to NAME_HINT in the documentation, and
describe it as a hint only.


2) Maybe treat the comment text above the (part) element in the sweet string as the description text
for eventual use in a picklist side-car panel.


Dick