Moving from Python to Lisp/Lua


That’s great, sounds like very good progress.

Other simple scripts you may like to test are ones like

and this one is a plugin, more integrated, to a running PcbNew …


Its hard to maintain everything for developer, but you can though also get the query to be fulfilled by any of python or odoo development services provider.


I think simple interface in native python class to encapsulate C++ API function call would do. It also allow the maximum flexibility for backward, and forward compatible event C++ API function change so much. Allow a freedom on C++ API function call interface refactor without broken old python scripts if their always a set python codes can be make for old python interface classes work in similar manner. This way, also all other script languages added more easier too by addition native interface of it’s own.
And a C++ API direct function call should be enough for all other script language interface class to work.


I managed to get the wxpython-4.0 patch of @mmccoo working and ported it to be in mergable state. Now I have Python 3 with the new wx binding running:

The code can be found in a new wx-python branch which is on top of the python3 branch. Please read the commit message carefully, otherwise it will not compile due to a missing include of the Phoenix binding. It can be activated using -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON


I think you are getting the abstraction layer interface right and the wxPython 4.0 update you have done was another missing chunk. IMHO we should consider merging your changes in 5.1. Thank you pointhi, you have done very valuable work!


The Footprint Wizard is now also running. I managed to get it running with wx3.1 and gtk3 on Linux (some other config variants caused gui issues).

Thanks to @nickoe we also have a working windows build now:


Very cool to see this getting done quickly! Most distros are moving forward with having GTK3 I guess the issue would be LTS distros.


Any idea approximate number of months we are from the semi-stable 5.1 binaries? Would love to use mmccoo’s stuff on Windows but haven’t had any luck getting it working just yet.


5.1 will mostly fix problems on linux. Not really on windows as the wx stuff still exists compiled against gtk2 for it. (A lot of linux distros dropped support for that old library. Some parts of the python interface rely on that. Kicad now has now only very limited support for python on that distro.)
I think you should open a separate post detailing your problems with python under windows. Maybe somebody can help you with that.


I’d love to get the plugins working on Linux too. I tried to setup a virtual box with the plugins running on a Mint installation but it crashes on launch of PCBNew if mmccoo’s plugins exist in ~/.kicad_plugins. So far I’ve only had success on mac with that plugin set.


Dealing with recent stability issues in Kicad/python

kicad/python is not compatible with ubuntu 18 (and variants like mint). This is because of the wxPython, wxWidget, gtk2/3 stuff that’s been mentioned in this thread an others. Having my plugins present causes seg faults/crashes kicad on start because I import the wx library. That’s due to version mismatch type issues that probably should have also appeared on older versions but somehow didn’t

Ubuntu 16.04 with the nightly kicad install is probably your most trouble-free bet.

It includes the scripting window and runs python scripts (I can only speak for mine)

mmccoo’s opinions on dealing with overall stability issues, language and all that

I learned python only because that’s what pcbnew supports. Before then I spent many years on perl, tcl, c++, scheme, skill,… Never got paid to write python. Language doesn’t really matter. Pick one and move on, especially now that python support is there. Python is nice because it has so many useful libraries. I resisted python before, cause I love me my curly braces.

Beyond language choice, kicad suffers from two problems:

  1. pcbnew’s c++ data model kinda sucks. No consistency between types (ie, getName has different names between the types). The Kicad developers don’t seem to have a problem with this. Don’t ask me how. Probably cause they’re in close contact with each other and know what’s changing. Since the data model is not that great, the resistance to changing it is small. These changes are then reflected in python.
  2. kicad doesn’t have any regressions that I’m aware of. There are one or two trivial “tests”, but they do little. If I’m misspeaking, please correct me.

Should there be an abstraction layer?
Perhaps, but I think it’d be a shame. I’d be more inclined to change the c++ model to be better. To add another numbered list (I do those a lot), there are two benefits in an abstraction layer that would be important to me:

  1. Can you find what you need? Many object types have names. There should be a common method name to access that name. Today, we have getNetName(), getReference(), getName()… To get from one type to another, should be as easy as get_TheOtherTypeName(). With such consistency, my tutorial posts would be much less necessary.
  2. Once you’ve found what you need, can you rely on it? If the time has been spent establishing some consistency, I’d hope that effort would be honored. Regression tests to enforce would go a long way.

Perhaps, next to the existing sucky c++ method names, I and others can give parallel ones that suck less.

Thanks to those that have complimented my plugins.

I’m glad that others find them to be of value and that they are referred to. I do kicad stuff in spurts every couple months and I enjoy doing it.
If anyone has requests, message me. I do this largely for the enjoyment I get out of programming. If you want/need more direct support I might do that to. My current rate is: “one of whatever it is you’re making” :slight_smile: