Add blocks to support Processing API

[dethe]

We should be able to support doing anything Processing.js or http://p5js.org can do, short of 3D. We don't have to do everything the same way, but we should be able to do it.

[dethe]

To be more specific, we'd like to support the ability to do what these APIs do: http://processingjs.org/reference/. That can be an overwhelming list, but the first step would be to remove all the APIs marked in red (which the JS version of Processing does not support), all of the 3D methods (out of scope) and then all of the things we already do. I think that would result in a more manageable list.

We don't have to have blocks 1:1 with Processing APIs either. Ideally we can have simpler ways of doing things than Processing does. And we certainly don't have to support all of the Java keywords like void, super, static, etc.

P5 (http://p5js.org/) is a re-thinking of Processing. Similar goals, but starting from JavaScript rather than from Java, so http://p5js.org/reference/ might be a better starting point than the Processing reference.

Some features may be out of scope due to complexity, for instance we already have a feature issue for creating new blocks (i.e., functions) so any Processing APIs for that would not be part of this issue. Once we have a list of features supported by Processing that are not yet a part of Waterbear we can discuss that list to prioritize, scope to blocks, etc.

[ghost]

Here's a list of APIs supported by p5js that are not currently supported by waterbear:

• Shapes
  • arc()
  • [x] quadrilateral() - covered by the polygon block
  • [x] triangle()
  • [ ] ellipseMode(), rectMode() - these functions just change the order of the parameters, this won't be useful to us
  • [x] bezier(), bezierPoint(), bezierTangent()
  • [ ] curve(), curveTightness(), curvePoint(), curveTangent()
  • beginContour()
  • beginShape()
  • [ ] bezierVertex() - this function is just another way to define a bezier curve, I don't think it will make sense with our current implementation for shapes
  • [ ] curveVertex()
  • endContour()
  • endShape()
  • quadraticVertex()
  • vertex()
• Lights
  • ambientLight()
  • directionalLight()
  • pointLight()
• Environment
  • [ ] cursor()
  • [ ] noCursor()
  • [ ] focused
  • [ ] frameRate()
• Transform
  • [ ] scale()
  • [ ] shearX()
  • [ ] shearY()
  • [ ] translate()
• Keyboard
  • [ ] keyIsPressed
  • [ ] key
  • [ ] keyCode
  • [ ] keyPressed()
  • [ ] keyReleased()
  • [ ] keyTyped()
  • [ ] keyIsDown()
• Mouse
  • [ ] pmouseX
  • [ ] pmouseY
  • [ ] mouseButton
  • [x] mouseMoved()
  • [x] mouseDragged()
  • [x] mouseReleased()
• Touch
  • [x] touchX
  • [x] touchY
  • [ ] ptouchX
  • [ ] ptouchY
  • [ ] touches[]
  • [ ] touchIsDown
  • [x] touchStarted()
  • [x] touchMoved()
  • [x] touchEnded()
• Math
  • [ ] constrain()
  • [ ] distance()
  • exp()
  • [x] log()
  • pow()
  • [x] sqrt()

\ updated list to reflect comments

[dethe]

My thoughts on these. If I don't mention something from the above list, that's because I think it is straight-up a good block to have.

• Shapes
  • arc() We have shape.drawArcWithRadius
  • ellipseMode(), rectMode() These can be handled on the ellipse and rect constructors with select options, but also by passing Vector, Size instead of Number, Number, Number, Number. This is an opportunity for Waterbear to be easier to use and more clear than the Processing family.
  • bezier(), bezierPoint(), bezierTangent() We have a bezier curve, but not point or tangent
  • curve(), curveTightness(), curvePoint(), curveTangent() We have quadratic curves, but not Catmull-Rom splines
  • beginContour() We don't have contours (negative space within a shape) explicitly, but it can be created by drawing the shape correctly. I could see having "add" or "subtract" one shape from another would be useful, but as it stands I don't see the benefit of contours.
  • beginShape() beginShape() is implicit in Waterbear, you don't need to call it.
  • bezierVertex() this is a confusing name for adding a bezier to a shape in progress. We have path.drawBezierTo for this
  • curveVertex() Same comment as for bezierVertex, except that we support quadratic curves but not Catmull-Rom splines
  • endContour() Implicit in Waterbear
  • endShape() Implicit in Waterbear, unless you need to close the path
  • quadraticVertex() We have this
  • vertex() This is what we call vector/point
• Lights Lighting is for 3D and out of scope for Waterbear currently.
• Transform I was surprised we didn't have these. We used to have them as part of a matrix type, but they could be part of the stage type too.
• Keyboard
  • keyPressed() we have this for selected keys, but not arbitrary keys
  • keyIsDown() we have this for selected keys, but not arbitrary keys
• Mouse We should adapt all mouse blocks to be pointer blocks and work with either mouse or touch. I don't think we need to support multi-touch at this time though.
• Touch Same comment as above
• Math
  • distance() I needed that enough to add it to my branch in utils, but haven't made a block yet
  • exp() We don't have this but we have blocks for e and toThePowerOf
  • pow() *We spell this toThePowerOf
  • sqrt() Weird, I was sure we had this

[dethe]

There are some more APIs around Acceleration, Pixels, Input, Output, etc., but this is a good start.

[ghost]

I guess I missed the arcs, bezier curves and quadratic curves, I see them now though! Maybe that is an indication that Paths isn't an intuitive name for these? At least not for me, but I may not be the general case :). As for the keyboard ones I think that there may be value to detect arbitrary keys, a lot of the p5js examples use "if any key down", so I included them here. I wasn't sure how much of the acceleration API we are currently covering, I have started to make a little example so I can figure out the scope of our implementation now, but I agree that they could be included in this list. As for the Pixels, I wasn't sure if that was a high priority or not, same with Input and Output. They would be useful at some point but to me seemed like a different project, say an I/O feature.

[CelticMinstrel]

Distance and square root are both possible currently, though it's probably more convenient (and maybe even less confusing) if they're included directly. I could do this, if you like. I notice we're also missing logarithms.

[CelticMinstrel]

distance()

I needed that enough to add it to my branch in utils, but haven't made a block yet

This is Euclidean distance, right? Only asking because I noticed the great circle distance implementation under geolocation (which, incidentally, appears not to have a block?).

[ghost]

log() is on the first list. I think those operations are common enough that they should be included as blocks

[ghost]

And yes distance() would be the Euclidean distance.

[CelticMinstrel]

Euclidean distance is easily implementable using Math.hypot().

[CelticMinstrel]

Since you self-assigned it, does that mean I shouldn't add the math blocks?

[ghost]

I am going to do this for my term project. If you do add the blocks there will still be enough for me to take on for the term, so you are welcome to if you want, but I can also do them once we have prioritized the list.

[dethe]

I agree 100% that Path isn't the right term. These should be part of the Shapes collection of blocks, I think. We should probably have a generalized regular polygon block too.

[CelticMinstrel]

I was thinking about the lack of polygons a little while ago, actually.

[CelticMinstrel]

The path blocks are also kind of weird, and I don't really understand how you'd use them.

[ghost]

@dethe do you have any input for prioritizing the updated list ?

[dethe]

@AdriennePind sorry for the delay. I think the new shape blocks are probably the most important of the missing pieces, especially if you can merge shapes and paths as discussed in #1238. Happy to talk more about this as needed.

[ghost]

@dethe no problem! I was thinking the same thing so I started working on adding a triangle block yesterday. I also think that merging shapes and paths is a pretty high priority so once I have finished this triangle block, and know a bit more about how shapes work, I will work on that.

[ghost]

@dethe I think I'm going to move on to adding some of the API's for input. You had mentioned something about that in the meeting on Monday that you would like me to address (for touch inputs I think). Would you be able to elaborate on that?

[dethe]

Mainly that I want to unify touch and mouse inputs as pointer inputs. We already do that for drag-and-drop, but should expose them that way for the blocks.