Cadquery 2.0: Community Advice Needed

[dcowden]

Creating this issue, which is a copy of my post over on the google group, for community feedback.

We have had a lot of activity recently, and I think its time to set a direction and scope for CQ 2.0. I'm hopeful that doing so will allow us to organize all of the really talented developers to bring a new release to fruition.

Over the past year, we've seen a lot of really great development, but our dependency on FreeCAD is beginning to show its limits. Our goal as we move forward is:

• based on pythonOCC instead of FreeCAD. This will give us the flexibility to improve a lot of things which we currently cannot.
• New GUI. CQ is often compared with OpenSCAD, but many users find it disappointing that we do not have a one-step-to-launch GUI that shows your part as you develop.
• conda packages. Installation needs to be fast and easy. Installation is currently smooth when combined with FreeCAD, thanks to the cadquery-freecad-module, but we need to take a step forward and provide easy installation without FreeCAD.
• python 3 support. CQ 1.x supports both python 2 and python 3, but for CQ 2.0 we'll be using python 3 exclusively.

We are closer than it seems to this goal-- we just need a little help to bring it together and test it. Our plan is to execute this development on a branch, which will prevent breaking the 1.x stream. Development will continue on the 1.x stream until the 2.0 stream is stable.

The most obvious question is: what will happen to FreeCAD support? Some people use FreeCAD code mixed with CQ code, and/or enjoy using FreeCAD as their primary driver.

The short answer is that we don't yet know. We'd like to support FreeCAD, but right now we're not sure we have the resources to support both pythonOCC and FreeCAD on the 2.0 branch. We also do not know how well the new GUI will work out, and that will have a lot to do with it.

Another question is whether much-discussed direct API will be in CQ 2.0. Right now, we're thinking "no". The Direct API is a dramatic change to the way CQ works, and would take far too long to deliver anything useful. We want to tackle moving from FreeCAD first, and then work on the direct API.

We think this plan can produce a CQ 2.0 within about 6 months, with current resources. Please feel free to view the current scope, and/or comment on the issues

Do you like the plan? If not, what would you prefer?

As always, help is much appreciated. This is a huge project, we need all the help we can get!

[dcowden]

@adam-urbanczyk @fragmuffin @jmwright @hyOzd @innovationstech @huskier @RustyVermeer @gntech @Peque

Please comment/weigh in on key direction choices! Feel free to be opinionated if you're willing to help!

[fragmuffin]

New GUI. [...] a one-step-to-launch GUI that shows your part as you develop.

