DeepSOIC wrote: ↑Sat Jun 30, 2018 8:34 pm
Does toggling visibility of an object change the App-domain visibility property? If so, what ends up being touched? How does FC determine that a recompute is necessary to update the example compound?
For backward compatibility reason, 'Visibility' in App has 'Output' status bit set by default, which makes it behave the same as Gui 'Visibility', i.e., do not touch object when changed. You can change that behavior by calling obj.setPropertyStatus('Visibility', '-Output'), after which the object will be touched when toggling visibility. And yes, the Gui 'Visibility' and App 'Visibility' are synchronized. Extra logic can be implemented in parent object, in case it uses its children object's 'Visibility' property for building compound, for example to automatically change the property status of the newly added child. I didn't implement that in App::Part, because I think it is better to store the visibility information of the children directly inside parent, instead of using children object's global visibility information. LinkGroup has 'VisibilityList' property for that purpose.
DeepSOIC wrote: ↑Sat Jun 30, 2018 8:37 pm
I have a feeling that if I try this feature, I will instantly understand. But from a more passive reader's perspective, the use case doesn't justify second pass. Is the second pass needed for assembly3?
Because for better organization purpose and easy editing, all SketchExport are grouped under its parent Sketch object, by using a PropertyLinkList, which causes the dependency inversion.
There is another solution to this problem now. I later added a
Hidden link scope, which hides its dependency information from the core. It should now be possible to change PropertyLinkList in Sketch to PropertyLinkListHidden, and add a normal PropertyLinkSub to SketchExport, which will be a better solution. I implemented hidden scope later, and decide to leave the sketch export unchanged as an example of two pass recompute, in case it is needed in other use case.