| 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



_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to