| 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