kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Thu, Feb 5, 2015 at 9:20 AM, Miguel Ángel Ajo <majopela@xxxxxxxxxx>
wrote:

>
> 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>
> 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
>
>
OK, I'll work on that.

[snip]

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

[snip]

OK, now I think I understand your point. This is possible to do without any
modifications to the tools, but users will have to write all the necessary
python scripts/plugins. I would leave the current batch generation scripts
in the toolbox as examples (as originally intended) and perhaps the
additional footprint plugins can be placed elsewhere (yet another github
repository?)

In addition it may be possible to reuse code in 3DViewer (or refactor
3DViewer so we can reuse code) so that the user can immediately see the
result in a window as they update parameters in the wizard.

Since you used the BGA footprint wizard as an example, I can say that the
tools can model BGA packages and even provide pretty little ball connectors
at the bottom (at the cost of increased file size for more realistic
rendering of course).

- Cirilo