@scalamorphing @brusherru Do not use .jsx extension uless it is a module containing <ReactXmlishSyntax />.

I think plain JS should use plain .js extension.

Rationale

Having a feature to run a program on PC without any Arduino opens XOD to people who don’t yet have a board, for very quick experiments, and quicker development.

User story

• I put system-time linked to watch
• I hit Deploy → Simulate
• A progress bar in the Deployment pane header appears
• When done, the Debug tab appears in the work area exactly as if I upload with the debugger
• The watch is live and shows time past the start of Simulation

Acceptance criteria

• The basic scenario works as described above
• The behavior of the Deployment pane is the same as while uploading with the debugger (collapsed by default, logs are populated, tabs are auto-switched)

How to implement

• In C++ make a WasmSerial object which mimics the standard Serial print/write/flush operations
• When compiling use macros to define XOD_DEBUG_SERIAL as WasmSerial in case of simulation and basic DEBUG_SERIAL otherwise. Use the XOD_DEBUG_SERIAL in the watch implementation

Creating patch nodes is a most powerful way to evolve the user project and to extend the ecosystem. We should allow the user to create new nodes by combining existing.

A patch node implementation is a special kind of a patch that has unbound pins for inputs and/or outputs of the node as a whole.

The approximate user action steps are:

• I create a new patch
• I put a special input or output “pin” entity of given type on it
• I set its name via Inspector
• I connect it to other pins

After that, I have a ready-to-use new patch node.

The patch node should appear in a list of node types available for insertion. Nodes placed such way get the same label as a patch nodes’ patch name and input/output pins that are not bound on its implementation patch.

Story acceptance criteria

• A user can put unbound pins on a patch
• A user can give them names
• A user can link them to other pins utilizing common validation rules
• Such patch becomes patch node and gets added to available node types
• A user can place nodes of newly created type on other patches
• An attempt to change unbound pins on patch nodes already in use should bark on a user

Are there any reasons we develop against Node 0.12.0 (maintenance only) instead of Node 6.0.0 (current stable)?

From package.json:

"engines": {
  "node": "0.12.0"
},

Make a button that would call a JS function (black box) with patch JSON.

We could use AngularJS commit message conventions (https://gist.github.com/stephenparish/9941e89d80e2bc58a153) to make history more clear.

I don't think we should be very verbosive in body message until the release but other practices would be handy.

At the moment, we have a lot of modules, that we don't need or it performs approximately the same functions. For example, we have a lodash, underscore, and ramda in node_modules.
Of course, we didn't load everything into a client.bundle, but it's harder to decide what we shall use (and already used somewhere in code).
So I propose to remove all modules that we didn't use now, determine what shall we use (really it's not so big list) and then we'll add something else in the future if we forget something.

I looked at the modules and think that we can leave the following modules (or choose some of those that are written with a slash):

production:

