kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Florian Delizy wrote:
> Hi,
>
> I had really few time the past year to work on KiCAD, I started the
> integration of python support into KiCAD but never finished it (really
> sorry for that).
>
> Since I finally have time to look at it, I start again today, I see
> that my old code is still present (but unlikely to even compile), I’ll
> start cleaning it out.
>
> back then I used boost::python to include it, I consider now this as a
> mistake (regarding the developements of boost), I’ll then turn to
> SWIG. Here are my plan :
>
> – Remove the old code (all of it)
> – Remove dependency to boost::python (I saw that other code is using
> boost elsewhere, so I wont remove boost, unless you think I should)
> – Start over the thing with SWIG
>
> Advantages of SWIG are (now) :
>
> – Support 3.x flavor of python (SWIG community maintains it as it si
> moving, so no hassle for us)
> – Support for lot of other languages
> – Can automate interface and doc generation
> – Wx is bound using SWIG
>
> what do you say ?

Hello Florian, one our python champions! Nice to hear from you again.

The last time we had notice of you was when you snuck into the kitchen 
for a midnight snack, and left python cookie crumbs all over the floor! :-)


My opinions follow:

1) Python has a warm place in my heart.

2) Python is undergoing transition from 2.x to 3.x, this affects the C 
API, and the python source code.

3) I only like 3.x python.

4) I think we should remove the python statements from Kicad C++ code 
altogether.

5) We are using boost elsewhere, so removing dependencies on boost is a 
no no.

6) I would like to start supporting python scripts, but *not from within 
the C++ code*, but rather from a "Wizard Fountain". This means no 
swig. No C++ to python bindings until later, see below.


The Wizard Fountain:
---------------------------------
This is an incubator and launchpad for python scripts which users could 
use if they had wxpython installed. Any of the scripts invoked from 
here should operate like a wizard, you know like step-wise dialog 
boxes. The Wizard Fountain (WF) would be launched from the Kicad 
project manager with a new icon. Again, WF is written in wxPython. But 
it in turn can call python scripts that are placed into dedicated 
directories. There would be a directory tree dedicated for these 
scripts, and the directory tree names and structure would be mimicked by 
a menu system within WF. That is, WF would build a menu hierarchy 
exactly like the dedicated directory structure, using directory names as 
sub-menu names, and script names as menu choices.

So you could determine the menu used to invoke a script simply by 
placing the script in a sub-sub-sub-directory of a proper name.

Somebody that did not want this facility would not install wxpython, 
however I don't see a problem including the python scripts as part of 
the stock Kicad install.

Python scripts can communicate with Kicad by way of files. That is, we 
do not have a clear use case to bind python into the C++ code, because 
anything that we would need for that can best be done in C++.

Maybe we can pull in Patrick's python BOARD library.

Some day, should we ever re-write the BOARD storage model, I would 
suggest that we do that as a shared object (DLL) without user 
interface. Keep the UI code out of the data tree management DSO, but 
park it on top of the DSO, as a separate C++ link image that sits on top 
of the storage model DSO. Then at that point, you could argue that 
parking python on top of that C++ DLL would make sense. Until then, I 
will oppose any C++ to Python binding except in one other place, and 
that is in the footprint retrieval plugins, which are free to do 
anything they want to do. (Because anyone can write them, and by 
definition we will not have control over every one of them.)

Having said all this, I cannot get excited about python again until the 
python world fully crosses over into 3.x. I cannot find wxpython for 
python 3.1, and I think to make a big investment in python until it 
decides to follow its leader is a mistake. I have converted code from 
2.x to 3.1, but why should we have to do that. It makes better sense 
to start with 3.1 or 3.x.

*I don't want to see any swig code munging the core C++ source.*

I don't know what Jean-Pierre or Wayne think about this.





So to summarize my opinion, what could you, Florian, do to best help the 
project?

A) remove the dis-functional python code from KIcad's C++ source.

B) Get into the wxpython mailing list and complain like a mad-man that 
it is way past time for them to support 3.x python. Make it happen, 
quote this list if you have to.

C) Then write the Wizard Fountain.



Dick