Yes it’s a shame it can’t be done natively in Kicad … yet … maybe in the future? And the TI tool makes quite crude estimation using line segments. Potentially there are better options using smaller segments like the examples made by spiki but I have not tested this (I avoid scripting tools because of effort in dealing with missing/incompatible libraries!)
I have never thought about using any scripting tools (I am even not sure when tool can be named script and when not).
With PCB I was working with Protel. Only one problem I had to solve out of that tool. I coud’t put graphic at PCB. So I have written a simple program (C++) to convert bitmap to gerber (not efectively - 1 mils line by line). An year ago when I first look at KiCad I found that people here need to use not only the software itself. My first thought was - something has to be wrong with this software 
One does not need to use scripts. But scripts can be powerful tools to automate things or to tailor software to your particular usecase. A typical example are footprint or symbol generation scripts. But even things like extending kicad for panelizing which will most likely not be a core feature in the near future.
It does not even mean that you will need to develop such scripts for yourself. If the API is well developed and stable (goal for v6) then it is expected that a community will develop around scripting. See freecad as an example. Their whole point is that the software itself is only the core functionality and everything else including all workbench tools are typically developed at a higher abstraction level using python as the scripting language.
Or take the text editor atom. Which uses the same approach but uses a different scripting language.
In my opinion this is the way to go. Limit the software itself to the functions that need to be implemented at a low level and that need to be well tested and leave additional features to the scripting interface. (With additional features i mean things that automate a set of core functions and present an additional abstraction layer to the user. An example here are footprint wizards which abstract away the details of how to make a footprint and use the low level functions to add pads or graphical lines for you.)
I would take it a step further. The whole UI, the main window and all, could be scripted. If KiCad ever reaches the point where the “engine” is a library without any remains of wxWidgets classes, event handling etc. this will be at least theoretically possible. Even now I feel uncomfortable every time I see a core developer adding a feature which could easily be done with python, if only the infrastructure was there.
BTW, the term “script” is ambiguous. Even inside KiCad it could mean many things. Basically and usually a script is a small program which is written as plain text and then can be run immediately on all platforms through an interpreter without intermediate steps (done by the user) like compiling. But most “scripting languages” are just programming languages with interpreters and can be used to make programs of any kind and size. In that case they usually use some compiled libraries for efficiency and aren’t really “scripts” anymore.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.