Taking into account the fact that in v8 again everyone will not break at the plugin level?)
If that happens, I’m sure the developers will hear about it again from many users and plugin developers. And they themselves would likewise be disappointed. Right now it’s not very useful to write post after post about it. Like I said, this is going in circles, the same things will be repeated and it doesn’t help at all.
1 Like
Apparently the solution is only one rollback to v6?
1 Like
Let’s be positive. The solution for now is for people who understand the changed API to help the plugin developers to move forwards to V7 compatibility.
3 Likes
Whatever
All we can do is give every assistance and encouragement to the plugin developers
3 Likes
Alright, I’ve updated mine for 7.0.0; maybe the changes can be useful for others (it’s the same as __init__.py in my official plugin, and the changes can be seen with git diff --no-index -w old.py new.py).
5 Likes
Btw, for RF tools there’s a pull request for 7.0 compatibility
5 Likes
Hi @dsa-t and Charles Grassin
thanks for the PR, that is a nice way to solve the discussion… cooperation 
I’m going to merge it and then adding some check to keep back compatibility w kv6 and kv5, which I use atm more than kv7.
7 Likes
@dsa-t, thank you for your great work!
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?
I had no involvement in this pull request actually, it’s not my repo. It’s better to leave these comments on Github.
See if restarting pcbnew helps. There is a bug with selections and plugins in 7.0.0 that will be fixed in next point release.
1 Like
On Windows with Rectangular fill, the vias seem to be in some composite object, even after a restart
Using Outline or Concentric, I am getting this error
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
What you see above in messages looks almost on all plugins and it’s sad
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.
Create a simple test project and have a look at the PCB file with a text editor
The vias are in a “Group”
Here is a trivial stitched PCB. The group and member list is at the end of the file
Test.kicad_pcb (28.8 KB)
@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
2 Likes