Dual list view #44

Open
opened 2025-02-06 19:51:24 +00:00 by Vectornaut · 2 comments
Member

Problem

It's important to have at least one view that lists all elements and regulators. The outline view currently plays this role, but its tree structure gives it several awkward features:

  • Elements are visible at surface level, but regulators are buried.
  • It's easy to sort by element properties, but hard to sort by regulator properties.
  • Each element appears exactly once, but each regulator appears multiple times when all the elements are unfolded.
  • Following interface conventions for outlines would make elements and regulators interfere with each other. For example:
    • By convention, I'd expect a multiple selection to be able to encompass both elements and regulators. (For example, a multiple selection can encompass items at different levels in Inkscape's outline view.) There aren't many operations you could do on a selection like that, so it mostly seems like an opportunity for finger slips. However, Glen doesn't think we want to disallow mixed selections altogether -- at least, you can delete or hide everything in such a selection.
    • By convention, I'd expect single-selecting a constraint to clear the previous selection, even if the previous selection includes only elements. This would needlessly prevent me from operating on elements and constraints in parallel. [Glen -- I don't quite see "prevent": we will definitely in the end need a gesture to add an entity to an existing selection. But sure, it could make it more awkward; on the other hand, if the "select an element" gesture sets the selection to just the element, why wouldn't the same gesture on a regulator have the analogous effect?]

Solution

By creating a dual list view comprising parallel element list and regulator lists, we can put elements and constraints on equal footing while also keeping them from interfering with each other. The lists should be independently sortable and filterable, and we might want them to have independent selection sets too.

We could show the relationships between elements and regulators by sorting or filtering each list according to what's selected in the other list. For example, selecting an element might do one or more of the following:

  • Bring the selected element's constraints to the top of the constraint list.
  • Dim or hide the constraints that don't apply to the selected element.
### Problem It's important to have at least one view that lists all elements and regulators. The outline view currently plays this role, but its tree structure gives it several awkward features: * Elements are visible at surface level, but regulators are buried. * It's easy to sort by element properties, but hard to sort by regulator properties. * Each element appears exactly once, but each regulator appears multiple times when all the elements are unfolded. * Following interface conventions for outlines would make elements and regulators interfere with each other. For example: * By convention, I'd expect a multiple selection to be able to encompass both elements and regulators. (For example, a multiple selection can encompass items at different levels in Inkscape's outline view.) There aren't many operations you could do on a selection like that, so it mostly seems like an opportunity for finger slips. However, Glen doesn't think we want to disallow mixed selections altogether -- at least, you can delete or hide everything in such a selection. * By convention, I'd expect single-selecting a constraint to clear the previous selection, even if the previous selection includes only elements. This would needlessly prevent me from operating on elements and constraints in parallel. [Glen -- I don't quite see "prevent": we will definitely in the end need a gesture to add an entity to an existing selection. But sure, it could make it more awkward; on the other hand, if the "select an element" gesture sets the selection to just the element, why wouldn't the same gesture on a regulator have the analogous effect?] ### Solution By creating a *dual list view* comprising parallel element list and regulator lists, we can put elements and constraints on equal footing while also keeping them from interfering with each other. The lists should be independently sortable and filterable, and we might want them to have independent selection sets too. We could show the relationships between elements and regulators by sorting or filtering each list according to what's selected in the other list. For example, selecting an element might do one or more of the following: * Bring the selected element's constraints to the top of the constraint list. * Dim or hide the constraints that don't apply to the selected element.
Vectornaut added the
enhancement
label 2025-02-06 19:51:24 +00:00
Owner

Some counterpoint to a straight-up dual-list view: The most convenient place to see a curvature regulator might be in-line with the display of its subject element. So perhaps we need a hybrid of unary regulators in the element list and poly-ary regulators in a separate list.

Some counterpoint to a straight-up dual-list view: The most convenient place to see a curvature regulator might be in-line with the display of its subject element. So perhaps we need a hybrid of unary regulators in the element list and poly-ary regulators in a separate list.
Author
Member

The most convenient place to see a curvature regulator might be in-line with the display of its subject element. So perhaps we need a hybrid of unary regulators in the element list and poly-ary regulators in a separate list.

Yes, I'm very confident that we'll want inline views of at least some single-subject regulators.

> The most convenient place to see a curvature regulator might be in-line with the display of its subject element. So perhaps we need a hybrid of unary regulators in the element list and poly-ary regulators in a separate list. Yes, I'm very confident that we'll want inline views of at least some single-subject regulators.
glen added a new dependency 2025-03-01 02:13:16 +00:00
glen added the
ui
label 2025-03-12 22:01:01 +00:00
Sign in to join this conversation.
No description provided.