WEWoS and Vision

What WEWoS keeps of Vision, what changed, and where Vision came from.

What is kept

The engine is a Python 3 port of Vision's NetworkEditor, and keeps its semantics:

• soft and hard runs, data-driven breadth-first scheduling, blocking connections, the 'Stop' status, and the scheduling nodes (iterate, while);
• port types with their shapes and colors, casting between types, single and multiple connections, required and optional inputs;
• widgets bound to inputs, unbound and rebound, in the node or in the parameter panel;
• macros, with their input and output nodes and the new port;
• the node definition API: inputPortsDescr, outputPortsDescr, widgetDescr, setFunction, outputData, so that the node libraries were ported with few changes;
• Vision's networks, which import.

What is different

• No Tk, no OpenGL on the server. Widgets are data that the page draws. The 3D viewers are drawn by the browser with 3Dmol.js or Mol*; DejaVu's geometries became plain Python objects that the server sends to the page.
• Data flows from left to right, inputs on the left of a node and outputs on its right, where Vision drew it down the page. Imported networks are laid out again.
• One run at a time, on a thread of the server. Changing a widget during a run queues another run.
• The parameter column replaces the parameter panels: it shows the selected node's widgets, ports and buttons.
• Each network has a folder, where its files are read and written.
• Vision's libraries were reorganized: vizlib is 3D Visualization, MolKit is Molecules (on MolKit2 and ProDy), and Lines/CPK/MSMS macros are single nodes.

What is not ported

• user panels (a network as a standalone application), and saving a node's source to a user library from its menu;
• the libraries of PMV, ADT, FlexTree, ImageMagick, web services and the other MGLTools packages;
• from DejaVu: textures, volume rendering, clip planes, stereo, and the legend's units and inverted label colors;
• from Volume: volume rendering (UTVolRen) and QSlim mesh simplification;
• matplotlib's navigation toolbar;
• Vision's option panels for widgets other than numbers.

History

Vision began as ViPEr, a Visual Programming Environment for Python, written by Michel Sanner, Daniel Stoffler and Arthur Olson in the Molecular Graphics Laboratory of The Scripps Research Institute. It was presented at the 10th International Python Conference in February 2002, where it received the best paper award:

M. F. Sanner, D. Stoffler, A. J. Olson. ViPEr, a Visual Programming Environment for Python. 10th International Python Conference, 2002. legacy.python.org/workshops/2002-02/papers/10

It was later renamed Vision, because of a name conflict at Scripps with VIPER, the Virus Particle Explorer of Charles Brooks's lab, and distributed with MGLTools, with NetworkEditor as its engine, alongside PMV and AutoDockTools.

The paper describes the design WEWoS keeps: nodes that wrap Python functions, ports colored and shaped by data type, any Python object flowing on connections, data-driven scheduling, widgets bound to input ports, macros, libraries of nodes (Standard, Imaging, MolKit, symserv), and networks saved as Python code. The network of its figure 1 (crambin's MSMS surface, transparent, over its atoms scaled by a dial and colored by their x coordinate, and the viewer's picture grabbed and filtered) runs in WEWoS as the example ViPEr paper figure 1 (group Vision examples).

Credits

The engine and the node libraries are ported from MGLTools (Michel Sanner, Daniel Stoffler, Guillaume Vareille and the Molecular Graphics Laboratory, TSRI). The tutorials follow the Vision tutorial of MGLTools 1.5.3 by Michel Sanner and Guillaume Vareille. 3Dmol.js is BSD 3-Clause licensed, Mol* MIT licensed; see THIRD_PARTY_NOTICES.md. The server and page conventions come from ADapt and ADCP_docking.