CQ-editor VS cadquery

I installed cadquery with cq-edit from github using the prebuilt package release for windows 10. This seemed to work great, cq-edit GUI launches and I can even model basic shapes. However when I try to run the printables file from above I get the error

Use the latest version of cadquery. The version of cadquery that comes bundled with cq-editor binary isn't the most recent, and doesn't have support for cylinder.

On a previous laptop I used i3, then after a few years on Windows, I returned to Linux on my current laptop and decided to try Sway, and now I’ve been using it for almost a year and a half, but I set up i3 somewhere along the way too, which I have used when I needed screen sharing on Zoom.

I much prefer Sway. It handles output management much better than i3 (because it’s integrated and integrated well rather than being entirely up to you with xrandr—so this probably wouldn’t apply to full desktop environments like GNOME or KDE), supports mixed-DPI environments, properly supports high-DPI (though I’ve also been using patches for fractional scaling since I want 1.5×), avoids all tearing (which was what really surprised me when I first ran i3, I’d forgotten what the tearing was like), and supports my XF86AudioMicMute key (key code 256; it took a little effort to get it to work, involving dumping the xkb keymap and adding in a suitable entry, but I think that it’s literally impossible to support under X, though you may be able to remap it to a different key like F20 in some way at a lower level, but my attempts at that failed).

It’s not been without its troubles. Screen sharing is only possible at the screen granularity rather than individual windows, and I think Zoom is still broken because they did things stupidly in the past (using a GNOME screenshot API many times per second instead of the compositor-neutral screen sharing API that did exist when they implemented their thing) and are still unravelling them. I’ve also had a couple of apps require tweaks to unbreak, e.g. https://github.com/CadQuery/CQ-editor/issues/266, if you build it with a version of Qt that supports Wayland (the default, though their first-party distribution doesn’t), you have to explicitly tell it to use xcb instead of wayland or it crashes on startup. But honestly that’s all I can think of.

All this talk about anaconda etc is a little overblown. Just grab the release ZIP here and run the launcher. It drops you in the editor/debugger workspace with full functionality. https://github.com/CadQuery/CQ-editor/releases/tag/0.2 It doesn't appear to modify your system in any way.

I understand that other modes of using CadQuery require 'conda, but the basic built-in editor experience is self contained. Or am I misunderstanding something?

I tried this a couple of months ago, I found what it's trying to do very pleasant to use but the tooling around it is very annoying. The up-to-date version 2 isn't on pypi, conda is thoroughly unpleasant to have as an environment. There seems to be a drive to using it inside it's own editor https://github.com/CadQuery/CQ-editor while nice seems like wasted engineering effort in developing an editor when the language needs so much work. I didn't have much success structuring cad into modules as they wouldn't import well.

The point IMO of parametric cad in an existing language is to use the ecosystem. Lots of choices in this project make that really hard.

Anyways, I've just written that to make sure you know that the "code-CAD scene" or "state-of-the-art" is not OpenSCAD (and I'm not saying you don't know that), and that the ideas you had are really great, but they have already been brought to existence in CadQuery, CQ-Editor (the editor + visualization + debugging GUI for CadQuery), and the (still incipient) Semblage, that started to implement the "hybrid" approach of code-CAD + GUI based on CadQuery. I do believe another code-CAD program won't hurt at all, and there is even the possibility of collaboration between Fornjot and CadQuery and possibly Semblage, but I wouldn't say the world needs another code-CAD program. The world needs first to know about CadQuery and then decide its real needs. I've just read your blog post of your criteria for CAD software, and I really think that (apart from the community part, that requires that the project is known by many people, which seems to not be the case with CadQuery) CadQuery meets them nicely. If there is something I'm missing please let me know, specially if you already knew about CadQuery but it didn't suit your needs. Anyways, good luck with Fornjot!

To be fair these grievances are old: I've avoided conda like the plague for - easily - the last 5 years, and they might have cleaned up their act.

However, I still find the notion of having to install 2 gigs worth of stuff on my machine only to try a simple CAD package for a few hours a rather offending proposition. Call me an old curmudgeon if you have to.

To be fair to the cadquery folks: they seem to have realized the issue and they now offer what looks like a somewhat self contained binary dowload of the cq-editor package [2].

Finally, I'll leave you with this, taken from the cadquery homepage itself [1] (note the use of the word "polluting" in there, looks like I'm not the only one feeling this way):

For those unfamiliar (or uncomfortable) with Anaconda, it is probably best to install Miniconda to a local directory and to avoid running conda init. After performing a local directory installation, Miniconda can be activated via the [scripts,bin]/activate scripts. This will help avoid polluting and breaking the local Python installation. In Linux, the local directory installation method looks something like this

[1] https://github.com/CadQuery/cadquery#alternative-anaconda-in...

[2] https://github.com/CadQuery/CQ-editor/releases

>Python for CAD

You might be interested in CadQuery:

https://github.com/CadQuery/cadquery

I am currently developing a pipeline for creating STL files, slice them and create a print job based on it. My setup at the moment is an Ultimaker S5, which offers a simple REST-API, for example starting a job with a G-Code or UFP file. I am using the cadQuery library for creating parametrized 3d shapes and export them as a STL file. I want to use the CuraEngine CLI interface (Backend for Cura) for slicing or their library libArcus (python bindings) but there is literally no documentation or any kind of examples, except the source code. There is also the prucaSlicer, which also offers a CLI interface for creating G-Code, but no support for the Ultimaker S5.

CadQuery would be a closer alternative to OpenSCAD. Not sure if it’s available on OpenBSD.

Check out https://github.com/CadQuery/cadquery

That thesis is really fun, but it will take me a couple weeks to digest. Before it even starts I see Pat Hanrahan, who is one of the nicest most creative people I have met in CS (), I know this going to be good.

A fantasy of mine is to have a bag of arbitrary constraints and behaviors of agents that exercise the system. One could sketch a building, model the behavior of people that will use it and let the system run, doing backwards and forwards inference to evolve a structure that makes those agents satisfied across lots of criteria. The designer if they are still called that, can select designs they like and the system can use that as a seed or test oracle. Virtual cows, cow paths and evolvable structures wrt those cow paths.

What do you think of "Growing Neural Cellular Automata" [1]

Are you by chance following CadQuery? [2]

[1] https://distill.pub/2020/growing-ca/

[2] https://github.com/CadQuery/cadquery

I agree with you. That's why in the past I made this issue: https://github.com/CadQuery/cadquery/issues/153

The developers don't seem to be receptive. But fortunately a nix flake exists: https://github.com/marcus7070/cq-flake

Takes ages to compile thought so I advice you to either be patient or add the cache.

If it's only distributed by anaconda, it's a hard "no" for me, since anaconda breaks existing libraries. I mean I could play with miniconda, but really, a docker container / flatpak would be better suited. And if I have to spend hours to try to get something to work, it's usually not worth the sunk time.

See here for the discussion.

https://github.com/CadQuery/cadquery/issues/153

Yeah, I think their approach to blaming PyPi for not being able to distribute their 1GB standard install is really putting the blame on the wrong people.

https://github.com/CadQuery/cadquery/issues/153#issuecomment...

As an example of an approach that doesn't break Pypi, nltk distributes through Pypi but has an download() method for installation.

https://pypi.org/project/nltk/