kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> 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