Possible roadmap additions / feature suggestions

[trych]

Hi there,
as this is getting lively here, I would like to add some ideas for the road map that I collected. I probably forgot a few now, but no harm in adding them later, once I remember them. ;)

(And yes, I know we want to get rid of the b. , but as long as it's still there, I'll use it here ;) )

1. b.collides(object, object) -> Collision detection between two objects. I know there is several levels of collision detection from detection of bounding box collision to collision of more complex shapes to collision of several glyphs. I could imagine that this could be implemented in a simple way in the beginning and then become more complex and advanced over time, if somebody wants to give it a try. Could also work to hold arrays of objects instead of just an object.

2. b.spreadWidth -> to return the spread width, no matter how many pages the spread contains

3. b.interpolateShape(object1, object2, interpolationValue) -> interpolates the path points of a shape or path to a certain value and creates a new interpolated object. I am not sure, how easily objects with a different amount of path points could be interpolated, but maybe this can be done in several steps as well. First allow interpolation of objects with the same amount of path points only, and then later, if somebody wants to tackle it, do a more advanced interpolation. This should allow for extrapolation as well of course.

4. b.beginLog() -> could write all b.print() and b.println() statements that follow to a log_YYYYMMDD_HHMMSS.txt file next to the document. This makes debugging easier for beginners, as they can compare logs to each other and they can also more conveniently send their logs to others for debugging help

5. b.startTimer(timerName), b.takeTime(timerName) -> starts a timer with a certain name and takes the time of this timer. This could be a great learning tool for beginners, as they can learn how changes in their code influence the time that stuff takes. My first steps with basil.js (and with scripting in general) lead to a few scripts that would run for hours or even days. With such a tool this risk could be minimized. ;)

6. generally I think there should be more example scripts and the scripts should be more consistent. I think there should be a sample script for EVERY single method from the reference. As a beginner, I remember, I had to poke around a lot and often thought it would be great to have more sample scripts. I would be willing to have a closer look at this to define what "more consistent" could mean and then to come up with some missing sample scripts. As I am totally new to Github, I think this might be a good place for me to start to learn about the Github workflow.

7. fix that every time a basil.js script is run, the past board becomes overly large. I am not sure, why this is handled in such a way? Is this a feature? Is it there to prevent objects leaving the pasteboard area? All I know it gets really annoying for documents with more than one spread, you can't really navigate them that easily anymore. Could somebody tell me what the purpose of this enlargement of the past board is? :)

8. Generally I have the feeling there could be more "book related" functions (as in: stuff that does not only happen on one page, but continues over several spreads). I believe that since the project was inspired by Processing that this was not the main focus, but as InDesign offers this possibility, we should include some "book related features". Problem is, I remember that I had some ideas about that in the past, but I forgot them all now. So for now, I will keep looking for them and update you, once I remember what I was thinking. ;)

Any thoughts on these ideas?

Thanks!
trych

[ff6347]

Hi @trych here are my 50 cents on this.

(And yes, I know we want to get rid of the b. , but as long as it's still there, I'll use it here ;) )

As suggested by @b-g the removal should be optional for backwards compatibility.

1. b.collides(object, object) -> Collision detection between two objects.(…)

Collision detection is hard. Even checking if a point is inside of a polygon is already cumbersome. Maybe we should think of having a more modular approach to things like this. I would not suggest including this in the core of Basil. It could be more like a plugin/library/extension as Processing does it. something that registers at Basil when it is in a plugin folder and then can be used.

2. b.spreadWidth -> to return the spread width, no matter how many pages the spread contains

I don't get it. Please explain a bit more. Maybe with in example using only the InDesign API.

3. b.interpolateShape(object1, object2, interpolationValue) -> interpolates the path points of a shape or path to a certain value and creates a new interpolated object. (…)

Same as collision. Could be an extension.

4. b.beginLog() -> could write all b.print() and b.println() statements that follow to a log_YYYYMMDD_HHMMSS.txt file next to the document. (…)

Could be nice to have. Something like this should hook into b.println to not have double output.
I already wrote something like this some time ago here

5. b.startTimer(timerName), b.takeTime(timerName) -> starts a timer with a certain name and takes the time of this timer. (…)

