kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

First of all, let me first clarify, we’re discussing two things at the same time:

[people scripts (2, 2.1, 2.2)] —> [kicad-python-api(1)i] —> [C++ swigged-API]

                       
1) Building an API to access the kicad objects in a way that is not  
tightly coupled to the KiCad internals, and that it’s for consumption from  
python scripts. This API is to be written in python.

    I believe this API should live in the kicad repository, even if we iterate
first on a separate one. This way, when breaking changes happen in the C++
implementation (interface change, object change, etc..) the API layer
can be updated to work with the new C++ interface.


2) Having scripts people build on python to provide specific functions.  
This could live on a separate repo without risk, since the API contract  
should not change (unless somehow deprecated). If something becomes
really useful for the wide community, of course, it can always be packaged
together with KiCad.  

2.1) At some point, we could even make a repository available via github,
 the same way we do for footprints.

2.2) I also find interesting another kind of special functions, not to run standalone
from kicad, but to run inside kicad:

    a) Contextual menu hooks: scripts that can hook certain contextual menus,
        to provide functions, so users can plug those special functions into kicad.

    b) Tool bar hooks: To install functions in the toolbar.
    
    c) I/O plugins: To write I/O plugins in plain python.


I’m replying between lines too->  

On Friday, 16 de January de 2015 at 15:25, LordBlick wrote:

> In response to a message written on 16.01.2015, 14:35, from Tomasz Wlostowski:
> > On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick,
> >  
> > I'm of quite opposite opinion - all scripts of decent quality should be
> > available in some official repository (whether it will be separate from the
> > main Kicad repo is a different discussion) and possibly packaged with the
> > releases of Kicad.
> >  
>  
> Separate repository seems more sensible. My OS packaging environment (RPM)
> spends 23 minutes to build every release (without docs and libs) and that amount
> of time still grows. Every element, which can stand alone, should have separate
> repo as was done with docs and libs.
>  
>  

Build time is painful, but I believe it's something which shouldn’t stop us from  
adding new functionalities, otherwise we should stop development now ;-)
> >  
> > A stable and simple API for scripting, that is independent of the pcbnew's
> > internal storage model is a big step in that direction. To me the discussion
> > if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
> > 10) is a waste of time, because I don't see any of these forms making script
> > development significantly more difficult.
>  
> That's my appointment too, but possibly haven't found proprietary words…
> Some of ways comes from Python language specific forms.
>  

Ok, let’s not spend more time on that part. :)
  
> > @Miguel: PS - What do you think about adding a GAL canvas object to the
> > scripting API? It could be useful for footprint/import wizards or other PCB
> > feature generators as a preview window, embedded in a GUI form.
> >  
>  
> It will be great to control fast drawing area from external script. Today I use
> cairo/gtk to my scribbles.
>  

Yes, I totally missed that when using scripting, if you could give me an example  
of how to instantiate the GAL canvas from a standalone simple wxpython  
application, that should give me an  idea on what do we need to provide  
from the C++ API layer.
  
> > I've had in mind a Pythonish SVG graphic importer (see attachment), adding a
> > simple OSHW logo to a Kicad PCB project is quite painful now...
> >  
>  
> Curiously, I'm doing svg import work in python with additional ability to simple
> edit points position.
> Screenshot contains yet unfinished UI editor. I have some ideas, eg. a choice to
> import (DrawPolygon footprint or other draws - arcs, circles segments, zone on
> board or draw elements on board etc ...)
>  


Nice!  
>  
> --  
> Best Regards,
> LordBlick
>  
> _______________________________________________
> 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
>