kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/6/2010 10:54 AM, Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> I'm interested in what you come up with for clipboard support.  At some
>> point I would like to add clipboard support to the component library
>> editor after the lexer is in place.
>>
>>   
> 
> (Wayne knows I was talking about a new footprint format.)
> 
> Check this out:
> 
>        http://en.wikipedia.org/wiki/EDIF
> 
> 
> It is a good read, and it has some nice references at the bottom.
> 
> Frank Bennet has that sourceforge based edif2kicad translator.  Some of
> that functionality can eventually pulled into the upcoming Kicad
> loaders/parsers using our planned recursive descent parsing with
> DSNLEXER strategies.  (I am guessing that the DSNLEXER could handle the
> EDIF format with a proper keyword table, although it was my desire to
> commit to lowercase only keywords, whereas EDIF seems to use uppercase,
> a minor point.)
> 
> 
> 
> I have stated them before, I state them again.  My drivers for new
> formats are these, the files:
> 
> 1) will be *very* human readable.  You should be able to created them
> easily with a text editor in a pinch, or as a measure of human
> readability.  This will also ease the process of writing translators TO
> the new kicad formats.
> 
> 2) self documenting.  this means that when balancing small size against
> descriptiveness, descriptiveness should weigh more.
> 
> 3) our recursive descent parsing design is also self documenting in the
> source code.  The recursive descent structuring of the code is very easy
> to follow, modify, and extend.
> 
> 4) the exact line number and character offset of any error is provided,
> with a text message that we control.  Error handling is focused in a
> single exception handler.
> 
> 5) these formats can be designed to be clipboard compatible.  to see
> what's on the clipboard, treat it as text, read the first two DSNLEXER
> tokens, you have already a description of the clipboard contents (object
> type).
> 
> 6) it gives us a chance to "fix" a number problems that we have been
> procrastinating as previously identified by Jean-Pierre and others.  (I
> say "gives us a chance" for a reason.)
> 
> 7) the new formats are easily extensible.
> 
> 
> Maybe it's time to move this to one of the blueprints on launchpad.  I
> will create one dedicated to footprints soon.  My thinking is to walk
> before we run.  Footprints are a smaller discussion and eventually
> become part of a larger discussion of a new board format.  Whereas Wayne
> will probably want to head up a similar discussion and follow a similar
> path with respect to symbols and schematics.

In the next few weeks I plan on submitting a proposal (blueprint?) for
the new component library file format using the DSN lexer.  I think I
have a pretty good idea of the requirements that will cover most if not
all of the previous discussion on what the new component library file
should support.  I'll give everyone a few weeks to comment and start
coding once we have the particulars sorted out.  Once the lexer is
complete, I'll start working on the component library editor to take
advantage of the new component library file capabilities.  This work
will also include clipboard support for the library editor.  After the
dust settles on the new component library file lexer and the library
editor, I'll repeat the same steps for the schematic file lexer and
schematic editor.

Wayne

> 
> 
> Dick
> 
>