kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

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.


> 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 only
issue I see here is how do you
define model parameters and names from within the PCB script in a useful
way. 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