| Commit message (Collapse) | Author | Age | Files | Lines |
| |\ |
|
| | |
| |
| |
| | |
and prepare for new release
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(experimental) slotwise inheritance à la Henry Lieberman for
sprite-local variables.
see
http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.htm
l
Let a sprite inherit another sprite’s local variables by making it the
“parent” in the sprite-icon’s context menu (the button icon in the
sprite corral underneath the stage). The child not only inherits the
variable slot but also - dynamically - the parent variable’s value.
Changing the parent’s variable value also changes it for every child.
If a child uses SET or CHANGE on an inherited variable it automatically
“shadows” it with its own value, thereby stopping dynamic participation
in the parent slot’s value (in effect dis-inheriting that slot).
Deleting a shadowed variable slot once again reinstates its inheritance
status.
inherited variables are shown as “ghosted” both in the child’s
variables palette and in such stage watchers. “Shadowing” them
un-ghosts both the variable blob template in the palette and the
watcher onstage (if any). Deleting a shadowed variable once again
ghosts the watcher and the palette block template.
Delete a (shadowed) variable either via the “Delete a variable” button
in the IDE or using the new “Delete” block in the variables category
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
and warped / turbo recursive commands by up to 40%
|
| | | |
|
| | | |
|
| |\|
| |
| |
| | |
https://github.com/jmoenig/Snap--Build-Your-Own-Blocks into development
|
| | | |
|
| | |
| |
| |
| |
| | |
notify users of potential incompatibilities when opening projects
created in other forks (e.g. BeetleBlocks)
|
| |\ \ |
|
| | | | |
|
| | |/ |
|
| |\| |
|
| | |
| |
| |
| | |
(hidden in dev mode)
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
REPORT now reports to the nearest lexical element expecting an input
(which may not be the block holding the REPORT statement, this lets you
REPORT out of nested FOR loops).
STOP THIS BLOCK behaves as it used to.
If you’ve been using REPORT instead of STOP THIS BLOCK, you should
migrate.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
introducing Variable objects, all functionality stays the same at this
time
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and pushed to this date
|
| | |
|
| |
|
|
|
| |
also custom block input slots reverting to default now show their
default value (useful in combination with the new "read-only" option
|
| | |
|
| |
|
|
|
|
| |
prevents an occasional DOM error saying "an attempt was made to use an
object that is not, or is no longer, usable" when loading a project
that has costumes
|
| |
|
|
| |
and release adjustments
|
| | |
|
| |
|
|
|
| |
thanks, Caitie, for reporting this bug and for supplying a project
which let me reproduce it!
|
| |
|
|
|
| |
text code mapping and block header support, both via GUI and
primitives, for built-in blocks and for custom ones.
|
| |
|
|
| |
in project and block library files
|
| |
|
|
|
|
|
|
|
| |
Primitive blocks in the palette can now be hidden in the project via
their context menu. Each palette's context menu further lets you hide
or show all its primitives depending on whether any primitives are left
to hide or show.
Hidden primitives are stored in the project data. This lets instructors
create "simplified" examples and problem sets.
|
| |
|
|
|
|
|
| |
for new "scripts pic..." feature on the scripting area's context menu.
Also pushed up version dates for new beta release, and added
SnapManual.pdf to the help folder
|