kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/6/2010 10:09 PM, Dick Hollenbeck wrote:
> 
>> 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.

The more I think about it, the inherit concept eliminate the need for a
separate symbol concept.  There is no reason why a component has to have
properties.  This would simplify the grammar.  I can revise my file format
document to reflect this discussion thus far and publish it for comment.

> 
> 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?

How about generated at the time they are imported into the schematic if no
properties for a component are specified.  The value property become the name
of the component sans GUID and any look up information and maybe some default
reference designator as part of the component grammar.  Hard coding U for the
reference designator would be ugly for resistors, caps, inductors, etc.

> 
> 
> 
> 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. 

I will take on that task.

> 
> 
> 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. 

You could use the child level to set the indent level for each object's sexpr.
 LIBRARY would not be indented.  LIBRARY->COMPONENT would be indented on level.
 LIBRARY->COMPONENT->ARC would be indented two levels and so forth.

> 
> 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.

The inherited objects would not be editable.  Only the objects specific to the
current component being would be editable.  If you wanted to edit inherited
component, you would have to open it in the editor and modify it.  Currently
the library editor does not directly modify the components in the library.  It
makes a copy of the component and modifies the copy.  Each object could have
its own sexpr that gets rebuild every time you change or modify the object
rather than have a top level library sexpr.  You would add or replace a
component the same way we do now.  All the object sexprs are already valid.
The beauty of always having the sexpr up to date is you now have simplified
your copy and paste.  You just copy the sexpr of the object you want to copy to
the clipboard.  The beauty of each object maintaining it's own sexpr is when
you remove an object from a library you don't need to refresh the library
sexpr.  Saving the library is simply a matter of writing the table(s) of
generated object sexprs to a file or stream.

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

There definitely will be some details to hammer out but none of them seems
insurmountable.

Wayne

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