When there's a quiet moment 
could I ask for a disable blocks feature (like Blockly has) please?
It would save having to extract blocks/swapping them in an and out and leaving them hanging around while developing stuff
can you explain a little bit more in detail what exactly you'd like to disable? tnx
In Blockly you can do this - just right-click on a block to disable / enable it
If the block is a C-shape - then all blocks within it are disabled automatically as well
is it the same as commenting out?
Yes - exactly that
There is a similar feature on AppInventor as well. Blocks can be disabled and they do not get executed in the sequence. It is a very helpful feature for debugging.
Pulling blocks out of a group with extract is very error prone. Long c-blocks make it hard to figure out at what point the extracted sequence was located.
hmm..... I'm not convinced, because you still need to click on every script to change its state, same as exctracting a block and placing it besides the script. Also, it would introduce state to blocks, i.e. yet another color / scheme, increasing cognitive load and introducing yet more aspects a teacher needs to check when a kid comes to them saying "my project doesn't work".
Plus, you can make your own C-shaped "ignore" block and simply wrap it around the parts of a script you wish to disable.
The is a huge difference bw disabling a block in place and inserting an ignore c-block to wrap other blocks. The point of disable is that the block structure is not affected, only the execution selection of certain selected blocks. The key point is that one does not mess with the order of blocks.
All I can say it that its quicker to right-click and then select disable / enable than extracting and re-inserting
Less prone to error and more easily corrected than extracting
And doesn't leave blocks hanging around making the place look untidy!
I find it quite useful in Blockly and have wanted this for sometime in Snap!
Not sure that it would be a big issue in a class but obviously depends upon the class
As to the point about new state and colors etc, and hardship for the teacher: it is easier to read a script with disabled blocks in place but greyed out. Because the logic still can be followed. When blocks are removed and placed aside, the code is no longer the same and logic flow has changed. So a teacher could much easily follow a potential change if blocks in place were greyed out than removed and placed aside.
There is also a huge exploratory aspect to the whole idea: when playing with a new script from someone else, one can simply change a block to disable / ignore mode, and see how it affects the result.
Being able to do it without removing blocks / inserting blocks and affecting the flow is very helpful in the discovery process .
Hi everybody,
I don't think this proposal is bad... but I have some comments:
- I want to think a little more in some cases (continuations, recursion, editing a custom block...) but I think it has no problem, because the "execution effect" must be the same than "extract" those blocks.
- I think the "color mark" is not possible... because the new category features. A new color can not have a semantic meaning now. A possible solution is doing the same we can do now: a c-shaped comment block (that does nothing). And yes, following your proposal, adding the possibility to change to that commented block (or stack) with some extra options (not dragging). It would be similar to the "relabel" feature to comment/uncomment.
- And a last comment. I think blockly (or some blockly implementations) us this to mark (as disable blocks) with all the blocks that are not compiled. And so, all the blocks into the scripting area that are not under a "compilable" stack, are marked as disable. But here is different, because our dynamic environment.
A disable block does nothing... but all the other blocks are clickable and can do its task whenever we want. So for me, other reason to make this feature (if it is implemented) in a different way (not coloring). Something more explicit.
Joan
dunno about the benefits, really. Disabling only makes sense for statements (command blocks) and not for expressions (reporters), because you'll want to return a constant instead. So, this feature would emphasize imperative computing even more.
I agree about the emphasis on sequential programming.
It would be nice if the feature of dragging a C-shaped block into a gold halo to capture the rest of the script had a way to select less than the rest of the script; that would make your DISABLE block easier to use. It's not a huge problem because it's easy enough to pull part of the script back out of the C-shaped block, so it's not high on my list, but it'd be nice.
Hi, Joan!
What about "dark fading", instead? No new colors, just darkened/faded ones, if a portion of code is disabled?
It would be very useful in my recent project to disable portion of code (that doesn't do what my intention was).
See a mock-up in the image below.
How would this work with people who use fully transparent blocks?
If a user has set the appearance of code to a fully transparent one, only the disabled portions of the code would be less-than-fully transparent and in a darker shade, I mean, obviously, in a less darker shade because you can't get darker than black :~)
I think colors are the least of your worries. How is the user going to set this up? Select a reporter to disable, and then select some piece of it as its replacement? What if the replacement isn't a piece of it, but rather a constant value? As Jens said early in this discussion, the idea is much more applicable to commands than to reporters.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.