Should be able to determine sketch size when it is computed only from constants

[teo1978]

Example code:

static final int WID=400;
static final int HEI=400;


void setup() {
  size(WID,HEI);
}

let alone this:

static final int WID=400;
static final int FACTOR=2;
static final int HEI=400;


void setup() {
  size(WID*FACTOR,HEI);
}

Expected: both should export just fine, since the provided values are constants.

Observed: it issues an error, which I have to remember because it only shows up once (i'll report that as a separate bug), which says more or less:

The size of the sketch cannot be determined from your code. You'll have to edit the html...

[GoToLoop]

• I can't get why "JS Mode" would need to determine canvas' dimensions.
• In my experiments so far, an empty <canvas /> tag would work for any sketch.
• Take a look at my custom "index.html" file in this recent post:
  Cannot get texture() to work: "createTexture is not a function" processing-js/processing-js#177 (comment)
• Canvas was automatically resized to sketch's size(350, 100, P3D);.
• And in this online prototype game, size(GW, GH, JAVA2D); is working alright w/ constants GH & GH:
  http://studio.processingtogether.com/sp/pad/export/ro.9Ql2E8JBC54LJ/latest

[teo1978]

I can't get why "JS Mode" would need to determine canvas' dimensions.

JS Mode uses it not only for the canvas but even for css applied to some of the divs which contain it.
I guess that could and should be avoided.

A sketch exported with regular JS Mode without tweaks, does NOT work if JS mode is unable to determine the size.

[fjenett]

There are no constants in JavaScript.

The message is not an error as the sketch will run fine afterwards. It just informs you that you are doing something unusual.

Both your examples above work fine for me … i don't see what you are reporting.

[teo1978]

The message is not an error as the sketch will run fine afterwards.

Except that you'll see only a portion of the canvas, because it will be wrapped in a div that has 300px max-width, and 100px width. I wouldn't call that "working fine".

If you cannot compute the sketch size (but see below), then I think you should consider rewriting the html and css of the template index.html so that it doesn't need to have the size hard-coded anywhere (except in the canvas, which will be resized dynamically by processing.js so it's fine). That should definitely be possible, and not even that hard, so I think you're being a bit too quick in closing this issue, with all due respect.

There are no constants in JavaScript.

I know that. But there are in Java and when JavaScript Mode runs it has access to the pde source code, doesn't it? I thought it would be possible (not saying it would be easy at all) to resolve the value of the constant.
Anyway, probably the solution above is much simpler.

[fjenett]

The message tells you that you need to take care of proper HTML/CSS yourself if you use variables with size().

It is min-width: 300px; not max-width. The width of the container is needed to float the sketch in the middle of the page. Feel free to adapt the css to work as you expect it to, then test it on all common browsers and systems and send me a PR.

[teo1978]

It is min-width: 300px; not max-width.

Ok, I didn't look at the html/css carefully, but the fact is, it does not adapt if the canvas grows dinamically, and it could - and hence should.

The message tells you that you need to take care of proper HTML/CSS yourself if you use variables with size().

I know, and that shouldn't be needed. That's the issue.

Feel free to adapt the css to work as you expect it to, then test it on all common browsers and systems and send me a PR.

Perhape one day I, or someone else, may do that. Untill then you should leave this bug open, because the issue is not fixed.

[GoToLoop]

There are no constants in JavaScript.

Actually for some couple of years now there is: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const

Of course const isn't some "compile time constant" since JS isn't compilable, but it's close enough.
And even though it's ECMA6, it has been recognizable for many years already across major browsers!

[fjenett]

Thanks for the info but please let's stay focused and do not open up the issues to general discussions …