blocks_horizontal/* are not included in blocks_compressed.js

[tmickel]

blocks_compressed.js as generated only includes blocks in blocks/*

This causes out horizontal blocks to break when trying to use the compressed version as in https://developers.google.com/blockly/hacking/building

[rachel-fenichel]

So do we want a blocks_compressed_horizontal and a blocks_compressed_vertical? I think if I make it contain both blocks/* and blocks_horizontal/* we will probably have conflicts, at least until we thoroughly sort out naming.

[tmickel]

blocks_compressed_horizontal and blocks_compressed_vertical makes sense to me.

[rachel-fenichel]

My concern is that we may want to share blocks between the vertical and horizontal versions. Having separate blocks_compressed_horizontal and blocks_compressed_vertical makes it hard to share.

Another option is to have a blocks_common/ directory, a blocks_vertical/ and a blocks_horizontal/

Then blocks_compressed_horizontal would contain the contents of blocks_horizontal/ and blocks_common/

[RoboErikG]

Shouldn't all the horizontal blocks be included in the vertical UI? That would allow users to migrate from the simpler horizontal UI to the more complex vertical UI.

If so, that means there doesn't need to be any duplicates between them, and vertical pulls in both sets of blocks. For specific projects you could update the build script to generate horizontal_blocks_compressed.js (or simple_blocks_compressed.js) and all_blocks_compressed.js and tell developers to import one or the other.

[tmickel]

@thisandagain might have some opinion on this. I was raising this issue because I tried to use compressed mode for our iOS wrapper and it was broken :)

The blocks_common/, blocks_vertical/, blocks_horizontal/ idea would seem fine to me.

I didn't think we should be explicitly thinking about the case where horizontal blocks could be included in the vertical UI at this point in time. In any case supporting the option for them to have exclusive blocks for each version seems more generic and desirable from my point of view.

[rachel-fenichel]

I thought the plan was to be able to cleanly move a program from scratch jr
into scratch, as a sort of "leveling up". In my mind that meant that the
blocks stayed the same and were simply rendered differently.

On Thu, Feb 11, 2016 at 5:11 PM Tim Mickel notifications@github.com wrote:

@thisandagain https://github.com/thisandagain might have some opinion
on this. I was raising this issue because I tried to use compressed mode
for our iOS wrapper and it was broken :)

The blocks_common/, blocks_vertical/, blocks_horizontal/ idea would seem
fine to me.

I didn't think we should be explicitly thinking about the case where
horizontal blocks could be included in the vertical UI at this point in
time. In any case supporting the option for them to have exclusive blocks
for each version seems more generic and desirable from my point of view.

—
Reply to this email directly or view it on GitHub
#54 (comment).

[ChampikaF]

I suggest we hold for a beat and discuss in our meeting next week when everyone is in the 'same room'. I think part of this is also what things we should prioritize right now.

[NeilFraser]

I'd vote for duplicating blocks rather than trying to share them. The reason is that there may be more differences than mere rendering. Scratch Jr may have a dropdown of limited options, whereas Scratch may have a type-in field with a validator. Thus the blocks may be quite different even though the XML is the same.

Since the set of blocks in Scratch Jr are quite limited, I don't think the disadvantages inherent in duplication are severe.