| Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
|
|
|
|
according to my yet unwritten coding conventions:
1. no single line blocks
2. no empty lines without a good reason
|
|
verbose logging
|
|
|
|
|
|
|
|
Auto suggest doesn't work for nodes loaded from local storage
Fixes #60
|
|
Works around a problem where you load rhizi with a small window size and then
enlarge it, since we don't dynamically change the svg size (and it is
fixed instead of filling a parent div or such) we lose access to a lot
of the screen (i.e. can't drag nodes there, can't see anything there,
etc).
|
|
|
|
|
|
|