To answer your questions:

I am running Ubuntu Linux 22.04.3 LTS on 64 bit Intel architecture.
I followed these instructions to the letter:
https://cadquery.readthedocs.io/en/latest/installation.html
I used the "conda" approach described there, except that I followed the "Adding a Nicer GUI via CQ-editor" section, in order to install both the underlying CadQuery libs plus the editor in one go. In addition I wrote a launcher script for the cq-editor which is a file named 'cq-editor-launcher.sh' in my ~/bin directory, which specifies the following:

#!/bin/sh
set -e
ARGS="$@"

The 'activate' command seems to look at arguments passed. Therefore we saved

the arguments to 'ARGS' above and we skip over all of them here.

while (true); do
ARG=${1}
if [ -z "${ARG}" ]; then
break
else
shift
fi
done
. $HOME/mambaforge/bin/activate
conda activate cqdevcq-editor ${ARGS}

In this way I'm able to call the launcher script and I'm able to give it an argument on the command-line, which is the Python file I want it to open.

BTW one of the things I noticed right away is that cq-editor does not have a lot of command-line options for automation or batch processing. For example in OpenSCAD I can create computer animations by using the openscad command-line and generating a static image for each call. Doing a 'man openscad' exposes a rich set of options for command-line use, whereas there does not seem to be an equivalent in cq-editor. I think they rely on Python to do anything, in other words you'd put that logic into a Python script and open that. It's a slightly different paradigm, which is acceptable.

To answer your other question, yes I'm the owner of Neri Engineering and Blockout With Coffee.

Cheers, the non-alcoholic version.

Sent with Proton Mail secure email.

On Tuesday, January 16th, 2024 at 1:20 AM, Guenther Sohler via Discuss discuss@lists.openscad.org wrote:

Can you please try if this kind of model can be created in cadquery?

[image: image.png]

inner cut section of the same is as below:
[image: image.png]

On Tue, 16 Jan 2024 at 17:01, neri-engineering via Discuss <
discuss@lists.openscad.org> wrote:

My guess is probably yes, it's quite easy.
However I'm not a slave.

Sent with Proton Mail secure email.

On Tuesday, January 16th, 2024 at 2:05 PM, Sanjeev Prabhakar via Discuss discuss@lists.openscad.org wrote:

On 1/16/2024 6:45 AM, Rogier Wolff via Discuss wrote:

So that was somebody telling you how to accomplish your goal today,
not necessarily a rejection of the idea.

Unfortunately, most "easy" ideas have already been implemented, and new
ideas tend to fall into one of a few basic groups:

• This is more or less straightforward, but there are no volunteer
  developers who are interested in working on it.
• It would be good if we could do this, but it would break backward
  compatibility and users would (rightly) complain.
• That's interesting but we're not sure it's the right answer.
• There are already good library-based solutions for this problem, and
  we don't want to clutter the core.
• This would be great but nobody understands how to do it.
• These are not the droids you're looking for.

