What is the state of RF/μwave tools in KiCAD7? In the past, I think up to version 4, KiCAD had a dedicated μwave tool. Later, that tool disappeared, but @maui 's excellent work made up for the disappearance. At the moment, on KiCAD7, it seems to me that all RF/μwave plugins except 'Measure Track Length" (Track Rounder, Slder Mask Expander, crash. The footprint wizards (mW Arch Pad, uW Mitered Bend, and uW Taper Pad,…) also crash. I have installed pyclipper. The crash error reports I am getting all seem to have something to do with malformed data passed on to KiCAD. Did the API change going from KiCAD6 to KiCAD7? The RF toolkit gitgub page mentions compatibility with KiCAD5 and 6 only, not 7, but I thought these tools were almost mainstream. Or am I doing something wrong?
All plugins on the python for version 7 have api changes further updating plugins depends on their developers but not on the kicad without any guarantees, unfortunately
And why exactly did the API have to change going from 6 to 7? Apologies if my question is naïve, but one reason for KiCAD’s rising popularity is its plugins. Thank you for your quick response, @m852 !
As far as I understand, the developers of kicad are gradually moving away from external modules on the python and embedding new functions directly into the program code. This makes it much easier to contain and maintain code… The second thing is that many new functions could not be done without updating the api… I think in more detail they themselves will answer…
KiCad does not currently have an API in the true meaning of the term. It only has Python bindings which are largely generated automatically from C++ code. This means that we can’t offer stability guarantees from release to release for these bindings, because the underlying C++ code often changes as part of refactoring to fix bugs / add new features. There is work underway to solve this problem but it is slow going.
unfortunately very low priority has been assigned to this task…
By changing the functions so much programmers are disincentivized to code to reinventing the wheel each new kicad release
it seems to me that plugins are not considered enough relevant to kicad environment
We end users value your plugins
I need the RF functions
I understand your frustration.
In my opinion, the current SWIG bindings should never have been created (in the way they were). They were destined to create this problem by design, and now we are buried under their technical debt.
But, they were created, and so now it is at least possible to do some scripting, even though there is no API. Unfortunately it is not practical to treat SWIG as an API on the C++ side, it would prevent us from fixing and improving KiCad in a serious way.
I wouldn’t say that. It’s just a much harder task than it sounds like, and it’s also not the highest priority, because even though it’s not a great situation for plugin writers, it’s at least possible to deal with (and some have even created libraries to help deal with this, like GitHub - yaqwsx/pcbnewTransition: Library that allows you to support both, KiCAD 5 and KiCAD 6 in your plugins ). It is true that we put a higher priority on fixing issues that don’t have a workaround at all.
unfortunately it was simply bypassed from kicad v5 (2018) till now (2023) … it seems to me a very low priority and low consideration in the plugin ecosystem, which imo is an advantage for kicad itself.
Plugins have solved many problems and anticipated many new features related to use cases that are not simple or marginal.
thanks for the link … interesting library for porting tips
thanks also to @MitjaN for his useful tips
but as I said the problem is not in coding but in having to rearrange what was just working before, spending time on something not innovative or creative
This is what it’s like to work on the KiCad codebase too 
I think this is probably the case for any long-standing software project.
Just because nothing has shipped publicly yet doesn’t mean nobody has been working on it.
nor publicity nor result 
ok, sorry I didn’t want to be too brave 
In order for this to work well, it must be part of the program and not a python plugin developed by a student by an amateur or just a person by a programming lover without guarantees of updates and work. All add-ons should be supported by Kicad developers in this case you get full cad support
I have bad news for you about who writes KiCad…
The point is not in the level of programming but in the fact that different people who are not related to each other are engaged in this as different projects
I think that’s a feature. KiCad can focus on the needs of 90% of users, and the other 10% who all have different needs from each other can be supported by a larger number of developers.
And what is included in the needs of 90 percent of users?) In my understanding, electronics are not only arduine) For example, power or high-frequency is very different and for this there must be tools so, for example, how I don’t have to jump from altium to kicad and back depending on the project)
If we had a lot of upvotes on a GitLab feature request relating to RF features, that would be a good indication that it is important to the 90 percent.
If you think so, then Kicad has no prospects for further development as a full-fledged cad for different areas of electronics… And in the 8-9 version, we will receive an interface change and line replacement) no more… Just look at successful cad and what they offer
The problem is, let’s say (imagine) that 5% would need feature X, 5% feature Y, 5% Z, 5% Å, 5% Ä, 5% Ö etc. Should the developers put those users in a ring with gloves to see who wins their feature? Eventually all those features may be implemented, but it takes time.
Personally postponing the new API when v6 was released and then v7 was the biggest disappointment to me. But I knew the development was (and hopefully is) going on behind the scenes. We would just like to have a bit more updates every now and then, even if nothing visible happens.
I’m not talking about small functions are global things of any full cad end-to-end design… It doesn’t matter if you are developing an arduine or rf satellite module or power electronics for this should be the main set of tools and these are not 5 percent functions…
It’s like a modern car where there are steering wheel and seat pedals and you ride on all roads with different surfaces that you can’t say about F1. And they are trying to convince me that three wheels are normal and 4 will be delivered to you in the service, but this is not accurate and without guarantees)))