Added support for equal lengths, equal radius, horizontal and vertical constraints as well.

Let me know if this is something we would like to add, I think it makes thinks a lot easier, especially since there is not really a good way to select / deselect stuff, so getting the selection exactly right can be time consuming.

This PR is still missing updated text labels for valid selections, and the logic could be added to some other operations as well, but I'll first wait to see if this is something we would like to add.

For reference #530

Interesting.. I guess I should have searched first...
At least it validates the idea...
What is your current stance on this subject?

I think this will already be an improvement even without a select -> run tool workflow?

I really liked the idea in #530 but there are potential problems. If we add multiple constraints A=B B=C C=D and then the user comes along and deletes the B=C constraint then the group of equal things is split in two groups without any indication.

What is the scenario where you want to do multiple pairs of points-coincident? I'm not sure that makes sense given the other (obvious?) interpretation of forcing all selected points to be coincident.

Given 2 people have gone to the trouble of doing implementations and submitting PRs I'd say creation of multiple constraints at once is a much desired feature. Maybe we should give it a try after 3.0 is out?

BTW I'd also like more constraints for faces - faces perpendicular, faces parallel. Not sure what the visual representation of those would look like.

Isn't that already the case with how things work right now? I don't think this change would make it worse.

Basically this becomes useful when points are overlapping but not constrained yet.
This can happen when mirroring a drawing and especially when step translating a drawing, you end up with possibly a whole bunch of these, and to connect them all "by hand" just takes a long time.
Imagine drawing a saw blade with 50 tooth, you draw a single tooth /\ , step translate it 50 times, now you have to go and connect all the bottoms together, and if you want all tooth to be the same length, you also have to add the equal length constraint one after the other.

With this PR, you simply select the bottom row of all the points, and add the coincident constraint, then select the edge chain and add the equal length constraint, done.

Since it doesn't interfere with other operations, I don't see many downsides at this point.

Those other constraints sound very useful as well!

Step rotating and translating create new groups with only 1 or 2 degrees of freedom. You dont need all those constraints and if you do it will be over constrained. The copies are not independent.

@vespakoen did you mean repeated copy / paste transformed? That would leave a lot of things to constrain vs doing the same with a step-rotating or step-translating new group.

Oh yes, I meant "paste transformed" indeed.
I wasn't aware of the Step Rotating / Translating of groups, which seems to be a very handy features!

I guess these "batch" operations and "relaxing" of what is in the selection can still be useful.

Let me know if we want to implement the "batch", "relaxing", both or none and then I'll update (or close) this PR.

@vespakoen funny, I only learned that paste-transformed could do that last week. The step groups are nice but they repeat an entire sketch, so if you want a grid of holes in a rectangle you need to step-repeat the holes first and then draw the rectangle around them. BTW those also work for 3D groups including holes. Whatever solid was last created for a new 3D group can be repeated.

I just ran across this function: GraphicsWindow::FixConstraintsForRequestBeingDeleted() which has the following comment above it:

//-----------------------------------------------------------------------------
// Let's say that A is coincident with B, and B is coincident with C. This
// implies that A is coincident with C; but if we delete B, then both
// constraints must be deleted too (since they reference B), and A is no
// longer constrained to C. This routine adds back that constraint.
//-----------------------------------------------------------------------------

This might make it OK.
@77maxikov have you tried deleting one of your constraints from PR #530? Can a set of equal things get broken into two sets of equal things by deleting? That was my main concern although previous maintainer has other issues.

Just to explain my point of view on multiple constrainnig - it is only my job to check whether design is changed after deletion of one of these constraints - not software's. Maybe it is because of "locality" of such constraints in my designs - often equal segments for example are situated near each other and if I want to make a distant one beeing equal to them I just select one of those and add equal constraint to this distant one, not constrainig this distant one to each those equal. Also I would prefer having A=B, B=C rather than A=B, B=C,A=C for performance reasons.

@vespakoen yes, we want this feature. Have a look at the other PR and either keep going, merge them, or suggest we use the other one ;-) I'm interested in cleaning up these old PRs one way or the other.

Used 1314 which was the other PR rebased.