> Agreed. If memory serves, this change requires moving to an S-expression > schematic file format. I should be able to start working on the new schematic > file format in the next week or so. If there is no objection, I will use the > same format as I did for the part file (Sweet) format document. I'll need > your > input on embedding the parts into the schematic to provide access to external > projects when I get to that point. > > Wayne
I am at a loss to name a better format, even though this one (*.odt) comes with the disadvantage that it does not "diff" at all. Docbook or something like it would not be unreasonable, but I don't think it is as easy to work with as OpenOffice/Libre. Ease of working with it trumps lack of diff, by a wide margin. Thanks for your help. There are several tricky parts to the new schematic format: 1) sheets which have been separate, are now combined into one big ass file. To be able to support the sheet instantiation concept, which we have now where the same sheet can be embedded more than once in a schematic, we could need to do something like what is done in verilog, where you have an external interface to a sheet. We need something like describe the external interface of a sheet, and then there are instantiations with specific bindings for each instance. This is not too dissimilar to the new pin signals, which get bound to nets, for each instantiated part. But I think we already have a term for this: pin sheets, or something like that, which are two words that seem backwards to me. In summary, there are sheet declarations, and sheet instantiations. 2) parts list This needs to be up front near the beginning of the schematic file. It needs to be early so we can load it quickly from the PARTS_LIST_LIB_SOURCE class for re-use on other projects. It also needs to have enough fields in it to achieve a spreadsheet UI. This means the properties in here "trump" any properties which may come in as part of the parts which are nested within the parts list. This is because all parts in the parts list have the same properties, and those properties are established by the spreadsheet UI. A spreadsheet row is part, a spreadsheet column is a property. Spreadsheet values at each cell position represent a property on a given part, and this needs to go into the file, bound to the part within the parts_list within the file. 3) components These can supply property text "effects", but not properties per se, other than reference designator, instantiated part name, position/orientation, and stuff. Storing components in the file should be easy. Finding old emails could be helpful also, since this has all been mentioned before in old emails. ------------------------- When it comes to coding, we should be careful not to allow the schematic editor to go beyond the bounds of the public Sweet API. This should be possible to enforce by keeping the sweet stuff as a separate DLL. Again, thanks for your help. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
