I was the Chief Software Architect, it did help somewhat that I was also the CEO.
It appears you learned about the parameters panel option for āhiddenā between the two projects as you used the let command to hide them in one, not exactly what it was designed for.
/* [Hidden] */
You may have over-complicated the options in the projects.
The audience most likely to use the Customizer service has far less ability than a developer. My aim for features is those they need to answer, followed by those they can answer (anything that tweaks) and those they need not answer (my job to determine).
Imagine Apple creating it vs Red Hat.
You could do with using modules far more, you can also nest modules within a module to simplify your work.
If you utilise the Children() feature and design modules to do a lot of the heavy lifting followed by reusable chunks, you can save yourself a lot of repeative code when similar actions are taken. With those chunks being introduced using the Children(); method.
This can be particularly useful for things needing to be translated, scaled or resized.
I found the Swatch grid particularly dense with parameters, many of which were just not required. It can be daunting for users to see 50+ options when they only really need to enter half a dozen or less. Only then should they be allowed to tweak.
I think you tried hard to fit everything on the actual swatches when in reality, much couldnāt be due to size. We do not have access to text metrics, so it is impossible to service the needs offered in such a tiny space.
Your very first placeholder value is clipped and it isnāt very long. You are hampered by the constraints.
I designed my filament swatches a few years ago. I struggled to provide the ability of all lengths of text on a swatch because the names needed to fill the spaces are simply too long in some cases.
You tried to match the BL one, but it is too constricting.
I would also have come up with descriptors for the value you sought. Line 1, Line 2 etc only get you so far, you had more of them, and you could easily have used; brand, material, and colour and made it easier on the person filling it in.
You do love comments, I prefer making the modules and function names very explicit. Almost all coding solutions provide cursor position indication of the start and end of nested code. Yuo do not need to provide the end comments for those things anymore. Even the code editor in the browser for the Customiser shows matching groups.
You clearly know how to use OpenSCAD, there is more you can get out of it when you use the additional methods you are not using yet (at least from the code I have seen). Your code will become neater, your code will be easier to lift and use in other projects.
You are using hull and cylinders to create rounded rectangles, it is more efficient to use linear_extrude, offset and square. You will not get any performance improvements where you have used it as there is only one. But, for larger projects, you should consider how to reduce the triangle counter and the processor load. Cylinders use the $fn function the offset feature doesnāt, but $fn is slower.
Every model I have uploaded was designed using OpenSCAD. Some of mine end up with more than tens of millions of triangles. Performance is key there.
As I always sayā¦
If you canāt improve something you wrote 6 months ago, you are not learning.
