First cut at an API for Canvas

[kfl]

Hi

I have made a direct, and thus low-level and highly stateful, API to the HTML canvas element.

Currently are the parts for drawing (filled or stroked) straight lines, arcs, and text implemented, documented, and (somewhat) tested.

The currently implemented API should be enough for implementing tic-tac-toe (as mentioned in issue #22). At least it is enough for making a pie chart (see Pie.hs).

Let me know if you have any comments or changes you would like to see before merging. I don't have strong opinions regarding the API "design".

Some somewhat open questions are:

• Rather than having a bunch on setter functions (like setFont, setFillStyle, ...), would it be better to have a general set function for setting properties on the context object. (If so, how can we avoid conflict with the Core.set function?).
• I tried to follow the API style you had started for drawImage using the Vector type for (x, y) coordinates. But I'm sure I like it for the full API.
• In general how should JS optional arguments be handled. See for example arc and arcAC functions that both bind to the JS function arc.

[HeinrichApfelmus]

Awesome, thanks a lot!

Concerning the open questions:

1. Well, I think the best idea is to integrate them with the Core.set function. :) It's very simple to do: Instead of defining a function setFont, you define a value font :: WriteAttr Canvas String by wrapping the former definition in a call to Core.mkWriteAttr. Voilà!
2. Looks good. I think it's nice to have a type synonym for points and vectors, the tradition is to call them Point and Vector. Maybe it should be type Point = (Double, Double), though, for sub-pixel stuff.
3. Beats me. The sunroof compiler sets a precedent by defining a function arc with the default argument fixed and an additional function arc' with the default argument becoming an additional argument. Let's just do it their way.

---

In the long run, we probably want to turn the Canvas API into a backend for the diagrams library. Judging from the source code for the diagrams-svg package, this doesn't seem to be too difficult. The main advantage would be that we would get compatibility with libraries like Chart for free. But for now, I'm just as happy with a simple binding.

[kfl]

All the open questions have now been addressed. I agreed with and followed your recommendations :smile:

---

I agree that making a canvas based backend for diagrams is next up. However, I also think that a low-level direct binding has value, in case you don't want to use diagrams (for whatever reason).

[kfl]

BTW I've made the PR against the develop branch. Would you rather want it against the master branch as the examples on the develop branch is a bit wedged right now (the Tidings.hs files is missing)?

[kfl]

Sorry for being the chatty. I just discovered why the develop branch was wedged. The cabal file just need to be updated.

[HeinrichApfelmus]

Thanks! I'll take care of some minor cleanup.

[HeinrichApfelmus]

I have extended the FFI code to cover the stuff that you needed for the Canvas bindings. I could simplify the implementation somewhat and made minor improvements to the documentation. The latest commit is 9105fa6a1c2f33b3bca56add5b46d05e4149d1bc .

[kfl]

Looks great.

I was debating how to best document the functions with many arguments, the way you have done it is probably more Haskell idiomatic.

[HeinrichApfelmus]

By the way, if you happen to work on a project using Threepenny, I'd be interesting in screenshots for the gallery.

[kfl]

I'm currently working with a student on a project based on Threepenny. However, currently the only thing really worth showing is the pie chart example.

We'll make sure to send something once we have something worth showing off.

[HeinrichApfelmus]

That would be great, thanks!