14 Jan
2010
14 Jan
'10
8:24 p.m.
Hi!
Now that some of you are building complex and interactive
visualizations, I feel the need to add some annotations on things that
are displayed. I am not talking about the model here, but really
annotation on the view. For example, assume that I want the size of a
node to increase (e.g., to see its method inside) when I double click
on it. Where do I store the information that the node has been
expanded ?
I started to have this need with popupView:. A node needs to know
whether its popupview is on or not. I added a variable popup in
MOGraphElement which solve this. But more complex interaction requires
a generalization of this.
I am about to introduce a variable annotation in MOGraphElement that
will lazily create a dictionary.
Any comment?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
14 Jan
14 Jan
10:19 p.m.
it is probably not related. but today when coding with jr for a new version of blueprint
we saw that it would be nice to have the possibility to share information either other all
the packageBlueprints (we did that using a class)
or between all the blueprints displayed inside a canvas. (this was for the color of the
marked surfaces and knowing which one was selected).
For the marked surface we took the easy road: we said ok the color table can be a class
var and we will have
one table for all the blueprint. Now for the selection (when we click on a bp head ) may
be this is better to have the effect
local to easel.
So what I want to say is that your annotations should be accessible from the scripts and
it would be good to have
- node
- view
- all nodes
Stef
Hi!
Now that some of you are building complex and interactive visualizations, I feel the need
to add some annotations on things that are displayed. I am not talking about the model
here, but really annotation on the view. For example, assume that I want the size of a
node to increase (e.g., to see its method inside) when I double click on it. Where do I
store the information that the node has been expanded ?
I started to have this need with popupView:. A node needs to know whether its popupview
is on or not. I added a variable popup in MOGraphElement which solve this. But more
complex interaction requires a generalization of this.
I am about to introduce a variable annotation in MOGraphElement that will lazily create a
dictionary.
Any comment?
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
15 Jan
15 Jan
12:05 a.m.
Hi,
No to be negative, but I actually like the way I do it now, which is
as follows:
- I visualize famix elements (namespaces, classes, methods, ...)
- each of these implements a method that is responsible for adding its
representation to the view
- each of these has a status (a famix property) responsible for
keeping its visualisation state
I like this because
- I dont need to add vars to the classes
- the visualisation state is permanent: if I do a full refresh nothing
is lost
- closing-opeing an element returns the element to its previous state
although all the contained entities are redrawn
The only (minor) downside to this is that if I would have 2
visualisations on the same data they will show the same expansion
state. I see no problem with this.
Now the popupview is interesting as well. Are there any other use
cases ?
On 14 Jan 2010, at 16:24, Alexandre Bergel wrote:
Hi!
Now that some of you are building complex and interactive
visualizations, I feel the need to add some annotations on things
that are displayed. I am not talking about the model here, but
really annotation on the view. For example, assume that I want the
size of a node to increase (e.g., to see its method inside) when I
double click on it. Where do I store the information that the node
has been expanded ?
I started to have this need with popupView:. A node needs to know
whether its popupview is on or not. I added a variable popup in
MOGraphElement which solve this. But more complex interaction
requires a generalization of this.
I am about to introduce a variable annotation in MOGraphElement that
will lazily create a dictionary.
Any comment?
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
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
4:41 p.m.
No to be negative, but I actually like the way I do it
now, which is
as follows:
- I visualize famix elements (namespaces, classes, methods, ...)
- each of these implements a method that is responsible for adding
its representation to the view
Yep, this is the way that we used in Moose
- each of these has a status (a famix property)
responsible for
keeping its visualisation state
But you're relying on properties in the model. Which could not always
be the case. For example, imagine I deal now with numbers, plain
instance of SmallInteger. Numbers cannot be annotated. Where would I
store the fact that a node is expanded or not?
Moreover, by using the properties of FAMIX objects to store the
"state" of the visualization (i.e., node that are expanded), your
model is somehow aware of the visualization. This is not what can be
called a clean separation of concerns :-)
I like this because
- I dont need to add vars to the classes
Right, but your model support properties.
- the visualisation state is permanent: if I do a full
refresh
nothing is lost
Good point! This is something I will have to take care of
- closing-opeing an element returns the element to its
previous
state although all the contained entities are redrawn
What I am proposing will have the same benefit
The only (minor) downside to this is that if I would
have 2
visualisations on the same data they will show the same expansion
state. I see no problem with this.
this is a no-surprise since you have one unique model for two
different visualization and your model is aware of your visualization.
Now the popupview is interesting as well. Are there
any other use
cases ?
Node expansion is one. Another is highlighting. For example. Try this:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
view interaction highlightWhenOver: [:v | {v - 1 . v + 1. v + 4 . v -
4}].
view shape rectangle
width: 40;
height: 30;
withText.
view nodes: (1 to: 16).
view gridLayout gapSize: 2.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
When the mouse leaves a node, it set back the border to black! (set in
MOAnnouncer>>highlightWhenOver:). And if you want to highlight nodes
that have a non black border color, then the highlight will not behave
the way it should be.
The annotation mechanism should not have any impact on your existing
code by the way. More I think about it, more I am think this is the
way it should be.
Cheers,
Alexandre
On 14 Jan 2010, at 16:24, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
Now that some of you are building complex and interactive
visualizations, I feel the need to add some annotations on things
that are displayed. I am not talking about the model here, but
really annotation on the view. For example, assume that I want the
size of a node to increase (e.g., to see its method inside) when I
double click on it. Where do I store the information that the node
has been expanded ?
I started to have this need with popupView:. A node needs to know
whether its popupview is on or not. I added a variable popup in
MOGraphElement which solve this. But more complex interaction
requires a generalization of this.
I am about to introduce a variable annotation in MOGraphElement
that will lazily create a dictionary.
Any comment?
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
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:51 p.m.
On 15 Jan 2010, at 12:41, Alexandre Bergel wrote:
You are right on both points ...
In that case your solution would be cleaner, yes.
- each of
these has a status (a famix property) responsible for
keeping its visualisation state
But you're relying on properties in the model. Which could not
always be the case. For example, imagine I deal now with numbers,
plain instance of SmallInteger. Numbers cannot be annotated. Where
would I store the fact that a node is expanded or not?
Moreover, by using the properties of FAMIX objects to store the
"state" of the visualization (i.e., node that are expanded), your
model is somehow aware of the visualization. This is not what can be
called a clean separation of concerns :-)
I like this because
- I dont need to add vars to the classes
Right, but your model support properties. - the
visualisation state is permanent: if I do a full refresh
nothing is lost
Good point! This is something I will have to take care of [...]
The annotation mechanism should not have any impact on
your existing
code by the way. More I think about it, more I am think this is the
way it should be.
Go for it then ;-)
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
5455
days inactive
5456
days old
4 comments
3 participants
participants (3)
-
Alexandre Bergel -
Johan Fabry -
Stéphane Ducasse