Basil.js Team Call Summary

Summary basil.js Team Call, Nov 25th 2016

Timeline and general direction

• Aim is to release basil.js 2.0 in March, to give us time to implement everything and release between university terms. After March also parenting matters would get in the way for some and shrink the team.
• Aim is to offer the funcitonalities of Processing and p5.js but staying totally synchronized with every little function is a low priority; well documented and well working basic functionality is more important
• Processing or p5.js functions that don't make sense or are overly complicated in InDesign do not need to be implemented, like real time functions, 3D functions etc.
• The decision if we align more with Processing, processing.js or p5.js should be made on a case-by-case basis to figure out which way makes most sense for the specific function

Website

• Move the entire page to GitHub pages, site can still be reached on a custom domain
• Create a build process for the webpage, so that changes on the GitHub Repo are automatically reflected on the web page
• Fabian will find a way to set up the page and build the docs
• Give the gallery some love, new projects should be added (there will probably be some projects to present from Timo's class)

Docs

• Docs need updating, at the moment they are really outdated and have lots of errors, typos and inconsistencies
• Reference page should be reworked so that every function has a subpage with images and with example snippets of the various ways to use the specific functions, much like the p5.js reference is structured
• The docs and code of these subpages should not be completely in the source code of basil, we will have a look at p5.js to see, how they solved it.

Bundle

• Remove example scripts from download bundle and offer them as a separate, easy-to-find download
• Move example scripts to a different repo, so the main repo is only concerned with basil.js itself

Production tool

• While basil.js is a great learning tool and sketching tool, it is also used as a production tool, so the aim is to cover InDesign's basic and central functionalities to enable people to stay within the basil.js universe as much as possible. This includes adding
  • masterPage functionalities
  • basil.js wrappers to work with files and folders and something to provide InDesign's getFiles() method

Getting rid of b.

• We will get rid of the b. notation
• Preferrably there is still an option to bind everything under a b. prefix to ease the transition for those that still prefer to use b.
  • Implementation could be similar to jQuery's .noConflict() to have a flag at the top of your script, setting that you want to use b.
• Give downloaders of basil.js 2.0 a prominent hint that basil works without b. by default now and offer a basil.js v1.x download to use with old scripts

Functions

• Make everything a function: change all functions with notation var functionName = function(args) to notation function functionName(args) for consistency and easier linting
• Allow function overrides as it is standard in JavaScript, but give the user a warning when he is overwriting a basil function

b.go(), draw() and setup()

• If technically possible, get rid of b.go(). Fabian will try to do a proof-of-concept demo with a minified basil, if this works, we can implement it
• If technically possible, b.loop should be replaced by draw(). setup() should replace the current draw(), so it works the same way as in Processing and p5.js, have setup() for "static" things and draw() for things that loop. Fabian will try to do a demo.

b.doc()

• Keep b.doc() named b.doc(), but acknowledge that it might have been a mistake to name it like that in the first place. ;)

b.property()

• Add a b.property() function that is a simple basil.js wrapper for the JavaScript's .property notation and additionally allows to use a property name/value pair object to set several properties at once.
• After implementing this basic function we could try to make this more sophisticated, reaching properties on sub-levels however will most likely not be feasible, as there might be several sub-level properties of the same name and other scripts doing recursive property collecting show that performance is really bad

b.transform(), b.imageTransform(), b.graphics(), b.inspect()

• Add a b.transform() function that allows matrix independent transformations of page items via convenient fake properties (width, x, y, rotation etc.) to replace the current b.itemXXX() functions
• This function will work analog to b.typo() and b.property() and can set single properties as string or several properties at once via a property name/value pair object
• Remove b.imageTransform() and instead treat graphics as a true child of their frames. For graphic only operations a b.graphics(container, cb) will be added that works analog to b.words(), b.paragraphs() etc.

b.inspect()

• Improve b.inspect() by making it less buggy and more versatile
  • Add an option to show only the available top-level properties (without their values)
  • Add an option to show methods