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 <[email protected] > (mailto:[email protected])> 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 : [email protected] > (mailto:[email protected]) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
