just use this:
Or this:
No need for users to use the EXTENSION block explicitly.
What scisnap should do, is load the extension in every block that uses the extension blocks, so that if soneone shares a single block, people will still be able to use it just by running the block.
Alternatively, the EXTENSION block knows what all the extensions are; it could just automatically load the needed extension instead of erroring.
And while we're tweaking things, ^N should change the logo back to the one. :~)
Which would also mean that scisnap would have to not override the function that creates the snap logo (which could be solved with a function that takes in an image url to load the snap logo, instead of having it be explicitly set inside a function, or scisnap adding in a logo restore function).
Or at least save the old one somewhere.
I wonder if Jens has thought about this. He never stops bugging me about the bignum library clobbering the arithmetic operations, and sure enough, ^N doesn't restore those either.
What do you think about a set-unloader option in the EXTENSIONS block that would take a procedure as input (probably a library-specific EXTENSIONS option) and save it so that it gets called on ^N? It'd also have to make sure that Unused Blocks doesn't consider the unloader unused (and if we really want to be fancy, if you remove the last block of a library, with Unused Blocks or otherwise, it could run the unloader).
OTOH, if I propose that, I bet Jens just gets mad and deletes the bignums library. (But not the SciSnap! one. :~/)
Honestly, I think that's a good idea. I've also just thought of a way to add to the extension system to make it more organized and add stuff for unload scripts, however this is probably not the best place to talk about it (when I get around to typing it all up, I might create a proposal on github explaining how it would work, as well as it working with the current extension system. I would also not mind if jens doesn't like my idea).
Why?
There is no reason to undo such a massive, stateful library loading. Why risk problems and inconsistencies caused by library remnants? It should be a one-way road. If you are done with the library, just reload the page.
Without a major redesign of Snap, undoing the changes made by the native JS is extremely unreliable and effectively pointless.
I beg to differ. Creating a mew project is supposed to be creating a new project. You don't want to create a new project and run into issues because you loaded the bignums library at some point in the current session. Also snap would not need a major redesign to do all this, instead, if snap adds the ability to unload extensions, as well as allowing a cleanup script for unloading functions, that would make the extension creators responsible for restoring what they changed, not snap.
If anything, I feel like loading a mew project should be equivalent to reloading the page.
Also, the point of unloading scisnap, is that it's a massive stateful library that people probably don't want remnants when loading a new project in the current session. I know for a fact that I tend to have one tab for snap, and just load multiple projects in the same session, without reloading.
The whole point of the bignum library is to override existing procedures. This is a case corner, not really applicable to regular libraries.
The other cases are big libraries, substantially modifying the internals and UI of the Snap. They are really a mods.
I don't understand - is reloading a page to get a fresh copy of the Snap that big deal (data is served from cache)?
It's a matter of personal preference, but I work with Snap open on many tabs. After saving a shared project, I reload the page to check if changes are stored.
I've found myself deliberately loading a new project to already augmented Snap, but for regular use, it may be a good idea.
Certainly the easiest...
No, but snap should still at least try to let extensions restore what they changed.
That's the reason why you would run into issues with it when you load a new project in the same session you loaded bignums in. Not every project knows how to handle bignum fractions.
Which is also the reason why they would need a cleanup script for those libraries to restore what they modified (such as scisnap restoring the snap logo when loading a new project).
That's fine for us grownups. But I wouldn't expect a kid taking their first CS class to have deep thoughts about how Snap! is or isn't stateful.
Your approach would be more plausible if we just didn't have a ^N feature at all! Then it wouldn't matter what libraries left behind. But one of the implicit ideas behind the UI is that Snap! is an editor, and it does all the ^N, ^O, ^S things that people expect of editors.
At the moment I have six Snap! instances open, and I still managed to discover that ^N after SciSnap! doesn't restore the logo. :~/
^N, means "New project"? Chrome@Win10 opens a new browser window.
If I understand correctly, you want the effect of the window.location.reload()
, but achieved in a twisted and potentially expensive way.
Pressing ctrl (cmd) + N is supposed to create a new project, but it looks like it doesn't work...
Yeah, on the Mac we can use CTRL for Snap!-specific hotkeys because MacOS uses Command. On systems with lesser character sets, Snap! tries to take over the CTRL hotkeys, but whether it succeeds or not depends on the OS, the browser, and the phase of the moon.
But anyway the problem still arises if you choose New project from the menu.
For me, C-N opens a new window and a new Snap! project. I still use it though. :/
Actually, I looked in the code, and it doesn't look like it tries to take control over them. I should see event.preventdefault()
somewhere, however it doesn't look like that is anywhere. I'm not sure why ctrl + s doesn't save the page, even though it probably should.
Okay, I'm wrong. But it does put hotkeys in the File menu, which is what I meant.