One GUI using technology for web applications
- gcylc: large memory footprint in graph mode - possible leak?
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Close.
- (Bruno) Closed.
- gscan misc view improvements
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Close.
- (Bruno) Closed.
- Document how to change GUI font-size
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close. Can use themems/CSS in the future? Accessibility issue?
- (Hilary) Close. (and plain old browser Ctrl-+)
- (Bruno) Closed.
- cylc gui tree view progress bar
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Close. (But we obviously need to do a better job of this in the new UI)
- (Bruno) Closed.
- GUI: unused view memory release?
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Close.
- (Bruno) Closed.
- cylc gui: keyboard interrupt handling broken
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Close.
- (Bruno) Closed.
- cylc graphing: optional branching
- We should move to cylc/cylc-web repository if we still want this feature.
- (Matt) Move to cylc/cylc-web.
- (Bruno) Transferred.
- multi-level family expand/collapse in the dot view
- Move to cylc/cylc-web repository I think.
- (Matt) Move to cylc/cylc-web.
- (Hilary) agreed
- (Bruno) Transferred.
- Show external trigger values in the GUI.
- Move to cylc/cylc-web repository I think.
- (Matt) Move to cylc/cylc-web.
- (Hilary) agreed
- (Bruno) Transferred.
- Remove redundant graph edges.
- As we are moving the graphvix logic the cylc/cylc-web, I think this must be moved to cylc/cylc-web repository.
- (Matt) Move to cylc/cylc-web.
- (Hilary) agreed
- (Bruno) Transferred.
- cylc graph - search for task?
- Move to cylc/cylc-web repository I think.
- (Matt) Move to cylc/cylc-web.
- (Hilary) agreed
- (Bruno) Transferred.
- New GUI: scalable navigable matrix (quilt) view
- Move to cylc/cylc-web repository I think.
- (Matt) Move to cylc/cylc-web.
- (Hilary) agreed
- (Bruno) Transferred.
- cylc run --set=NAME=VALUE inputs persistence and gui issues
- If we want this feature of storing the name=value in the GUI, then we must move it to the cylc/cylc-web repository.
- (Matt) Yes. Values are stored in the runtime SQLite file. We need to be able to enable read/write from the web UI.
- (Hilary) Agreed. (BUT it might be good to require that such input values are stored in a file on disk - the to-be-migrated rose-suite.conf - and rather than specified dynamically in the UI, and allow that file to be edited via the UI?)
- (Bruno) Transferred.
- gscan for all registered suites (or a subset of them)
- Move to cylc/cylc-web repository I think.
- (Matt) Yes.
- (Hilary) Yes.
- (Bruno) Transferred.
- cylc graph, cylc gui graph view: nice way to specify node images
- We should move to cylc/cylc-web repository if we still want this feature.
- (Matt) Yes.
- (Hilary) Agreed. Maybe. But very low priority.
- (Bruno) Transferred.
- (re)allow independent filtering of views
- Move to cylc/cylc-web repository I think.
- (Matt) Yes.
- (Hilary) Yes.
- (Bruno) Transferred.
- suite report utility
- I think this is possible in the Web GUI, and would be quite useful. We could allow users to print, export as PDF, CSV, etc.
- (Matt) There are 2 parts. We need to collect more relevant data, and then we need to serve the data on the web UI.
- (Hilary) Agreed.
- (Bruno) Transferred.
- Colour coded task names in LED view
- If we will have a LED view in the Web GUI, then this issue must be moved to the cylc/cylc-web repository.
- (Matt) Yes.
- (Hilary) Agreed. ("LED view" == old name for "dot view", which origially used LED light images for dots) The issue title is a bit misleading - it's really about using
[visualization]color settings in some way in the control UI - in all views - alongside the live task state colors. - (Bruno) Transferred.
- gcylc - keep view options client-side
- Not sure how that plays with the Web GUI?
- (Matt) Browser cookies? Or user session settings on server side? Should probably move to cylc/cylc-web.
- (Hilary) Agreed. Not sure how to do it yet, but we don't want one user's family-collapse choices to affect other users viewing the same suite (as happens now)
- (Bruno) Transferred.
- internationalization of user visible strings
- Q: We will have i18n in the Web GUI. Do we still need it for the command line?
- (Matt) Yes for help strings (and interactive prompts?)
- (Hilary) Agreed
- (Bruno) OK, we have i18n already in cylc-web already, so will leave this issue in cylc/cylc for the command line part.
- cylc graph (readability): node labels always white
- Close as superseded by One GUI using technology for web applications. (Unless fixed for cylc-7.8.x)
- (Matt) Accessibility for 7.8.x.
- (Hilary) yes, fix for 7.8.x
- (Bruno) OK, leaving in cylc/cylc.
- Finer-grained authentication and authorization
- I wonder if we need a sibling issue in cylc/cylc-web? There will be some discussion about authX in cylc/cylc (change granularity, add new roles/privileges, etc) and also in cylc/cylc-web (use tokens, refresh time, technologies used, which JS library to use, etc) I believe.
- (Matt) Yes.
- (Hilary) Yes.
- (Bruno) created an issue in cylc-web and another one in cylc-jupyterhub. The first will be about Vue.js/JavaScript auth, while the other will be more about Tornado, Python, JupyterHub authorization. All issues linked.
- Future Cylc Authorisation / GUI Architecture
- I think this and the previous issue need to be reviewed, and either both updated, or one closed, so we document everything in one issue only, which will be included in CHANGES.md later.
- (Matt) Combine this with the previous issue and split it up again for cylc/cylc and cylc/cylc-web?
- (Hilary) Agreed.
- (Bruno) Looks like this issue was intentionally created and linked to the previous issue. Not sure if I can just copy the main issue description as a comment, or leave it as-is?
- gcylc - better command output display?
- Would have to be re-scoped for cylc/cylc-web or closed.
- (Matt) Move to cylc/cylc-web - how can this be done better in the web UI?
- (Hilary) this is about capturing stdout from commands executed in GUI subprocesses:
cylc validate,cylc edit(edit suite.rc in your editor),cylc view(view a temp copy of suite.rc in your editor),cylc graph,cylc show(suite or task metadata),cylc list,cylc doc(browse suite task URL),cylc COMMAND --help,cylc jobscript(generate a jobscript),cylc trigger --edit(edit run: generate the job script for a re-run and present it in your editor).- ugly GTK text window pop up, in some cases only to show stderr in the unlikely event that the command fails
- some of these will go away (we can't present anything in the user's text editor)
- some may be unecessary (we could - at least initially - require users to log in and use the CLI for some things that go beyond running and monitoring their suites)
- browse URLs - open in new browser tab?
- edit run (job script edit) (end event suite.rc edit?) would have to be served by the browser, in a text edit tab
- anything remaining that requires that UI Server to run a command in a subprocess and generates a small-ish amount of text (e.g. validation) could be handled by an arbitrary command capture sub-service, and we would have to figure out how to present the output in the main UI window?
- have I missed anything?
- SUMMARY: close the issue and just note the above on the new issue(s) (/roadmap)?
- dynamic 'best fit' in GCylc's graph view
- Close as superseded by One GUI using technology for web applications.
- (Matt) Are we still going to have this issue in the web UI? Probably depends on the graphing framework we choose.
- (Close) We are naturally going to have to think about this sort of thing when implementing a new graph view.
- (Bruno) It may or may not resurge in the Web GUI, but I think it may be easier to close and get feedback from users after we implement the new graph view. Otherwise it may be forgotten in the backlog, even if fixed.
- gscan: unstable folding
- Close as superseded by One GUI using technology for web applications.
- (Matt) Close.
- (Hilary) Don't close - I think we are intending to fix this for 7.8.x! (in which case need to update the milestone)
- gcylc - surprising behaviour with families and multiple inheritance
- Move to cylc/cylc-web repository I think.
- (Matt) This is also a general problem due to families being used for both runtime settings and graphing.
- (Hilary) yes we still need to consider what to do about this in the new UI. I've added a new comment to the Issue: cylc/cylc-flow#2570 (comment)
- (Bruno) If this needs work in cylc/cylc, then I think we can leave it there for now then? And worry about it if by the time we implement the UI part this issue affects the UX?
Yes, definitely a cylc/cylc issue, as visualization collapse/expand must be defined (one way or another) in the workflow definition. (Unless it is dependency graph sub-graph collapse).