[guitarbill]

Maybe. But at a hobbyist level, is the problem really the kernel?

The problem is that OpenSCAD is easy to get started and the code-first approach is unbelievably useful - but too simplistic/limited. Meanwhile, FreeCAD is too complex, and often buggy.

There's also CADQuery, which is surprisingly good already. Don't get me wrong, the GUI (CQ-Editor) is unusably buggy. But the Jupyter notebook integration works amazingly well. If I were that project, I would work on a hot-reload, cross platform, standalone viewer only (in the same way people use OpenSCAD often). I would also pay for that, safe in the knowledge that the code produced can't be locked in so easily.

Is it a FreeCAD replacement? For better or worse, no. But it has let me avoid FreeCAD/Fusion360, while finally being free of OpenSCAD shortcomings.

[OJFord]

> Don't get me wrong, the GUI (CQ-Editor) is unusably buggy. But the Jupyter notebook integration works amazingly well. If I were that project, I would work on a hot-reload, cross platform, standalone viewer only (in the same way people use OpenSCAD often).

Couldn't you equivalently use any STL/STEP/AMF viewer?

Seems a good choice to me that the GUI is a separate/subordinate project. I suppose it is somewhat necessary to have it at all, easier to gain popularity if you can show screenshots and have a single app 'quickstart'.

[guitarbill]

> Couldn't you equivalently use any STL/STEP/AMF viewer?

I'm not sure. A quick feedback loop is important. With OpenSCAD and CadQuery, you write code that defines the geometry. You then want to see what the geometry looks like, and possibly debug it. For this, you generally want to be able to give certain parts a different color, or opacity, wireframe, etc.

STL is out; it has to tessellate geometry turning it into triangles. AFAIK, it only supports one object. This means a sensible wireframe is out, and so are multiple parts. AMF has similar drawbacks. STEP files might work.

Generally, my understanding is many people write OpenSCAD code in their editor of choice, and then simply save the file. When you open an existing file in OpenSCAD GUI, it monitors it for changes, and refreshes. So this is great.

That said, I misspoke a bit. CQ-Editor is definitely somewhat close to OpenSCAD. It still has a - in my view - unnecessary code editor. But the last standalone release is over a year ago, and I found it to be extremely buggy on macOS. It crashes quite often. Meanwhile, Jupyer-CadQuery [0] works great.

> Seems a good choice to me that the GUI is a separate/subordinate project. I suppose it is somewhat necessary to have it at all, easier to gain popularity if you can show screenshots and have a single app 'quickstart'.

Generally, I think this is true. My personal opinion is I can be productive with something that has a minimal set of features but is rock-solid; over something that has gobs of features but is buggy. That was my main issue with FreeCAD. Ease of installation is another big one. For all it's issues, OpenSCAD gets both of these things right.

[0] https://github.com/bernhard-42/jupyter-cadquery/

[OJFord]

I'm not as familiar with the formats as you are, all I meant was - with the assumption that the CQ viewer is doing the same, with {stdFormat} as intermediary - surely any other viewer could be used.

Just as long as it 'hot reloads', and then you can configure editor/IDE to compile the {stdFormat} file on save.

No need for the viewer to be first-party (to the language). (If assumption valid.)