Hi Tom & Michael,
I'm using the scripting interface quite often and had never that much trouble with it.
The currently missing std::unique_ptr is not an argument, it is still possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
The currently missing std::unique_ptr is not an argument, it is still possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
I'm quite sure that in the future almost any C++ 11 features will be supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is exactly the downside.
Pybind is - as you have written - generatorless, in my opinion this is exactly the downside.
You have to write wrappers yourself, while with swig you're simply including headers in the *.i files.
--
About the pythonish API:
Although this sounds good, I'm sceptical - simply because the very limited ressources of the KiCad developers,
something like this has to be regularly maintained. This means documentation too, both C++ and Python.
something like this has to be regularly maintained. This means documentation too, both C++ and Python.
As Miguel has written, there is already some work by Piers Titus van der Torren, see
https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
I've not used that, because I've found it easy enough to work with the swigged functions.
Even when internals are refactored, in most cases I've found it easy to adapt my scripts, this is only an issue between
Even when internals are refactored, in most cases I've found it easy to adapt my scripts, this is only an issue between
the releases - even with an abstraction layer you don't know if something has to be changed.
Python helper functions would be nice, but I'd still like to have full access to as much as possible PCBNEW methods.
--
In my opinion the work should be invested elsewhere - for instance a launcher for python scripts is missing.
Sure there is a console, but ideally I'd like to press a button, a keystroke or similar to launch my script.
Sure there is a console, but ideally I'd like to press a button, a keystroke or similar to launch my script.
Also several functions are not yet wrapped, like the P&S router or the tool framework (working with selections etc.).
Thanks,
Torsten
Torsten
> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
>
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.
> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.
Hi Michael,
It may sound controversial, but I'd say using SWIG is a bad idea: we
expose for the people the internal APIs of pcbnew that we intend to
refactor in the near future. Any change to the BOARD storage model means
a change to the scripting API. IMHO we should have a more pythonish API
that hides all C++ stuff from the python side completely and is
independent from the changes in pcbnew's core.
Cheers,
Tom
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
>
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.
> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.
Hi Michael,
It may sound controversial, but I'd say using SWIG is a bad idea: we
expose for the people the internal APIs of pcbnew that we intend to
refactor in the near future. Any change to the BOARD storage model means
a change to the scripting API. IMHO we should have a more pythonish API
that hides all C++ stuff from the python side completely and is
independent from the changes in pcbnew's core.
Cheers,
Tom
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