Could we get a list of all the GUIs people have developed, and do a bit of a pro/con analysis of them.
@zignig has recently started yet another GUI (which further illustrates our user community's desire for a GUI)

1. jmwright/cadquery-freecad-module (ie: FreeCAD)
2. jmwright/cadquery-gui
3. fragmuffin/cqparts web display (although it hardly compares with the above 2)
4. RustyVermeer/cqnb Jupyter Notebook extension
5. zignig/cqparts-server (mentioned above)
   edit: the following added
6. @adam-urbanczyk : "Qt-based stand-alone GUI", could you share a link to that?

Personally I think a web-based solution would be ideal if we can pull it off.
@jmwright and I had an excellent discussion about this in jmwright/cadquery-gui#2

I also think, when it comes to displaying web-based, glTF 2.0 is awesome.

conda packages. Installation needs to be fast and easy

Will there still be a pip package? (I hope so)

what will happen to FreeCAD support?

I don't know; I'll have an opinion on this when I've migrated cqparts over to pythonOCC...
I don't yet know what we'll be missing.

Another question is whether much-discussed direct API will be in CQ 2.0. Right now, we're thinking "no".

I agree, pushing the direct API in will drag out parallel development of CQ1.x & CQ2.0, and we're all spread thin as it is.

[jmwright]

Could we get a list of all the GUIs people have developed, and do a bit of a pro/con analysis of them.

@adam-urbanczyk is working on a Qt-based stand-alone GUI for CQ 2.0 as well. Other than that, I think your list is complete with all the main ones.

None of them is a one click solution currently like OpenSCAD has though, and it sounds like that's the goal.

[dcowden]

@fragmuffin I'd like to add 'web based' to the list, though it's probably covered by the cqparts-server.

My goal has always been to make a docker image that can run either as a server or locally.

[jmwright]

I'd like to add 'web based' to the list, though it's probably covered by the cqparts-server.

I think that cqparts-server fits that bill. It's probably a good fit for a Docker container too. cadquery-gui can be converted to a web app without too much work as well. I started the work to run it both in desktop and web app modes awhile back, but if memory serves I only got about 40% finished. @zignig and I have had a brief conversation about pulling useful parts of the cadquery-gui 3D viewer into cqparts-server.

[fragmuffin]

I'd like to add 'web based' to the list

Technically jmwright/cadquery-freecad-module and @adam-urbanczyk 's QT UI's are the only ones mentioned thath aren't web-based.

I consdier everything using WebGL to render as web-based
The discussion in jmwright/cadquery-gui#2 (comment) explores splitting a web-based implementation into a simple core (which would do almost nothing on its own), and plugins, such as loaders, cameras, renderers, and parts selectors (would be for cqparts hierarchy).

Splitting it up like this means we could use the same core implementation everywhere, including simple renders on web-pages (like this) to a single-install electron app (ie: jmwright/cadquery-gui) that includes all the bells & whistles.

Feel free to be opinionated if you're willing to help!

I would love to help... finding the time may be the issue.
Improving cqparts is my priority, and there's a lot of work there already.

[zignig]

I think @fragmuffin is correct , we should have a 'Viewer' based on threejs that just shows constructs for exploration (possibly with an auto explode). As a preference I think it should be embedded rather than a iframe but that is out of scope for this discussion.

Importantly CadQuery and cqparts must be able to operate without a gui and still be fully functional from a python command line or library inclusion.

As for the freecad excision I think it is a good thing to use pythonOCC it will bypass some of the cruft and use a cleaner OCC layer.

I also think that it is critical to maintain compatibility with freecad at some level, being able to transfer designs and components between systems will be important in the long term.

I initially started writing cqparts-server as a development helper for my exploration of cqparts. It's written in golang (sorry pythonistas) , but it also means that it can be shipped as a single binary with all the files included.

[huskier]

When it comes to the GUI thing, could we take account of the collaboration into the picture(Just like the Google Docs)? For the next step, I think the CAD development will be towards the collaboration direction.

I like the web-based GUI idea, and I think OnShape is in the right direction.

[dcowden]

thanks everyone for the thoughts!

Once these discussions are complete, I'll create a roadmap document that shows how all of the pieces will work together. Here's the layers i see so far. I've ignored the packaging dimension for now.

'Core' -- can run on any machine, command line only

• OCE
• python OCC
• cq, cqparts, cqgi, and other core libraries
• cqgi command line executor

'Desktop' -- added to core if you want a gui

• GUI(s)
• FreeCAD bindings (this is just conceptual. I suspect this really ends up in core)
• cadquery freecad module

'Server'

• lightweight webserver with REST interface ( executes scripts using a promise interface)
• monitors local files and runs them

'Collaboration Server' designed to support multiple user collaboration

• includes 'server'
• git integration for script sharing and importing scripts from git repos

From a packaging viewpoint, i think ideally we support conda packages and also docker images.
I don't think we want to re-invent github, so i'm imagining a lightweight import module that allows importing scripts directly from other repos-- primarily including a (soon to come) official cadquery contrib repo.

[dcowden]

I've created a branch for this work:
https://github.com/dcowden/cadquery/tree/python_occ_2_0

[dcowden]

It appears that the community is ok with this overall direction.

[fragmuffin]

@dcowden

but for CQ 2.0 we'll be using python 3 exclusively

To be clear, which python version will be supported?
I ask because there's some metaclass functionality I'm looking in to that's a bit fuzzy between 3.5 - 3.7.

[dcowden]

I don't know-- what's your opinion? I was sort of ignorantly assuming 'any 3.x'-- i didn't know there were major considerations for older 3.x versions.

[fragmuffin]

@dcowden

i didn't know there were major considerations for older 3.x versions

I don't think there are major differences. There are a few metaclass perks that have been added in 3.7, but not worth shirking support for versions < 3.7...
I think 3.x support is fine.

Realistically: I think most people are using >=3.5 anyway.

[zbynekwinkler]

Realistically: I think most people are using >=3.5 anyway.

That is what I would aim for as well.

[dcowden]

Ok, 3.5+ it is then!

[dulouie]

I would appreciate, if cadquery becomes an official scripting language of FreeCAD. To create smaller tools like FeatureScript on Onshape.

[dcowden]

I certainly agree that a web-based solution would be great. The existing cadquery container ( see https://hub.docker.com/r/dcowden/cadquery/ )-- is capable of running cadquery scripts, with a 1 step installation. I'd like to extend it to be able to run a web-based UI-- then, running the UI can be done very easily: * I can host it cheap/free on a number of platforms * It can be run locally very easily-- without installation * Updates to get new versions are as simple as 'docker pull' * its _VERY_ easy for people to make derivative containers that include extra files. If the community can produce a web-based UI, i'll be happy to do the work to package it up as a docker container. It would be a one-step install, gui and all! I can also do the work to reduce the size of the current image, which is currently pretty large ( mainly due to the fact that it installs the full Conda base-- which includes all the python libraries on the internet it seems )

…

On Sun, Sep 9, 2018 at 10:35 AM dulouie ***@***.***> wrote: I would appreciate it if cadquery becomes an official scripting language of FreeCAD. To create smaller tools like FeatureScript from Onshape. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#275 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPOA1ywk5q9btSd1CrQdgFl4Rof_2gcks5uZScjgaJpZM4UO8H3> .

[dcowden]

This has been closed in favor of the CQ 2.0 implemention at https://github.com/cadquery/cadquery