More robust, complete design for block shapes and v/h space automation

[pikurasa]

A few people who have seen MB have asked whether or not v and h spaces are really necessary. They say it would be better if the blocks were automatically re-rendered to keep everything visible and avoid overlap.

Further, the block re-rendering is still a little unreliable, with some corner cases unaccounted for. Here is a recent image of the addition block being used. Note that some of the blocks are hidden behind others.

Project link (assuming it is not overwritten): https://musicblocks.sugarlabs.org/index.html?id=1536891681820758&run=True

Image:

[walterbender]

Lots of corner cases. Not convinced eliminated vspace blocks would fix that. That said, there are situations where we could probably change the block shape, Maybe a GCI project?

[pikurasa]

So perhaps eliminating v/h spaces is impossible/undesirable. However, I do think we can do the following:

• Block shapes that avoid the need for most/all of the most common block types/combinations
• More instances, and more robust implementation automated v/h space generation when necessary

Also, the same people who point this problem out mention that part of the issue is that it is not obvious what these blocks do, so is there a way to make their function more obvious? (I suppose our new help function will help with that but there may be other ways, too)

[walterbender]

There are three separate issues convolved here: (1) what are vspace blocks? what do they do? (2) can we replace some vspace blocks with changes to the block design? (3) can we detect all of the corner cases where we need to add spacers to prevent block overlap.

I think we can address #1 with better graphics (and help, as you observed). I am open to suggestions as to what a vspace block might look like (good GCI design task).

2 is a bit of work in that it involves (1) modifying the block generation library to include the new shapes -- not difficult per se, but it will take time and effort (a more advanced GCI task in that involves knowledge of both Javascript and SVG), and (2) triggering the block modification at the appropriate time. This is very tricky because it is driven by events external to the block itself. But presumably we can look at all the cases where we are adding vspaces and use them as the trigger. (Not sure how we'd do this with the macros, which don't use this mechanism internally).

3 is a matter of diligence and documentation (through creation of new issues) for specific corner cases.

I suggest we create separate issues for #1 and #2 above and a new issue for each instance of #3.