-
Notifications
You must be signed in to change notification settings - Fork 27
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
task metadata view #1071
Comments
Great idea. We should discuss details in the next meeting though. |
(flagged as a question for raising at the next meeting) |
Maybe think about how we can view other task info?
Should any of these be included in the "info" view? |
Could the info view have config as a separate tab/window/section? Some of the runtime config can get quite chunky, especially the script settings, but websites have shown worse! For extra brownie points why not add syntax highlighting to the |
Should the Task Info view open in a tab to the side, or in a new tab in the same panel as the view you were in? Opening to the side might not gel well with already-split panels (i.e. if you've already arrange tabs in > 1 panel) |
The way new tabs open is down to the workflow component. The current behaviour is to open the new tab in an existing panel (but behind, I think it should go in-front but that's a different issue).
This section could be collapsible. E.G. We could show the title and description at the top and have the rest pre-collapsed.
Yeah, why not. If we are displaying the |
Discussed in developers meeting. My takeaways (please correct if otherwise):
Suggest the following:
|
All good, thanks @oliver-sanders
I think we concluded the tab should open in the same way for all views. However, it would be good if the default (for all views) was new tab on top. Not sure if that's an option out of the box. |
Should be easy to do, I think JupyterLab works this way so it's probably just a configuration matter - #1090 |
There are two sides to this view:
The most critical thing is "prereqs and outputs" as it is not currently possible to see why a task is not running in cylc-ui. Suggest starting off with just "prereqs and outputs", calling the new view "Info" and adding a link to open the info view in a new tab on the mutation menu e.g. with an (i) button e.g. http://cdn.onlinewebfonts.com/svg/img_51582.png. Putting this on the 2.1.0 milestone for the "prereqs and outputs" bit. |
The boilerplate is a little different from other views due to its nature so not especially obvious:
I've put together a view template that covers the cylc-ui boilerplate needed to get started on this: https://github.com/cylc/cylc-ui/compare/master...oliver-sanders:cylc-ui:metadata-view-template?expand=1 Note, I've named the view "info" rather than "metadata" (more user friendly). |
Cylc 7
Cylc supports task metadata e.g:
Cylc 7 made minimal use of task metadata, namely in commands like
cylc show
but some metadata was also used in the GUI.Cylc 8
Cylc 8 has greater potential here. Earlier design sketches had an info "pane", "tounge" or "panel" which was intended to show the
[meta]
info for the selected task (or the workflow itself as workflows also support[meta]
). The GUI has moved on since then, the Lumino tab system is now the natural place for displays, I think dividing the screen beyond this would be unhelpful.So here's my suggestion, we implement a "metadata view" (or "info" view). This view gives you a text box to type in the name of the task (we should be able to make this a combo box with all task names pre-loaded). Once you've selected a task it displays the
[meta]
. For convenience we can create a shortcut from the task menu which opens a new "info" view pre-initalised at the specified task. We should also consider adding the "title" field to the task menu.Sketch
Here we have an info view showing some basic metadata. The task menu has been opened for the task "baz" on the right. The "title" has been added to the top of the menu along with an info button which is the shortcut for opening the info tab on the left.
Metadata & Formats
Some sites are already making use of the "URL" field. In [at least] one case, using HTML pages generated from markdown. We can make this much easier (rendering markdown in a web app is trivial).
[meta]
items as markdown by default.Many tasks already have extensive documentation in the form of Rose application metadata. There is an existing Rose config to ReST generator which is used by the Rose documentation.
[meta]_markup_format
config to allow this to be configurable in the future?#markdown
,#rest
, ...?Workflows & Documentation
Workflows can have
[meta]
too. We might want to add an option for viewing the workflow metadata here too (and possibly a shortcut for it in the workflow toolbar).Cylc has documentation too! We might want to add an option view viewing it here!
Additional context
Once discussed / agreed this should be quite quick to implement.
Tasks
in the schema).Pull requests welcome!
The text was updated successfully, but these errors were encountered: