kicad-developers team mailing list archive
Mailing list archive
Re: New part file format document.
| 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.
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.