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.
4 Likes
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.
Rick
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.
2 Likes
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. 
5 Likes
Couldn’t have said it better… 
2 Likes
…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
Personally I can just about stand Python, I guess it’s mostly a community/tooling thing. I’m a software engineer with background in JVM and Node and mostly favour statically typed languages. To me, it’s a bit of a hassle starting out trying to script in Python because my lack of experience.
A binding for the API to run in Node.js would be awesome. I understand Python has been a choice for many plugin scripting tools, but js/node is gaining there I think. Look at OpenPNP, for example.
With a node.js binding I would be up and running within minutes compared to my current stumble with python path hell on OSX. My current understanding is also that the pcbnew.py file is entirely autogenerated from C/C++ with SWIG (file header says so). I know nothing about SWIG and swip.org is currently down, but if it was possible to generate node.js bindings I would be happy to curate this if someone could give me a bit of first pointers. I could do typings for Typescript and maybe even Purescript bindings if it would be reasonable.
The more the merrier I feel, if it’s not too hard to maintain it wouldn’t hurt to support more scripting langs…
That’s a good point, if the Python is auto-generated, something else could be too…
That said, there are other non-language issues with adding ever-more choices - you risk dilute of the critical mass, and none of them ever are quite properly finished.
My main issues, with the little KiCad Python I’ve tried, are not really with the language itself, but more with the poorer debug and ‘what can be done’ documentation side of things.
A good example is this useful code I looked at recently
Seems to be quite small lines-of-code, and I can scan read most of it, but I then look for the key add actions.
Obvious are self.board.Add(newtrack) & self.board.Add(newvia) but that leaves other items, looks like zones are
newzone = self.board.InsertArea(to_net,…) but more elusive is the line that creates new text ?
Other scripts I’ve used have a simple GUI wrapper that lists the database items as a tree, and their supported operations.
Good question, to me there are two different types of script.
- Read-only scripts, which scan and report and should be inherently ‘safe’
- Write scripts, which might change co-ordinates, attributes, or even add/delete items.
Clearly, Write scripts are less-safe 
Perhaps an explicit read-only import, can be used for safest ?
1 Like