Roadmap

[jmwright]

@fragmuffin Based on conversations on the cqparts and cadquery issue trackers, I think we might be wanting different things out of this GUI. I'd like to start a discussion here to figure out a high level path forward for how this UI will work.

What You Would Like to See

If I understand correctly, you would like for the GUI to be view only, but allow the user to adjust parameters though the GUI. Is that correct?

What I Would Like to See

I'm interested in that mode of operation, but I'm also interested in a couple of others.

1. A replacement for the CadQuery module/workbench for FreeCAD. This requires an editor pane and a 3D view pane side-by-side to allow for editing and re-executing scripts. That's the way the GUI is currently laid out.
2. A platform for experimenting with code-mouse interaction, where what you do in one pane effects the other.

A Possible Path Forward

Right now what I'm thinking is this:

1. A user opens a CadQuery script (cqparts or a stock script) and they only get the 3D view with a parameter editor box somewhere in the GUI.
2. The user has the option of hitting a hotkey or (doing something like) right clicking and selecting "Edit Script". Then the GUI splits into the editor-viewer mode.

Additional Design Goals

There are a few other goals that I think are work pursuing.

1. Support PythonOCC as well as FreeCAD as CadQuery's CAD kernel interface layer. The current design of this GUI makes that pretty easy I think since JSON is used as an intermediate object format. The current version of the GUI was designed while using FreeCAD-CadQuery.
2. Allow the GUI to be run in web server mode where the UI is served to a web browser instead of into an Electron window.
3. There should probably also be a well-integrated Python console available in the GUI somewhere so people can try things quickly.

There's also been talk in the community of a single installer for a CadQuery GUI as well as the command line. Something similar to what you get with OpenSCAD and FreeCAD. Should we try to do that at some point with this GUI?

Far Future

Something in the back of my mind is other modes of operation for the GUI such as a generative design mode, but I'm a long ways from having time to start that. It's not feasible to cover expanded use cases at this point, but it's worth noting that this GUI lends itself to being expanded for other uses later.

[fragmuffin]

@jmwright

A replacement for the CadQuery module/workbench for FreeCAD. This requires an editor pane and a 3D view pane side-by-side to allow for editing and re-executing scripts

I agree; I think it's important for an author to have both an editor, and viewer on the screen at the same time. However, I think the editor should be optional.

To illustrate what I mean, this is what I can do now using cqparts.display.

The display function in a command line environment, starts a http service, and hosts an export of the model.

I imagine the cadquery-gui could achieve the same dynamic:

• an author may edit their code in an IDE of their choosing
• they run their code
• cadquery makes a connection to cadquery-gui (possibly opening a new instance), and displays the model.

I've raised fragmuffin/cqparts#46 to improve the cqparts web service, but ideally it would be completely replaced by cadquery-gui In the above screenshot, the displayed webpage could have a link to the cadquery-gui, something like improve your viewing experience with cadquery-gui.

A platform for experimenting with code-mouse interaction, where what you do in one pane effects the other.

That is very cool, and would be excellent while people are learning (I would have loved that). Could this be achieved with an Atom.io plugin?

Atom? It's actually very plausible that the display, and the display's interaction with an editor window could all be achieved with an atom plugin!

• Atom is already in electron
• authors could use any of the thousands of plugins already available for Atom alongside cadquery

oh!, hey... look! https://github.com/apla/atom-jscad I just tried it, and it works. it seems to have similar CPU/GPU usage issues to #1, but they're fixable.

[jmwright]

To illustrate what I mean, this is what I can do now using cqparts.display.

If we added file watcher code to automatically re-render the 3D view and threw some 3D controls on the page, I guess I'm having a hard time seeing any advantage in doing cadquery-gui over what you have there. Your solution would make more since to distribute with the CadQuery library as well, which would be a big advantage for some users.

[fragmuffin]

I guess I'm having a hard time seeing any advantage in doing cadquery-gui over what you have there

One big :+1: for the cadquery-gui is a new user's familiarity with the process of learning a new thing:

1. A completely green developer finds some reference to cadquery.
2. They google it, and are impressed by the features and examples.
3. They jump straight to theinstallation instructions, run pip install cadquery (or similar).

cadquery-gui in its current form

4. They run a cadquery app which immediately shows them the familiar input vs output and a play button with a pre-loaded example, and intuitive access to many more.

that is appealing

The alternative I've proposed

4. They find the folder containing all the examples, and executes one of them, a browser pops open to show them the result.

Or if they choose to use the Atom plugin:

4. In addition to running pip install cadquery they also run sudo apt install atom and apm install cadquery
5. When running Atom, they select a drop-down menu to: a. paste an example (of their choosing) into a new file b. open the preview window

[fragmuffin]

Do we have to choose? If we carefully compartmentalise each aspect of this GUI, I believe we can do both... or rather, all 3 (standalone, an ad hoc web service, atom.io plugin) quite easily!

