Hi Alex,
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.
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?
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
Alexandre
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Presenting is storytelling."