It's not that simple as that. And I still/again think that the current plan to merge the topo-naming solution is wrong. Now, of course, I could just lay back and see this whole thing fail and come back and say "I told you so", or hope for the best that I'm wrong and it succeeds, but that would not be fair to any of us. And least of all to realthunder. I really appreciated to work we had done on App::Link and Assembly4 in the days of pre-0.19 (he did most of the coding of course !) and I wouldn't stand by if the problem I've seen is real. Please read carefully.adrianinsaval wrote: ↑Thu Sep 15, 2022 2:03 pm I think he has, but zolko kinda wanted to start over just for sketches.
You're right that my staring point was not very scientific, merely an intuition that this was not going to fly. As it happens, my intuitions are often right and I have a tendency to follow them. It did bring me into trouble sometimes, but it also saved quite many projects. If I'm wrong you can put the blame on me, I won't die from it.
As it happens, user GuGa has raised a problem in the German forum. Admittedly, he presented his case quite badly, but he did uncover a real problem with LinkDaily topo-naming method. Unfortunately, people didn't understood what he was after and the thread has been blocked. The problem is very easy to reproduce:
- in a new document, using only PartDesign, create a new Body.
- create a sketch, draw a rectangle, exit.
- pad the sketch
- select an edge and make a fillet
- select a face, draw a sketch (a hole) and make a pocket through all
- delete the fillet
- the hole disappears, and the sketch of it is on a wrong face
Code: Select all
OS: Debian GNU/Linux 11 (bullseye) (KDE/plasma)
Word size of FreeCAD: 64-bit
Version: 2022.709.26244 +5001 (Git) AppImage
Build type: Release
Branch: LinkDaily
Hash: 096210d21183e9dfdc3b25777760bfb6c00a210b
Python version: 3.9.13
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United Kingdom (en_GB)
I then have tried to test such features, and as I have found out the LinkDaily toponaming algorith is very good for additions and modifications, but it can't deal at all with deletions. It's actually worse than stock FreeCAD for this. Having the bad reputation I have, I didn't want to be the harbinger of bad news, so I decided to let it be. But since I'm quoted here I want to bring my explanation, and also a plan forward.
So the first question is: can people reproduce the problem from the steps above, using LinkDaily ? If yes, I think that apologies to user GuGa would be welcome (and if no, please blame me and leave him alone):
On a technical level, I've read realthunder's entry in the wiki (https://github.com/realthunder/FreeCAD_ ... cal-Naming) and I see that the base feature are 2 new functions setElementName() and getElementName(). This is logical and corresponds to what I have also proposed in the thread toponaming solution for sketches: it all begins with FreeCAD being able to explicitly giving names to geometric elements. So far so good.
If you grep setElementName on LinkDaily source code, you get returns only from :
Code: Select all
App/ComplexGeoData.***
Mod/Part/App/TopoShapeEx.***
Mod/Sketcher/App/SketchObject.***
Unfortunately, this is not the current plan:
If we follow this plan, we won't see any real benefits, but also no real problems, before EVERYTHING is merged. And if/when the problems appear, we'll have to deal with a huge chunk of code already merged.
- The first batch of patches makes necessary core changes to build up the foundation for generation and utilization of the new Topo Naming. There is no visible changes for the end-user at this stage
- The next batch of patches adds code to the features from Part workbench (...) And if sketch is involved (e.g. Extrusion from a sketch), then try not to modify the sketch
- The third batch of patches modifies the Sketcher workbench to fully support the new Topo Naming
So what I propose, again, is the following:
- merge the explicit naming of elements ...
- ... but not realthunder's naming algorithm. Leave it to FreeCAD how elements can be explicitly named
- fix Sketcher so that the internal naming is persistent : Constraint_19 should always be COnstraint_19 even if Constraint_18 has been deleted. Same for lines, points, ...
- let Sketcher use setElementName() with it's own internal - now persistent - naming convention : in this case, the topological naming will, if everything goes according to plan, be solved for sketches
- if not, we have limited amount of code to search for
- now a big chunk of the code can be used and debugged
- release FreeCAD v0.21
- merge the rest of toponaming on top of the debugged code
- release FreeCAD v1.0