kicad-developers team mailing list archive

[Piers Titus van der Torren <pierstitus@xxxxxxxxx>]

About units: For me it was a big benefit to be able to just use any 2
element tuple like object for coordinates and sizes, and direct numbers for
other values, and not having to use a conversion to internal units all the
time. I do a lot of my calculations with numpy, so it makes things a lot
easier if numpy arrays can be used directly.
To me it makes most sense to use mm as default unit for the python API, and
convert from inches to mm using a simple inch2mm function.

Furthermore I put my script in a github repository, like Wayne suggested, I
hope this leads to more organized experimenting, please clone and improve.
It can be found at https://github.com/pierstitus/kicad-python

LordBlick, thanks for another improvement to the layer conversion, it is
much better to use the names that are used in the GUI ('F.Cu' instead of
'F_Cu'). It's committed to the github repo above.

Piers

On Fri, Jan 16, 2015 at 5:14 PM, Miguel Ángel Ajo <majopela@xxxxxxxxxx>
wrote:

>
> 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
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>