The first example on the main page has a formula with two variables being updated from changing one value. The immediate question I have is if I change the output, where does the extra degree of freedom come from on the inputs? Does one stay locked in place? Unclear.
I am a huge fan of the concept though. It's been bugging me for years that my spreadsheet doesn't allow editing text fields after filtering and sorting them down to the subset I want. I have to go all the way back to the mess of unsorted input rows to actually edit them.
You can do this with bidicalc already! You just have to model the problem correctly. If you expect the ratio to remain constant, what you actually want is a problem with a single free variable: the scale.
A1 = 1.0 // the scale, your variable
A2 = 6 * A1 // intermediate values
A3 = 8 * A1
A4 = A2 + A3 // the sum
Now update A4 (or any other cell!) and the scale (A1, the only variable) will update as you expect.
100% this. When I reached the end of that page I felt pranked because the obvious question was never answered. How are these cases resolved? Is it possible to fix some inputs and only update others? What if I sometimes want to change input A, and other times I want to update input B? All this should be explained as early as possible.
You can do it and it is explained, actually. Use # as a prefix to indicate a constant, e.g.: #50 will be a constant and not a variable.
In the future I'd like to support more user input constraints, in particular domain constraints for variables. So you could tell the solver that this cell must remain in some interval, and it would respect that interval instead of assigning any real value.
I got into FreeCAD's python interface, and then Cadquery for 3d printing a few years back, and I think you've got about 70% of the solution.
Things you've got right:
- Human-readable text file is source of truth
- GUI editing is first-class, because it's easier to work on (most of the time)
Features your proposed solution is missing that I want:
- Full power of an established programming language. Yaml or json won't cut it.
- Code and GUI on equal footing. Edit in GUI -> see generated code. Edit in code -> see result on model.
The main problem with Cadquery is that it's entirely code-first, and you lose out on the intuitiveness of GUI editing
One of the less obvious things I really like about dealing with code cad is that feature selection can be based on intent. Like "upper-rightmost feature" rather than "feature closest to this coordinate I just clicked". There's got to be a good way to incorporate this aspect into the "edit in GUI -> code is generated" step (without just requiring manual code editing), but I'm not good enough at UX immediately see it.
