Set n-window extent: default and current value (non-GUI)

[hjoliver]

We're getting quite a few requests for this, and it would be easy to do (and of course, we do plan to do it ... this probably features in an existing issue somewhere, but I failed to find it).

Currently the default is fixed (n=1) and users can only change it via the GUI.

Users need to be able to:

• configure the default value
• change the current value via the CLI and TUI

The appropriate (or at least the maximum appropriate) n-window extent is kinda workflow-dependent, and possibly user-dependent (e.g. for users who typically only run small workflows), so I think it would make sense to set the default n-window extent via both a global and workflow config item.

[oliver-sanders]

The n-window extent is intended to be a client (GUI, Tui) property, it was never intended to be a scheduler property, so configuring it there doesn't really make sense. The n-window generation code needs to be moved out of cylc-flow into cylc-uiserver (higher priority), but we haven't found the time to do this yet. With current memory management issues at the UIS allowing higher values to be configured by default is a bit of an issue.

[ColemanTom]

I don't know that you need to be able to change the displayed n-window from CLI, but, it would be useful to be able to do various non-UI commands, that rely on the n-window being set, without having to do things via the UI. I think cylc show for example relies on the UI n-window. So, being able to do cylc show --n-window=3 ... as an example I think would make sense.

[hjoliver]

The n-window generation code cylc/cylc-uiserver#464 (higher priority), but we haven't found the time to do this yet.

Yes but I'm concerned that we're unlikely to get this done any time soon. It is quite a big change, and there are reasons why the datastore ended up in the scheduler in the first place (as a rather long term interim measure!). Plus, as you note, we need to put effort into UIS efficiency before attempting that.

[hjoliver]

Trying to think of some way forward that would work now and in the future.

It's quite important to have a workflow-specific default n-window extent. Some users run small and large workflows. For large workflows it is bad to have a large default N, but for small ones it is annoying to have a small default that you just change up immediately every time. Even saving workflow-specific N value changes in the client is not ideal, because it's more of a workflow thing than a client thing (is this workflow sufficiently big that we should have a very small window by default, or not?).

Having default n-window extent as a workflow config item doesn't necessarily imply configuring the scheduler. It could be treated as workflow metadata that determines the initial window extent in the scheduler (now) or in the UIS (future).