-
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
One GUI using technology for web applications #81
Comments
[meeting]
|
To avoid confusion, the main idea currently is to write a new GUI using new technology (in particular technology for building web applications). It does not necessarily mean that we want the new GUI to be a web application. |
To attach a few related matters discussed but not yet captured... Graph View For Large Suites For suites with large numbers of tasks the graph view becomes unusable. One way to get around this would be to have the graph view display a configurable number of levels from the currently selected task. I.E. if a user clicked on a task in the treeview the graphview would display that task and This would supersede #1086. [update: see also #2566, which expresses this problem slightly differently] Suite List With a new plugable architecture gscan can be used as a sidebar to gcylc allowing it to replace the current Portability The gui should not be deeply written into a windowing framework which prevents if from being rendered in a browser so as to leave scope for future extensions in functionality. Data Driven Using a data driven approach (e.g. d3.js) would simplify things greatly and allow a single updater to drive all of the GUI components with minimal fuss. The use of graphql or a similar framework would offer better flexibility in suite communication enabling us to dynamically adjust what information is requested to meet the requirements of GUI components whilst minimising http requests, see cylc/cylc-flow#2123 (comment). |
https://electron.atom.io/ looks like the most attractive framework right now. |
Graphlayout
other:
|
(A minor feature request that I've punted to the new GUI): We should be able to annotate tasks with warning indicators (and maybe other things) - perhaps via a column in the tree view and badges in the graph view. |
WebSocket?
|
Hi, Is there a timeline / milestone for this issue ? pygtk is being removed from Debian/Ubuntu, which means as it stands cylc will ship without a GUI. Note that if its agreed what new frameworks will be used (electron?), then that would be good to know, as I can make sure dependencies are present before then. |
@amckinstry - yikes, that's tight, thanks for the heads-up. The core developers are to meet in person in 1-2 weeks time, we'll see if we can chart the way forward... |
Comments on the benefits of using GraphQL or an equivalent system: cylc/cylc-flow#2563 (comment) |
Finally got around to mocking up most of what we discussed in June. According to tradition the following [rough] sketches are in aqua, windowing systems may vary! The One Cylc GUI A combination of
Mobile Friendly Callouts Context menus provided on "tap" or "left click" to leave open the potential for mobile friendliness. Sub-contexts provided as "tokens" where possible (or at lest most commonly used sub-contexts) to avoid nested contexts. GUI Tools Displayed In Context Tools specific to a particular view displayed in a "hover-over" transparency on "capable" platforms rather than an obstructive extra toolbar. Rightmost icon is a depth selector enabled automatically for large graphs, it determines the depth of nodes / edges to display as measured from the selected node, enabling responsive display of large graphs. Alternative Node Styling Web-tech opens up a lot of opportunities as regards node styling (gradients, patterns, etc). One simple option for denoting node stays without the use of colour displayed below (task failure could be represented with a cross in a circle). This leaves colour free to be defined by the user (using the current visualisation settings) or for displaying suites as collections of sub-systems al la (https://github.com/cylc/cylc/wiki/Possible-Cylc-Futures#sub-suites). In the above example |
Suite Discovery (for running suites) no longer needed under the new web architecture? If all suite server programs know (via global config) where the reverse proxy is, they can initiate communications with the proxy instead of the reverse. Subsequently, the reverse proxy knows where each suite is via existing persistent WebSocket connections and/or from host:port values stored from previous connections (which can then be verified or dropped after attempting to connect again). I suppose we might still want suites to store host:port in their .service/contact files (as info for users) but the reverse proxy will not need read them from the filesystem (if the previous paragraph is correct). |
The reverse proxy will still need a discovery service for suites that are not running, to allow uses to start them up via the web interface. [UPDATE] - actually, now that we need a "central" system component (the reverse proxy) we might as well modify In which case, suite discovery just got a whole lot easier. |
Sticky force layout - good for manual exploration of workflow structure? https://bl.ocks.org/mbostock/3750558 |
I've not had the time to investigate graphing properly, I've set up a trial with a couple of graphing systems using our current global suite as a performance test. Probably after Brussels I'll plug in some of the other systems and do some profiling (with comparisons to graphviz). Quick conclusions thus far:
|
You're probably right, but maybe we could add an additional linear "gravity" that increases with cycle point, to impose some structure. |
@oliver-sanders - regarding graph layout performance, yes I doubt any system can do very large graphs quickly enough for the control GUI, so we will need to aim for the restricted view (as previously discussed) n-levels out from user-selected tasks of interest. We can play with a wider variety of graphing tools for static workflow visualisation though. |
ooh, interesting |
d3 force-directed graph layout Vue component:
|
Vue collapsing/expanding tree view from a nested tree data structure: https://vuejs.org/v2/examples/tree-view.html |
A Vue component to draw directed acyclic graphs in the browser leveraging dagre-d3v4 (https://github.com/smbolton/dagre-d3v4) - https://github.com/vdidonato/vue-dagre-d3v4 - seems to be broken. |
I'm currently looking at Javascript libraries for graphing, I'll update this issue with conclusions as I investigate. I'll probably put up my experiments as a GitHub repo when more complete. Graphing consists of two components: The Layout EngineThe bit which arranges nodes / edges spatially. See the layout engines supported by cytoscape for examples.
Requirements
Results
[1] Benchmark using the first cycle of MO global opp suite The Graph EngineThe bit which renders the graph, provides an interface for manipulating and interacting with it. This is the component we will end up working with / extending to form the graph view. Requirements
Results
HybridsSystems where the graph engine and layout engine are integrated: Results
|
Interactive arbitrary grouping: select a bunch of nodes (individually, or by drawing a rectangle around them) and group them into a single node. |
Layout algorithms for visualizing directed acyclic graphs - https://github.com/erikbrinkman/d3-dag - new-ish? demo https://jsfiddle.net/ye2xanf9/12/ |
Digressing a bit, but maybe we could choose more than one library for visualizing the graphs in Cylc? I believe the new Web GUI will have authentication, and user management. If we add to the list of requirements, to have system settings and/or user settings (for things like language, locale, etc), then we could an option to choose the graph visualisation algorithm/library. With that, if one implementation works very well for small-mid graphs and provides a lot of useful features, but perform poorly with large graphs, maybe users would still be able to use that implementation if they only had small/mid graphs. Furthermore, that way we could also release new versions with different implementations for testing, and get feedback of users without having to break their current environments. |
Two pieces of user feedback on UI:
|
If the suite is unable to stop intermediately, the UI should display some information on what the suite is waiting for. (It may be waiting for submitted/running tasks, kill/poll commands, event handlers, etc.) |
From conversations in #2842:
|
We have a disability & accessibility network within our organization. Perhaps such groups might be worth talking to and/or getting to test gui propositions? |
Whilst trying to understand someone else's Javascript I was wondering if there are docstring standards and/or docstring parsing tools. Casting around the internet I have found a number of tools:
None of the ones which I've looked at on GitHub look vastly active, although if they work that's not necessarily an issue. This blog post has some interesting comments on how well a number of systems work, although frustratingly not SphinxJS, which I like the sound of since it is an extension to software we already use. The good news is that across these platforms JS appears to have a fairly standard syntax for docstrings. Is it worth including docstringing in any definition of done? |
@wxtim good question. I think in the long run they will converge to whatever standard is the one more adopted by TypeScript developers. Maybe https://github.com/Microsoft/tsdoc? Which looks refreshingly - for me - similar to Java's javadoc (for me Sphinx/reStructuredText Python does too). Example from their readme: export class Statistics {
/**
* Returns the average of two numbers.
*
* @remarks
* This method is part of the {@link core-library#Statistics | Statistics subsystem}.
*
* @param x - The first input number
* @param y - The second input number
* @returns The arithmetic mean of `x` and `y`
*
* @beta
*/
public static getAverage(x: number, y: number): number {
return (x + y) / 2.0;
}
} |
@amckinstry - a belated update to your question (in case the answer to it was lost in the noise here and elsewhere):
We're not going to port the GUI to PyGObject, and not going to make a drop-in GUI replacement with Electron, because there is a strong need for an in-browser web GUI that integrates with site identity management and supports remote workflow monitoring, etc. We have settled on an architecture very much like that of Jupyter Hub. It involves: Python 3, proper packaging (pip and conda), Tornado, ZeroMQ, GraphQL, Vue.js, and other technologies. Target first release mid to late 2019. |
This issue has discussions around Graph, Design, and several other topics - some covered by other issues. I wonder if we would be able to close this one and move whatever is not documented in other issues to new, and more specific issues. |
Makes sense. |
I finished re-reading this ticket and the comments. And looks to me like we are still in the right direction. Most comment had features like Warning icon (already implemented in a component by Oliver), GraphQL (done), sets of icons for different statuses (done but still being discussed in other items regarding design and separation of Job/Task), performance displaying graphs (being discussed in a separate issue though with lower priority than the Tree view), theming (discussed in a separate issue), accessibility (covered in design and other issues like the one for font size), I think the only things that could be copied to other issues (or the other issue could simply reference this one to add a link) are:
Looks like most of the topics here are already being covered in separated issues 🎉 Any objection to just adding the two links above, and then closing this issue? And great to see that from 2017 to now, we are making good progress and in a steady trajectory 🚢 |
Seems fine to me - I just quickly re-read all the comments above. |
Comments copied to new issues. Closing this one now 👍 |
Thanks @kinow 👍 |
Depends on #1872DONE.The text was updated successfully, but these errors were encountered: