dbrnz / celldl-web Goto Github PK

In fact, each Group and Component may have an associated bond graph.

This is most obvious for compound groups -- are Cytoscape's corner radii fixed? We scale the radii when generating SVG.

e.g. line-start: 10% left [ANGLE [until ELEMENT]]

cytoscape-edgehandles allows us to do this, though we need an edge-drawing tool item to enable/disable edge handles (to prevent handles appearing when the user is doing other things (e.g. moving nodes)).

It's possible to filter target nodes to prevent potential nodes being connected to other potentials etc.

This implies referencing and loading local style sheets (via file:// ??) and possibly having multiple (tabbed?) editor windows.

For file open/save etc, setting options, etc, etc.

This is for the resulting SVG (unless we generate SVG on-the-fly from CellDL (#19)).

Can we do this be embedding elements within a SVG diagram??

We are currently running beta code flagged as not ready for production.

Compare same diagram in Firefox:

with Chrome:

The README file should also show at celldl.org.

e.g.

position: left #el1, above #el2;

This will keep all MathJax related code in mathjax.js.

For example:

• compartments
• part membranes
• transporters

These are now secondary to the bond graph and could be seen as an annotation layer on the bond graph.

Can we somehow highlight the error in the editor window??

This will require us to keep a z-order to take into account when generating SVG. It will also require SVG to be regenerated whenever to current selection changes.

When:

1. Loading a CellDL file.
2. Closing the browser window.

We can use editor.isClean() and editor.markClean() methods.

The console has "Object doesn't support property or method 'Symbol.iterator'" error" which comes from for (let file of fileList) { } in main.js:173.

1. Implement rotation (for both plain and MathJax generated text).
2. Implement color for MathJax generated text.
3. Better centre generated text? Can we get a bounding box??

For both the XML and the styling rules...

Things currently work though, because the new viewport positions of all manually positioned elements are saved after each reposition. If percentage offsets wrt an element's containing group were saved then only those of the repositioned element would have to be saved.

Properties of the current element are shown when the element is selected.

Needs to be a HTML form with [Save] and [Cancel] buttons.

Possibly hard-code a grid, say with (2vw, 2vh) steps (or (2%, 2%) steps??) and later add a toolbar and/or menu item to enable/disable, set step size, etc.