kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> 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.

I'm not terribly thrilled about using SWIG either. SWIG has it's place
but I don't think using it at the application level is it. Maybe as a
library wrapper similar to wxPython but Kicad doesn't have a completely
clean separation between the various object libraries and the
application (UI) code. I certainly don't want to see a bunch of SWIG
constructs in the Kicad source code.

Like Dick, I would rather wait until 3.0 becomes the default version of
Python. If for no other reason than to eliminate the effort of having
to rewrite in order to support the Python 3 API. There are still too
many important libraries that have not been brought up to the 3.0 API.
To be honest, I really thought by now that major libraries like wxPython
would have been ported over to 3.

Wayne

> 
> 
> 
> 
> 
> 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