Model Tree widget instabilities

[DeepSOIC]

! this thread was split off Changed Document Linking: Bidirectional Graph Structure. It started off this post:

I am not sure if this is the right place to bring up this issue. I just stumble upon this thread, which I think is kind of relevant.

In FC, a document object can be linked to many other objects, hence the InList. But in treeview, an object can only appear in one place. So, when adding or deleting new objects, their children will just magically disappear, re-appear, and out of order (e.g. Cut object with reversed Base and Tool). With this new graph structure, will it be easier to just show an object in all of its parents child branch?

-----------------------------------

With this new graph structure, will it be easier to just show an object in all of its parents child branch?

Most likely no. Tree view grouping is controlled by claimChildren method of viewproviders, and may have no relationship to InList/OutList at all.

[realthunder]

Most likely no. Tree view grouping is controlled by claimChildren method of viewproviders, and may have no relationship to InList/OutList at all.

I see. But I think the disappearing/re-appearing issue still stands. I don't think I am the only one who is kinda annoyed by this. I developed habit of constantly renaming the object just to see its children.

Are there any reason of using clainChildren rather than OutList to determine the children? So that the object can choose which child is shown in the tree view? Is there any use case of such object, i.e hiding dependencies on purpose?

[DeepSOIC]

Are there any reason of using clainChildren rather than OutList to determine the children? So that the object can choose which child is shown in the tree view? Is there any use case of such object, i.e hiding dependencies on purpose?

Well, tree view is more for organizing the model, rather than to show dependencies. To view dependencies we have Tools->Dependency graph, as well as a few macros for more interactive browsing of the dependencies.

Example of objects that don't parent its dependencies:
* Draft Clone
* Sketch
* PartDesign features always depend on previous PD feature, but never show this in tree
* any attached object depends on objects it's attached to, but it is not reflected in tree
* sweep partents profiles, but not sweep spine (path).
...

[wmayer]

I see. But I think the disappearing/re-appearing issue still stands. I don't think I am the only one who is kinda annoyed by this. I developed habit of constantly renaming the object just to see its children.

A tree view is only a special graph and cannot display a general DAG. So, if an object is referenced by multiple objects one way would be to create a tree item for each of them which causes other problems. Therefore tanderson implemented the DAGView which shows all the connections.

Are there any reason of using clainChildren rather than OutList to determine the children? So that the object can choose which child is shown in the tree view? Is there any use case of such object, i.e hiding dependencies on purpose?

In most cases claimChildren and the OutList are coincident. But there are a few cases where you have a connection but don't want to show i in the tree view. For example in PartDesign when you place a sketch onto a face of a pad then it's not shown as child. This way we can keep a rather flat layout. If we displayed the real connections you would get a very nested tree view which is ugly to work with because you had to expand a lot of tree item when changing something on a prior modeling step.

[realthunder]

Are there any reason of using clainChildren rather than OutList to determine the children? So that the object can choose which child is shown in the tree view? Is there any use case of such object, i.e hiding dependencies on purpose?

Well, tree view is more for organizing the model, rather than to show dependencies. To view dependencies we have Tools->Dependency graph, as well as a few macros for more interactive browsing of the dependencies.
...

It does make sense to hide dependency on some of the objects. But still I think those claimed children should not just disappear and reappear often. That partially negates its purpose of "organizing the model", don't you think? Dependency graph really isn't humanly readable for complex projects.

In order to hide dependency, we can just use what returns by claimChildren as it is, no change. But when the object is claimed by other objects, don't remove it from its current parent in the treeview. We can use the newer graph based more efficient InList to perform things like object deletion, etc.

[realthunder]

In most cases claimChildren and the OutList are coincident. But there are a few cases where you have a connection but don't want to show i in the tree view. For example in PartDesign when you place a sketch onto a face of a pad then it's not shown as child. This way we can keep a rather flat layout. If we displayed the real connections you would get a very nested tree view which is ugly to work with because you had to expand a lot of tree item when changing something on a prior modeling step.

I haven't looked at the code yet. But, QT can definitely do things like dynamic tree expansion, right? So we can simply delay branch population until user actually expands that branch.

[wmayer]

I haven't looked at the code yet. But, QT can definitely do things like dynamic tree expansion, right? So we can simply delay branch population until user actually expands that branch.

Sure, but that's not the point. After doing 20 or 30 modelling steps with sketches, pads or pockets you get a very wide tree structure which doesn't only look ugly but is also very inconvenient to work with.

[realthunder]

I haven't looked at the code yet. But, QT can definitely do things like dynamic tree expansion, right? So we can simply delay branch population until user actually expands that branch.

Sure, but that's not the point. After doing 20 or 30 modelling steps with sketches, pads or pockets you get a very wide tree structure which doesn't only look ugly but is also very inconvenient to work with.

You've probably missed one of my previous posts. I agreed that some object needs to hide the dependency, like the Sketch object here. I am saying that we shall just keep using cliamChildren as it is to only show children the object wants to show. But when an object is newly claimed, do not remove it from its current parent. How about that?

[wmayer]

But when an object is newly claimed, do not remove it from its current parent. How about that?

The tree view implementation is based on Qt's QTreeWidget and thus is item-based. Now internally we have a 1:1 mapping of view provider and tree item. This causes then the behaviour. To fix this one needs to make a 1:n mapping but this is a huge amount of work.

An alternative is to use Qt's QTreeView class and the MVC pattern. The implementation however was never finished and is from a time before the claim-children concept was introduced. Personally I prefer this approach. (The involved classes are TreeView and DocumentModel).

[DeepSOIC]

But when an object is newly claimed, do not remove it from its current parent. How about that?

... To fix this one needs to make a 1:n mapping but this is a huge amount of work...

I understood realthunder's idea as one not requiring needing a 1:n mapping. I see three possible implementations:
1. The first parent who claimed a child permanently gets it as child. New parents are simply ignored. [realthunder's idea, 1:1 mapping]
OR
2. If more than one parent claims a feature as child, let no one get it. Put that feature on the top level (or preferably on container level, e.g. group or Part or Body) [my idea, haven't seen anyone suggest it before]
OR
3. show object in tree multiple times if it is claimed as child more than once. [1:n mapping]

PS. This thread needs splitting... EDIT: done!