Page MenuHome

Rules based row filtering for attribute spreadsheet
Confirmed, NormalPublicTO DO

Description

See T86027 - need final mockup.

When a rule row is complete, a new blank one is available.

Each rule is a set of:

  • column name
  • condition (e.g., larger than)
  • value

Conditions:

  • Equal
  • Larger Than
  • Smaller Than

The rules are AND conditions. So they don't add new rows, but only remove them.

If the column name is not available (e.g., the active object doesn't have attribute Mask), user should be aware of that. (e.g., warning icon, red background, ...). The other rules should still be applied though.

The column name should do string search/lookup with the columns names of the spreadsheet. Ideally this should work for scene data in the future.

Operators:

  • Reset (i.e., remove all rules)
  • Preset [good to have, not a requirement - need its own task]

Revisions and Commits

Event Timeline

Dalai Felinto (dfelinto) changed the task status from Needs Triage to Confirmed.Mar 1 2021, 2:41 PM
Dalai Felinto (dfelinto) created this task.

The way phabricator handles rules is simple enough and I think it can be the focus of the initial implementation here:

Besides we don't even need the "reset" button at first. It is super fast to click the remove button few times in a row. This is based on the phabricator experience. Once we have the basic in master we can reiterate on it.

branch: temp-spreadsheet-row-filter

The UI is basically implemented, it should be straightforward to move it wherever we want it. I just liked the idea of trying it in a popover first (I like it, though it means we won't be able to drag them : P)
Things I'm thinking about:

  • Specifying the data type is necessary because an attribute might have one data type on one object, another data type on another, etc.
    • We could set the data type automatically when you first type in the name (or choose it from a search?)
  • How are we going to deal with sorting by material_index but seeing the position values for example? They are separate data sets, so they don't really interact on the spreadsheet level?
    • Either this becomes a "geometry spreadsheet" level feature (rather than a feature for all spreadsheets), or we just require people to use the attribute convert node or something
  • "Equal To" needs a threshold, it's basically useless without it.
  • The original mockup in T86133 mixes up column filtering and row filtering (it puts them very close together). I think that's confusing
    • We're probably going to change that anyway when we use the "hide column", "unhide column" anyway?

Hi @Hans Goudey (HooglyBoogly) I couldn't get this to work. Did you implement only the UI?

  1. I think we can do without the data type. The filters should map to the existing columns in the spreadsheet.
  1. That also means there no "Vector" data type since we are filtering the columns individually.
  1. "How are we going to deal with sorting by material_index but seeing the position values for example?

We basically won't. Sorting (if implemented) is local to the current data-set.

  1. "They are separate data sets, so they don't really interact on the spreadsheet level?" Correct
  1. re: "Equal To".

In the original-original design all we had was a "Range".

Which we could use for floats. But the equal to ca be used for integers and booleans.

  1. Hiding individual columns or a global column filter is different. But anyways, this is not related to this task.

(also, the "property search" is important to be able to pick from the existing columns)