Hi Alex,

-=-=-=-=-=
Previous discussion:
What we did in Glamour was to attach to each Presentation a kind of default interaction.
In your example, I would make #mouseEnter, #mouseClick ... default ports that are populated
when the corresponding interactions happen on a graph element.

Then of course, these ports will belong to graph elements. Like this transmissions
are created between the ports of a graph element. Perhaps there will also be a need
to identify graph elements by name so that you can refer to them from outside the context
of a script.

-=-=-=-=-=
Previous discussion:

Why not having ports that belong to an interaction instead? Consider the following
script:
view nodes: (1 to: 1000).

Figure selection will imply a transmission between the root and each of these nodes.
It could be a single transmission between 'root interaction' and the unique interaction
of the nodes?

-=-=-=-=-=
Doru answer:
At least two reasons. First, the ports are not just for transmitting information, but
ports also allow you to store arbitrary values that model the graph element, and thus
you can model the state of a visualization (including side-effects). Second, using
ports you will be able to let the shape populate ports by default without writing any
explicit interaction (only write transmission when you want to deal with them).

Now, about we can be smart about transmissions and do what we do for shapes: we share
the object between multiple graph elements. For this, we will just need a lookup of
the origins instead of hardcoding them. Actually in Glamour, we have:

GLMTransmission>>originatesAt: aPort

and thus, you can have a smart transmission that performs a more complex check by checking
if the port is part of any elements from a collection. Like this you will have only
one the transmission object. You could write:

view nodes: #(1 2 3) labeled: #interestingNodes.
view nodes: #(5 6 7) labeled: #otherNodes.
view transmitTo: #otherNodes fromAny: #interestingNodes port: #selection.

Cheers,
Doru