couple of TODOs:

• Prevent crash when rotate goes to zero (for example because the solver pushed it there)
• Find similar edge cases if they exist

In a future PR, we should look into adding ceiling and floor operators to expressions.

Playing around with a silly demo. Very excited to have something super parametric for CAD work! It's either simple "substitution" for parameters in other CADs (that inevitably break your geometric contracts), or pulling teeth out one-by-one in OpenSCAD over a relatively simple design (no offense, love openSCAD).

Excited for the power duo: A simple-to-use WSYWIG CAD with true parametric support that upholds your geometry.

https://youtu.be/qX3N7cF-32w

TODO: Helix's get stuck (maybe?) and effectively become revolves if their expressions evaluates to zero or constraint on its parameter gets deleted (in this case we should display a popup and go back to the non-fixed behavior). Inspect solver input, correctly condition equations, or "avoid" zero expressions from making it anywhere.
TODO: confirm this doesn't break savefile backwards compatibility. (mostly just conditionals everywhere to pick between val and expressions when evalutating or displaying). likely will be taken care of by some encapsulation of the (expression string, expression tree, evaluated value) tuple.
TODO: scale groups, for sake of completeness
TODO: gracefully display/handle unit conversions elsewhere (for example in Helix length per turn)

@dgramop I finally got a look at this. I kind of like the idea of being able to use expressions in the TW, but I don't think this is the right approach. While looking at the Helix Pitch implementation I do think i made an error. The code computes the pitch based on the group parameters for angle and linear displacement and displays that. It uses valB of the group to store the users pitch (which is IMHO a mistake) and if they specify a non-zero value it creates a constraint to enforce that value. I didn't know any better at the time.

What I think should have been done is the group should have created a pitch parameter and a constraint. The new parameter and constraint would result in the same DoF. Then the text window could just show the pitch parameter and offer a way to lock it. I'm not sure how to lock a parameter, but worst case would be to create a simple pitch=value constraint. Notice that I'm talking about a generic parameter and not group->valB. Then we could allow an expression on the right hand side of that constraint equation. I'm not exactly sure where that expression string would live, but I'm pretty sure adding new members to the group is not the way to go.

I do suggest keeping this PR around as an example for now. I'm doing my own stuff in the "parameters" space, but that doesn't mean anything is decided yet ;-)

Yep, I'm reading your comments on other PRs/issues and that approach makes sense. I think it's good for us to stabilize and centralize over some single pattern for parameters. As (i think @ruevs pointed out) there are far too many different models (some of them dead code) in solvespace for this.

I have a few cad models that use this feature so at some point I might have to migrate save files. Also I noticed severe performance issues (likely introduced by some extra call to something somewhere) for drawings made of linked .slvs files. Not yet sure if the same bug exists on master