What type of language would you prefer for writing KiCad scripts?

The python API afai-understand-it already is a ‘wrapper’ to the C modules.

It would be better to classify the python API into safe and unsafe modules, and the novice should only use the safe ones. This would not add additional work onto the developers.
So instead of

import pcbnew

you’d have (for example)

import pcbnew_safe


import pcbnew_unsafe

Question then just becomes - what is considered safe and what isn’t?

PS: python is human readable most of the times, so pretty easy to work with. And with it’s forgiving nature (search google for python try/except) very kind to newbies.
And for testing pieces of code it’s got a live interpreter. You can type code into the command line and test it right there. Very convenient.


I was more thinking of a collection of kicad specific functions. The whole point of it is to hide as much of python as possible from non programmers with great ideas for new features. Look at mmccoo’s tutorials, the functions he has written is good examples of what could be in there.

I started with KiCad about a year back and i like it. Nevertheless I found many things which added to customize. I use Visual Basic (.net) and work with Kicads files .pro, .sch and .kicad_pcb.
I wish there were a programming interface (.dll) to call internal functions of KiCad. If there is something like that I would be happy to learn about it.

Have you had a look at this?

The scripting API is an interface to the internal functions if I understand correctly.

Out of curiosity, what is it you are missing and want to add?

1 Like

Wow, this sound very interesting and if it can do for me want I am
looking for it will save a lot of time.

If you have a little example, how to call these classes from within VB I
would very much appreciate to receive it. The reason is that I decided
some time ago to write all applications in VB if possible. This includes
use of databases, calling uC via USB, graphs etc.


I have no idea but you could ask the author of the blog in his thread here at the forum.

I’ll throw in my $.02 (USD) on this topic.

I’m an “as needed” KiCAD user. I also have a rather long background in CAD and software…and hardware, and electronics…well that list gets long after so many years. :wink: And, the list of coding languages I’ve used is WAY longer than I care to remember…even if I could. :open_mouth:

Having a scripting language for quick lash ups and time saving is a great idea. And having a real programming language to do heavy lifting is better when needed.

Since KiCAD has limited developer resources, I’d recommend having one, rather than diluting resources on two. And ending up with limited, buggy support for two.

Python is not hard to learn. There is a ton of help on the web. In the case of using scripting or programming tools to automate tasks in any CAD package, the CAD portion is typically what people perceive as hard. Mostly because it is an API (Application Programming Interface) added onto the language so the language can access the details of the CAD package. The interaction between GUI, CAD constructs, and the API is where the learning curve is steeper than learning just the programming language on it’s own. (Especially if you attempt to learn both at the same time.) The point here is there maybe 1000 examples of how to use a tuple on the web, but, not how they are used when working with a particular API. Hence, examples and good documentation for the API is essential.

Again…just my $.02 (USD), YMMV. :wink:


This is what I meant by “arduino like wrapper library”. Not very obvious maybe.

@KiCADsmktec I don’t know how straight forward it’d be to make the python stuff available from VB.

Since the python stuff can be called from standalone python scripts, one possible workaround is to have little scriptlets that you’d call from VB.

I don’t know if the effort would be worth it. To me VB means windows, and my luck with getting non MS languages to work there (python and perl come to mind. stuff within cygwin is an exception but I don’t believe that help us here). So once you’ve got a python scriplet working, you’d then have to get the VB shell call to python to work.

I’d encourage you to look at the examples in my blog (mentioned in one of the earlier posts).

@bobc I’ve thought about developing a wrapper for the python APIs, also in python but more consistent. Each of kicad’s classes does things a little bit different. The wrapper would make things more uniform. For example, to get the name, you call getName. To get the parent, call getParent. To get children call getChildren. They’d all return a python list, not a goofy swig wrapper…

As for the status quo, I’m guessing that there is a desire by users to have easier programming type interfaces. The problem is that there are few people with the skillset, desire, and time to implement them.

@rickb I believe you emailed me about ulp stuff. I replied but I don’t know if you’ve received it.
I still don’t fully understand it, but there is a nice feature that I’ve seen in another CAD tool that could be relevant here.

In that tool, all significant GUI interactions were recorded into a file. (mouse clicks, key bindings, button clicks…) Those could then be read back into the tool. It was developed as a recovery mechanism for debugging and to avoid losing data when the tool crashed (all too frequent)

Over time that recovery mechanism was used for macro type stuff. Folks wrote scripts to write stuff in the recovery syntax.

Either way, it seems there’s a need for several interfaces at varying levels of complexity. Macros, python, c++. My opinion is that a ton of stuff should move from c++ to python. Way more accessible to way more people. I can’t comment on macros, since “real” programming languages feel natural to me.

Kudos (or condolences) to anyone who’s made it to the end of my rambling.

1 Like

