Scratch-blocks: Issues with showing and hiding flyout

[cdeng-amplify]

I tried to use flyout.hide() function to hide the flyout and flyout.show() to show to populate it with a new set of blocks. When the flyout is hidden, I can drag the blocks in the workspace to where the flyout was suppose to be, then the blocks gets deleted because those blocks are deemed to be dropped on top of the flyout. There seems to be a bug where the workspace doesn't know that the flyout isn't there anymore. Additionally, using flyout.show() doesn't work as expected. workspace.updateToolbox() works but then if the flyout is hidden, it doesn't reshow it. Is this a known issue or that isn't supported in the current version of the library.

[Tymewalk]

Just confirmed on the vertical playground, Firefox 50.1.0, Ubuntu 16.04.

Maybe we should add a check to not discard blocks dragged into that area if the flyout is hidden?

[rachel-fenichel]

I don't believe hiding and showing the flyout is supported on scratch-blocks.

[Tymewalk]

@rachel-fenichel It can be done through entering workspace.toolbox_.flyout_.hide() and workspace.toolbox_.flyout_.show() into the JS console.

Do we intend to support that in Scratch 3.0?

[rachel-fenichel]

I understand that the code to do it still exists, but that involves using two private objects (the underscore at the end of a variable or function name means that it is intended to be private, as does the @private annotation). That code is used internally. That being said, I don't think scratch-blocks supports the developer choosing to hide the flyout.

Scratch 3.0 and scratch-blocks may do different things here, but I would not expect Scratch 3.0 to ever use that functionality either.

[Tymewalk]

@rachel-fenichel Ah, OK.

In that case I see no reason this is a problem.

[cdeng-amplify]

Thanks for the clarification. I will let my product manager know and discuss a plan of action. We will likely add that the feature to hide and show the flyout on demand and fix any issues related to it on our end.

[thisandagain]

We recommend that the blocks be visible at all times. Because of this, we removed the ability to hide the flyout in Scratch Blocks. You can of course add this back in your implementation, but I'd recommend that you test both paths with kids. One of the things that we observe in children is that having options (in this case – the blocks) in front of them during the act of creation leads to discovery and creative applications that can be somewhat inhibited when those options are hidden from view.

[MichaelZawadzki]

For us its not about hiding/showing dynamically within one activity... but about having initial activities that simply introduce kids to a working example of a set of blocks. Then, as students progress to subsequent activities, we'd like to then enable the toolbar with blocks in them for students to use and to augment the existing ones. Just wanted to clarify the specific use case.

We'd like to avoid destroying/recreating the workspace throughout the flow, and would prefer to "hide/show" the toolbox.

[thisandagain]

@MichaelZawadzki Thanks for clarifying! That's interesting and fits well with some of the "microworld" concepts we have been exploring. I'll discuss this with the team ... it can be a little hard for us to know where to draw the lines with the APIs so this feedback is very helpful.