Hello all. I am late to the party and have yet to read through this thread. I did receive a PM from jnxd asking for some input regarding the Topo Naming work I did last year, so I imagine this year's GSoC is relating to Topo Naming? That is great! I have PMed jnxd my personal email so that he can access me more readily, as I'm not on these boards as often as I was last year.
I will say I've been working 'offline' (from here) a bit on a prototype Topological Naming solution written purely in python. The idea was that it is easier and quicker to develop-test-refine using python and its built-in testing framework rather than trying to do all the development within the larger FreeCAD project. If I could develop a solution using just python, the idea was to later write the FreeCAD->python code that is necessary to use that solution in the FreeCAD project.
I was hesitant to post anything about this work on the boards here due to the strong opinions that any Topo Naming solution must by definition be written in C++ at the lower level - I wanted to wait until I had a better working solution before floating it out for further discussion. But, all that being said, I'm also open to discussing and sharing the work I've done in that arena as well. It hasn't come all that far, but I do think it may be a more sustainable solution rather than using the OCC built-in topo naming stuff.
Edit: after reading through the thread a bit I have an additional comment.
Moving forward, there is a need to replace the use of BRepBuilderAPI_MakeShape with a more general implementation
For what it's worth, if you look at my
tnaming_ezziey_01 branch, you'll notice I've created a
TopoNamingHelper class. This class is subsequently used in various helper methods that I've added to the
TopoShape class. One of these methods is
trackFuse.
This trackFuse method is then
used in FeaturePartFuse, which is the existing legacy FreeCAD code that gets called whenever two shapes are fused together.
So why did I go with this approach? Well, there are various analogs to FeaturePartFuse already that do many of the common tasks that we want in FreeCAD: there's FeatureFillet, FeaturePartBox, FeaturePartBoolean, etc... Traditionally, each of these creates the requisite OCC objects needed to perform the needed operation, i.e. BrepAlgoAPI_Fuse for the fuse operation. You'll notice in my FeaturePartFuse implementation, I've removed that code and moved it instead to the trackFuse method in TopoShape. The reason for this was in order to retain access to the BrepAlgoAPI_Fuse instance without having to pass it around - also, philosophically, I don't believe that FeaturePartFuse should itself modify the TopoShape, but rather call access methods located in TopoShape that themselves modify the stored TopoDS _Shape variable.
Finally, if you look at the inherited methods that
BrepAlgoAPI_Fuse has from BrepAlgoAPI_BooleanOperation, you'll notice there are methods such as IsDeleted, HasModified, etc...
So that was the strategy - move all the actual "change an OCC TopoDS_Shape" logic out of periphery classes such as FeaturePartFuse and move it into TopoShape. Subsequently, tap into the *API_whatever OCC classes to track the modified/deleted/created topology using OCC's builtin tnaming classes.