multiple selection

[oliver-sanders]

Cylc 7

We currently have multiple selection in the tree view in the Cylc7 GUI.

This system works by iterating over the gtk.TreeView model to work out what's selected, but with one small twist, if you select a family you are implicitly selecting all of the tasks within that family.

To explain, if you select the following:

  flow(foo)
   cycle(1)
^     family(A)
|       task(a1)
v       task(a2)
        task(a3)
      task(b1)
    cycle(2)
      family(A)

You will be operating tasks a1, a2 & a3 because family A is included in the selection.

Cylc 8

In Cylc8 we should open this multiple selection up to all Cylc views.

Q1) What is the primary focus of the selection. If we open the context menu should we see mutations relevant to workflows, cycles, families, tasks or jobs?
Q2) What is contained the expected selection.

Example 1 - single selection

x  flow(foo)
     cycle(1)
       family(A)
         task(a1)

Option 1 (complete tree):
Q1) tasks
Q2) a1.1

Option 3 (only tree leaves):
Q1) workflows
Q2) foo

Example 2 - single-level selection

   flow(foo)
x    cycle(1)
       family(A)
         task(a1)
         task(a2)
         task(a3)
       task(b1)
x    cycle(2)
       family(A)

Option 1 (complete tree):
Q1) tasks
Q2) all tasks in cycles 1 and 2

Option 3 (only tree leaves):
Q1) cycles
Q2) 1, 2

Example 3 - multi-level selection

^  flow(foo)
|    cycle(1)
|      family(A)
|        task(a1)
v        task(a2)
         task(a3)
       task(b1)
     cycle(2)
       family(A)

Option 1 (complete tree):
Q1) tasks
Q2) a1, a2, a3, b1

Option 2 (single level in tree):
Q1) tasks
Q2) a1, a2, a3

Option 3 (only tree leaves):
Q1) tasks
Q2) a1, a2

Example 4 - just to be awkward

  flow(foo)
    cycle(1)
      family(A)
        task(a1)
          job(01)
^         job(02)
|       task(a2)
v         job(01)
          job(02)

Q1) jobs
Q2)
* Option 1: a1.02, a2.01, a2.02
* Option 3: a1.02, a2.01

Use Cases

• Kill/trigger/expire all tasks in a family/cycle

Questions

• Does it actually make sense to have consistency in the behaviour of multiple selection between views or should each one handle this in its own way?
• Should we actually display options for each different object type (i.e. provide the user with multiple interpretations of the selection).
• How should we go about this, remembering that this model needs to work in views where nodes are not displayed in a tree (e.g. the graph view).
• Which of the options above seem the most logical?
• Any other edge cases?
• Any other ideas?

[oliver-sanders]

FYI I think I'm leaning towards a hybrid solution using the root and leaves of the selection.

E.g. if you right clicked on this selection:

^  flow(foo)
|    cycle(1)
|      family(A)
|        task(a1)
v        task(a2)
         task(a3)
       task(b1)
     cycle(2)
       family(A)

You would see:

• workflow foo
  • stop
  • hold
  • ...
• 7 tasks
  • expire
  • trigger
  • hold
  • ...

[oliver-sanders]

This issue has increased in priority due to "select multiple tasks to re-run" type use cases and is now listed on the roadmap.

With the benefit of the past four years (wow this issue is old), I would suggest:

1. If multiple types of object are included in the selection (e.g. tasks, families and cycles), list mutations for the "namespace" type. This is the most generic type and the old valid catchall.
2. If a family/cycle is included in the selection, we should consider all tasks in the family/cycle to be selected (i.e. no change from how it is now, if you trigger a family, you trigger all [n=0] tasks in that family).
3. Any refinements to point (2) can be bumped to aoft: expand cycles/families in mutations to the visible selection #686.
4. The mutations menu should make it clear that multiple items have been selected.

So to answer the questions in the OP:

Q1) What is the primary focus of the selection. If we open the context menu should we see mutations relevant to workflows, cycles, families, tasks or jobs?

Namespaces (which is Cylc GraphQL slang for a task or a family, remembering that cycles are ultimately just "root" families).

Q2) What is contained the expected selection.

An unexpanded list of the selected items, e.g:

namespaces = [
    // a task
    "1999/foo",
    // a family
    "1999/BAR",
    // a cycle
    "2000/*"
]

[oliver-sanders]

Suggest tacking this one view at a time.

The "Table View" is the easiest candidate to start with.