kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

I have spent most of the day in eeschema's BOM support code.

One idea I have is to simplify that code significantly, because of a
belief that we will be unable to meet all needs in C++.  It will take a
user modifying a script for him to get truly what he wants.  Using a
script means it requires no compiler or build environment.  For example,
a python script.

To embellish this idea:

When he clicks the BOM button, we export everything we (would ever) need
to an S-expression file, with basically NO options since everything is
exported.  Then transparently we run an external script/executable which
can do anything, but would be passed the name of the S-expression file,
and perhaps a desired final output filename that might be CSV.  The
script converts the S-expr file to CSV or whatever, maybe emails it to
grandma.

For a configuration dialog, the user only gets to name the
script/executable that is run on the exported file, perhaps the name of
the final file, and basically nothing else.

I write 3 or 4 python scripts which duplicate what we have now in terms
of outputs.  But the 3rd one is better, the single line per part type,
which is the one I am most interested in, in CSV output format, with
full field name support.  These scripts go into <bin-install-dir>/scripts/*


I think I can load S-expressions now into python.  With this plan a
python install becomes a nice to have, but not a true Kicad
*requirement* since the user can provide his own executable/script in
any language, including Java, SCALA, or C++, or not run the BOM generator.


(BTW, I have worked with Groovy extensively and was disappointed with
the lack of compile time type checking.  SCALA looks better in some
ways, and has many concepts in common with Groovy.  I do not really know
it yet.  It runs on top of the JVM like Groovy. At first glance it looks
interesting for anyone currently working in Java.  You can actually
write scripts in it too.)


This is one thing that could be done to the BOM generator.  I don't like
the current dialog window there at all, and am not too exciting about
fixing something for which I have no enthusiasm for.  I am not sure it
is worth salvaging.  A few lines of python code will do a better job and
give the user the ability to easily refine the output him/her-self.

What do people think?

Dick