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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 15 Jan 2010, at 12:41, Alexandre Bergel wrote:
- 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.
You are right on both points ...
- 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
In that case your solution would be cleaner, yes.
[...]
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@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
-
Alexandre Bergel -
Johan Fabry -
Stéphane Ducasse