The n-window determines how much of a workflow is visible in the GUI / Tui.
The n=0 window contains only the active tasks (i.e. queued, preparing, submitted or running tasks).
The n=1 window, also contains tasks one “edge” out from active tasks (i.e. the tasks immediately upstream or downstream of active tasks).
The n=2 window, also contains tasks two “edges” out from active tasks, and so on.
It is now possible to change the window extent in the GUI via a button in the toolbar allowing you to see tasks further back in the workflow’s history.
Note - This is currently a per-workflow setting so changing the n-window in one browser tab will also change it in other browser tabs and Tui sessions.
Thanks for making this easier. I’m not completely sure if this idea would be useful, but, would it be possible to have different window depth forwards than backwards? For example, N=1 for completed items, but N=3 for future tasks?
That would be possible, though a bit tricky to explain. There are some other likely developments in this area which may interact:
Expanding the window forward is a little awkward due to the impacts of graph branching (both automatic ?, and manual cylc remove). We can get more advanced with this in the future, but we will need to move the window expansion out of the scheduler and into the UI Server codebase which is technically challenging.
Expanding the window backwards is conceptually easier (all the required info is in the database). We hope to open up a querying interface onto this data (e.g. show me all tasks in a cycle) that we can somehow integrate with the n-window concept (e.g. overlay the n=2 window onto a per-cycle request to combine live and archive data). All possible, but we will need to prepare the UI to handle this extra data, e.g. through efficiency improvements and likely implementing node limits for UI views.
