Model Tree widget instabilities

[agryson]

I don't see how a tree view and a linear historical view would be two different things.

First post demonstrates the issue nicely, a child can have multiple parents - leading to weird behaviour when you modify one parent.
A linear history can only have a single parent (the preceding operation) and a single child (the following operation)

[tanderson69]

I do not need to waste 15 minutes of my life looking at your screen captures.

Taking 15 minutes to try and comprehend something is a waste of time?

Objects are listed exactly in the order they were created, from first created at the top to last created at the bottom.

This is just not true. Creation order is all but meaningless in parametric solid modeling. Have you ever used a system that allowed you to re-order features? Have you looked at jans work in part design with insert feature?

That's how I respond to a condescending tone. Which "take 15 minutes and look at them so your idiot brain can understand you are wrong" was.

You put quotes around that? That isn't what I said! I am sorry you took it that way, but don't misrepresent what I said or did to justify your reaction.

@tanderson. What do you think about adding DAG view to combo panel? like making another tab there, with dag view and property editor combined? I have nowhere to place DAG view as of now.

The DAGView is dockable, but I am guessing you already knew that and you want to maximize 3d view screen space? As far as putting it into the combo view, I am guessing it wouldn't be a huge deal, but I haven't looked.

[triplus]

Therefore currently tree view doesn't cut it anymore when it comes to providing information about connections but it makes sense from hierarchy representation point of view. DAGView would require neurones to be rewired from hierarchy representation point of view but it does provide information about connections.

Sample.png (25.05 KiB) Viewed 2164 times

Therefore if DAGView adopts current tree view hierarchy paradigm or tree view highlights parents/children with different color when something is selected. Both solutions should provide what we are after.

[tanderson69]

Therefore if DAGView adopts current tree view hierarchy paradigm or tree view highlights parents/children with different color when something is selected. Both solutions should provide what we are after.

Both of these scenarios provide 2 different GUI paradigms for showing relations. I don't think that is going to clarify anything.

at the risk of igniting this thread again: I think what was throwing norm off with the DAGView was the fact that the body object was coming at the end of the list instead of the beginning. If you look at the dependency graph you can see why this happens. The body object is a feature like everything else and has to be in the topo-sorted list after all of its parents. I have been thinking about a filtering object that can be applied to the dagview that will only show the active body parents. This would probably present an acceptable list.

[triplus]

Both of these scenarios provide 2 different GUI paradigms for showing relations. I don't think that is going to clarify anything.

But what is the initial problem we try to resolve then? User puts a Sketch on XY plane and uses it is a a base for 10 Pad features. Current tree view therefore falls short as it doesn't provide this information to the end user. Dependency graph needs to be used instead to figure it out. On the other hand in the DAGView you select the Sketch and it highlights the connections to Pad features and to XY plane. Therefore you don't care anymore if you have 10 Sketches listed instead of just one to show the relations. As it would only clutter the tree view anyway. But you get to see the connections easily without using the dependency graph.

From coding perspective likely selecting the Sketch in current tree view and highlighting the XY plane in for example the red text and 10 Pad features in for example the green text is easier. But DAGView likely enables the possibility for building more advanced UX if the need would arise. And likely a lot more hard work.

at the risk of igniting this thread again: I think what was throwing norm off with the DAGView was the fact that the body object was coming at the end of the list instead of the beginning. If you look at the dependency graph you can see why this happens. The body object is a feature like everything else and has to be in the topo-sorted list after all of its parents. I have been thinking about a filtering object that can be applied to the dagview that will only show the active body parents. This would probably present an acceptable list.

To me it sounded more like his mind was set. Adapt the tree view paradigm in DAGVIew or he won't use it. But partially this is your fault as you didn’t enable the DAGVIew once the development cycle started. I doubt he used it for 15 minutes in the past BUT i might be wrong and apologize up front for the assumptions made.

P.S. You should (if you choose to) care only about the valid feedback part. And that is current tree view hierarchy approach will likely be hard to replace for now. And you did resolve one mayor problem current tree view has with DAGView. Therefore i do see possibilities here for progress.

[tanderson69]

But what is the initial problem we try to resolve then? User puts a Sketch on XY plane and uses it is a a base for 10 Pad features. Current tree view therefore falls short as it doesn't provide this information to the end user. Dependency graph needs to be used instead to figure it out. On the other hand in the DAGView you select the Sketch and it highlights the connections to Pad features and to XY plane. Therefore you don't care anymore if you have 10 Sketches listed instead of just one to show the relations. As it would only clutter the tree view anyway. But you get to see the connections easily without using the dependency graph.

I don't think we are on the same page. The point I was trying to make: If you look at the sample picture you posted, you have 2 gui structures in the same view both implying dependency/relation. You have the DAG elements then you have the tree elements. These will be either be redundant or conflicting, so what is the point?

[triplus]

Well the point is when i would click on the Sketch feature the thing would light up.

And i would know it was made on XY plane (parent) and it has one child (Pad).