Closed Francisco-Rosa closed 2 months ago
Response to observation 1:
Sorry Yorik, I didn't understand that it was a question to answer, but rather some guidelines, which are excellent and I followed them.
I believe that the main issue is in the single file of doors and windows. The first step is quite difficult, it will be to rework the file(s) from scratch with a basic Sketch in the vertical plane (XY, for example), which will define the opening in the wall and all the elements will be fixed to it through the Attachment, similar to the objects delivered in this third stage.
From there, there are three considerations to deal with this issue, see what you think:
The main file can be used to create new components and through macros it will be possible to extract derived components, which will be able to be applied to a project. This strategy has the advantage of generating a very wide range of solutions, but the disadvantage of requiring more work on the part of the users, in addition to forcing them to deal with a complex file where it will not be possible to delete the properties not used in the final solution used;
Do not use a single file and generate several simpler individual files with the solution to be applied directly to the project. Advantage: simple and direct. Disadvantages: solutions are limited to the number of derived files;
Combination of possibilities 1 and 2, that is, leaving a single file available only to create other alternatives and, at the same time, the simplest and most defined ready files.
Regarding an example of using macros, as mentioned in report 3, I left the file Sideboard_R01.FCStd with four macros. You can test them there. The issue that has not yet been resolved is that the Prop object is renamed each time a parameterized component is inserted (Prop001, Pro002, etc.). It would be necessary to specify the Prop object manually or automatically (better!) when applying the macro. I'm thinking about how, any suggestions would be welcome, of course.
While on the subject, would it be possible to allow the texts in the object tree to be formatted in Python? This way, it would be enough to open the text, or use a menu activated with the right mouse button and click on "run macro". Here's a suggestion, what do you think?
Note 2:
Yes, I can request progressive PR, without a doubt. I will remove the single file for doors and windows, which will need to be redone, and I will leave the ducts and the latter delivered, which will still undergo minor revisions before the PR.
As a final comment, I would like to know your opinion on the air conditioning ducts files, regarding Report 2. I don't know if I'm mistaken, but I didn't see your comments on these files specifically.
"Otherwise, good job, the models are good and the parametric system is powerful. This will be a significant asset to FreeCAD!"
Thank you very much!
Thanks for the answers! I just saw your PRs on the library, thanks for that!
I let you look at the best way to cope with producing different "static" versions of an object, indeed a macro seems a good idea. I have no strong opinion on how to do that, but having one "master" single file that produces several "dumb" objects seems good to me. For windows there is indeed the problem of defining the hole in the wall, which requires something parametric, but there are other ways to achieve that too, for ex having a second object (a cube) that defines the opening...
Adding a context menu entry to the tree view can be done in two ways: Either in the parametric object code (in the view provider), or in the workbench definition code. Here since your objects use mostly expressions, and you don't have a workbench, it will be harder, but I would start creating the macros, and we can see about how to make a better UI next...
Nice work!
I still have basically two observations:
Otherwise, good job, the models are good and the parametric system is powerful. This will be a significant asset to FreeCAD!