kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/18/2012 11:19 AM, Miguel Angel Ajo Pelayo wrote:
>
> Hi All, 
>
>     I wanted to share our progress on this, and ask a few questions.
>
>     At this moment, we're already able to:
>
> 1) run scripts (python) from inside pcbnew,
>         pcbnew.GetBoard()  must return our current BOARD* in the editor.
>
> A little example:
>
>    from pcbnew import *
>
>    m = GetBoard().m_Modules
>    
>    x,y=54000,54000
>    i=1
>
>    while m: 
>         m.SetPosition(wxPoint(x+i*2000,y))
>         m.SetReference("C%d"%i)
>  i+=1
> m = m.Next()
>
>
> 2) run pcbnew classes and objects from inside a standalone python script.
>
> #!/bin/env python
> from pcbnew import *
>                            
> pcb = LoadBoard("/tmp/my.brd")                           
> m = pcb.m_Modules
>
> x,y=54000,54000
> i=1
>
> while m: 
>      m.SetPosition(wxPoint(x+i*2000,y+i*1000))
>      m.SetReference("C%d"%i)
>      i+=1
>      m = m.Next()                  
>      
> SaveBoard("/tmp/my.brd",pcb)
>
> Same example from commandline:
>
>     For which I added some functions to easily load or save a PCB file via IO_MGR //
> KICAD_PLUGIN (as Dick asked, it
> was the best way)
>
>     I added typemaps for strings<->wxString, and also wrappers for wxPoint and wxRect,
> which let
> us to talk to methods depending on this types.
>
>     We have wrappers for most objects (BOARD, COMPONENT, PAD, segments , tracks, text,
> etc... ) and lists (DLIST based),
> but we still miss access to std::vector and std::list objects yet.
>
>
> We already have something quite useful, but testing is very welcome.

I would be inclined to offer my help on the architectural changes needed to make this
right, before I were to spend any of my time "testing".

Finding that time is my biggest problem.  Some of my thoughts:

a) This is very important ground work.

b) Eventually I hope to be able to help, and it will come in bits and pieces.  You will
see on my personal todo list in TODO.txt, that I have adding "loading modules" to the
PLUGIN API near the top.  This will happen very soon.  See number 2) in that file.

c) The architectural changes I identified before still need to happen before we can call
this a completely sound design.  I personally am not motivated to merely get this done,
but am motivated to get it done correctly on top of the proper architecture.   I do not
feel that much if any of the work you have done is a waste of time.  Quite the contrary. 
However, I am not surprised in the least that you have hit a an architectural wall.  It is
precisely the wall that I warned about.


(On a personal note, the wall that I am hitting lately is insufficient time to spend on
KiCad.  There are several items before this scripting in my work queue, but I feel
scripting is probably one of the most important enhancements that will ever happen to KiCad.)


We will soon be moving to all new file formats in PCBNEW, both for footprints and boards,
driven by the move to nanometer internal units.
At this time we have an opportunity to make very disruptive changes to the PCBNEW file
format, an opportunity which does not come along often.  The beauty of having the
scripting inside the program, on top of the object model, is that your work will be
largely preserved, even as the BOARD format changes, probably radically.  (An external
pure python library which tried to read *.brd files would be immediately obsolete.)


I thank you for the progress report, and I honestly believe you are doing *very* important
work, which will eventually get pulled into KiCad.  You have my personal guarantee.


But just like the command line argument patch that came in 2 months ago, there will be a
better time to merge this all in.   After BOARD_ACTIONS, after nano-meters, and after we
have a clean separation of UI from actions.  Otherwise it would be like re-modelling while
someone is cleaning the house.  Yes, I have been saying this for nearly 5 years, but I
honestly believe we are now very very close, relatively speaking.


Dick