kicad-developers team mailing list archive
Mailing list archive
Re: exploiting human readability
On 10/07/2010 12:20 PM, Wayne Stambaugh wrote:
> 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.
>> 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
> 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.
Textually editable yes. Graphically editable is the open question, and
even if the answer is yes, you are editing the subset that comes with
(component A extends GUID
(line 0 12 34 56 78)
here the line is editable, but not the stuff you inherited, which could
consist of 100 lines can circles.
> 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.
Things get simpler if we remember that the standard Kicad supplied
libraries are READ ONLY.
This is really difficult to remember. Basically it should not be
possible to edit the Kicad supplied libraries, unless your name is kicad
The parts_list concept is not dissimilar to what we are doing now. What
I'd like to see different though is all the *schematic instances*, be
simplified and limited.
Looking something like this conceptually:
(part uses PLID REFERENCE_DESIGNATOR
(loc X Y)
The PLID is an internal parts list ID, and you only get to add the
reference designator, location and orientation, *nothing* else.
Then the parts list holds this thing:
(component A extends GUID
(field value 33k)
(rect 0 0 144 144 )
Where PLID == A
In this case GUID is a link to the kicad standard library.
You can see now that the parts list can become a library source for
somebody else. If you implement one of the abstracted LIBRARY_SOURCEs
to load the new schematic format on a read only basis, then you get
another library, one that you know worked in another schematic.
> 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.
Well only one kind of LIBRARY that I mentioned is directly writable.
And I had that as a directory with separate components in it, not a
So it gets even easier than you said. If that is the writable library
kind, the user simply saves the component on disk, as a sexpr, in a
directory reserved for that library source.
This way the user can put them under version control, and this is how
our project librarians would maintain the kicad supplied library source.
>> 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