Doesn't Basil already take the execution time? I think so.
But I get the idea of having several timers at once. I would suggest not having to register a timer by name. What if you run several timers nested? To stop a timer of let's say 10 active ones would mean looking the one we seek up and stop it to calculate the time. I would rather create a function that has a start and stop function that calculates the time. It could be like this:

function Timer() {
  var started = null;
  var stopped = null;
  this.start = function() {
    started = new Date();
  };
  this.stop = function() {
    stopped = new Date();
    var timetaken = (stopped.getTime() - started.getTime()) / 1000;
    return timetaken;
  };
}

The usage would be like this:

 // the delay function is just for testing
  function delay(prmSec) {
  prmSec *= 1000;
  var eDate = null;
  var eMsec = 0;
  var sDate = new Date();
  var sMsec = sDate.getTime();
  do {
    eDate = new Date();
    eMsec = eDate.getTime();
  } while ((eMsec - sMsec) < prmSec);
}
// usage
var duration = new Timer(); 
duration.start();
delay(1.456);
$.writeln(duration.stop());

(Actually it would be b.timer() // returns new Timer())
My point is if the timer is to complicated the result is distorted.

6. generally I think there should be more example scripts and the scripts should be more consistent. I think there should be a sample script for EVERY single method from the reference. (…)

This would be awesome! I always dreamed of having a working code example within the docs. Like in the Processing or P5.js reference. Please contribute. A rule of thumb should be: "Make the example dead simple". No eye-candy. No external dependencies. What I always loved when learning programming with Processing is the simplicity of the examples in the reference. You can copy & paste into the IDE, hit run and it works.

7. fix that every time a basil.js script is run, the past board becomes overly large. I am not sure, why this is handled in such a way? Is this a feature? Is it there to prevent objects leaving the pasteboard area? (…)

Can you boil this down. Maybe with an example? I took a look at some of the provided examples but there seems to be no issue with them in CC2015. Maybe it's a CS6 thing. One problem with the pasteboard in InDesign is: If something goes out of the pasteboard it can destroy the whole document.

8. Generally I have the feeling there could be more "book related" functions (as in: stuff that does not only happen on one page, but continues over several spreads).(…)

Please provide some examples and ideas.

[trych]

Hi @fabiantheblind, thanks for your comments!

1)

Collision detection is hard. Even checking if a point is inside of a polygon is already cumbersome. Maybe we should think of having a more modular approach to things like this. (…)

Personally I am against making this a "module", as basil.js is already some sort of "module" itself for InDesign, I think it becomes cluttered, when there are submodules for different things. For the target audience "designers that are not great at programming" I think this will be confusing.
About the collision detection itself: Yes, I guess doing proper collision detection is hard.
How about either starting of simple then, with just a detection for bounding box collision or alternatively look into using pathfinder operations on duplicates of the objects to detect collisions? I think collision detection is tremendously helpful for a lot of cool things and it is not very beginner friendly, so it would be great for our beginners to help them out with a custom method for it.

2)

Please explain a bit more.

Well, similar to b.width returning the width of the page, b.spreadWidth would return the width of the entire spread (which could contain several pages of different sizes, so it's nice to have a quick way to retrieve the spread's width).

3)

Same as collision. Could be an extension.

Again, I think extensions will clutter stuff and be confusing. I think interpolation of objects with the same number of path points should technically be trivial, or shouldn't it? (Correct me, if I'm wrong). I can imagine the other type of interpolation (different amount of path points) to be very difficult, however, I have absolutely no idea. Does somebody know anything about this? The method could only provide the first type of interpolation then. Again, I think this could be very useful and be it only for positioning a new copy of two identical shapes at a certain point between them.

4)

I already wrote something like this some time ago here

Cool, will have a closer look at your example then, and yes, exactly it should hook into b.println()

5)

I would rather create a function that has a start and stop function that calculates the time. It could be like this: (…)

Your example looks like a much cleaner implementation to me. This would allow for interlaced timers (start duration1, start duration 2, take time of duration1 , take time of duration2), right?
5a) Also a sidenote: The execution timer that is included switches to some sort of exponent notation for very long running scripts that is not very nicely human readable. It would be nice, if it automatically switches to minutes, hours, days if necessary.