• es6-shim / babel
• d3
• lodash / ramda
• sass / stylus
• rxjs / derivable
• websocket (really we don't need it right now)
• fs

development:

• ts-loader
• typescript
• tslint
• tslint-eslint-rules & jscs (I propose to use these features for compliance with the common code style)
• eslint (do we really need it?)
• webpack
• json5 (we don't need to pull it into production, cause we can compile json5 into json)
• precss / postcss / sass / stylus
• csso (cssoptimizer)
• karma
• jasmine / mocha

If you think that we need to add something in this lists or propose another module instead of those that in the list — feel free to write it in comments.

1. Abstract ServiceState
2. ServiceState for each Service, that we have at the moment

As a documentation author, I want a command-line utility that given a path to patch JSON would provide rendered SVG file.

Patch figures are massively used for end-user documentation. It’s a pain to have a long toolset to produce that images.

The better idea is to keep example mini-patches as JSONs along with documentation source files and get them rendered automatically on documentation build.

This would also guarantee that we’ll get 1:1 visual experience between IDE and HTML docs.

Produced SVG’s must be correctly rendered by supported browsers.

Acceptance criteria

• I can xodc render /path/to/project/patch-to-render/patch.xodp and result SVG well be rendered to stdout
• xodc render can understand paths of shorter form /path/to/project/patch-to-render/ and /path/to/project/patch-to-render as well
• xodc render can take --output or -o argument to output to file rather than stdout
• Dimensions of the output are determined by bounding box of patch contents
• The resulting SVG alone is rendered correctly in Chrome and Firefox

How to implement

• Implement an additional build step of xod-client that would produce a single CSS for patch rendering
• Make a ReadOnlyPatch React container that is similar to existing Patch but doesn’t attach all interactive stuff
• In the implementation of render subcommand use that container and invoke method to render it to an SVG string
• Inline CSS required into the SVG string
• Output the SVG string

Rationale

It would help a lot to understand what’s going on in a XOD program if I can view values on outputs I’m interested in real-time.

To achieve it we’re going to introduce xod/core/watch node that has a single (unnamed) input of type string. When a debug session is active the watch shows the value passed as its body, i.e. instead of own label.

Prerequisites

• #459

Acceptance criteria

• I can place a xod/core/watch like a regular node on my patch
• The watch node has outstanding look
• I can link watch’s input like any other pin
• I can Deploy → Upload → ✔️ Debug → Upload to start monitoring the value incoming in real time
• I can simply Deploy → Upload and it would not have any differences in memory, etc regardless of whether I have watches or not
• On Deploy → Debug a new tab named “Debug” is opened and shows the entry point patch
• Visually a patch chosen as entry point doesn’t get offset on debug session start
• The serial log is embedded to the Debug tab pane
• When a debug session ends the Debug tab gets closed automatically and I’m switched back to the entry point patch tab or the patch that changed

How to implement

• Remove watch nodes on transpilation if it is targeted toward regular upload, i.e. not for debug session
• Record an ID map from long XOD node IDs to short C++ NodeId’s
• Implement xod/core/watch like a regular node that Serial.println(...) in it’s evaluate. A ctx argument is passed to evaluate it’s a node ID which we could use to correctly bind the data to a watch.
• Use some special textual format to send watched value updates. E.g. +XOD:42=76.9859 plus line break, where 42 is a node ID and 76.9859 is input value (text)
• Monitor incoming serial port data for the lines matching debug format, decode data, map ID back and update the view of corresponding watch node
• Handle wrong IDs gracefully: do not crash, do not update watches, just dump the line as is to the debug log

There should be help available for nodes available on node choice stage as well as when a node already placed.

Node’s help page should contain an overall description, each pin type info and description, pre-render of the node. The info should be fetched from node metadata.

See vvvv help pages for inspiration.

Acceptance criteria

• I can select a node on canvas and select “Help” via menu or keyboard shortcut (h) and will be presented with a sidebar containing node help page.
• I can click an “info” button next to node type label while choosing node type to be inserted to get the same help before insertion.
• The help article contains a link to the same page on site (UTM’ed with campaign=docs, medium=helpbar)
• Switching selection on the patch board updates contents of the help sidebar
• Switching selection in the Project Browser updates contents of the help sidebar
• A node miniature is zoomed out 2×, 4×, etc if it doesn’t fit width

Are there any reasons we have a big bunch of various labels and no rules how to use them and when.

What if I remove all but few actually used for now?

• Inspector on the sidebar
• Type-specific widgets in inspector
• Dynamic label (hard-coded branching)

We should have an intuitive cut/copy/paste behavior like most editors do.

Acceptance criteria

• I can copy then paste on the same patch. The cluster pasted would appear as zombie with selection preserved so that I can immediately drag it to a new place
• I can copy then paste on another patch or even another app instance
• If clipboard content belongs to XOD but pasting it would lead to an error (e.g. integrity fail), a error message is shown
• If clipboard content doesn’t belong to XOD, pasting results in nothing
• I can copy/paste individual nodes, multiple nodes or multiple nodes with links between them
• I can cut rather than copy which behaves like “copy then delete”

How to implement

• On paste regenerate items IDs to avoid conflicts with existing items
• Use HTML5 features to make clipboard work with web version

What to test

• Successful scenarios of copy-paste (unit test)
• Failing scenarios of copy-paste (unit test)

Don’t fake clipboard contents, use implemented functionality to forge the data required.

Don’t involve real clipboard of the OS in tests.

Desks are a composition of widgets that could show some value or receive some input from a user. They kind of forms or console for xoders’ devices.

From another side, a desk is a patch node with inputs and outputs corresponding to its widgets. This node could be placed on a regular patch to hook it up.

Once the desk is hooked up to a patch of NodeJS target, its UI should be served on some port so that it is available for interaction with web-browser.

Prerequisites

• #238

Acceptance criteria

• I can create a desk via UI with “Label” and “Button” widgets
• I can place the node provided by the desk on a patch
• I can save/load all stuff created
• I can run the patch on NodeJS platform and get that desk rendered in browser on some localhost URL (printed in console)
• I can see the label updated according to patch logic. E.g. it could show the current time.
• I can see the button sends its signals. E.g. it could trigger label update.

Development tasks

• Client and server code generation for desks
• Desk serving
• Binding of server-side values to client-side widgets
• Binding client-side interactions to server-side signals
• Desk creation UI

$ npm install
...
npm ERR! [email protected] install: `node install.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script 'node install.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the phantomjs2-ext package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node install.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs phantomjs2-ext
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls phantomjs2-ext
npm ERR! There is likely additional logging output above.

$ node --version
v6.0.0

What we’re using phantomjs2 for?

Multilevel undo/redo with Ctrl+Z/Ctrl+Y

Implement serializer classes.
For a beginning just Serializer (abstract) and LocalStorageSerializer.

Serializer works only with Services and works with serverState (composition of all service states).

For mapping their hardware with UI

The story is a prerequisite to a very important #31. Although it is self-sufficient.

We should create a project browser sidebar where the user can add, modify, delete, navigate through several patches of his project.

Any project starts with a single patch named main. But the user can rename it and add more patches. Patches are equal in rights, they kinda “simultaneous”. So there is no actual main one.

Story acceptance criteria

• There is a project browser listing current patches of the project. It can be a flat-list at the start, but eventually, we have to make it a tree-view.
• There is an Add Patch button that asks for a new patch name, creates it as an empty canvas and brings the user to it.
• Click on browser list item opens selected patch for editing. We can make a tab selector of currently open patches, but it is optional for now. “Click to edit” is enough.
• There is a Remove Patch button that deletes selected patch with all its contents. If the patch is not empty, XOD should ask the user to confirm removal.
• Undo/Redo system should have separate histories for each patch. So that if I Ctrl+Z on an active patch it should not affect any other patch.

• Inputs can be linked to outputs only
• An input can accept no more than a single link (but an output can have many)

Valid pins of the same type (in bool/number/string meaning) as a linking pin should be highlighted green. Other valid pins should be highlighted yellow.

Following things should be implemented:

• Highlight valid link targets on linking start
• ESC cancels linking
• If trying to create an invalid link, a message should show up
• Clicking on a link selects it (visually as well). Click area should be much wider (10px) than a link thickness (1px).
• DEL on selected link should remove it

For valid linking see docs.

Features to be implemented:

• INS presents a dialog box with available node types
• Selecting a node type creates a ghost node under cursor
• ESC cancels insertion
• Click puts new node under cursor
• Click on an existing node selects it (visually as well)
• DEL on selected node deletes it along with any ingoing and outgoing links.

From user’s point of view:

• Ctrl+Shift+S should open “Save” dialog box where the user types new or selects an existing *.xod file to overwrite
• Ctrl+O should open “Open” dialog box where the user selects *.xod file to be opened as a new project