Thanks very much for your feedback!
First of although the length stays fixed, the height changes each time you change the radius.
Yes. That's a feature my implementation shares with yours. Leaving that untouched for now was an intentional choice, see my first post. I find "height" ambiguous for restricting the bent leg, but I proposed to introduce "lenbent" for that second parameter at a later point, as opposed to "lenfixed" for the fixed leg.
Let me add a drawing to clarify the terms.
The base solid is yellow, "radius", "length" and "angle" are status quo parameters, "lenfixed" and "lenbent" are what I'd like to add, with "pad" being squeezed in automatically.
I chose to try and introduce "lenfixed" and "lenbent" incrementally, because:
a) "lenfixed" in itself is already an improvement over the current situation, and I have trouble seeing how a parameter of sorts could be avoided in the future anyway, see below. Currently, a bend will take up 21.7543 mm, depending on radius and length. With the patch, you can nail that to 20.0 mm lenfixed off the base face and go from there.
b) "lenfixed" is lenbent's prerequisite, but it can be implemented independently.
c) "lenbent", while mathematically easier without 3d-rotation, will clutter your code beyond recognition with a distinction of cases (< 90°, 90°, overbent)
d) "lenbent" will introduce an overconstrained situation between the parameters "angle", "length", "lenfixed" and "lenbent" which needs to be discussed. My plans for the semantics were:
- as long as there are enough parameters lenfixed or lenbent disabled (i.e. equal zero), solve it
- as soon as an overconstraint is specified, make "length" the dependent variable, and have FreeCAD adapt it accordingly
This way, the current semantics of "length" would be mostly left intact. As good as it gets.
Second, lets say you start with an 80 by 80 plate and add a fixed 10mm bend on each side to get a 100 by 100 box. The spacing between the walls an in the corner are too big. What I was thinking off, is if I know I want a 100 by 100 box, I will start with a 100 by 100 plate, and each bend will "cut" from the original plate such that the it will stay 100 by 100. In this case instead of another "lenfixed" parameter, you just need to add a Boolean that's determins if you use fixed length or not. this way, in the case of fixed length, the height will also be set to fixed. This is where collisions might occur if you want to bend several sides. (they cut one over the other)
I see. Let me try to respectfully win you over to my approach, as it avoids the problem altogether and leaves collision resolution to the user. Bends are created as seperate animals within your workbench, and I find that a good thing. Why make them depend on one another? It would break the semantics of adding independent bends. I'm very new to FreeCAD, but it would seem to me that this would also break the typical FreeCAD way of doing things.
In my book, a bend is a bend is a bend. If I were to make a part by hand, I would want a drawing with dimensions spanning the whole part. That's because putting a calliper around the whole thing is easier than finding the line where a bend starts. But for modeling? I fail to see how blending multiple bends into an interconnected entity could integrate well with a generic workflow. For your example, I would design an 80x80 base plate and add two bends, each of them constrained to 10 mm lenfixed, job done. But then again, maybe that's just my lack of imagination.
Another issue to take into account, is what will be the behavior when the bend is not 90 degrees.
Yeah, seconds my point, I'd say. The patch already handles over- and underbent legs in a sensible way, have you tried?
Regarding backward compatibility. This is an important issue, specially if you add parameters.
You must take 2 things into consideration:
1. there are no edge "names" only list of edges which get an automatic "EdgeX" name based on its position in the array.
Hm. No edge names involved, but there are face names stored with a bend object, see Document.xml in the .fcstd-file: <Sub value="Face6"/>
That's the name of the base object's face the bend grew out of. Your workbench bases all of a bend's existence on that name. Now, if you have Bend2 hanging off Bend1, and Bend1 has changed its face names during Save - Restart FreeCAD - Open, Bend2 will try to grow out of the wrong face upon redraw and fail miserably. I've changed the patch to replay the order of fuse operations of the original implementation, and that seems to work. Not sure though if that will guarantee deterministic face naming under all circumstances, also given that I optionally want to fuse in the pad solid in the process, but for the few older drawings I have, it worked.
2. old models loaded must be detected and a new "lenfixed" parameter added to them so it will no crush when looking for this missing parameter.
You are absolutely right, that's a bug in the last patch. The attached updated patch hopefully fixes that. I added compatibility checks to SMBendWall.execute() and SMViewProviderTree.attach(), which did the trick all situations I have tested. That might well be overkill or the wrong places, though. FreeCAD's API is still lots of guess-work for me, I must admit.