p5.js compatibility wrappers

[ffd8]

I'd like to wake up issue #252 – which discussed push() and pop(), in relation of how to make basil.js as compatible as possible with p5.js. The more I use p5.js, the more I find little nooks and crannies that are missing. Last fall I had students complain about how slow/etc it was to code purely in basil.js/inDesign and we found p5.js to be a great sandbox environment allowing code to quickly be copy + pasted + tweaked to basil.js (bummer ES6 isn't implemented). For that reason, I realize lots of little things that could be added/modified to make it that much smoother. Nevertheless I think we need a consensus about where these functions should sit and how their documentation should work. For speed of implementing this, I suggest we avoid new functions (ie. pushStyle()- unless time/interest allows), but put a priority on code compatibility that avoids error messages of non-existing functions = just mirrors/wrappers.

DOCUMENTATION (wrapper functions)

• own description (clear when reading docs, but tricky if alpha-order doesn't keep side-by-side)
• implemented but no documentation (confusing when appearing in code examples)
• separate section called 'p5.js wrappers or compatibility' where they are listed and link to the main function
• ______________

SRC (where do these wrappers go?)

• right next to the function it's wrapping
• new src doc called wrappers/compatibility (within that, /* SECTION HEADERS of src pages */ )
• ______________

EXAMPLE (wrappers)

• createCanvas() » size()
• frameCount » new global frameCount = 1
• textAlign() » needs same constants linked to TOP, BOTTOM, LEFT, CENTER, RIGHT
• textSize » needs to allow 0 and not break.. could use abs() and <= 0 becomes .1
• text() » work with just 3 params.. text(txt, x, y) (use width, height as default size)
• circle() + square() + ellipse(x, y, w) <- ellipse with just 3 params = circle
• color()/fill()/stroke() » allow a 2nd or 4th value for opacity = probably not so easy to implement...
• textToPoints() » had based function name on Processing's Geomerative, but p5.js style makes more sense now
• ...

Of course the list can slowly be implemented after a 2.0 release, but it would be nice to launch w/ main ones that would trip up beginners. Please feel free to add to the list and once we decide how/where to put them and documentation style, I'd get started.

Re: neverending launch of 2.0, this adds a decent reason for further delay... I'd aim for start of new year, or anniversary of 1.0 = Feb and schedule how to make that happen?

[ff6347]

Hey @ffd8 Sorry for not reacting in short time. Since you and @trych are the ones using Basil the most I would leave this decision to you guys how to proceed with this. I will finish the site I new Promise(()=>{setTimeout(()=>{}, n)})! (As you can see the promise does not reject ;-))

[trych]

Hi there,
sorry I didn't get back to that either. I think I have a very good solution for the issue, it just takes a bit longer to explain. I will try to post my idea later today (or if not, later this week).

[trych]

Ok, now that I have managed to create the plugins branch and made a post about it, I am now ready to answer the points raised here.

So basically my suggestion would be to use sane defaults for basil itself (for example make a decision for each conflicting function name if it is best to go with the Processing, the p5.js or our own basil.js way).

Since this would still leave some conflicts unresolved (some stuff does not work as in p5.js, some stuff does not work as in Processing, some stuff does not work as either of them), I would solve all these remaining conflicts by creating a p5.js and a Processing plugin for basil.js that each mimick the functionality of each of these two packages respectively.

This would allow for the greatest flexibility and we could circumvent arguments like "Yeah, but then it doesn't work like Processing at all anymore" by just suggesting, "Well, if you need it to work like Processing, just install the Processing plugin".

This also means I would leave all wrappers (and their documentation) out of the main basil.js source code entirely and only have these wrappers in the plugins themselves (as this is where they belong then).

This way, if someone teaches a class and it becomes obvious that the p5.js way would be the best, the entire class could just install the p5.js plugin, which is as simple as placing the plugin folder next to the basil.js file.

I hope this makes sense and seems like a good way to move forward.

We still need to decide on the best defaults for basil (and in this regard I also lean a bit towards the p5.js way of things), but we don't need to make a decision that excludes any other way of doing things, thanks to the plugins.

If you guys agree on this plugin suggestion, we could move ahead and then use this thread to start listing all basil functions that need some decision and then try to agree on these basil defaults.

What are your thoughts? 😎

@ffd8 @fabianmoronzirfas @b-g

[ff6347]

Great idea. It saves us a lot of discussion.
Also 👏 👏 👏 👏 👏 👏 here.

I'm with you on this.

[ffd8]

Hey hey this is awesome! Part of me would prefer the p5.js + Processing bits to be embedded within the main basil.js code (since it's based upon them) – nevertheless, this helps reduce the issue of either undocumented wrappers or stuffed references with both ways of doing something. Curious if/how our new fancy references page could deal with the plugins, or if they are somehow self-contained with good docs? But really nice idea and thanks for the initiative! Will check out branch asap. + Moving additional comments to #337

[b-g]

Hi all, Great idea! I have nothing new to add to the conversation. Good luck!