Just do it works, or at least I’m happy with the result. Here’s the first version:
The black areas are through holes, the teal squares are inset, and the blue lines represent the size of the rough openings. I printed this on paper, checked it out for scale, make sure it met with initial spousal approval, and then off to FreeCAD! Should be easy to import Inkscape‘s SVG file into FreeCAD and go, right? Wrong. The biggest issue is that the Inkscape drawing has a line width for all these elements, and the line widths throw things off, ever so slightly. There’s probably some way to write code for this, but disassembling a complex XML file, tweaking it, and putting it all back together again sounds like a project in itself. Besides, I’m trying to create art here, not more code!
I take shot at drawing this in FreeCAD but it’s just too tedious and making adjustments is time consuming. But wait! FreeCAD is mostly written in Python, right? This is like the days of doing rendering in POV-Ray: if I can describe this thing in code, it can be perfectly precise every time and if I change something, it’s just a code edit and re-run. It seems no matter where I turn, there’s coding involved.
The problem with almost anything involving non-trivial code is that the gap between an initial idea and an implementation is always larger than it first seems, and although all the information is there, the FreeCAD documentation at the time was rather scattered. Getting this to work means pulling information from multiple wiki pages, forum posts, and reading code from other macros, sometimes even delving into the C++ code that likes behind the Python interface to understand what’s really going on.
Still, being able to tweak part of the layout and regenerate the entire thing in seconds compared to painstakingly tweaking dozens of elements is pure gold, worth the effort.