Supporting Tabular Attribute Views

This discussion is focused on developing a mechanism for creating a Qt View that displays a set of attributes in a table form as shown below:

If the Attribute Definition with the following properties would be easily displayable in a table:

  • All of the Items are not-extensible
  • All of the Items do not have conditional children
  • If any of the Items support Expressions, then there needs to be an expression for each value instead of a single expression for the entire Item

The above conditions allow an attribute to be constructed as a “regular” structure. Unfortunately, this can severely reduce the usefulness of this type of View.

The design being proposed would allow for conditional children and could allow for extensible non-Group Items in theory.

Proposed Design

Instead of using representing an Attribute’s Items as qtItem-based classes, this approach would make use of Qt’s Model/View architecture by creating a new class derived from QtAbstractTableModel that represents all of the attributes directly instanced from an attribute::Definition. Note that the reason for requiring the attributes being instanced from a specific Definition instead of one derived from it, is because all of the attributes being displayed should have the same “structure”.

Possible Requirements of the QtAttributeTableModel

  • Constructor takes in the attribute::Definition being used to select which attributes being displayed
  • Each column of the table (with exception of the 0th column) would have an item path associated with it. In the above example this could be:
    • “./density”
    • “./porosity”
    • “./electrical conductivity”
    • “./thermal conductivity”
  • The model should be able to either extract the column structure based the attribute::Definition or be explicitly give the item paths. This would allow the designer to omit parts of the Attribute from being displayed. It would also provide the means of controlling the order in which the items would be displayed.
  • Ability to fetch the ith column attribute::ItemDefinition from the model.

Possible Automatic layout

Lets assume we have an attribute that has the following structure:

  • Int Item a
  • Group Item b
    • Int Item b-a
    • String Discrete Item b-b with values (alpha, beta, gamma) and conditional Items
      • Double Item b-b-a (alpha)
      • Int Item b-b-b (beta)
  • Double Item c

If we automatically extracted the potential columns for the Table doing a depth first traversal, we would get the item path structure:

attribute a b-a b-b b-b-a b-b-b c
a1 1 2 alpha 2.0 10
a2 4 5 beta 4 12
a3 5 7 gamma 10

The corresponding search paths would be:

none “./a” “./b/b-a” “./b/b-b” “./b/b-b/b-b-a” “./b/b-b/b-b-b” “./c”

Note that Group Items are not explicitly displayed. Also note that if we limit the search to include “Active Children” only, then we would receive a nullptr for each cell where a conditional item was not currently active.

What about Optional or Expression-base items?

What if in the above example Item a was optional and Item c could be an expression?

attribute a b-a b-b b-b-a b-b-b c
a1 cb 1 2 alpha 2.0 fb 10
a2 cb 4 5 beta 4 fb 12
a3 cb 5 7 gamma fb 10

Where cb is a checkbox widget and fb is the current function button.
The new column search paths would look like this:

none “./a” “./a” “./b/b-a” “./b/b-b” “./b/b-b/b-b-a” “./b/b-b/b-b-b” “./c” “./c”

Displaying Item Values

Since each column represents the same “type” of Item, each column would have a custom delegate associated with it. Similar to the ItemViews, we could have a factor of delegates that the designer could chose from. A delegate would be assigned to each item column in the model. The list of delegates we would initially need include:

  • Optional Delegate - deals with setting the state of an optional item
  • Expression Delegate - deals with setting expression state of a Value Item
  • Double Delegate - deals with editing a Double Item
  • Int Delegate - deals with editing an Int Item
  • String Delegate - deals with editing a String Item
  • FileSystem Delegate - deals with editing a FileSystem Item
  • Reference Delegate - deals with editing a Reference Item

Others could include delegates for interpreting a 3-tuple double as a color, or 3D point, …

How does the Table Update?

When a column is modified, the model would indicate all columns that contains the item path of the column modified in the same row should be considered changed.

Category and Advance Level Filtering

Since each column is governed by an Item Definition, the QtAttributeTableView class would only need to test each Item Definition to determine if that column should be displayed.

Signaling

Signaling that an Attribute has been modified would be relatively easy. If we need to also know which item(s) had been changed, that could require some additional work.

@johnt @dcthomp @aron.helser @C_Wetterer-Nelson @Ryan_Krattiger @chart3388 @amuhsin - FYI, and Comments Welcomed as always.

I think the proposed design makes sense. One thing that would be useful would be to visualize how this new view would be used along with the rest of the user workflow.

Some questions that come to mind are:

  • Is this view meant to be used in conjunction with other views?
  • If this view is meant to replace something like an Attribute View how do we handle the conversion of Attribute Views that show more than one att def each with it’s own unique structure?

This View is meant to work in conjunction with other Views including the existing AttributeView.

I hacked up an example using Qt Designer + PySide to show what this might look like for the Truchas “body” attribute, taking some liberties along the way. The main motivation was to see what the header looks like after flattening the attribute structure. There is some concern it might not be sufficiently clear to casual users.

  • Note that the “f(x)” and checkbox columns have no column header. If not obvious, the “f(x)” column applies to the temperature column to its right, and the checkbox column applies to the 3 velocity columns to its right.
  • I also wanted to see what the header for the 3-tuple velocity would look like. I set the Vx and Vy column headers to ${item_label}:${component_label}, and for Vz I replaced the colon with a forward slash.
  • Disabled items didn’t look very disabled to me, so I added “–” as text in those cells.

image

@Bob_Obara @Neil_Carlson @amuhsin et al, do you have any opinion or other feedback on this view vis-a-vis our standard attribute editor?

1 Like

Ideally the “f(x)” and “Initial Temp” columns would be merged and simply have a widget for the cell that contains both the toggle-button and either a drop-down or text-edit depending on the toggle state. Qt makes this painful but not impossible to implement.

1 Like
Privacy Notice