I’m just curious as to what this flag in the latest nightly version is for? Thanks.
It’s the eventual full replacement for the python api
1 Like
The new “interprocess communication” API which in the future will replace the current python API. This flag switches on the compiled part of the API. For the actual end-user API, see
I haven’t got it working, all I get is the note in the GUI that it should be working, but I don’t know what to do with the socket, the example external python code doesn’t find it.
1 Like
what did you try and what error did you get?
1 Like
How much can we assume to be working already if I can run examples\hello.py? As in COMPILING.md · main · KiCad / KiCad Source Code / KiCad API Python Bindings · GitLab. Here’s the result:
(Envi) c:\Development\kicad-python>python examples\hello.py
Not connected to KiCad: Connection refused
At least the bindings exist and can be imported and work in theory. KiCad is running, as in the screenshot. When I check C:\Windows\Temp\kicad, it’s empty. I don’t know how sockets work in Windows and how I can debug them. I have a compiled KiCad here, too, and I can set breakpoints and edit the code if needed in VS.
1 Like
That’s normal, it’s not a real file.
Well, it should work, but I don’t test on Windows regularly, it’s been a month or so since last time I checked it. I wouldn’t assume anything works right now since nothing has been formally released or announced, but I’ll put it on my list to go check on a Windows machine sometime.
1 Like
Maybe it’s related to protobuf compiler version mismatch with the kicad build?
@craftyjon It’s because kicad is creating a socket with path:
but the kicad-python example does
return 'ipc://\\.\\pipe\\kicad' if platform.system() == 'Windows' else 'ipc:///tmp/kicad/api.sock'
1 Like
Ah yeah, the launch standalone stuff hasn’t been fixed for Windows yet after the change to using user-scoped temp dirs. It will work if running an example plugin from inside KiCad.
Nah these don’t have to match
OK, it’s fixed now in kicad-python
3 Likes