Adding stop and full screen buttons

[sfederici]

The fact that the project starts immediately after translation and there is no stop button is kind of annoying when using Leopard during lessons with students. Can a stop button be added?

Also a full screen button could be nice. Now I first press the button to move the stage to a new tab and then use the magnification features of the browser, but, again, doing it during the lessons is now ideal.

[towerofnix]

Yeah, the "player" that the Leopard website generates and provides for running a project is really bare bones. I think we'd like to support both of these.

The "stop" button can't be added yet because we don't support the "stop all" block, which the button would presumably make use of. See #124. Then again, I don't know how restarts are currently handled (i.e. clicking the green flag again)... @adroitwhiz mentioned having an idea about throwing an exception to cancel at any point, but that was a year and a half ago, so not sure if the details are still clear on that.

The "full screen" button I'm not too sure about blockers for — obviously it means rendering the stage at a higher resolution (if you don't want vector graphics to look super grainy), without actually changing the stage's internal dimensions (the space is still 480x360 units, only rendered higher). See #26 for discussion here.

More practically, what are the contexts where we expect the fullscreen button to be used? I imagine most students/users are coding using Code Sandbox, so their project is already "framed" inside one quarter or so of that IDE, and the fullscreen button would make it huge while they're presenting it, not editing it. I think a full screen button is perfect for them.

For people who are editing at the same time as viewing, and just want a bigger stage, "full screen" is pretty much useless. Unless they happen to have a second monitor! I think for them a "fit stage to window" mode would be the most useful. This is kind of like Scratch's own fullscreen mode, in that it doesn't literally take your browser fullscreen, but it does cause the stage to use as much space as is available. In Leopard that doesn't take you out of editing, because editing space (Code Sandbox, or a text editor) is altogether outside of the "window" that Leopard is framed within.

Right now we don't change stage scaling at all and I wonder what the reasoning is behind that, really. But I do want to avoid just changing the default (i.e. making it "fit stage to window" instead of "don't scale stage") without considering the impact that it'll have on everyone working with Leopard.

I'm also not super familiar with Code Sandbox, but I would assume it works by reloading the preview window every time you make (or view) a change? If this is the case, it's important to note that making any edit will probably kick the user out of fullscreen mode, because pages can't start in fullscreen (entering fullscreen has to be a response to a user interaction). It wouldn't prevent "fit stage to window" from working [even in another tab... even if that tab is in fullscreen!], but we would have to make sure that state (if it's a user-selected choice) is preserved across page reloads, so the user doesn't have to click "best fit please" every time they make a change to their code.

[PullJosh]

One of the things I've been playing around with in my free time is a dedicated Leopard code editor that meshes together the conventions of JavaScript editing with the conventions of Scratch. This feels like a feature that lives right at that boundary, so I'm wondering if some combination of...

• Features in the Leopard library that make it easier to resize your canvas and/or make it fill the full width of the viewport AND
• A full screen feature in the Leopard code editor that makes it easy to change your viewport size

...would give the best experience?

[towerofnix]

Putting these together would be awesome! (I realized we totally missed your introduction for the Leopard code editor by not watching the leopard-website repository. Excited to read about that!)

I do think that in the interim, once the library has basic canvas resizing support, there's very little harm to adding a button ala "Start" in the barebones view we have right now. That can be pulled out and into a nicer user interface when the integrated code editor is ready, of course.

[PullJosh]

Love it. How pragmatic of y'all. We can update the current template to have more features (maybe a "stop" button as well, once we add that). And if/when there's a dedicated editor, we can have the generated code integrate nicely with that.

[adroitwhiz]

once the library has basic canvas resizing support

To be clear, canvas resizing is already fully implemented.

[towerofnix]

@adroitwhiz Does this include support for rendering the stage at an arbitrary level of scaling? I.e. will a 480x360-Scratch-units stage render vector sprites just as crisply on a canvas that is 576x432? This is the canvas resizing I'm concerned with, and I wasn't sure if it's supported as the render target appears to be frozen in dimensions by the renderer.

edit before posting: Yup, nevermind, we're all good for sure! I was confused because there's never a getBoundingClientRect or similar done on this.renderTarget, but this.stage is in fact the canvas in question. Good to know, thanks.

[towerofnix]

I've branched out conversation on specific user-interface details into #193.