6)

This would be awesome! I always dreamed of having a working code example within the docs. Like in the Processing or P5.js reference. Please contribute.

Cool, will look into this and contribute. I would first like to work on improving the included example scripts and adding new ones where they are missing. If this will be also included in the docs eventually, I guess we should have a more general discussion and about this, to agree on how exactly that happens. I agree to keep it very simple. As I said already, this will be probably the first thing I want to work on, just to get used to the Github workflow, which is new to me.

7)

Can you boil this down. Maybe with an example?

Okay, this is strange. Now I have set up the "bundle" as the clone of the Github repository, instead of the download bundle and now the "bug" does not happen anymore. Maybe it was fixed in the master branch already? Will probably switch back temporarily to the download bundle later to figure out, what's going on. Or is there a way to automatically generate a download bundle from the current master branch.

8)

Please provide some examples and ideas.

Yes, will provide examples, as soon as I remember stuff.

[ff6347]

would be great to hear from the rest of the team as well.

[ffd8]

Hello @trych + @fabiantheblind ! Sorry for the lag.. busy the past week, but happy to share the following comments (referring to #'s so quoted text doesn't get too long):

_1 [re: collision detection]

I would also try to avoid modules, so that one simply can do everything when loading the script. I could imagine a basic boolean function for this, 'b.collide(obj1, obj2)' – it automatically grabs and checks the bounds of the objects. One can loop through objects on page if they want separately. For the latest HOLO 2 stream, I implemented a multi vector collision detection that was based on one similar for processing. I attach short snippet of code here that might be useful.. it was made for comparing two vectors (with 3 values), but could surely be extended for handling the b.bounds of an object:

// input awaits two vector based shapes like:
var tempBox = [c[0], c[1], gSize];

// then i cycled through all other shapes like so:
var overlap = false;
  forEach(boxes, function(bx){ // bx was array of other already created boxes
      if (checkMultiRect(tempBox, bx, bigBuffer)) {
        overlap = true;
        triesCounter++;
      }
   });

function checkMultiRect(c, r, buff) {
  var left = c[0];
  var right = c[0]+c[2]+buff;
  var top = c[1];
  var bottom = c[1]+c[2]+buff;
  var otherLeft = r[0];
  var otherRight = r[0]+r[2]+buff;
  var otherTop = r[1];
  var otherBottom = r[1]+r[2]+buff;
  return !(left > otherRight || right < otherLeft || top > otherBottom || bottom < otherTop && (bottom < gridY || right < gridX ) );
}

... there's quite a bit more code involved for my usage, but maybe that bottom function inspires a solution?

_2 [re: 3+ page spreadWidth]

Yeah- it would definitely be useful to rework b.width to account for a spread of more than two pages. At the moment, one can use b.canvasMode(b.FACING_PAGES) to get b.width to measure the whole spread.. but just did a test and it failed to recognize a 3 or 4 page spread.

_3 [re: interpolation of poly points]

Could be a fun feature- makes me think of what one would do in Illustrator when choosing to 'blend'. No idea how it could be done, but I'd have a look at the sample script from Adobe 'AddPoints.jsx' for inspiration and guidance.

_4 [re: println log file]

Could be useful indeed for beginners, however I'd suggest the log file function generate one file in the folder of the project, then simply add a timestamped output to the top of document.. that way just one file to keep track of.

_5 [re: timers]

I don't quite understand the purpose of this when one can just create variables that are based on grabbing millis() at one time then comparing them later in the script.. but why not.

_6 [re: basic examples in reference]

As much as that would kill workshop security ;) it's a great idea and long overdue. The tutorials offer a walk through via topics, but our reference is really dry if you don't already have a slight idea of what you're doing. Processing style examples that use as little additional code as possible to work would be great... just requires lots of work!

_7 [re: github vs website download]

