That UI makes sense to me, and I would be happy to see that used. However, I think a more holistic view of the tools suggests a different overall UI for this feature. (If this is too much work to rearchitect in this way consider the suggestion withdrawn, but this is what I currently view as the ideal.)
Each layer is starting to take on a lot of properties. What if you grouped all of those together per layer? Basically you'd add a list of layers to the current UI and move some of the settings there- Layer type (switch, top, open, etc,) screw hole size, oversize width (for GON-style cases,) and a list of shapes/polygons to place. Advantages include the ability to add/remove layers, a cleaner/more scalable UI, and making it extremely clear to users which layer a particular polygon is associated with. Plus, it reduces the number of drop-down boxes you need, which is always a plus. (I have a thousand other reasons, like enabling live previews so you can see how a setting will affect your particular design, but I won't get into those for sake of not overloading you with info. 
)
The format you POST (and the format of the raw code that gets pasted) wouldn't have to change, you'd just be changing how it's specified in the UI.
I would even suggest simplifying this interface further and removing the ability to specify multiple coordinates. Novice users will be less confused, and experienced users can fall back on the raw code. I think enabling more novice users to use the tool is a good thing, as all expert users were novices once upon a time. Right now it's a sea of dropdown and text input boxes that are daunting. A lot of that could be inferred through contextual clues, so why not arrange the UI to do so?
So I don't really know if I want to go down this route. First of all, I don't plan to offer
raw input. I feel like it will be too complicated for 95% of the users and the 5% who MAY use it, shouldn't need to because the UI gives all the same functionality, but will less places for the person to make mistakes.
So just to be clear. The user does not see all of that craziness right away. That is an example after a user has built out a bunch of elements. It won't be that crazy when a user tries to use it.
For example, this is how it would look when a user first sees it.
Then when the user turns it on, they get the following options.
From there, they can start adding different types of polygons to different layers as they see fit until they get to something like what I posted originally...
I don't like the idea of grouping it based on layers because I don't want to treat a layer special at all. I want the exact same logic to apply to all functionality exactly the same way and the cutouts just so happen to go on one or more layers. This simplifies the development immensely. Adding a new polygon for example, is as simple as adding the functionality and it will automatically apply to all possible layers. Adding a new layer is as simple as adding the layer type and all existing polygons will already be wired up to work with it. I want to make the implementation as flexible as possible, while avoiding developing layer specific logic. By doing layer specific logic (even if it is just in the UI), it adds a lot of unneeded complexity to the design (IMO).
If I do handle multiple points, I will probably want to change it from
[[x1, y1], [x2, y2], ...] to just
[x1, y1], [x2, y2], .... People don't need to know that is an array. I can stick the brackets around it before submit to validate it is properly formatted JSON. That will likely make it less confusing. Because you do have to add a line item for each type of shape you want to add, I do like having the ability to add more than one in a single row. So if you only need to draw 5 extra holes with 3mm diameter, they can all be added with a single line item.
I don't expect more than 10-15% of people will actually want to draw extra polygons and the ones that will want to will want as much control as I can give them. I think this starts small and builds on itself pretty well so people can build most of the functionality they would want with it...
Oh, and live preview is not going to happen with my engine.
Everything is evaluated on the server side, so that is just not very feasible.
Also, I don't see the point in not drawing layers. Yes, if I was still using FreeCAD and it took 45 seconds to draw, it would make sense. But even the most complex layouts take less than 10 seconds to draw with my new implementation.
Don't take this the wrong way. I appreciate the feedback and the work you have done on the old builder, but I am trying to offer as many features and as much flexibility as I can without really changing the complexity of the application from an implementation perspective. I think the way I have it currently designed lets me do that...
PS - I could make the
Layers dropdown a multiselect so you can pick which layers you want a specific cutout to be drawn on. I think that is probably a more likely use case. I originally added the concept of
All, but with a multiselect it could make it even more flexible.
