How to handle click events?

[Widdershin]

Should we provide an API for clicking on parts of the canvas? or should this be a separate driver?

[UrKr]

@Widdershin Asked me to detail my use case for this.

It's pretty straight forward. I have to make a sort of chart where the y axis is a list of people and the x axis is time.

I have to be able to move the bars inside the chart, so it would be convenient if I could do something like:

Canvas.select(some_sort_of_id).events(click) -> stream of events with information about the pressed mouse buttons etc...

I think this would also require implementing isolation so that the individual bars could easily be defined as separate instances of a component.

So yeah... pretty much the same as the DOM driver. :)

[apretto]

This is an interesting problem.

Drawing to a canvas simply paints the pixels on the canvas. Any information about what was painted there (a circle, square, text, an image) is lost. To be able to tell what "entity" was clicked on, you need to have the information about what was drawn to the screen (like the vtree used internally in the canvas driver, or just an object where you kept all your entities before even calling cycle-canvas functions), and the coordinates of the click.

Long story short, you need this:

clickToEntity(allEntities, clickCoordinates) -> entity

Inside that function, you'll have to figure out the layout of all your entities:

• their position (this will be affected by the position and any current transformation)
• the ordering (if 2 entities overlap, the second one will be "over" the first one)
• alpha (possibly, maybe not)
  and from that you can figure out who was clicked.

You can do it yourself right now, just getting the clicks from the canvas element and creating your implementation of clickToEntity, or we can add it to the driver (it should be possible to use the instructions generated from the vtree to keep updating a hit-map while you perform the instructions).

This is a very interesting problem to solve, but I would question if it is something that cycle-canvas should support. Right now it's not clear to me if we want to have this driver being a straight on wrapper for the html canvas, or if we want to aim more towards something more similar to a game engine.

Another option is to use SVG, as you can attach event listeners to SVG elements in the DOM. I don't know if there's a svg-driver for cyclejs yet.

[UrKr]

Thanks for the response!
SVG is cool, but unfortunately it's too slow for my needs.

I think it would be cool if the canvas driver had similar ergonomics to the DOM driver, Perhaps it could even wrap a library which works on WebGL and falls back to canvas when WebGL isn't available? pixi.js and ivank come to mind, though it might be preferable (for some reason) to make your own. If you go for a game engine, I think WebGL would probably be good.

[grozen]

If you don't mind me bringing this relatively dusty issue back up, I think we really should provide an API for clicking (and I will gladly work on it). Of course, I am thinking of something very basic that'll just give you the coordinates, and possibly modifier keys. That means tracking entities is left entirely to the user.

The way I see it, clicking the canvas is a very common interaction so it makes sense to include it in this driver.

[grozen]

#35 does indeed close this.