← Back to team overview

kicad-developers team mailing list archive

Re: Plot and drill file generation via scripts



was/is a potential solution to a relatively small problem space, whose size is given by
the answer to the following question:

*) how many functions, say member functions, are there that operate on a BOARD, that need
no GUI, and must be used by both the frame and by top level python scripts?

-) save
-) load
-) flip
-) rotate

Clearly this is a small problem space.   However, the size is somewhat unknown, in as much
as we don't know what will really be needed in the python top level interfaces yet.

So I am happy to table BOARD_ACTIONS for the time being.   Also, priorities have changed
from 2 years ago, and much work has been done by folks which have moved us down the road
in alternate routes.  Miguel's work has shown that we can use a DLL/DSO under python, that
carries wx code in it, to no harm.  So pristine GUI-less DLL/DSOs are now a much lower
priority....   CERN has written a roadmap document, and gotten it approved by the lead
developers....    Work has been done at CERN in those directions....

There are almost always multiple ways to solve problems.


The plot controller seems to have a good interface, from the python side anyways, and I do
not agree with Adam about exposing the FILE* to python.  StringIO is really not needed for
such a small file.   A drill file can be written to disk and read back into a byte array
using python in about 5 lines of code, for sending to a socket.  (BTW, I have never
squirted into a socket, do people really do that?  Seems too dangerous.)   If you had this
on a server, and were processing hundreds of drill files per second, because KiCad was
being used by every man, women and child on the planet, then even then you could probably
set up a RAM disk on the server and still do it this same way just fine.

Miguel's idea about extending the PLOT_CONTROLLER with some drill file generation
functions makes the most sense to me, rather than doing a "DRILL_CONTROLLER".

(BTW, StringIO is "file-like" only in a python duck typing sense.  The typemap cannot
convert a StringIO object into a FILE*.)

Those are my thoughts.


Follow ups