FIX: Add a hard coded width bound to canvas rendered as widgets

[MridulS]

Fixes #169 (a hack-y one).

After some researching around about bouding canvases out of py3js it seems like this is the easiest
way of fixing the overflow problem of the canvas. A better solution would be to expose max_width from
py3js but I guess this is a minimal invasive change.

This does hard code the 80% width value but I guess we can expose that upstream to be user controllable
if the need arises.

[MridulS]

The failure seems unrelated. I can't restart the runner.

[nvaytet]

The failure seems unrelated. I can't restart the runner.

I now gave you the correct permissions, and restarted the build as well ;-)

Edit: it seems the failure is consistent. I'm wondering if our CI setup is broken for PRs from forks?? I'll investigate.

[MridulS]

Edit: it seems the failure is consistent. I'm wondering if our CI setup is broken for PRs from forks?? I'll investigate.

Yup, it is indeed. Seems like an issue people run in actions/checkout#551

[nvaytet]

I wonder if this would also remove the need for having e.g. figsize=(550, 400) in the docs, which (I think?) were there to prevent the figure from being too wide so as to not partially/totally hide the toolbar buttons? See for example here.

Edit: it seems to help indeed. I think we can remove most or all of the figsize=(...) for the 3d plots in the docs?

[nvaytet]

I think the same fix could also apply to 2d figures, when using the %matplotlib widget backend, in the (rare) case where you would make a very wide figure. I think it would also hide the toolbar buttons without it? Adding it here should work?

[MridulS]

@nvaytet updated for 2d canvas and removed the use of figsize in 3d examples.

[nvaytet]

Needs #320 for builds to pass