Add a conventional UI layer

[tdeck]

Since most users have no experience with the command line, learning those skills presents a significant barrier to getting started with designing and printing using 3DMake. This issue is a place to discuss approaches.

Since the command line interaction is easy to automate, there's always the option for anyone to create a wrapper that calls the 3DMake commands. This could be written in any language and use almost any technology. For example, someone could write a hosted web editor and slicer that uses 3DMake. It would also be nice to have plugins for popular editors etc...

I'd like to explore the idea of adding a lightweight and functional GUI to 3DMake itself. Since @ashleycox interested as well, here's a brain dump from my point of view:

Functional requirements

• Be able to work with both 3DMake projects (designing, slicing) and downloaded STL files
• Be able to do the settings involved in 3dm setup
• Natural interaction paradigm (
• Cross platform. Largely (~90% or more) the same code for Windows, Linux, MacOS)
• Obviously, works well popular screen readers
• Should work well for sighted people as well
• Graphical install and setup (I.E. no need to touch the CLI at all). Installer can be separate from main UI

Architecture goals

• Keep the CLI working. It's useful and it lets other folks build different UIs in the future more easily.
• Share as much logic as possible with the CLI implementation. Duplicated logic makes for a mess in the long term and becomes a burden.
• UI is testable
• Lightweight addition. As nice as web-based UI development can be, I'd prefer to not ship a whole browser runtime for 3DMake's straightforward UI needs
• Maintainable strategy for the large number of slicer settings (see challenges section)(
• I'd prefer not to maintain my own custom text editor as part of this. There are plenty of good editors out there already that are better than whatever would end up in 3DMake. Embedding something full-featured would be fine.
• Something structured in a way where we can build it up gradually rather than adding the whole UI in one big commit is a must.

Challenges

• Slicer settings. The simplest is to give people a set of name/value pairs, like the config files we currently have. A search box and categories would be trivial to add. But that's not a great experience. Settings have types, and allowed values. Some are enums. Some are integers. Some are floats. Some are multi-line GCode scripts. We can use an LLM to help with this to some extent, but I also feel like I'll need to check over it.
• 3dm setup. This is one of the few interactive flows in 3DMake and its one-at-a-time question interaction paradigm doesn't translate very well to a GUI paradigm, where you'd like to see the different branches of options all at once and be able to toggle between things like Gemini and Ollama setup. I think this might be an area where we just duplicate the logic and write the file from the GUI.

Random thoughts

A VS code plugin would probably be a quick win to give a lot of the benefits for project-based work, although using VS code to print downloaded STLs would be a bit odd. It would also allow progressive enhancement as we go (e.g. first we just show a settings file, then add some kind of auto-complete or linting to it to help users edit their profile correctly).

If we build a wrapper, the CLI can be invoked in some mode where it presents certain output in a machine-readable way.

I haven't researched UI frameworks enough to have any opinion yet. My bias is toward something with Python bindings so that automated testing and packaging will be easier. I'm not sure which of the architectural goals we might have to trade off yet either.

[mrhunsaker]

PySide6 would do well with this. NiceGUI in python would also work and can be 100% accessible as it is basically html and is anyways. I have been thinking in this and have just been too lazy to tinker on it yet.

I think it would be great if there could be a number of options available by folks who would make unofficial gui wrappers for this project. That way the public clamoring over more GUI features would not get in the way of the core functionality.

[ashleycox]

great suggestions for frameworks. I don't think we need more than 1 UI wrapper, you end up with fragmentation and a bunch of UIs that all do slightly different things. What we need is to settle on a framework that allows for the creation of a cross-platform UI that will be expandable in future to encompass anything that might realistically be needed, and then build 1 UI that people can contribute to.

[mrhunsaker]

Oh yeh. A lot of projects I have worked with suffer that problem. Here is a NiceGUI one I threw together, it has flaws as I have not de-Clauded it yet, but the idea is there, and it is 95% accessible out of the box: https://github.com/mrhunsaker/3dmakeGUI . I love NigeGUI, more people would use a PySide6 or PyQT more readily. I just teach the blind and I can never make anything accessible enough and the browser works on all systems. (I hate having to install pywebview and cairo on my Linux systems as they argue with my windows side of life -- so I make things open in browsers)

[mrhunsaker]

For any added fun, here is a VSCode vsix implementation [https://github.com/mrhunsaker/3dmake_vscode_extension}(https://github.com/mrhunsaker/3dmake_vscode_extension)

[tdeck]

Thanks for sharing your prototypes @mrhunsaker . I had the chance to try both of them out this weekend, although I wasn't able to make many of the GUI workflows work. Ultimately I think it will benefit users to have some kind of UI that's bundled with 3DMake and actively maintained, and I'll probably set to work on it sometime in the next few months. Right now I've been hard at work on making the tactile previews more useful, which has involved a big refactor. I certainly appreciate the input and framework suggestions.

In terms of the interaction paradigm, it's important that the UI do what's most natural rather than be bounded by the interaction patterns of the CLI. GUI users often aren't used to those interaction patterns and learning them is a big barrier to using a command line tool. For example, something like "changing the working directory" makes perfect sense in the terminal, but having to explicitly do that in the GUI is not intuitive. instead we expect to do something like File > Create project > get a file dialog, or File > Open project > get a file dialog. Likewise with setting the command options like -m or -v, it's natural in a command line tool to choose all the settings before running something, but in a GUI that's less common. Just to sketch out some of the more natural flows I imagine:

1. Build model. Select the model in the project navigator. Model .scad file opens. Build button in the toolbar (or by hitting F5). Any SCAD errors get surfaced in the console in a way that you can scroll them one by one and hit a key to jump to that error's line in the source file.
2. Describe model. Describes the open file's model like build. Has a toolbar button. Description shows up in the console.
3. Watch model. Continuously open console, runs a 3dm watch command (yet unbuilt but in my TODO list) that first describes the model, then detects when the .stl file is rebuilt and feeds new images to the AI, asking it to describe the changes. So the user can get feedback as they change and rebuild the model without having to explicitly run "info" all the time.
4. Settings: One settings dialog that populates the .toml file appropriately. Makes it easy to choose common settings. Shows up the first time you run the GUI or extension
5. Print. Dialog lets you choose a printer profile from a dropdown (remembers last used one globally) and lets you choose overlays from a combo box (remembers last used ones for this model). Orient or not is a checkbox, not a separate command. Printer connection settings are in the settings dialog. When you run this, slices and prints the model. Tells you estimated print statistics and the like.
6. Slice. Similar to print (you get the statistics) but doesn't actually print. Probably used less but may be used for debugging supports and things.
7. Print a preview (I'd call this "print preview" but that means something else). Works on the open model like the others. Preview dialog has a dropdown with preview options. Rest of the print options are similar to the print command, but maybe also an option to use the SVG instead and send it to the system print dialog for those with an embosser (or this could be a separate "emboss preview" command).

I think the core non-visual workflow for most people is going to be something like:

1. Edit SCAD file (most frequent activity)
2. Get many AI descriptions (very frequent activity)
3. Print tactile previews to check specific things (a few times)
4. Print the full model (a few times)

The later activities will take longer but be performed less often. In my development, I've been trying to strike a balance between improving each of these workflows because none of them is in an ideal state yet.