Selection layer abstraction

[haosharon]

There are many uses for a 'selection' layer of the graph. The selection layer can be used to zoom to a certain rectangle scale, or it can be used to select certain nodes of the graph. That's a design decesion we'll have to reach together. For now, the layer is abstracted in way that will allow us to define the functionality pretty easily.

Note: I don't really like what I did to capture mouse events. I'd love to have a separate div container specifically for this layer, but I was having trouble with event propogation and absolute positioning. I currently use the main parent div as the layer's container.

Another note: I did this in coffeescript and compiled it to javascript. Currently, I'm just ignoring the coffee files when I commit code so it doesn't pollute the repository. I'm fine with continuing to do that, but I'm not sure that's the smartest / most efficient way to develop, especially when we start editing the same files.

[jdhenke]

hey @haosharon - i definitely like the sound of this and am still getting up to speed on your implementation but have a few initial thoughts.

1. coffeescript - i would love to use it. I think we might want to come up with a workflow that involves it.
2. canvas element - it looks like you used an absolutely positioned canvas element.
   • i'm not very familiar with canvas elements... what are the pros and cons compared to svg, which is what is being used to render the graph?
   • how does this work with the current zoom/drag functionality? is the whole point to separate the two?
3. event propagation/absolute positioning - if you'd like a second pair of eyes i'm happy to take a look at whatever you were running into

[haosharon]

@jdhenke

1. coffeescript: I think a good idea would be to exclude compiled .js files from our commits, so that when we make commits, the only changes we see are the ones we actually make. We can each compile them to javascript locally as we work using coffee --watch --compile -o js/ coffee/ so it shouldn't be much of a hassle.
2. I believe canvas is easier to use when building dynamic elements because it can be rendered programmatically vs using files / bitmaps. Honestly, I have more experience using canvas and felt it could do the job better. What svg does well in is supporting text, but I don't think for this particular feature we'll need much text rendering support. Check out this article for a more detailed analysis.
3. My main issue with absolute positioning was that events are propagated to child / parent elements, and the elements it's positioned over aren't in its ancestor tree, so wasn't getting the events. I might push another branch with my other implementation if I make any headway.

[jdhenke]

coffeescript: I think a good idea would be to exclude compiled .js...

OK, we should talk in person briefly about when to do this as it would affect all the source files and I don't want people to have to redo a bunch of stuff.

What svg does well in is supporting text...

Do you think we should keep the core graph rendering done by svg or switch to canvas?

the elements it's positioned over aren't in its ancestor tree, so wasn't getting the events

could we then make this part of the graphView? i put in a g element solely for capturing events and this seems like a similar situation. maybe modifying graphView to provide an ability to insert these middleware elements and then making the zoom functionality and this selection layer use this functionality? just a thought.

[haosharon]

I think there should be a pretty straightforward way to convert/compile from .js to .coffee. If we did that once and then .gitignored them from then on, I think we'd be set. We could potentially use this converter.

I think svg is good for graph based objects, since I think they're organized by actual objects whereas html5 canvas is by pixels. I think it'd be fine if we stick with svg for our current graph / d3 things, unless you feel it's weird to have both svg and canvas at the same time?

[jdhenke]

I think having canvas elements mixed in is fine. My conclusion is that this is totally fine, but wanted to verbalize my decision process. My main concern thought is that the coordinate systems used to render the nodes and the selection rectangle are different.

• The nodes are using a force layout in the background and the zooming/panning is handled by an svg transform.
• The selection rectangle is using the raw x/y on the page based on mouse events.

To link the two, we'd have to either

• rely on the rendered x/y coordinates of the nodes
• transform the raw x/y coordinates into the same original coordinate space of the nodes.

I prefer the first one since we have both readily available, unless there are other reasons against it.

I also wonder if there are other uses for inserting another "type" of layer which is subject to the same transforms as the nodes/edges.