kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> All in all it seems like a very sound concept.  It will be interesting
> to see how it works in practice.
>
> Wayne
>   

Wayne,

You could zero in on the grammar for the component, and symbol if you
still want that property-less grammar element.  A symbol element/token
could exist if you really want it, and it can control the grammar (which
would say explicitly exclude properties) but still parse down to a
COMPONENT in C++ terms, with an empty property table.

Also, after having just done that example in my previous posting, I see
that the number of child elements for a property are quite involved.
Possible simplification: optional most common defaults which need not be
supplied?



We really have to keep the notion of "this is source code and it needs
to be very human readable" in mind.


I could be working on the *.h file while you get the component grammar
done and parsing. 


Formatting, the reverse of Parsing
----------------------------------

What is interesting about this design is that to "format" the COMPONENT
to sexpr, you simply have to output the already existing sexpr.  I can
think of no case where the sexpr does not already exist, because in
every case the component was generated by parsing from the sexpr.

The only thing to think about there is beatification and indentation. 
We could have the object specific parser like we discussed, and we could
also have a generic parser that build a token tree kind of like the
XNODEs and then simply uses the XNODE save function to "beautify" the
token tree back into string form. 

We never have to generate the sexpr from the binary component object's
graphic's and pins itself, and this is remarkable I think.  We always
simply have the sexpr from which we generated the binary, so that will
always be good enough ?  Well wait, what if we still want to support
graphical editing?, then this idea gets trickier.  And keeping track of
what you inherited from could easily get lost.

I had mentioned earmarking the (line) (pin) and (property) binary
elements with their GUID origins.  This could put them off limits to
graphical editing of the containing component.

There are still some conceptual holes to be plugged if we want to
support both inheritance and graphical editing in the same component.


Dick