Tree-Based Attribute Task View

This is a discussion of a new way of creating/editing Attribute Information.

Current Functionality

Currently, the designer creates an UI based on a set of Views. These Views are then displayed starting with the “Top Level View” within the “Attribute Panel” within a ModelBuilder application as shown here:

In the above example, the designer has chosen to use a Group View (with a Tabbed Style) as the top level View. The user then navigates through the attribute information using the provided tabs (and if there are children tabbed Group Views, using those tabs as well.

Proposed Functionality

Instead of using tabs, we could instead use a tree style for navigation and then our more “traditional” Views for modification.

In this case, the Navigation Panel uses a tree to allow users to navigate through their data. Once they found something they wish to examine/change, they select it and it would bring up in the traditional Attribute Editing panel the appropriate View with desired attribute selected. In this example, a Surface Refinement Attribute named Rough has been selected and an Attribute View has been displayed in the editor panel.

Other Requirements

  • Needs to be filtered by active categories - If a sub-tree is empty then it should not be displayed.
  • Needs to indicate problems - Any node in the tree whose’s sub-tree contains an invalid Attribute should be able to indicate there is some kind of problem
  • Ability to search the nodes using a search string
  • Perhaps we should also have a special node that clusters all invalid attributes together? The issue with this might be to how do we figure out which type of View to use to edit the Attribute? This could be solved by one of two ways:
    • Have a Default Style
    • Doing a tree traversal and find the first node that could contain that Attribute

Possible Approaches

Add a new Tree View

One possible approach would be add a new type of Tree View.

<View Type="Tree" Title="Navigator" FilterByAdvanceLevel="true" FilterByCategory="false">
    <View Title="Analysis" />
    <View Title="Materials" />
    <View Title="Modules" />
    <View Title="Bodies" />
    <View Title="Outputs" />

If a child View was another Tree View it would introduce another level in the tree. If a non-Tree child View provided a query string, then it could be used to extract the appropriate attributes and display them underneath the tree node that corresponds to the View. If the user clicked on a non-Tree View node, the corresponding View would be displayed in the attribute editing panel. If an attribute was selected, then the View would also be told which Attribute was being edited.

Potential Benefits

  • Would be a relatively simple extension of the current format
  • No new concepts to learn

Potential Issues

  • Processing would get a bit complicated since the Tree View would go into a different panel than the rest of the Views. So maybe not the cleanest conceptual model.
  • What happens if a Group View contains a Tree View?
  • Could be difficult to update existing projects since this would require modifying the existing View Information

Create a New Tree Layout Specification

We could create a new specification for the tree itself.

<Navigator Title="Navigator" FilterByAdvanceLevel="true" FilterByCategory="false">
  <Resource Query="smtk::attribute::Resource[long{'foo'=5}]" Title="General">
    <Node Title="Material Library" Query="attribute[type='material']" HasView="true"">
      <View Type="smtkTruchasMaterialsView" Name="CustomMaterials" Label="Specification">
          <Att Type="material.real">
              <View Path="/shared-properties/enthalpy/specific-enthalpy" ExpressionOnly="true" />
              <View Path="/phases/enthalpy/specific-enthalpy" ExpressionOnly="true" />
              <View Path="/transitions/transition-spec/solid-fraction-table" ExpressionOnly="true" />
              <View Path="/phases/fluid/density-delta" ExpressionOnly="true" />
    <Node Title="Variables" Query="attribute[type='variable']" ViewName="ExpressionEditor"/>
    <Node Title="Stuff" View = "Instanced"/>
    <Node Title="I/O">
      <Node Title="Inputs" ViewName="InputView"/>
      <Node Title="Outputs" ViewName="OutputView"/>

Potential Benefits

  • You can insert query rules to refer to Attribute Resources and all children nodes would refer to that resource until another Resource Node was encountered.
  • A Node can refer to an existing View by name using ViewName or by explicitly including the View Configuration as a child and using the using HasView

Note that the Views that take in Definitions would be modified to also take in Attribute Queries that can be defined in the Node.

Potential Issues

  • New Concept to learn
  • Can’t be stored with the Resource (due to Resource Node) and probably need to be part of a Project specification.
  • Somewhat Similar to Task Model

Using Tasks

If in addition to defining which View should be displayed in the Attribute Editor Panel, the tree also controlled other parts of the application framework such as:

  • Which Resources and Components should be displayed in the Resource Panel
  • Context Menus
  • Render

For example the complete system could look like this:

Here the Tree is also Resource Panel what information should be displayed in order to see and modify Rough’s association information.

Then the functionality becomes very close to the designed Task System. So in theory the Tree could represent the set of available Tasks and have appropriate badges to indicate the state of the Task.

Much of the above functionality is already in the Task Design and Core Implementation.

Potential Benefits

  • All of the benefits of Tasks and the focus would not have to be only focused on Attribute functionality

Potential Issues

  • Though the Task Information can be stored outside of a Project, it was designed to work with Projects.
  • Need to finish UI and support both Tabs and Tree UI approaches.
  • A bit more broader scope than original problem

@chart3388 @amuhsin @dcthomp @johnt @C_Wetterer-Nelson @Ryan_Krattiger @aron.helser FYI

Just for clarification, is the main goal of the proposed view to provide an easier way to “find stuff” in the attribute editor? (I presume so)

My first impression is that, regardless of the implementation approach, this new view should be a separate dock widget from the current attribute editor, so that they can be used side-by-side.

And I don’t see that the new dock widget should need any “specification”, just a pointer to the top-level view in the attribute editor. (I think we would want the new view to stay sync’d to the current options – categories and advanced level – in the attribute editor.)

At the 10000 ’ view, yes it is a navigator for editing the attribute information that would replace the use of Tabbed Group Views for structuring the information. However, as the discussions have evolved, the entries in the Navigation Tree are beginning to look like more general tasks.

Yes - the Navigation/Task “Panel” would be separate from the current Attribute Editing Panel and the Attribute Editing Panel would become less complicated.

There are 2 reasons for the “specification” in the new Panel:

  1. In the proposed use case which would show the attributes under parent nodes that correspond to Attribute Views, the node would need to be able to access and display these attribute. I can think of 2 ways of doing this:
    • Extending Views to have an API to access the attributes it is currently displaying - I’m not a big fan of this because this would force this API on all Views not just Attribute Views (or the node would need to know about Attribute Views). In the current design they don’t.
    • Have the tree hold the query that would then get passed to the Views has part of their configuration.

In addition, in order for the Navigation panel to do what you are suggesting and just be given the current top-level view and “walk” the View structure would mean that the Navigation Panel would have to know the details of the Views themselves (including custom Views) or we would need to develop additional abstractions for the View classes.

Privacy Notice