Expanding on those... (and then I'll talk about something we could improve)

• This is more or less straightforward, but there are no volunteer
  developers who are interested in working on it.

It is critical to understand that OpenSCAD is free and there are zero
people who are paid to work on it.  It's a volunteer project.  People
work on it because they want a change for themselves, or because it
intrigues them, or just out of the goodness of their heart.  If
something doesn't interest them, only "the goodness of their heart"
applies, and that's pretty weak motivation for spending more than a few
hours.

(If somebody says "bounties!", do the math.  Figure out how many
developer-hours the bounty will pay for, at a reasonable salary.  Hint: 
not many.  No realistic bounty would attract my attention.)

• It would be good if we could do this, but it would break backward
  compatibility and users would (rightly) complain.

It may not be obvious to people who are working on projects that are
measured in dozens or hundreds of lines, but there are users who have
projects measured in thousands or tens of thousands of lines, developed
over years.  (My house project is 12K; BOSL2 is 65K.)  These users -
and, for libraries, the library's users - are rightfully unhappy if
something changes incompatibly.  Libraries are a particularly difficult
problem, because they may be supporting users who for one reason or
another are running an antique version of the program and are unwilling
or unable to upgrade.

• That's interesting but we're not sure it's the right answer.

See the previous notes on backward compatibility, but looking forward. 
If we add a new feature, we're more or less stuck with it forever.  If
it's just a pentagon() module, yeah, whatever, it's clutter but it's
pretty obvious.  If it's some new syntax there may be subtle issues that
won't be discovered until it's used extensively, or it may interfere
with some other desirable enhancement.  We want to be pretty sure that
we won't regret adding it.  And who is going to spend the time
experimenting, and researching, and thinking about the question?  See
the first point above.

• There are already good library-based solutions for this problem, and
  we don't want to clutter the core.

There are a lot of problems out there that have been handled in
libraries.  BOSL2 is the exemplary one, but there are several others
that are respectable.  When something get added to the core (a) it's
harder to implement, because it's C++, (b) bugs are more painful,
because they often crash the program, (c) it's harder to change because
there's no obvious way to switch from one variant to another and so
there are more compatibility concerns.

"But BOSL2 is so complicated!".  Well, yeah.  Specifying - really, fully
specifying, in a general way - complex shapes is hard.  And if those
features got added to the core, then the core documentation would be
just as complicated.

Some things maybe should be added to the core, either because so many
people need them or because they would perform much better in C++.  But
see above about needing the right answer.

• This would be great but nobody understands how to do it.

Some of the stuff that people want, that everybody agrees is useful and
is difficult to do today - rounding, filets, and chamfers come to mind,
but there are plenty of others - is hard stuff, like PhD-thesis work. 
Could it theoretically be done?  Probably, if the right people worked on
it... see the first point above.  I don't have a PhD in computational
geometry; do you?  There are things I can work on, but the interesting
geometry stuff is well beyond me.

• These are not the droids you're looking for.

Finally, there's just some stuff that OpenSCAD ... isn't.

It's not a conventional programming language, in a number of ways, for
good reasons and not-so-good reasons, and it, per se, is never going to
be.  There's work in progress around plugging in Python as an
alternative language, and that's got some really cool aspects and some
really problematic aspects, but the OpenSCAD language itself isn't going
to change radically.  Feel free to fork and plug your favorite language
on top of the geometry engine and UI.

It's not a drawing program.  You aren't going to grab points in the
rendered model and move them around, or add new shapes by drawing them. 
Only in the most trivial cases is that possible and meaningful.

If these things bother you, then maybe you need to be looking somewhere
else.

--

But what could we make better?

Several of the items above - backward compatibility, finding the "right"
answer, whether something should go in the core or in a library - are
judgement calls.  Today, we have no mechanism for making those judgement
calls other than one of a few people just making a decision.  There's no
voting or formal consensus mechanism.  I really don't blame those people
for being hesitant to make those controversial decisions, when there's a
good chance that they'll be the ones fielding the resulting complaints. 
I think it would help if we added some structure, if we had a steering
committee of a handful of people (more than three, but less than a
dozen) who would accept proposals and, after appropriate public
discussion, vote on them.  I think that would help to drive resolution
on projects that are complex enough to pose some risk.

I think the debate about the future of OpenSCAD, and the priority of
feature additions would be usefully informed by accepting that OpenSCAD is
just one of an existing family of code-to-design languages which at the
moment share the advantages and disadvantages of not being point-and-click
to create objects.
There is precedent for this situation in the document processing world,
where in science publishing a markup-based  tool called TeX and its
associated package library LaTeX has dominated the field. The problem here
is that occasional use of this software under deadline is very very
painful, while experts can make it sing. Also minor adjustments to a layout
are hell. This situation could have been avoided if Donald Knuth had at the
time he created his tool attached some importance to people who care about
exactly where something goes on a page, and provided GUI-oriented hooks
in his code.

Edmund

On Tue, Jan 16, 2024 at 11:57 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

I like the concept of OpenSCAD very much, suppose I prefer it over
CadQuery, because it's REALLY simple building blocks,
it's very intuitive and very easy to learn.
Only disadvantage over FreeCAD is , that its almost pure scripting language
and the Click-to-build Adventure which some users expect,
is literally not there.
This is why i put quite some efforts to improve on here, and if you look
into here:

https://www.youtube.com/watch?v=liUACvvMHhM

you will see: with some effort it's actually possible to click&put objects
together.

OpenSCAD's very basic methodology  appears to be to be stable,
backward-compatible, long-time-user-proven, secure.
And I believe the chosen attitude has helped OpenSCAD to become an industry
standard where many companies rely on.

However, this contradicts the ability to grow fast and bring new features
to the user.

Sometimes I wished that OpenSCAD would accept features a little sooner with
the attitude: when it's wrong, just fix it later,
but it would definitely put much more motion into the development
instead of the whole team to agree on:" this is indeed the best approach"

Personally I have accepted this decision for OpenSCAD to stay "little
old-fashioned"  for sake of stability, et cetera .
When I'd like to have a nice feature, I just code it (and probably PR to
OpenSCAD).
I am just a little sorry for many other users who are missing these
experiences...

these are my thoughts ..and thoughts are free :)

On Wed, Jan 17, 2024 at 12:55 AM edmund ronald via Discuss <
discuss@lists.openscad.org> wrote:

On Wed, Jan 17, 2024 at 12:54:48AM +0100, edmund ronald wrote:

I design PCBs. When you start out, you put everything on a grid. As
trhings get tighter, you start pushing things around and off the grid.
This, with further modifications down the line becomes a pain in the
butt.

The positioning something on a page exactly seems nice at first, but
once you have "just one more modficiation", things break down. Say the
program takes your wish literally: you've positioned your table on the
page exactly. Now that you've added or deleted something in hte intro
the natural position for the table would no longer be in the left
column but in the right column. You have to change that position again
manually. Or you forget and it looks ugly.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.