Proposal

I'd like to outline a path to #80 Hierachical sketches that starts with #77 - Parametric sketches.

1. First we need the named parameters. The evil-spirit approach of adding names to existing solver parameters seems better than creating separate things called Variables. That is being looked at closely as I write this.

2. Second, we need a way to enter Name/Value pairs for these parameters. I see equation constraints (like comment constraints) as an interesting way to do this which also makes Solvespace start to look like a mathematics scratchpad of sorts. But I also think it's important to be able to specify these in the text window. Each group could have name/value pairs specified in the text window - this might also be a useful place to specify units per parameter, which would default to the currently selected units, but I'm not too concerned about that right now. Handling units is currenly a major topic.

3. Scope: What happens when a named parameter is used in a group that has no definition for it? We should look up the hierarchy (is it actually just a list right now?) to find its value and treat it as constant if it's defined in a prior group.

4. Globals: I think adding Name/Value pairs in g001-references is a good place to define globals used throughout the sketch. There isn't much in this group, and no way to add geometry so the text window is mostly empty when clicking this group. It also comes before everything else, and every sketch has this group.

5. Linking: Linked sketches would behave exactly as-is for now, but we could display their g001 global parameters in the text window of the enclosing sketch in that group. This would be like Mask parameters in simulink models if you're familiar. So a user could create multiple files that are all copies but with different parameters. When linking these into a larger sketch, each linked sketch would show its specific parameter values in the text window when clicked. This would be nothing but a pure UI change to display the globals of a linked sketch - no editing.

6. No global sketch: The main issue with hierarchical sketches is that Solvespace currently has a single global sketch. A major step is to refactor so sub-sketches can be loaded and solved. The refactoring could be done without affecting the UI, UX, or file format - just internal code changes.

7. Per-instance parameters: Once the global sketch is eliminated and we think some kind of multi-sketch capability is in place, use that to actually load linked sketches in their entirety and solve them. Then allow editing the top-level parameters within the UI of the enclising sketch on a per-copy basis. In other words, allow the parameter editing that step 5 will have users clamoring for. This does mean makeing a copy of those variables into the link group and using those in the sub-sketch when solving it. But now instances can each be different without changing the linked file.

8. Beyond that, I think a fundamental change to the internal data structures and file format might be a good thing. There is a lot that could be done for Hierarchical sketches #80 but by follwing the outline above I think a lot of the core functionality can be incrementally built and proven without disruption to users.

Lets keep most of the units discussion in #77 for now, but more general comments on this path forward can go here. People I most want to ping for feedback: @ruevs @jwesthues @dgramop