How does this existing code handle the situation when the vias need to be deleted? How about handling them on-the-fly when tracks are pushed?
I believe that the “refining” idea where there are generating and generated items could be applied to zones and stiching, too. Zones with the same net on several layers could generate and delete vias automatically when zones are edited or items moved. To enable as easy board editing as possible the generated vias should be invisible to editing process, they shouldn’t be left there or moved but deleted when e.g. a track is pushed or a footprint moved over them.
I don’t think this would be possible with a simple non-file-format-changing solution. Same thing for fencing, the vias should be deleted/moved/generated on the fly when the track is changed. (In an ideal situation, of course - it’s great that less than ideal solutions are proposed and implemented, don’t get me wrong.)
Huh… I have to confess that Cal-linux and Python don’t get along (at all!) I’m more of a C++ fan (though I haven’t gotten into the newer, C++11 and later, features). I was into wxWidgets for a while (back when it was called wxWindows).
Is there any chance that I might get away with being able to contribute and not having to write a single line of Python?
Oh, man!! Those are neat! (I don’t think I have right now any need for via fencing or via stitching, but those are certainly important features to have to attract the RF community. I hope some of that work can be reused, despite the incompatibility with the old canvas (as I understood from Seth’s comment).
Although I have to say — I would rather see the feature implemented as a “routing mode” (a flag in the settings for the router), where you check a box “Round corners” (and supply any related parameters) and then the corners are rounded as you create the traces.
It’s the other way round, they were witten for the legacy canvas only. KiCad is creeping towards deprecating the old canvas, so all new features must run on GAL/Cairo
I can also see that true arcs in the database is quite complex to add, with many ripple effects. ie it will be a long time coming.
Perhaps the menu item of Add-curve can be added, pretty much as coded now, which splices in N segments, with an option for that to be Segments or Arc for future KiCad releases.
Yes, those are not easy to edit / move, but significant edits would re-draw the trace, and re-apply the curves last.
The examples show these as a niche feature, applied to just some traces in a design, so that level of user interaction is tolerable.
Similar with TearDrops. - those can be batch-added, and perhaps some fractional width can be used to tag the teardrop as ‘auto-generated’, allowing a re-generate to easily remove the old ones.
These would be a post-route, pre-pour apply step.
For easier manual editing, perhaps select could expand, to allow (eg) ‘trivial connection of same width’, which would pick all of an auto-generated teardrop, for manual delete.
I’ve found curved teardrops are best, to avoid clearance effects as they pack better.
As a bodge you can also turn on free angle routing in the interactive routing settings and draw the curves yourself.
I tend to draw it crude then redraw over to smooth it out. The auto delete old piece makes it very easy. And makes for much nicer lookign length matching than a random meander when you have the roo .
talking about RF, I have a friend who is a RF Professor and Nerd for many years. He has always been looking desperately for a SW that can handle RF needs. Even professional packages are letting you down when it comes to RF. So, yes, the RF people might embrace KiCad if it gives them some more exotic features. Right now the RF functions look a little bit abandoned…
I’m more of a C++ fan (though I haven’t gotten into the newer, C++11 and later, features). I was into wxWidgets for a while (back when it was called wxWindows).
