kicad-developers team mailing list archive

[Florian Delizy <florian.delizy@...>]

ok for that, but then what isyour answer to the use cases I asked for ?

2010/2/23 Dick Hollenbeck <dick@...>:
> Florian Delizy wrote:
>>>
>>> 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! :-)
>>>
>>
>> Well, I can’t agree more, last time we (my company) decided to use
>> KiCAD for several projects, but they were eventually outsourced, so I
>> kind of lost the time I had for it …
>>
>> really sorry about that, I start over on my own now
>>
>>
>>>
>>> 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.
>>>
>>
>> I feel the same
>>
>>
>>>
>>> 4) I think we should remove the python statements from Kicad C++ code
>>> altogether.
>>>
>>
>> will do
>>
>>
>>>
>>> 5) We are using boost elsewhere, so removing dependencies on boost is a
>>> no
>>> no.
>>>
>>
>> good to hear that
>>
>>
>>>
>>> 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:
>>> ---------------------------------
>>> […]
>>>
>>> *I don't want to see any swig code munging the core C++ source.*
>>>
>>
>> at least you made your point clear. I didn’t think about WF (didn’t
>> now the concept before even reading you), why not, I will read about
>> it.
>>
>> about the use cases, here are some I had in mind :
>>
>> - Export/Import scripts in python (IGES, industry proprietaries, Mentor
>> etc etc)
>> - Automate production files generation
>> - Integration with source revision control (eg svn)
>> - Integration with other CAD systems (for industrial use) (exporting
>> importing mechanical constraints, thermal simulations etc)
>> - Integration with other part management systems (automate BOM, and
>> order, calculate pricing and lead times)
>> - Integration with simulation software (integrate directly simulation
>> results in pcb/board editor)
>> - Allow simultaneous work by multiple peoples (for complex boards)
>>
>> well, I understand your points about the « no binding » policy (and
>> respect that), but then again, I don’t see how to perform all of that
>> in C++ (ok ok, we can make them plugins, but generally, python or any
>> script is more flexible to use).
>>
>
> Patrick has some python code that can load a BOARD (*.brd) file.  The Wizard
> Fountain is a new idea I just had 5 days ago, does not exist, is an
> incubator from which pure python solutions can arise to solve real problems,
> without munging the C++ source code or acting like a ball and chain on the
> evolution of the C++ code.
>
> I have an enormous amount of experience bridging languages like what swig
> wants to do.  Recall I even wrote a JVM, that means I wrote the JNI support.
>  Then I wrote an enormous amount of stuff that sits on JNI, etc.  I know how
> cumbersome it can get.
>
> For now, what I am saying is let python solutions be done entirely in
> python, let someone else maintain the python to UI code, (the wxpython
> project) and let's for the first time provide a place where python scripts
> can live within the Kicad project, and do so in way where the user does not
> have to become a python genius.
> I think this is all good, and you have a chance to direct the evolution of
> the structure of the python scripts and how they interact with your Wizard
> Fountain.
>
> Dick
>
>
>>
>>>
>>> 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.
>>>
>>
>> will do
>>
>>
>>>
>>> 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.
>>>
>>
>> hum, why not, but I am not sure that would much help :)
>>
>>
>>>
>>> C) Then write the Wizard Fountain.
>>>
>>
>> if we agree on that, will do too
>>
>> oh, and btw, the python 3.x thing is one good point of swig : it is
>> not us who will maintain the resulting binding, only a small part of
>> it needs to be changed (the c++ calling system)
>>
>>
>
>


-- 
Florian Delizy