Propose to change App::Part Tree View behavior

[realthunder]

The current App::Part (and Body for that matter), behaves differently than other type of objects in the Tree View. For other objects, their children in the tree view control their own visibility independent of the parent. App::Part (actually GeoFeatureGroup), on the other hand, overrides the visibility of its children. So the user (me at least) sometimes want to see the child object, and toggle the visibility a few times to try to find it in the scene, only to realize later that it is under a hidden Part. This problem may not be obvious to those who are used to Part feature from the beginning of its birth, but imagine in the future where we can have nested Parts, toggling the visibility to reveal a deep nested child is going to be a lot more troublesome.

So here is my proposal. Let's make Part the same as others, and let the child item control their own visibility in the tree view. Use a task view to configure the visibility of Part's children. How about that? If everyone is on board with this, I'll volunteer to implement this.

[DeepSOIC]

I'm afraid I don't like the idea. The new (current) behavior is a bit confusing, but very useful.

[DeepSOIC]

I have a different idea, and I think I may try it in part-o-magic.

The idea is, display mode of Body should depend on if its tree node is expanded or not. If not, the body displays its final shape. If yes, the body displays features.

Although this idea applies to Body, it can be extended to simply show Part if Part is expanded.

Also, it may be interesting to temporarily show a deeply nested child. Ickby suggested to add its inventor node to document root for that... so the technical side should be relatively easy. But how to organize it in gui - I don't have a clear idea.

[realthunder]

I'm afraid I don't like the idea. The new (current) behavior is a bit confusing, but very useful.

So about the nest Part scenario I describe, don't you find it troublesome? And this also makes App::Part difficult to get along with other WB. Say you create fusion out of two children of an App::Part using Part WB, that two children will be hidden automatically. I know mixing PartDesign and Part is bad and all, but there is nothing to prevent it. And with my proposal, there is less a need to worry about that.

The idea is, display mode of Body should depend on if its tree node is expanded or not. If not, the body displays its final shape. If yes, the body displays features.

I like the idea. But it doesn't address the fundamental problem here. The problem is, the children visibility should be a property stored in the parent (preferably the DocumentObject) , rather than in the children's ViewObject. An object shouldn't care who claims it, and it should behave just the same.

Also, it may be interesting to temporarily show a deeply nested child. Ickby suggested to add its inventor node to document root for that... so the technical side should be relatively easy. But how to organize it in gui - I don't have a clear idea.

Yes, and I think my App::Link prove that can be done. Besides, here, right now, we don't need to deal with the tricky selection problem, yet.

[ickby]

I also don't like the idea. I find it quite useful to have the visibility handled by parts, i need to toggle everything within a part on off way more often than individual parts.

[DeepSOIC]

I know mixing PartDesign and Part is bad and all,

Part container has nothing to do with PartDesign. And mixing Part and PartDesign isn't bad. My opinion is that all workbenches should cooperate as much as possible, not isolate themselves from each other.

And this also makes App::Part difficult to get along with other WB.

App::Part will work very well with other workbenches hopefully but now you can install my Part-o-magic, which was made to bring that in right now.

There's one important thing. Links across Parts shouldn't be common thing. If you want to use that-deeply-hidden-object from some other part, you should bring it in using a shapebinder-like tool first. This way, you don't have to dig the tree all that often. And most of times so far, I didn't even have to show the object I wanted to use, because I knew exactly what it was, thanks to all the detailed hierarchy.