I like Build123d but I really want a hybrid mouse/code CAD built around it. I want to be able to click on entities and have them show up in the code editor instead of blindly trying to select edges.
This feature technically already exists in build123d + OCP CAD Viewer (ocp_vscode). You can click a feature in GUI and it will copy the index to clipboard, you can then apply e.g. fillets to it on the code side. See here https://github.com/bernhard-42/vscode-ocp-cad-viewer/blob/ma...
The biggest caveat is that there is currently absolutely zero mitigation for toponaming. This feature is extremely brittle, so I tend not to use it very much -- but I am still glad it exists for those situations when composing a selector is too annoying.
I've tried various code CADs before, and they're fine as long as what you're creating is simple enough to build from independent pieces, ideally that you can keep in your head. As soon as you need to refer to aspects that have been created within the CAD, like an edge, or a particular face of an extruded shape, the paradigm falls apart.
I agree, I love code-based CAD but there needs to be a hybrid with GUI tools because selecting stuff with a mouse will almost always be easier.
I known there is research out there (can't dig it up at the moment), but the goal would probably be to generate a robust geometric query for a selected item, so that small changes in the model don't affect which edge gets selected after subsequent operations.
So if you extruded a face upwards, and then filleted all the edges at the top of that extrusion, this hybrid tool would generate a query which gives you all the top edges, instead of whatever the indices of those edges happens to be. I can't imagine it's an easy problem though to generate robust queries for all possible geometry a user might select.
> I known there is research out there (can't dig it up at the moment), but the goal would probably be to generate a robust geometric query for a selected item, so that small changes in the model don't affect which edge gets selected after subsequent operations.
There is quite a bit of research that this is impossible. No matter what algorithm or heuristic you use, the second that symmetry is introduced, the query breaks down. The only way to resolve those issues is to present them to the user as an underspecified constraint, and no geometric kernel is well designed to do that.
The biggest caveat is that there is currently absolutely zero mitigation for toponaming. This feature is extremely brittle, so I tend not to use it very much -- but I am still glad it exists for those situations when composing a selector is too annoying.