from Kozaneba Development Diary 2021-09-03
Write down what you will do when you wake up
-
Add frontmost SVG layer
-
Create an arrow object for now.
- N ko
-
Try drawing and see if it corresponds to dragging items
-
Add a click handler
- Delete first
-
Switching arrow heads
-
Paste now, always reassigning IDs, but only when duplicating.
-
Create a script to view file dependencies and generate JSON
-
Put it on Kozaneba.
Create an arrow layer today.
First, place the SVG element
Next, make arrows, start pomodoro
- Pomodoro end
- Lines are now drawn according to the itemās position, but the intersections with the edges are still being calculated.
Next, weāll complete the intersection calculations to give it an arrow-like appearance.
- Pomodoro start
ā Add foremost SVG layer ā Draw arrows for now.
The next step is to change the arrows, which are now hard-coded, to a form made from data.
- = Create an arrow object
- Pomodoro start
- done
Next time, letās put the test code into a more complex situation and see if it displays as expected.
- Pomodoro start
- done
Paste now, always reassigning IDs, but only when duplicating.
- First try to import arrows in small JSON
- Allow the arrow to be copied in the first place.
Implement copy before paste
- What if a partial selection is made?
- For example, if you select and copy only 2 vertices of an arrow that consists of 3 vertices, it should be an arrow if it consists of 2 vertices.
- What if an element is deleted in relation to
- It is subtle to notice the timing of the drawing.
- Annotation update process should be run after the item is deleted.
- What about REPLACE?
- Should the ID be maintained?
- Selective copying does not involve updating the state because it is, after all, a ācopy.
- Since it is not a tree, the process of reassigning IDs must be handled separately.
I found the implementation of copying before pasting to be quite a pain in the ass.
- Possibility of partial selection by the user
- Well, weāre starting to see a lot of it, so letās implement it.
- Pomodoro start
- I could copy-paste.
- However, bugs were also found.
1Repair Pomodoro and build a Python library in the remaining time.
-
Make a script to look at file dependencies and generate JSON
- I found one more bug along the way, so the library didnāt get going.
Make a script to look at file dependencies and generate JSON
-
Post it on Kozaneba
- Implemented (but not practical)
- Kozane, because I generated all of them to 0,0.
Iād be tempted to add physicsā¦
nishio: Iām tempted to add physics to Kozaneba, but I donāt think itās a good idea to mechanically apply physics to a place where the physical arrangement is an intellectual product. I donāt knowā¦
nishio: I donāt know if itās a matter of turning on the physics, or if itās a matter of maintaining the proximity of objects that were in close proximity at the time the physics was turned on as āa relationship expressed by a human being through proximityā. Is it better to make the physics calculation in such a way that the proximity relationship is maintained?
nishio: But when you put it that way, āplaced a bit apartā is also a statement of ārelated, but not enough to stick right next to itā. ā¦
nishio: the further apart you are, the less relationship you have and the less need you have to maintain it.
pokarim: Itās just a thought and Iād recommend going through it, but (sorry), if the distance is a certain distance, the closer the closer the attraction and the farther the farther the repulsion, the more cohesion between the closer ones, I wonder if it would be possible to do something like that. Maybe there should be some kind of frictional force. I donāt know if such a thing would be a match for intellectual production systems, but Iād be interested in either result.
nishio: If we use āfar away and repulsion in proportion to itā, it will scatter like a big bang, so we need āthe further away it goes, the closer it gets to zeroā, and ānearness and attractionā. If implemented naively, it will collapse into a single point, so for intellectual production, we need āa repulsion that doesnāt dip any closer than a certain pointā. The area in between has room for ingenuity.
nishio: For example, if you move a pinecone closer than one, it will attract it, and if you move it further away than two, it will try to move further away. It is like oil drops in water. However, when there are long thin clusters, they will repel each other through the points in the cluster that are farther apart and break up into round clusters (also like oil droplets).
pokarim: Yes, that is true. I think it would be interesting if it were adjusted well. It would be ideal if we could prepare a logic to make the adjustment in a way that is not too deliberate and āresults in something like that.
nishio: If you generate a strong āforce to keep the current distanceā (like a sticky rice cake in physics) at the very edge of the penetration, it is hard to shred even if there is a repulsive force Maybeā¦
pokarim: I see, rice cakes. It seems to me that the difference between a rice cake and a mochi varies greatly depending on whether they are just close together and not sticking to each other or exactly sticking to each other. I feel that the centers are attracted to each other and the contours of the kozane are repelled by each other, and that if we adjust the relationship between the distance and the force, we can prevent the rice cakes from sticking, but Iāll have to try a little more to find out.
nishio: I was thinking about it and wanted to do it w
nishio: Iāve added physics, but itās not very interesting as it stands pic.twitter.com/sWkyj00bh1
nishio: there is a way to remove the vertices where the arrows are clustered together, or to represent the directory hierarchy as a group
nishio: Oh, I thought AdaDelta didnāt work as expected, but itās mean square when it should be root mean square!
nishio: Also, it would be nice if anything the user drags from the initial position is pinned and stuck.
nishio: I thought it would be a little too much to do physics with JS, but when I took a profile, I found that the reason it was slow was because I didnāt add a key to the SVG line in the React rendering. It was because I didnāt add a key to the SVG line in the React rendering.
nishio: there are 666 import relations between 197 files and if you visualize them as they areā¦ they are not visualized! Uni! gyazo.com/5723029877bfb6ā¦
nishio: I wonder if the problem is that there are 2000 line elements in the SVG, because it is taking a long time even when ungrouping, which is a problem before physics.
nishio: The physics step itself is about 200ms, so the drawing is simply too heavy. Well, this application is not the main purpose, so letās interpret it as a kind of load test. In terms of visualization of source code, directories can be represented as groups, and only references that cross over them can have arrows drawn.
nishio: tomorrow weāll have a meeting, edit the video, rework the screenshots, and continue with the source code visualization when we have more time!
nishio: I wonder if it is possible to rewrite 4000 SVG line elements 10 times per second in a modern browser to begin with.
This page is auto-translated from /nishio/Kozanebaéēŗę„čØ2021-09-06 using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. Iām very happy to spread my thought to non-Japanese readers.