Add blocks to support Processing API #898

Open
dethe opened this Issue Jan 17, 2015 · 20 comments

Comments

Projects
None yet
2 participants
@dethe
Member

dethe commented Jan 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Oct 5, 2015

Member

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.

Member

dethe commented Oct 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 13, 2015

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

  • Shapes
    • arc()
    • quadrilateral() - covered by the polygon block
    • triangle()
    • [ ] ellipseMode(), rectMode() - these functions just change the order of the parameters, this won't be useful to us
    • 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
    • mouseMoved()
    • mouseDragged()
    • mouseReleased()
  • Touch
    • touchX
    • touchY
    • ptouchX
    • ptouchY
    • touches[]
    • touchIsDown
    • touchStarted()
    • touchMoved()
    • touchEnded()
  • Math
    • constrain()
    • distance()
    • exp()
    • log()
    • pow()
    • sqrt()

** updated list to reflect comments

ghost commented Oct 13, 2015

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

  • Shapes
    • arc()
    • quadrilateral() - covered by the polygon block
    • triangle()
    • [ ] ellipseMode(), rectMode() - these functions just change the order of the parameters, this won't be useful to us
    • 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
    • mouseMoved()
    • mouseDragged()
    • mouseReleased()
  • Touch
    • touchX
    • touchY
    • ptouchX
    • ptouchY
    • touches[]
    • touchIsDown
    • touchStarted()
    • touchMoved()
    • touchEnded()
  • Math
    • constrain()
    • distance()
    • exp()
    • log()
    • pow()
    • sqrt()

** updated list to reflect comments

@dethe

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Oct 13, 2015

Member

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
Member

dethe commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Oct 13, 2015

Member

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

Member

dethe commented Oct 13, 2015

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 13, 2015

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.

ghost commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor

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.

Contributor

CelticMinstrel commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor
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?).

Contributor

CelticMinstrel commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 13, 2015

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

ghost commented Oct 13, 2015

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 13, 2015

And yes distance() would be the Euclidean distance.

ghost commented Oct 13, 2015

And yes distance() would be the Euclidean distance.

@ghost ghost self-assigned this Oct 13, 2015

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor

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

Contributor

CelticMinstrel commented Oct 13, 2015

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

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor

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

Contributor

CelticMinstrel commented Oct 13, 2015

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 13, 2015

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.

ghost commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Oct 13, 2015

Member

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.

Member

dethe commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor

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

Contributor

CelticMinstrel commented Oct 13, 2015

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

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Oct 13, 2015

Contributor

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

Contributor

CelticMinstrel commented Oct 13, 2015

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 18, 2015

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

ghost commented Oct 18, 2015

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

@dethe

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Oct 19, 2015

Member

@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.

Member

dethe commented Oct 19, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 19, 2015

@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 commented Oct 19, 2015

@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 ghost referenced this issue Nov 21, 2015

Merged

#898, add shape blocks #1241

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 22, 2015

@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?

ghost commented Nov 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@dethe

dethe Nov 22, 2015

Member

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.

Member

dethe commented Nov 22, 2015

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.

ghost pushed a commit that referenced this issue Nov 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment