willrshansen
Doing CAD with code seems like obviously the right move to me. The ability to just write new functions in python and do version control with git are super powerful.
The big thing that struck me as innovative with CadQuery is the design intent query part. Selecting model geometry by relation to other geometry is way more resilient to changes ealier in the model's history than the regular "that point right there" you get with just clicking a point.
That the developers acknowledge that seeing the model at various steps in the script is important, and so have the CQ-editor, is also a point in their favour.
I do have a gripe though:
Having to keep all the geometry selection stuff relating to the model in my head is hard. I want gui tools that write code.
Like if I have a complex model, and variables assigned to various parts of the geometry. I want to be able to see that geometry highlighted and labeled, so I know what's easily selectable, and I want to be able to click buttons based on my design intent and get immediate visual feedback, and have each of those button presses added as code as I do them.
Look at this example model: https://cadquery.readthedocs.io/en/latest/examples.html#a-pa...
This bit that selects some points?
# compute centers for screw holes
topOfLidCenters = (
cutlip
.faces(">Z")
.workplane(centerOption="CenterOfMass")
.rect(POSTWIDTH, POSTLENGTH, forConstruction=True)
.vertices()
)
Each of those lines should be a gui tool interaction that generates that line of code.No way this isn't heavily studies by now.
Edit: found a whole meta-study in like 30 seconds of searching: https://www.frontiersin.org/journals/public-health/articles/...
terminal multiplexer
term mux
tmux
Switch to USBC from the old audio jacks though? Negotiable
For example, I really like the "select then edit" approach of Helix, but Vim doesn't really play nice with that (there may be better plugins since I last looked to be fair). File handling, buffer rendering, and frames have very little to do with that, and yet I have to switch editors, lose all my plugins and configurations, and switch all those subsystems at once.
There's missed opportunities for modularization.
I want to be able to piece together an editor from modular task specific executables. Different programs for file searching, input mapping, buffer modification and display, etc. Probably similar to how LSPs are already separated from most editors.
One step less hardcore than writing a whole editor.
Anyone know of any existing projects along these lines?
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.
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 editingOne 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.