Use URL parameters to determine which parts of the editor to show

[schanzer]

In the covid-19 world, online instruction is going to be a LOT more important than it used to be. WeScheme has long supported a set of parameters that allow it to be embedded in web pages, lesson plans, and even Google Slides (via Peardeck).

It is becoming immensely clear that this functionality is a game-changer for running a distance-learning class or PD.

Being able to pull up a slide with content and instructions, and having an embedded IDE right there for teachers to try it...is just amazing. It also cuts down on one of the most common headaches of in-person PD: "wait, which tab should I be looking at? I accidentally closed it, how do I get it back?"

To be clear, I can already embed CPO in Google Slides. But it's incredibly useful to give teachers and students just a REPL, with definitions loaded in a place they can't see, and the entire toolbar and footer hidden.

WeScheme supports the following embedding parameters:

1. hideDefinitions - a boolean, which just toggles display: none
2. hideInteractions - a boolean, which just toggles display: none
3. hideToolbar - a boolean, which just toggles display: none
4. hideFooter - a boolean, which just toggles display: none
5. definitionsText - a string, which populates the definitions area
6. interactionsText - a string, which is inserted at a fresh prompt in the interactions area
7. autoRun - a boolean, which determines whether or not to simulate "run" being clicked as soon as the page loads

We don't need all of these in CPO, to be sure. But being able to at least hide everything except the REPL would be extremely valuable. So would autoRun.

[jpolitz]

This is a super reasonable ask. I suspect we could get this (or the most important one or two) in place for the summer.

Are they #params or ?params in WeScheme? Do you think it matters which one? CPO tends towards #params.

[schanzer]

As long as they can be specified in the URL, we’re good.

[blerner]

Just recording comments from the conversation: Items 1-4 are definitely fine; items 5 and 6 are trickier to engineer, but in principle are fine. But we agreed that autoRun was unlikely, because it could easily lead to security issues if you click on a link while you're already logged in.

[blerner]

We also mentioned that once this infrastructure is in place, it would be good to have a UI mechanism to toggle definitions-only/definitions+interactions/interactions-only views.

[schanzer]

hideDefinitions was added today, and we already know autoRun isn't happening. Let's close this and see if a legitimate need arises for anything else.

[shriram]

FYI, I don't see how to compose these if they are # params. Would I write

<iframe src="https://code.pyret.org/editor#hideDefinitions#hideToolbar#hideFooter" width="800" height="400" title="Embedded Pyret Editor"></iframe>

? I'm not sure that is even well-formed, whereas

<iframe src="https://code.pyret.org/editor?hideDefinitions=true&hideToolbar=true&hideFooter=true" width="800" height="400" title="Embedded Pyret Editor"></iframe>

is clearly fine.

Also, it's nice that we now have hideDefinitions, but it would be really nice to also have hideToolbar and hideFooter: for small embeddings, the toolbar and footer are a substantial fraction of the space and also very visually noisy. This becomes pretty problematic when embedding several of these in a page (which, BTW, we're very likely about to do in PAPL, so this is not at all a hypothetical).

(Yes, hideToolbar takes away the Stop button, which may be a bit problematic for runaway expressions in the REPL. Not sure what to do about that, since much of the rest of the toolbar is useless for REPL-only anyway.)

[shriram]

Note to readers: the current state of this is that communication is by # parameter and only hideDefinitions is implemented, but it does mean you can write

<iframe src="https://code.pyret.org/editor#hideDefinitions" title="Embedded Pyret Editor"></iframe>

and it'll work!

[jpolitz]

You can join params with &, so, e.g.

https://code.pyret.org/editor#warnOnExit=false&hideDefinitions=true

On Fri, May 29, 2020 at 5:34 AM, Shriram Krishnamurthi < notifications@github.com > wrote:

Note to readers: the current state of this is that communication is by # parameter and only hideDefinitions is implemented, but it does mean you can write

and it'll work!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/code.pyret.org/issues/327#issuecomment-635947904 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IUZPPDQBDIBPVDJ74JTRT6TVNANCNFSM4MPU55NA ).

[jpolitz]

These also compose with share links, so you can do:

https://code.pyret.org/editor#share=1qdtx-SgZUziqFhgP4bWq55PXA-amyBww&v=ebd213d&warnOnExit=false

On Fri, May 29, 2020 at 9:37 AM, Joe Gibbs Politz < joe.politz@gmail.com > wrote:

You can join params with &, so, e.g.

https:/ / code. pyret. org/ editor#warnOnExit=false&hideDefinitions=true ( https://code.pyret.org/editor#warnOnExit=false&hideDefinitions=true )

On Fri, May 29, 2020 at 5:34 AM, Shriram Krishnamurthi < notifications@ github. com ( notifications@github.com ) > wrote:

Note to readers: the current state of this is that communication is by # parameter and only hideDefinitions is implemented, but it does mean you can write

and it'll work!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/code.pyret.org/issues/327#issuecomment-635947904 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IUZPPDQBDIBPVDJ74JTRT6TVNANCNFSM4MPU55NA ).

[jpolitz]

Going to close this for now, and we can re-open with something more specific/extended if needed.