Thanks for your questions. Below some answers.
The plugin just need to identify which objects are doors or windows and some of their properties. The principle is that:
- by default the user designates the doors / windows, and their main properties (orientation, type, etc…). The user can define its own list of attributes to appear in the schedule (as a pair property_name/ property_value). Nothing complex, just UI.
- If the object has some attributes coming from known and supported plugins, then FredoSchedule would pick them.
- For custom attribute marking, as in your case, the best would be that the user defines a pattern of attribute matching that would be use for the models, so that the plugin reads the attributes of objects.
- in any case, properties can be completed or modified by manual entry of names / values.
Selecting views is based on standard views (top, left, right, bottom, front, back) or setting the camera interactively. Here too, just UI.
Connecting points for dimensions are fake dimensions that you simulate in the Sketchup model. This would be via an custom interactive tool, just recording where you wish to have dimensions. This will not generate true dimensions in the model however (although the dimensions could be shown visually). The actual dimensions will be generated in Layout via the API.
Limitation of the Layout API is that you cannot update the Layout document when the Sketchup model(s) are modified. This is probably because the Layout document file embeds a copy of the participating Sketchup models. In addition, there is nothing like attributes in the Layout document, so it’s difficult to retrieve what is what in an existing Layout document that was previously generated. This is why a full regeneration is safer. Of course, unless you add doors / windows and change them, you can update the Layout document from the companion schedule model.
I could probably overcome some of these limitations and make sure that additional labels, notes and visual elements that have been added manually can be migrated to the new generated document.
Also, a workflow could be that the user just uses the automated Layout document and copy / paste viewports into another clean Layout document.
Anyway, you are right to point out that there would be as many types of presentation as users and user projects. This is why I will not pursue the development of this plugin. Too much work and hassles with the risk that it covers only 80% of the needs, whereas automation needs to reach 100%.
Still, the idea of using a companion model to generate views, sections, sections boxes, custom hatching of section cut fills, etc… is still an interesting approach to avoid polluting the main design model (and impacting performance), and also obtain some effects that cannot be easily achieved from the main model (like section boxes).