[etoys-dev] [squeakland] how to hide ALL connectors to/from a specific node in the Connectors package?

[Steve Thomas]

The problem as I understand it is how to propagate messages to tell all
outgoing connections from the current object and all sucessors outgoing
connetions etc.

See solution below:
[image: Inline image 1]
Each node is a Sibling and Each Connector is a Sibling.  So when I run
"hideConnOut" it tells all its "outgoing connections" to hide AND tells all
its succesors to do the same.

FYI Siblings are very useful when you want a bunch of objects to have the
same behavior. They share scripts and variables (ie: if you create a
variable in one sibling they all have that script, but one could be running
and the other not.  Same with variables add one and they all Siblings have
that variable (but they can have different values).  Below is from the
Etoys reference manual:

About Siblings (by Karl)

If you hold down shift while copying with the green halo handle you make a
copy. <http://booki.flossmanuals.net/etoys-reference-manual/_full/>

Almost... What you now have are two *sibling players*, each of which is a
"Player" or "Object" in its own right. (Also copies made by the Player Copy
tile are siblings.) Each players wears its own separate Morph as its
costume. The siblings are related in that they share certain things in
common, in particular: scripts and variable definitions.  So if you add a
variable to one sibling, all siblings will have their own instance of that
variable with the same name. The same name, but the values can be
different. For example if I add a variable called "speed" to one sibling,
all siblings will have a variable with that name. But I can have one
sibling with speed=5 and another with speed=10. Same variable name
different values.<http://booki.flossmanuals.net/etoys-reference-manual/_full/>

Also if I add a script to one sibling, all siblings will have the same
script (and same scripting tiles, if I change it in any sibling at
anytime). But although siblings share a script, each sibling has its own
private "status" for that script, i.e.remembers separately whether the
script *as used by this instance* is "normal", "paused,", or "ticking", or
set to trigger on mouse-up, etc.; and what the tick-rate
is.<http://booki.flossmanuals.net/etoys-reference-manual/_full/>

When using siblings, what's really happening underneath is that there is a
custom Player "Class" is created to bear the shared code, and the siblings
are individual "Instances" of that class. "Class" and "Instance" are among
the most fundamental concepts of object-oriented programming
<http://booki.flossmanuals.net/etoys-reference-manual/_full/>

So why would you use siblings? Well besides teaching one of the most
fundamental concepts of object oriented programming, you could use siblings
in a game to make characters that have similar behaviors (aka scripts) but
different looks (you can change the looks by either re-drawing the sketch
or by setting the
<http://booki.flossmanuals.net/etoys-reference-manual/_full/>Sketch's
graphic (if the object is a Sketch or image you copied in) or changing its
size and colors.  You could also have ships in a game that keep track of
how many times they were hit (using a variable to count the # of hits).
That way you can program a basic ship once and make multiple siblings. Then
if you decide to change the behavior (ex: modify a script, or add a new
variable), you can change it once and all the siblings are changed.

Siblings could also be used to try to simulate or model real world
behavior.  For example deer population or some other animal.  You could
create an Object that simulates the behavior of a deer: searches for food,
ages, breeds (at a certain age), etc. and make sibling copies of that one
object. Then each Sibling (aka individual instance of the Class Deer which
you have defined) could age, search for food (and find it or not which
could affect its life expectancy), etc at its own rate.  You could also
create predators and food that grows. Then run multiple simulations varying
the amount of food, starting number of dear, # of predators, etc.

If the "all instances" box is not checked in AllPlayers, you'll see the
scripts for only one player of each sibling group. This will give you
"control" over the scripts of only one of the players. If you want to be
able to "control" scripts for both of the siblings, make sure the "all

instances" checkbox is checked.
Unless the "all instances" checkbox is checked, creation of new siblings
will typically not result in any noticeable change in the all- scripts
tool, since all the scripts of the new sibling will already be represented
by another instance in the tool. Perhaps that's what you're seeing.

Also, if the "tickers only" box is checked, only scripts whose status is
"ticking" or "paused' are shown in the all-scripts tool. This can be
another reason why the all-scripts tool may seem not to be "picking up" on
a change.



On Sat, Sep 14, 2013 at 4:45 PM, Lawson English <lenglish5 at cox.net> wrote:

> I'll try again:
>
> I have 19 Connectors nodes showing in my project.
>
> There are 19 x 18 connectors -a fully connected graph.
>
> I want to be able to easily tell all connectors to hide using Etoys
> scripting. I already know how to do this with Squeak, but it isn't obvious
> at all how to make it work with etoys, despite the existence of a scripting
> option "tellAllIncomingConnections" and "tellAllOutgoingConnections"
>
> I can't figure it out.
>
> I've dropped down into the System browser and looked at the Smalltalk code
> for
>
> #tellAllIncomingConnections: aMessageSelector
>
> and
>
> #tellAllOutgoingConnections: aMessageSelector
>
>     "Send the given message selector to all the players of the receiver's
> costume's outgoing connections"
>
>     self costume outgoingConnections do:
>         [:m |
>             m playerRepresented ifNotNilDo:
>                 [:p | p performScriptIfCan: aMessageSelector]]
>
> I've even tried putting ^#hide into the script.
>
>
> Is this aspect of Connectors + Etoys broken or am I missing something?
>
> I can specify a SPECIFIC Connector to hide, but I have potentially 19 x 18
> or even 256 x 255 of them to work with, so obviously this isn't an option.
>
> Do I have to go with my incredibly cumbersome code I worked out in my
> Squeak youtube tutorials and stick that into a script, instead?
>
>
>
>
>
> Thanks.
>
>
> L
>
>
> --
> Squeak from the very start (introduction to Squeak and Pharo Smalltalk for
> the (almost) complete and compleate beginner).
> https://www.youtube.com/**playlist?list=**PL6601A198DF14788D&feature=**
> view_all<https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all>
>
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are, by
> definition, not smart enough to debug it." - Brian Kernighan
>
> ______________________________**_________________
> squeakland mailing list
> squeakland at squeakland.org
> http://lists.squeakland.org/**mailman/listinfo/squeakland<http://lists.squeakland.org/mailman/listinfo/squeakland>
>



-- 

To some of us, writing computer programs is a fascinating game. A program
is a building of thought. It is costless to build, weightless, growing
easily under our typing hands. If we get carried away, its size and
complexity will grow out of control, confusing even the one who created it.
This is the main problem of programming. It is why so much of today's
software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill
of controlling complexity. The great program is subdued, made simple in its
complexity.

- Martin Harverbeke (from Eloquent
JavaScript<http://eloquentjavascript.net/index.html>
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20130914/997c8637/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 46139 bytes
Desc: not available
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20130914/997c8637/attachment-0001.png>