Plugins / Packages

Packages that must be there in some form are denoted with a :star:

Web Front-end

each released as an npm package

• receiver : new content geometry & render data :star:
• receiver : debug data (show the context of REPL returns... however we implement that)
• receiver : static url reference (used for pages with no back-end) :star:
• 3d render window (could have more than one instance, eg: a 2x2 orthogonal view along x/y/z and free) :star:
• camera controls : orbital :star:
• camera controls : turntable
• camera controls : animate (non or semi-interactive)
• camera controls drop-down
• geometry : select / hide (3d pane)
• geometry : select / hide (from an object hierarchy, I'm thinking more cqparts here)
• geometry : animate (with optional slider)
• render : default (possibly just a dummy package) :star:
• render : wire-frame
• render : realistic (textures, metalicness, transparency, refractive index, reflections, and all the cool stuff kids are playing with these days)

that may be overboard, but you get the idea

Web Back-end

maybe as pip packages (?)

• pipeline : takes script in, alters the environment so cadquery knows to "display" via a network connection of some sort :star:
• file watcher : executes the pipeline on changes
• debug : python REPL that sends debug info along pipeline

Implementing into multiple "apps"

cadquery-gui

cadquery-gui, still using electron would simply be a skeleton that uses all of the above "plugins" as pre-requisites, and includes all of them.

Ad-hoc web service

A front-end app that gets built using npm and compiled with webpack (or something similar) to create a static page to be hosted by the ad-hoc service. The back-end is implemented by having the pip packages as pre-requisites (an advantage of the back-end being implemented in Python)

Atom.io plugin

Similar implementation as the ad-hoc service

Random web-hosting (eg: Jupyter)

As a huge added bonus to implementing as separate packages, people could host models on their own pages, and choose how their audience interacts with them... for example:

• simple display with minimal control & orbital camera (like this page)
• a checkbox for wire-frame view
• static model url with animated camera & animated geometry to "showcase" something.

You'd get all of that for free, and if people so desired, they could fork and create their own modified plugins to do exactly what they want under their name.

[fragmuffin]

oh!, and I just thought of another scenario:

• Web front-end:
  • receiver : updates to geometry translation / rotation (via MQTT)
• Web back-end:
  • transmitter : transmit stream of geometry transforms (also via MQTT)

Then it's just 1 step to create a gateway python service (that uses the transmitter) to update positions on a miller, or 3d printer (or anything) to show its position realtime.

I've actually done this, so I can submit that code.

[jmwright]

receiver : new content geometry & render data 3d render window (could have more than one instance, eg: a 2x2 orthogonal view along x/y/z and free) camera controls : orbital

I think this list is all rolled into the 3D viewer that I'm working on revamping now. I think that for it to work with Electron properly there would have to be two-way communication (probably via websockets). Would the receiver just be some Javascript that runs client-side that receives data from the back-end? I'm not quite sure what "new content geometry & render data" would look like in that context. It seems like the back-end would take care of running the script and converting the results to JSON for transport to the receiver on the front-end. Am I missing something?

[fragmuffin]

Am I missing something?

No; that's exactly what I was thinking.

But, rather than exporting to JSON, I strongly recommend glTF, I think it'll make our lives so much easier. Did you ever take a look at the glTF exporter for cqparts?

[jmwright]

Did you ever take a look at the glTF exporter for cqparts?

I read the issue when you posted about it, but I haven't tried to use it. How do we integrate that on the back-end? Will the back-end always need to include cqparts in order to export models to gITF?

I'm wondering if we need to create an umbrella project on GitHub to organize all these npm packages. Kind of like PyQode did. I'm not sure what we'd call it. Something like "Open Web CAD Toolkit" or something like that? I'm horrible at picking names for projects, and it could be used for a lot more than just CAD I guess.

[fragmuffin]

How do we integrate that on the back-end?

Ultimately the glTF should be a format available for cadquery exporting. (I've created fragmuffin/cqparts#49 to move as much as possible of this over to cadquery)

The cqparts glTF exporter is built to deal with a hierarchy of parts, because glTF as a format is arranged in the same format. Models are indexed in a scene with children, each child has a matrix transform in relation to its parent.

glTF demo I just made this gist to show a single layer, and a hierarchical .gltf output from cqparts if your'e interested.

I'm wondering if we need to create an umbrella project on GitHub to organize all these npm packages

I think we just need proof of concept first, if this won't work the way I think it will, then we'll just have some well structured code that's all compiled together. I'm sure we'll be able to move the origin of a package, both in npm and pip.

[jmwright]

I'm overhauling parts of this app right now, and will convert it's viewer system to being the proof-of-concept for glTF functionality based on your demo. I'll likely need advice during the process though.

[jmwright]

7 and #8 have been added to address the proof-of-concept that I think we're talking about here.