Sorry about that.. that's simply due to the version sitting on the basiljs.ch website right now not the latest we have on GitHub. The last update came in the middle of a workshop, so it was dangerous to just switch over.. but will update ASAP. That's an interesting idea.. as much as it annoys me to have Processing ping home and inform me every time a newer version is available, it can be useful for staying up to date and could be done from the script and simply dropped into the console as a 'friendly reminder'.. but could also make folks wonder why the script wants to phone home.

_8 [re: book specific functions]

We're all ears for those specific InDesign/book/multi-page features that are missing. Indeed the project started in the spirit of Processing to make the teaching/transition from one to another as easily flowing as possible, but of course there's also many many features of InDesign that simply don't exist for Processing. We only use InDesign to a certain extent and tried consulting some heavy users in the beginning for tips (ie. dealing nicely with footnotes)– but didn't come up with too many things that could be isolated to a function rather than a more involved script. Please do share, drop a feature request for any ideas you have.

Cheers!
Ted

[trych]

Hi @ffd8, thanks for the input!

_1 [re: collision detection]

Yes, on first inspection this looks like what I have on mind for the "similar" version of the collision, so it can detect bounding box collision. Will look further into this.

_2 [re: 3+ page spreadWidth]

Ok, I was not aware at all that the current implementation of b.width returns the spread width in some cases. I actually think this is inconsistent and we should split this up into b.width for page width only and b.spreadWidth for spread width.

_3 [re: interpolation of poly points]

Will have a look at this. I realized that the proposed function would be very similar to the current b.lerpColor(c1, c2, amt) method, as this method also works only with the same color spaces, so I see no reason to not have a b.lerpShape(s1, s2, amt) function that requires two objects with the same amount of anchor points as input.

_4 [re: println log file]

Yes, good idea to write it all to the same file.

_5 [re: timers]

Sure, it could also be done manually, but I think it is easier and more convenient if there is a dedicated method for it. So with @fabiantheblind's suggestion that would be similar to the hashList object, right? (In the sense that it has "sub"-methods b.Timer.start() and b.Timer.stop()).

_6 [re: basic examples in reference]

I think by now we are talking about two different things here: The example scripts that I was referring to in the beginning and the example code snippets that should go into the reference.
I totally agree and think that it's a good idea that there are super simple snippets directly in the reference that could be directly copied into the IDE. Would be happy to contribute to that, too. I guess we need further discussion about how to do this and I suggest we open a new dedicated issue about these snippets.
However, I still think that the example scripts that come with the basil.js bundle are super important, too, because they show the basil.js functions in the context of a script.
Take for example once again the b.lerpColor(c1, c2, amt) function: As a snippet it would maybe show that from a blue color and a red color input you can retrieve a purple color. That would be the snippet for the reference. But the example scripts could show more the potential of this function that might not be obvious to the beginner. The example script lerpColor.jsxshows that if you loop the function you can create some sort of rainbow gradient consisting of serveral steps. Therefor I think these scripts are important and should also stay. They should not be as dead simple as the snippets, but still be simple and give an example how the function could be used in a real world scenario and be commented for beginners.
So, tldr: We have two things, snippets for the reference that we should create a separate issue about and the example scripts that I still want to work on to make them more consistent and helpful.

_7 [re: github vs website download]

I actually don't think it is very important to automate this as it does not affect the end user. As long as the latest release is what you get when you download it should all be fine.

_8 [re: book specific functions]

Cool, as I said, will report as soon as I remember something. Will revisit some old scripts for ideas. But maybe you're right and the ideas I had in mind were more for dedicated, longer scripts. Will figure that out.

[ff6347]

I created some Issues for those topics. Left out the version topic* and the book topic.

* If the script makes a phone call home it should be clearly communicated to the user. Having this on every run would not be good but it would be nice to know who if Basil gets used. On the other hand it is the NSA approach. :-) But something like: b.checkForUpdates() could be nice.

[trych]

Cool, I would suggest to split up #56 into two issues, one about the example scripts and one about the snippets/the reworking of docs. Could you maybe just rename #56 to something like "Improving docs / adding snippets", then I could create the other one?

[ff6347]

Could you maybe just rename #56 to something like "Improving docs / adding snippets", then I could create the other one?

Done

[ff6347]

I think this discussion can be closed. It spawned some new feature requests and all that