DAGView

[triplus]

Some observations as i see them ATM:

SampleImage.png (23.72 KiB) Viewed 3019 times

Old behaviour (mirrored vertically):

• Easier to read but more space consuming.

New behaviour:

• Harder to read but more space efficient.

It will be interesting to see what happens when i will be able to apply hide filter for Body and Part. it could happen new behaviour could become easier to read. By easier i am talking about the overview that gives basic perception. But that has its limits i know as sample image represents clean and simple design tree but overview can become much more complex quickly. As for detailed information connection highlighting is used anyway.

P.S. I will try to find that crash but it might happen it was just some PartDesign Next related issue and DAGView when clicking on the tree objects just exposed it.

[tanderson69]

Some observations as i see them ATM:

SampleImage.png

Old behaviour (mirrored vertically):

• Easier to read but more space consuming.

New behaviour:

• Harder to read but more space efficient.

there are several things I would like to do to try and get a clear picture. However, these go beyond the scope of the view alone. So for right now I am trying to get an accurate, acceptable view and not so much the best view. I am pretty happy with the accuracy of the layout engine. I don't see any lines crossing nodes.

It will be interesting to see what happens when i will be able to apply hide filter for Body and Part.

uncomment lines: 167, 168, 169 in src/Gui/DAGView/DAGModel.cpp

P.S. I will try to find that crash but it might happen it was just some PartDesign Next related issue and DAGView when clicking on the tree objects just exposed it.

I had an older version test file here that was causing some crashing. Might be what you are seeing.

[triplus]

uncomment lines: 167, 168, 169 in src/Gui/DAGView/DAGModel.cpp

Looking good.

[tanderson69]

I made a change to the layout engine based upon feature type. Here is a side by side comparison:

together.png (111.32 KiB) Viewed 2810 times

I like the new one because it keeps the "real" features in line. "Real" is a poor choice of words but I mean; the features that actually change the object. Opinions?

[triplus]

Well some sort of hierarchy probably makes it easier for users to read the graph. Therefore looking from the single Body perspective the resulting Part will indeed be made by adding features one after another and keeping the features vertically aligned does introduce hierarchy. Especially if creating forks in Body will not be possible anymore.

Therefore i would say from single Body perspective if forks will not be possible anymore vertically aligning features might indeed make sense (space efficient and quite easy to comprehend). If forks will be possible i guess features should vertically align in "branches" respectively.

[jmaustpc]

I made a change to the layout engine based upon feature type. Here is a side by side comparison:

I like the new one because it keeps the "real" features in line. "Real" is a poor choice of words but I mean; the features that actually change the object. Opinions?

Hi Thomas
I don't know enough about the topic to offer much useful detailed input....but I thought I would post a note to say your work looks great to me!

Jim

[jriegel]

Really nice!

[tanderson69]

Really nice!

Thanks. I was hoping you would respond. I wanted to get your opinion on how I achieved this change, as I am starting to intrude on the "core". Here is the diff for the difference in the "old", "new" picture in the above post.

Code: Select all

tanderson@tanderson-Utopic:~/Programming/freeCad/free-cad-git$ git diff c198369 cf17e1c
diff --git a/src/App/DocumentObject.h b/src/App/DocumentObject.h
index 3f0b07a..0191464 100644
--- a/src/App/DocumentObject.h
+++ b/src/App/DocumentObject.h
@@ -49,6 +49,14 @@ enum ObjectStatus {
     Expand = 16
 };
 
+/*!Used to describe feature process*/
+enum class ObjectDescriptor
+{
+  None = 0,
+  Create,
+  Alter
+};
+
 /** Return object for feature execution
 */
 class AppExport DocumentObjectExecReturn
@@ -138,6 +146,8 @@ public:
      * -1: the document examine all links of this object and if one is touched -> recompute
      */
     virtual short mustExecute(void) const;
+    
+    virtual ObjectDescriptor getDescriptor() const {return ObjectDescriptor::None;}
 
     /// get the status Message
     const char *getStatusString(void) const;

//removed irrelevant changes to dagview model
...

diff --git a/src/Mod/Part/App/DatumFeature.h b/src/Mod/Part/App/DatumFeature.h
index 0e744d5..940fc64 100644
--- a/src/Mod/Part/App/DatumFeature.h
+++ b/src/Mod/Part/App/DatumFeature.h
@@ -53,6 +53,8 @@ public:
 
     /// Return a shape including Placement representing the datum feature
     TopoDS_Shape getShape() const;
+    
+    virtual App::ObjectDescriptor getDescriptor() const override {return App::ObjectDescriptor::Create;}
 
 protected:
     void onChanged (const App::Property* prop);
diff --git a/src/Mod/Sketcher/App/SketchObject.h b/src/Mod/Sketcher/App/SketchObject.h
index 45ef542..d3ca9fa 100644
--- a/src/Mod/Sketcher/App/SketchObject.h
+++ b/src/Mod/Sketcher/App/SketchObject.h
@@ -56,6 +56,7 @@ public:
     const char* getViewProviderName(void) const {
         return "SketcherGui::ViewProviderSketch";
     }
+    virtual App::ObjectDescriptor getDescriptor() const override {return App::ObjectDescriptor::Create;}
     //@}
 
     /// add unspecified geometry

Really basic, just an enum added to App::DocumentObject and a virtual method added to App::DocumentObject and a couple of test subclasses. Note: The very first post of this thread was describing this. This works good for the dag layout engine, but I see these document object descriptors as having a lot more potential than just laying out the dagview. For example: when walking(visitors) up and down the graph for some other operation, the descriptors could be used to determine what path to take when there is a fork. I can put together a visual of an example situation, if this doesn't make sense.

tangent thought: If I remember correctly, you mentioned in another thread about the document having an actual graph in the future. Maybe what I am talking about, is something that would be best be served after a document graph implementation?

Thoughts?

[Fat-Zer]

I'm not sure if it's still present in the latest version, but in my copy there is an error:
If document gets a cyclic dependency boost::topological_sort in Gui::Dag::Model::updateSlot throws an exception which passes to QApplication event loop and crashes FreeCAD (or making it exit).

By the word, are icons intentionally made smaller than in the tree view?

[tanderson69]

I'm not sure if it's still present in the latest version, but in my copy there is an error:
If document gets a cyclic dependency boost::topological_sort in Gui::Dag::Model::updateSlot throws an exception which passes to QApplication event loop and crashes FreeCAD (or making it exit).

Yeah that is probably still there. I knew I was going to have to catch that exception, but forgot about it. Thanks for the reminder.

By the word, are icons intentionally made smaller than in the tree view?

DagView icon sizes are based off of the font metric. I haven't done any close comparison to the tree view. I can barely notice any difference here, how bad is it there?