scratchfoundation / scratch-blocks Goto Github PK
View Code? Open in Web Editor NEWScratch Blocks is a library for building creative computing interfaces.
Home Page: https://scratch.mit.edu/developers
License: Apache License 2.0
Scratch Blocks is a library for building creative computing interfaces.
Home Page: https://scratch.mit.edu/developers
License: Apache License 2.0
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
In Scratch on web / desktop we have zoom controls in the bottom right of the editor:
For tablet and desktop / web, we should make a decision as to what we want:
One consideration is that "pinch to zoom" will impact the potential for multitouch interaction with blocks.
/cc @tmickel
@carljbowman and @tmickel experimented with multitouch a bit in the "Shakespeare" prototype. We need to spec our desired behavior / interaction.
Blockly has a really nice translation pipeline setup with https://translatewiki.net/. We'll need to adapt this for use with our translation workflow in Transifex for the vertical grammar.
/cc @mewtaylor
The Scratch team uses NPM as the dependency management system for new JS projects. Because of this, it would be nice to have a clear process for release "tagging" and publishing to NPM.
Looks like this has been explored quite a bit already by the blockly
community:
I was thinking that it might be helpful, since the methods for handling svg drawing are visual, to adopt a coding convention that contextualizes the methods visually in addition to docstrings. These comments could show an example of what the method draws, as well as reference constants/variables used throughout the method spatially/visually for debugging purposes. Here's an example of what I'm kind of thinking of roughly:
/**
* Render the left edge of the block.
* @param {!Array.<string>} steps Path of block outline.
* @param {!Object} connectionsXY Location of block.
* @param {number} rightEdge Minimum width of block.
* @private
*
* __
* start point -> /
* |
* \
* \
* | <-- Blockly.BlockSvg.NOTCH_HEIGHT
* |
* /
* /
* |
* end point -> \__
*/
Blockly.BlockSvg.prototype.renderDrawLeft_ =
function(steps, connectionsXY, bottom) {
.
.
.
};
Thoughts?
Currently if the toolbox position is not start, they will be overlapped by the flyout.
The new event model just landed:
google/blockly#252
You may wish to merge this at your convenience.
Update sound effects with assets from Scratch / Scratch Jr. Now would be a good time to audit these with the design team:
@carljbowman any thoughts?
Blocks currently only accept a hue rotation value. We'd like to modify this to allow either a hue rotation value (number
) or hex color value (string
).
{
"id": "math_foo",
"message0": "foo bar",
"args0": [],
"colour": 120,
"tooltip": "",
"helpUrl": "http://www.example.com/"
}
{
"id": "math_foo",
"message0": "foo bar",
"args0": [],
"colour": "#C98323",
"tooltip": "",
"helpUrl": "http://www.example.com/"
}
blockly
to allow the specification of absolute color values is pretty widespead./cc @afmckinney
We currently have two different ways to "insert" a block that is inconsistent between Scratch and Scratch Jr. From observation (particularly on mobile devices), we'd like to implement a variant of our design from Scratch Jr for all grammars.
Blockly currently:
Scratch currently:
Bring in the latest from https://github.com/google/blockly (2016
branch?). @NeilFraser which branch should we pull from?
We are unfortunately going to end up breaking quite a few of the demos. Prior to making this repo public we should make sure to audit / update / remove items from the ./demos
directory.
As we port over the Scratch grammar we should decide which generators we want to support. My initial thought is we'd want to support a generator for Javascript and a generator for SB2(3) but drop support for some other languages which the community can help us fill-in over time.
This is likely a topic for our kickoff coming up soon, but feel free to drop any initial thoughts in here:
/cc @cwillisf @rschamp @mewtaylor @NeilFraser @rachel-fenichel
We need to design the overall GUI for our initial prototypes with special emphasis on the palette (toolbox) / workspace paradigm. Discussion with the team has suggested that we should quickly explore and prototype a range of options. This is due to the fact that no one solution really seems to be perfect just yet.
Common source of typos and inconsistent with the rest of the Scratch codebase and HTML / CSS.
http://www.scratchjr.org/learn.html#blocks
Depends on #2
Since this depends on work in progress in Blockly a merge from upstream Blockly should be done on a regular basis to avoid large painful merges in the future. A standard merge can be used as this project will never be merged back in to upstream.
https://help.github.com/articles/syncing-a-fork/
Let's set up a schedule for this and can investigate automation if needed.
Create a new playground.html
for the horizontal grammar including updated blocks, toolbox, and generator(s).
http://www.scratchjr.org/learn.html#blocks
Depends on #2
For local development and prototyping (as well as design reviews around the lab) we should implement and lightweight iOS wrapper application around playground.html
.
In blockly
the mouse scroll wheel defaults to controlling zoom level. This feels pretty confusing IMO on Mac OS and we've discussed mapping our pan / zoom behavior to be closer to what is used in Apple Maps. Related to #43
We need two separate playgrounds for the horizontal and vertical grammars that represent our reference implementation for each.
Test suite will need to be updated to reflect new grammar, blocks, and generators. While doing so, we should automate the jsunit
and jslint
testing via Travis-CI which should help with open source contribution quite a bit.
We still need to finish work on rendering / connections for our iterator blocks:
An error shows up in both playgrounds on load.
In Scratch we allow both the "player" and the blocks themselves to modify the state of a program. Because of this, we need a way to allow more than one (in our case: two) client to modify the representation of a program. Support for this is encapsulated in @NeilFraser 's "realtime" work. Placing here for further discussion and to track progress.
Blockly:
Scratch:
As per our testing with Scratch Jr and Scratch on tablets, blocks should "grow" under the user's finger during a "drag" operation. Assigning to @carljbowman to spec and drop-in any additional context.
In the process of quickly implementing the horizontal grammar we broke RTL in a number of places:
Depends on #31
Likely not something we will want to support going forward but rather we should be sure to point folks to it within the google/blockly
codebase.
Blocks go left; scrolling goes right.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.