Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Mondrian
New issue 499 by alexandr...(a)gmail.com: Port & transmission in Mondrian
http://code.google.com/p/moose-technology/issues/detail?id=499
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
Status: New
Owner: ----
CC: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Mondrian
New issue 558 by alexandr...(a)gmail.com: Better visitor for Mondrian
http://code.google.com/p/moose-technology/issues/detail?id=558
Shapes are not correctly handed by MOVisitor. We should move all the
display:on: methods of the shapes in a visitor. The goal is to make the
core of Mondrian free of any canvas reference.
By doing so, we will produce exporter for HTML5 and Javascript...
Updates:
Labels: -Component-Mondrian
Comment #7 on issue 417 by alexandr...(a)gmail.com: Writing informations in a
Transcript
http://code.google.com/p/moose-technology/issues/detail?id=417
Mondrian contains just one "Transcript show:", when doing the benchmark. I
consider it acceptable
Updates:
Labels: -Platform-Squeak Platform-Pharo
Comment #1 on issue 321 by tudor.gi...(a)gmail.com: Problems using java code
importer with inFusion in windows
http://code.google.com/p/moose-technology/issues/detail?id=321
The command should be taken away from the menu until OSProcess works
properly.
Updates:
Labels: -Milestone-4.2 Milestone-4.3
Comment #6 on issue 114 by tudor.gi...(a)gmail.com: Resizable panes in Finder
http://code.google.com/p/moose-technology/issues/detail?id=114
The basic structure is in place. There are still a couple of things to do:
- include the changes to GeneralScrollPane
- solve the small scrolling animation problem
Hello,
With nicolas we started to have a look at the eclipse-php-parser (provide
with PDT), to export a famix-mse file from a PHP project. We already started
to build an eclipse plugin that does some work:
=> We create an AST for each php file of the project
=> Then we have a visitor on this ast, and we are therfore able to make a
specific action for each kind of node visited
=> For now, we just export some FAMIXNamespace, FAMIXClass, FAMIXMethods.
So what's left is to implement each visit-method to extract informations
for each node visited. For that we will have to know a bit more PHP :) Maybe
the metamodel will have to be extended to take into account some
PHP-specific elements, I don't know.
If you want to have a look, sources are available via svn at:
https://scm.gforge.inria.fr/svn/lse/Projects/Verveine
Vervaine provide the extractor (not yet finished) for Java ans this one for
PHP. Both are using a common mechanism to generate famix entities and
extract them to mse.
I will be on holidays until august and will probably no longer work on it
until august. So if you want to have a look (and have the courage to install
eclipse to read java code:)), have some suggestions, want to implement
something, feel free to participate :)