I cloned your repo and the tried the via fence plugin. It works, but the vias it places cannot be selected and cannot be deleted (except all of them with CTRL-Z). I even tried explicitly locking and then unlocking a couple of them individually, but to no avail. (And I did make sure the selection filter included vias.)
The three μwave footprint wizards do show up as wizard options, but none of them works right. I get errors on all three of them. Maybe I am doing something wrong?
This would basically imply removing the Python bindings and make every imaginable feature an integrated part of the KiCad codebase - this does not sound viable to me.
Ideally, a specific plugin/automation API should be created which can incorporate adaptations to smaller changes of the C++ codebase. In case new features can’t be easily supported, a new API version should be published (without removing older ones) which new plugins can be written against.
All of that, of course, is much easier said than done.
If you leave the python, then support for the main plugins must be left on the developers of the kicad… The main plugins include panelization of production file generation, etc… To not the main plugins beautiful pictures and duplicate functions of the kicad itself… But judging by how much the curve and the unfinished came out 7 this will not happen soon but I need to work now)) and not sit and wait 8… Plugins appear due to the absence of these functions in the kicad itself or if they exist, they work poorly
Negative, after performing the operation of via fencing, saving, shutting down KiCAD7 completely, and restarting it, the fencing vias are still not selectable and not deletable. There seems to be something special about them.
@davidsrsb, thank you very much for your test file! I played with it in the editor and subsequently played with my own test file with via fencing. I made some interesting discoveries, which I am sharing here for the benefit of all KiCAD users.
Some of your stitching vias were selectable and some not. The ones which were selectable could also be deleted and responded to pressing E (properties); the others did not. I did a search for ‘[Gg]roup’ (in neovim) and located the group of the stitching vias. I deleted some of them (each of them was in its own text line) in the editor and then reloaded your test file. Indeed, some of the stitching vias were removed and more vias became selectable and deletable.
Armed with this knowledge, I started hacking my test file with the fencing vias in the editor. Here is where things got really-really weird. In my original test file (attached here) none of the fencing vias was selectable or deletable or responded to E. Now, in the editor, I went to the fencing group and deleted all vias in it, while leaving the group decleration stand (essentially creating an empty via-fencing group). Now, all fencing vias (which should have disappeared, remember) were still there and each of them behaved normally, that is, could be selected, deleted, and responded to E!
I am attaching the initial file with the nonempty via-fencing group and the modified one where the via-fencing group is empty. The via fence straddles the trace ‘TEMP_ANODE’, towards the “north” side of the board. (The two topmost fencing vias should not have been placed, but they are there because I turned off the option to delete vias which violate DRCs.) Observe that in the second file, with the empty via group, all fencing vias (which should have disappeared!) behave normally! RXcard1.kicad_pcb (265.8 KB) RX1_empty_group.kicad_pcb (265.5 KB)
Why do you expect this?
The vias are in the file as individual objects, each with a net. Their tstamp reference is then reused in the group list. I would expect deleting from the group list to free up each via as individual vias that can be moved or deleted
well, it was clearly communicated, that not every bug was detected and not every plugin converted for v7 as it released. sensible update policy on your side would have been checking if the needed features work with the new version beforehand or not. as the saying goes: never play on patch day.
and btw, you can complain about voluntary maintained plugins all day but you have to understand that if they would not be there as plugins, they would not be in the main program as well. the plugin developers greatly expand the development resources kicad has, unless you want to pay kicad multiple full-time employees on your own there is no way the base programming team can match these additional ressources and create the features everybody wants.
I have included the changes and harmonized the code to allow kv5,kv6,kv7 to work with the same repo…
Also uwave wizards should be compatibles.
Please test RF-tools-KiCAD in your environment.
P.S. just out of curiosity (or for fun) I checked the same code in kv8 (7.99) and it does fail
Thanks! Since your bindings changes seem to be similar in nature to mine, have you by chance encountered a B command that hangs during the Building zone fills… dialog?
I had a look at SWIG and think I understand what you mean. What we think of as the “API” is dynamic because the interface file(s) for SWIG change if the underlying C++ code changes?
as a Hobby-single-sided-PCB-maker most KiCad Development is not meant for me but over time, from 4.x to 6.x a lot of my demands have been fulfilled anyway, slowly creeping in. I know a 100% HF man and problem is he knows everything about microwave but little about SW and its requirements. KiCad would need a HF-Software developer to push this, possibly a rare species ?!
