-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Users should not need to know about insertion (or task proxies generally) #2143
Comments
For a partial interim measure we could just do an auto-insertion for trigger commands (etc.) if the target task proxy is not in the pool. The second point above (GUI) would presumably require either asking the graph for all the tasks valid at a particular cycle point, or iterating through all proxies in the pool and asking if the target point is valid for each. The first method might be a natural fit for our plans to move away from task self-spawning to graph-driven spawning: see #987 (comment). |
Some what related. A user has asked for an easy way to insert the previous cycle of a task via the GUI. |
The graph view right-click menu has an "insert ..." option, that populates the insert task dialog with task name and cycle point - so it's easy to change the cycle point to the previous one there. (I think this menu item used to appear on ghost nodes - which would make more sense - but we seem to have disabled the right-click menu entirely on them) |
From an email discussion involving @matthewrmshin: this should be extended to instantiating future task proxies just for querying their properties with commands like |
A user reported a similar use case when trying to hold all tasks in a cycle. The user assumed that by right clicking a cycle in tree view and selecting Hold, it would hold everything in the cycle from then on. In actual fact, it only held the tasks in the cycle that were in the task pool at the time. The user was a bit surprised when some tasks in (supposedly held) cycle ran later. |
Ah yes, that's an interesting side effect of this problem. |
This should be solved by the "hybrid model" that makes our current task pool look like our future spawn-on-demand internals. |
We should probably generalize the ideas behind #774 (and the aborted PR #2027) - auto-insertion on restart and reload, and #423 (comment):
The fact that task proxies have to be present in the task pool before you can do anything with the tasks they represent is really an aspect of internal implementation that should be hidden from users as far as possible:
The text was updated successfully, but these errors were encountered: