I have to agree here, grouping isn’t the same.
My designs are simple enough that I can get by without constraint logic, but it’s seriously useful to have when you need everything to have exact dimensions for 3D printed cases.
It seems like a massive project that’s probably not a top priority for most people, but it’s also useful enough to avoid using data structures that would make it harder in the future.
If it never happens, it’s still the most promising PCB app I’ve seen, but constraints are pretty awesome.
“Real” constraints that allow you to constrain things relative to arbitrary points on a footprints could wind up being a major thing that touches every part of… Everything…
It seems like easiest way would be to let footprints contain an explicit 2D outline(Falling back to the literal copper and silk bounding box) that represents the mechanical bounds of the part, maybe with freestanding points that aren’t part of an edge to denote things like LED centers.
If the outline ever changed the number of points, you could run into topological naming problems that messed up existing PCBs, so you’d have to give every point a UUID, or just limit things to a four point box model, or forbid reloading footprints if the number of points changed.
I suppose edges could be named for the two UUID points they have.
There’s plenty of FOSS solver libs for that kind of thing.
You’d probably also want to be able to constrain all the points of the edge cutout and any milled areas.
For a somewhat hacky way to make interfacing with the solver easier, you could internally generate constraints that fixed every point in an part to that part’s origin, so they moved as a group.
Then just add the user constraints, dump everything in the solver, read out the origins, and set the part origins to match what the solver says they should be.
I’m not sure how the C++ libs are, but the Python bindings to the SolveSpace solver look pretty easy, and gecode has their epic industrial grade every constraint you can imagine library too.