-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes.txt
74 lines (58 loc) · 4.38 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
Directional
Localizing priority, weight of nodes or edges
Integrating nameable Plane objects... essentially 3D versions of 2D Edges.
UI considerations - VR vs Desktop primacy
Peace between explicit (user-added) Edges and systemically generated edges ( CompleteGraphBetween )
What's hard to change? How to make it easy to change?
- Explicit vs Programmatic Graph genesis (Edges, Nodes, Graphs)
- Develop a method for handling the fork between these. Fully understand the difference that would be required in
- Functionality
- UX transition.
- What functions would serve both possibilities?
- Handling some behavior in UX/UI vs via hardcode? Ie, the user creates the 'system,' 'completes the graph' and can set up desired behaviors in UI/Front-end.
- How to have multiple 'graphs' in a single file, while the file itself is treated as a single graph
- Potential solution built into version 1.9.5 - It's now possible to pass an array of nodes and check if it's a complete graph. Dynamic checking makes it possible
to have complete graphs be created/destroyed by the user inside a system of nodes, and, if verified complete as graphs, be treated uniquely. This also portends the
possibility of other graph types, such as incomplete, but closed, or branching/tree structures to be detected automatically and treated uniquely when detected.
- Some refactoring suggested for the new potential solution mentioned.
- An array.clean() function that handles the work of
- removing duplicate entries
- deleting references to graphElements identical to the graphElement being checked as the origin point
- deleting references to non-existent graphElements.
- Removing duplicate instrumentation arising out of nested function calls.
- Make functions able to recieve either an array of Nodes or an array of ids. For this to work, add a "referent" property to the graphElement "id" property.
- Detect loose nodes using a nodeHasEdges() function that simply tests for edges and returns true or false.
- UI should be highly flexible. The set of tools may change significantly. The UI interface will change wildly both to accomodate desktop vs AR situations. AR situation itself
will involve a lot of experimentation. We'll want to iterate quickly.
- Make graph completion functions explicit (executed via UI tools) rather than implicit as first step toward preserving functionality while creating user control.
-Functions executed:
- graphFromJson
- renderGraph
- nodesFromJson
- completeGraphFromNodes( graph ); - ACTIONS: refactor this function to take any array of nodes. DONE Test using the UI element. DONE Activate multiselect capability. Pass the selected as an array to the function. Test. Work out error conditions. DONE Replicate for the other functions on this list.
- LUCIDNODES.showGraphCenterPoints( graph );
- getNodeEdges({ graph: graph, node: graph.nodes[i] });
- getNodesAdjacentToNode( graph.nodes[i] );
Version 0.1.10
Refactor so that we don't need "graph" references in functions. Replacing top-down "graph" structures with "groups" that can be mindmap, graph, or other diagram structures.
- Changing Functions
- Started by
- making "graph" a Group type.
- renaming functions that could apply to any group to Group where previously Graphs
- left functions that would apply to graphs, ie 'Complete Graph' named as Graph... applicable to that type of group.
- still to do, renaming/refactoring where "graph" is still taken as a function param inappropriately.
- Generalized showGraphCenterPoints() to showNodeArrayCenterPoints() - now this function can show centerpoint for any node array. Groups can be passed....
- Changing JSON structures
- Started by renaming "graphs" to "groups"
Bugs noted:
- ALTSELECTED sometimes errors out. - Two bugs, shallow one FIXED, still another, much rarer fail.
- When edges are loaded from a saved file, the original source/target order should be preserved.
- Need to assure no extraneous info is saved in files (edges->nodes especially)
Version 0.1.13
- Working on Deleting nodes and related edges. Splicing the node.edges array shortcircuits the deleting for-loop, but we want to preserve the complete functionality on the
deleteEdge function. Not sure how to handle.
Node.inGroups = [];
Edge.inGroups = [];
Group.type = mindmap || graph || ??
Group.edges = [];
Group.nodes = [];