Open mawildoer opened 9 months ago
I started down this path to see what it yielded and, while not trivial, I did make some progress!
This would be a good capability to have! Could you develop some usage examples in parallel since it is a little hard to see what exactly you have in mind. Not necessarily code examples, but descriptions of how the workflow is envisioned.
I'm not sure this would fit within kigadgets itself because the goal is to have 0 dependencies, stripped down as much as possible. It may be similar to a situation a few years ago where I had a remote call system mixed in with a "gadgets" type package that needed to be rock solid. I ended up splitting into two repos with one-way dependency, and that has been working well.
IPC project: https://github.com/atait/klayout-ipc Gadgets project: https://github.com/atait/klayout-gadgets
KLayout is OSS if you want to download and try out the IPC examples. Let me know if you think a similar approach would work here or if it is something else
Hey folks,
I was mulling alternative interface mechanisms given the breakdown of the pcbnew.so bindings on OSx, and was thinking about an RPC interface.
It seems like it might provide a more stable and agnostic mechanism to connect external programs to KiCAD, allow people to run programs from other environments even interactively with the GUI open and even from other languages if they liked.
I've used gRPC before - though it'd add a few deps (could be optional) Other things would involve some more custom action, which is perhaps fine, though more effort. There's XMLRPC as part of the standard lib that might be useful: https://docs.python.org/3/library/xmlrpc.html There's another litany of RPC implementations; TinyRPC, RabbitMQ, and seemingly plenty of others.
Finally, Pyro makes it seem like we could even do something as straight-forward as exposing the pcbnew module/basic called methods Pyro5
expose
Very much spit-balling for the moment and sure I'm not the first to think of this - so curious to hear others' opinions!