When copy and paste object into another document, the object will be marked for recompute anyway, so the element map will be regenerated as well. The same principle applies to your use case. If there are objects coming from multiple documents, then it is possible to have ID conflict, hence, a recompute (of those imported objects along its dependencies) is required. For concurrent editing, I think you'll likely run into similar problem of object name conflict, if user is adding objects at the same time. How do you plan to solve that problem? We can of course extend the addObject() API to accept a user supplied ID number just like the name. So whatever your solution is, it should also be applicable to ID just the same.ickby wrote: ↑Thu Apr 22, 2021 10:06 am 1. The ID of document objects are used in naming now as the first real use-case. As far as I can see they are an integral part of the element mapping and hence names. The problem for me arises, that those IDs are not controllable. Hence in my effort to recreate a document fully from python I ran into trouble: I can cannot create objects with a certain ID, but some properties use those IDs to refer to this element in the new naming. Hence It breaks the recreation if e.g. the order of object creation changes.
The element map is designed to be largely 'invisible' to normal user. The new name is stored alongside the indexed based element reference in those property links in something called shadow. The tracking of element update is mostly implemented in PropertyLinks.cpp using static tables. The logic flows like this. Property link setValues() will call PropertyLinkBase::_updateElementReference() to obtain shadow names, and also register itself in a static table _ElementRefMap that maps the geometry owner object to this property link. When the geometry owner object updates, it will call static method PropertyLinkBase::updateElementReferences(), which will consult _ElementRefMap and update each property that references the relevant geometry. If there is any geometry element index changes, the property will be updated with the standard aboutToSetValue/hasSetValue() API, so the user code can catch that through the usual onChanged() interface.2. It looks like the element maps of geometries are updated automatically for dependent objects. However, I did not find any code that makes this observable. I fear that it could happen that a Geometry inside e.g. PropertyComplexGeoData is changed without me noticing it. I think the "propertyChanged" should be emitted than, or maybe another document-observer call, so that I can react on this change. Actually thinking about it, a separate one makes most sense, as most likely in 99% of times the change in ElementMap will be followed up by a recompute and hence property update anyway.
Thats perfect and works well for me. My second point is done with this info.
I need to avoid recomputes. They take potentially a noticeable time, which ruins the user experience if synchronization happens in the background. Hence I rely on data load only of individual properties and prevent any recomputes.
FreeCAD actually takes care of this internal renaming when merging/pasting objects, which is a very complex and error prone process. It will have to modify all involved property link and expression references as well.onekk wrote: ↑Mon Apr 26, 2021 4:40 pm but if you are merging different objects between different document, the way FreeCAD stores thing, make a recompute a "minimal requirement", how to cope with "not unique name" or other conflicts, without a "recompute", the treeview has to be updated and many other things are to be done.
I have thought about this 'connector' problem before my work on topo naming. This is actually a 'user problem' that is beyond the scope of the topo naming problem addressed here, but the software should also provide a way for the user to manage those 'connectors'. I introduce the 'Element' concept in my Assembly3 workbench to do exactly that. You can read the description here for more details. In short, it allows user to create common interface (using the Element object label) for various interchangeable parts/sub-assemblies. See the replacing part demo here.In a complex model, is my "care" to create the appropriate "connector" to place things in placement relative to others, so if "piston1" were modified I "HAVE" to take care of diameter and other things to match with the already present components, maybe it will be handy to have some indication that there are some mismatch, but I don't want to modify all the relation between part.
how such thing is achieved is not a "user problem", but have to be managed in "some way" whichever way is good provided that in a complex assembly a coherence is retained.
Other CAD/CAM gave the concept of Tag similar but not overlapping with FreeCAD "Label" property.
Code: Select all
OS: Debian GNU/Linux bullseye/sid (X-Cinnamon/lightdm-xsession) Word size of FreeCAD: 64-bit Version: 0.20.24781 (Git) Build type: Debug Branch: TopoNaming Hash: cdd2f59a6f91d56e716e26f93a0865e5ede27269 Python version: 3.9.2 Qt version: 5.15.2 Coin version: 4.0.0 OCC version: 7.5.1 Locale: English/United States (en_US)
Code: Select all
<Base> Reader.cpp(282): Document XML element 'ViewProviderData' not found In context: <Exception> Reader.cpp(210): const char* Base::XMLReader::getAttribute(const char*, const char*) const -- XML Attribute: 'Count' not found In context: <Base> Reader.cpp(747): Reading failed from embedded file: GuiDocument.xml
Thanks for taking time, I just pushed a commit for the fix. The problem is actually in the treeview expansion restore. Forgot to pick some changes in my branch.