kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

On Wednesday, 4 de February de 2015 at 21:27, Cirilo Bernardo wrote:

>  
>  
> On Wed, Feb 4, 2015 at 8:39 PM, Miguel Ángel Ajo <majopela@xxxxxxxxxx (mailto:majopela@xxxxxxxxxx)> wrote:
> >  
> >  
> > Hi Cirilo, awesome work.
> >  
> >    Don’t want to delay the merge, that’s something on what we could work afterwards,
> > but, are you aware of the higher lever scripting layer we started working on from Piers  
> > proposal? [1]
> >  
> >  
> >    I’m trying to splice his work into modules to have a very coherent and well documented
> > python API for KiCad at user level.
> >  
> > The idea is to keep the modules as:
> >  
> > kicad
> > kicad.pcbnew
> > kicad.eeschema   (when we get into such thing..)
> > kicad.gerber
> >  
> >  
> > may be we could expose your 3D API from kicad.vrml  ?
> >  
> > We adopted the naming convention of xxx_xxx_xxx for function names, and Xxxxx for classes,
> > and we are building a higher level python API over the C++ bare implementation, and we don’t
> > plan to break that one to avoid breaking off anybody’s already existing scripts.
> >  
> > We could do the same on top of your 3D api, or we could go and do a follow up patch to normalize
> > all function names. (I see you tight controlled how python naming is exposed based on the C++ API),
> > probably the 1st option is going to be the most flexible.
> >  
>  
> If necessary everything can be exposed from kicad.vrml; my only concern here is if many more C++ modules
> are added then kicad.vrml might become too big. Otherwise changing the library is not a very big job at the
> moment and since there aren't very many scripts it shouldn't be a big job to update the scripts to use the
> newer library name.
>  
>  
>  
>  
>  


That can be split them in submodules
kicad.vrml.xxx
kicad.vrml.yyy

Think about a logical way to provide them.

It’s common also to unify all you want to provide from a module from split modules
like this:

https://github.com/KiCad/kicad-python/blob/master/kicad/__init__.py

Or importing specific stuff.

You can also leave the C++ modules as you want, and then we can create simple endpoints
in kicad.vrml the same way, I believe that would make it easier, because otherwise the modules
could be conflicting at install time.

I would be more concerned about providing an unified way of naming methods,
do you find reasonable to export them to python with the pep8 naming convention?

https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables

>   
> >  
> > The intention is that [1] is very well documented for all users, and merged back to the kicad code  
> > base (when mature enough) so it’s widely available to everybody, and so we can fix any breaking
> > changes on the C++ API by updating the python layer.
> >  
> > I would also be very happy about making python-scripting a 1st class citizen by getting [1] merged
> > and, getting all the stable builds with Python, so this is widely available to everybody in the next
> > release. But I want to start a discussion about that.
> >  
> > One question:
> >  
> >    Is it currently possible (from python), to build a 3D model, and attach it to a module right away?,
> > that would be amazing from the footprint wizard perspective. (I didn’t have enough time to fully
> > dig into your code).
> >  
>  
> Models can be built from Python and if the kicad scripting interface allows you to add 3D models then
> the generated file can be immediately attached to the module.  
>  
>  
>  
>  
>  


The scripting interface should let you do whatever the c++ module class let’s you do  (the positive  
side of swig, the downside is not having too much control over the naming of your functions if you do  
it all automatically)  
> The only issue I see here is how do you
> define model parameters and names from within the PCB script in a useful way.  
>  
>  
>  
>  
>  


We already have that, http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/scripting/plugins/bga_wizard.py
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/files/head:/pcbnew/scripting/plugins/

The C++ UI talks to the python plugins (which get registered at pcbnew boot), and finds what to ask the user,
then when the user changes a parameter, the parameter list is propagated back to the plugin, and the
footprint is rebuilt inside python.

Within such plugins we could build a 3D model and attach it to the footprint.

http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/scripting/plugins/bga_wizard.py#L64

Please, ignore that those parts of the code are based on the C++ naming convention, instead
of the “pythonic” one :/
  

> The current workflow
> is to create a parametric model such as a tubular leaded diode model (which is currently in C++ but
> could equally be a python module) and to use the python interface to create multiple configurations of
> the component class through a script like do41.py.  To create models from within a PCB script you
> would need the name of the python module and the parameters for that model and my opinion is that
> this is too much information to put into a footprint definition or PCB script. Then again if we do that
> then it is more obvious what the dimensions of a model are and people can check that the dimensions
> are correct + the software can create models as they are needed if the model is built with this tool.
>   
>  
>  
>  
>  
>  

> - Cirilo
>  
>  
>  
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>