@Miles: I did get your reply, but had not yet formulated a response. See the links I posted in my first post to understand what I am talking about.

It’s no surprise that Python won this poll, given that the responders are almost certainly programmers. I see no problem with having a language available for low level access to KiCad, but for non-programmers, an application specific command language similar to what is available in Eagle is more accessible.

That command language I am referring to is already in KiCad, in the form of mouse clicks, key modifiers and keyboard data entry, we just need a way to access it programmatically via script files written in a command line editing window that can be called/made visible when needed. Command files can be saved and called by name or bound to a keystroke combination. In Eagle, .scr files can call .ulp files when lower level access is needed. I suspect that Eagle’s command line interface functionality can be written as a Python plugin by the many Python programmers that responded to this poll. :smiley:

Again, take a look at the links in my first post.


using python scriplet as a work around seems a good idea, though it
means that I have to get familiar with python first.
Myself I use windows only and I believe many poeple do. So, all my work
is in C++ or now mostly in VB.

I have no specific objections to Python (no love for it either), but what about JavaScript as a second script language (if there must be one)? Huge pool of available developers, tutorials, guides, etc to leverage. A simplified subset exposing C++ classes is not too hard to integrate using an engine like Duktape (I’ve used it myself to script a C++ application). Easy to use created scripts in web-based sharing / checking / etc platforms.

IMHO a far better option than something like the proprietary Eagle stuff that might cause legal and/or ‘eternal catch-up’ issues or as horrid as (Visual) Basic. Lua might be okay, but I see no real advantages over either Python or JavaScript in a non-embedded environment.

1 Like

Because vb came up here a (relevant) excerpt from the wikipedia page about vb:

Visual Basic is a third-generation event-driven programming language and integrated development environment (IDE) from Microsoft for its Component Object Model (COM) programming model first released in 1991 and declared legacy during 2008.

So yea, so much for vb. (There is “visual basic .net” but as @StefanHamminga already said it is a windows only product! as is c# and everything else that uses the .net interpreter.)

c and c++ do not work because they are compiled languages.

What is left? Python, java script (or better coffee script?), go, …
To be honest it really doesn’t matter. I restriction that comes to mind is: kicad should use a scripting language that is fully under the public domain. We don’t want to hand over control over parts of kicad to anybody or do we? Just think about the oracle vs google mess about java copyright claims that took place in the last few years. (But all above mentioned scripting languages fulfill this property.)

The main reason i would prefer python over anything else is because currently there already is a pyhton api and i don’t think it is a good idea to use development resources to implement another scripting api. (The resources can be used in a much more productive way. And it really does not matter what language is used. There are always people who do not like it.)

About the macro stuff that came up: I really like this idea! (Or at least some easy way to repeat an action for a selection. Example change the font size of multiple text fields.)

I don’t think he is trying to replace the official python API with VB. He just want access to it from VB wich happens to be his preferred language

I agree. Having worked a little with KiCAD scripting I don’t think Python is the problem. Python scripts can indeed be a powerful tool to create footprints or automating repetitive tasks in the layout. It also seems Python is becoming the de facto scripting language for open-source projects, with highly successful projects such as Blender and FreeCAD.

That said, I have found using the Python script in KiCAD quite difficult to use compared to for example Python in FreeCAD. This is not a problem with Python itself, but rather the often out-of-date documentation and non intuitive error-messages provided by KiCAD. But looking from the nightly builds, this is something that will be greatly improved in future releases.

To make life easier for “non-python” people, a nice feature to consider is the recording function in for example FreeCAD. In FreeCAD, every command you execute from the GUI is recorded in a log file and executed as a Python command. This way it is very easy to just cut-and-paste from the log file to create scripts that do what you want.


What on earth are you talking about? There is nothing proprietary about a command language for KiCad just because Eagle has one! Legal or catch-up issues? Why are you comparing KiCads command set with visual basic? What are you smoking? I would suggest that you go back and re-read my posts and try to understand them.


Just to clarify, there is no suggestion on the table that an “Eagle compatible” command or script language could be implemented for KiCad - apart from any legal issues, it just couldn’t be done as the underlying code is too different.


We are from all over the world communicating in a foreign language and have a huge span of technical experience so please, play nice if there are misunderstandings. :slight_smile:

:sunny: :couple_with_heart: :hearts: :tulip: :sunny:


Couldn’t have said it better… :+1:


…more and more user interfaces are today switching to Python, just because it is most probably because of the balance of being powerful, flexible, yet still quite easy to learn. I am still in the progress of learning Python, but I do strongly believe that it is the currently best option which the developers chose here.

When it comes to incomprehensible error messages - I believe that this is not dependent on the actual scripting language used, and of course, independent of the scripting language used there should be enough working examples around to learn how to use the scripts. However, this should not be the responsibility of the developers alone, but all of the community.

1 Like