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.
@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.
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.
Remember that Kicad is cross platform, so I think you’ll get pushback from the developers (and users of non-Windows platforms) if there is a suggestion that a Windows-only language (like Visual Basic) should be used for scripting.
Python is cross-platform, so its use here is not surprising.
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.
Couldn’t have said it better…
…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.
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 ?