| Age | Commit message (Collapse) | Author |
|---|
|
need better graph accessors to give only the 'real' nodes & links - that will fix some of the tests, leaving the real wrong ones
|
|
|
|
|
|
Yes, I'm being lazy. The purpose of require.js is to allow writing
modules, i.e. individual smaller then the whole files with clear
dependencies. This is achieved by using a new api provided by
require.js:
define, require, requirejs
Read more at [requirejs] (http://requirejs.org)
Tests have been rewritten to work correctly with require.js; they still
use jsdom.
Test output is now stored in the repository, all tests are run via
run_tests.js; This is a hack - once a good harness (with assertions,
suites - unittest like) presents itself it will be used.
Hidden here is also using FileSaver for history saving, so history is
saved to history.json instead to a random name. Plus dropping some dead
code.
|
|
|
|
|
|
The whole lower case thing is a hack. We should separete id and name.
But right now it seems to be holding.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not required right now, triggered by reverted patch.
|
|
This is more of #49 basically, just for a more complex sentence.
I've kept the flow that we have, but augmented the graph change check
(myGraph.compareSubset) and introduced some helper functions for sets on
the way.
|
|
|
|
|
|
Fixes #49
Note about solution: in general we need to find out whether the graph
from the new text (NewVertices, NewLinks) is homologous to the graph
from the old text (OldVertices, OldLinks). The implemented solution only
checks an easier case, where there is a single renamed vertex.
A better solution to do later:
- have textanalysis have state
- have textanalysis return the difference from the last state:
nodes added
nodes deleted
nodes changed
- plus for bonus refactor all the editing functions (edit* in myGraph)
|
|
event handler
|
|
|
|
|
|
|
|
|
|
|
|
changing state of existing node results in ability to delete nodes while
creating a new sentence by inputting a node name and then deleting it.
This was fixed for the common case in a previous commit, but not for the
case of loading from storage.
|
|
|
|
It broke the input box
|
|
Conflicts:
index.html
scripts/rhizicore.js
|
|
|
|
|
|
This reverts commit 5c5f9a8cfe3edd6f1df31ab00885e58e4a36bfd1.
reopen #63
this fix causes regressions - the update function does two things:
1. updates link & node graphical representation
2. causes the force layout to reposition links and edges (using tick
to selectively do that)
I need to change #2 without affecting #1.
|
|
|
|
Loading an old save (with no 'name' in nodes) triggers this path.
|
|
|
|
|
|
|
|
|
|
|
|
The fix is ugly. Basically we are relying on the force layout [1] for
the locations of the nodes. I've hidden the node until the first tick.
Since we do a tick calculation (tick is a function in rhizicore) when
adding a node there is no associated delay.
[1] https://github.com/mbostock/d3/wiki/Force-Layout
|
|
|
|
|
|
another refactor introduced (by
cd7157955d15802f34dee6ac4578ae249f3e397d), forgot to change
style at update instead of enter.
|
|
bug introduced by cd7157955d15802f34dee6ac4578ae249f3e397d
|
|
|
|
bug introduced in cd7157955d15802f34dee6ac4578ae249f3e397d
before that we recreated the links and nodes every update, and since all
links were created before nodes the document order was
<link>
<link>
<node>
<node>
which per SVG rendering order [1] leads to nodes being drawn on top of
links.
But after that commit the new links and nodes where created as they were
being edited, so we got
<link>
<node>
<link>
<node>
With this commit all links are created in a single group, getting back
the correct order:
<g>
<link>
<link>
</g>
<node>
<node>
nodes are ungrouped but there is no need for that (except that it looks
strangely assymetrical).
[1] http://dev.w3.org/SVG/modules/renderorder/SVGRenderOrder.html
|
|
|
|
|
|
|
|
still have new/edited node visible at 0,0 briefly while edited
The fix is by using d3 enter/update/exit and not killing all the nodes
every time we run update.
|
|
|
