Labels: Type-Defect Priority-Medium Component-ExternalTools
New issue 532 by tudor.gi...(a)gmail.com: inFusion should also export
void, long, int, boolean, char, char ... should be PrimitiveTypes, not
Labels: Type-Defect Priority-Medium Component-Mondrian
New issue 499 by alexandr...(a)gmail.com: Port & transmission in Mondrian
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
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:
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.
I found the new easel often quite problematic. Here is a list of issues I have found:
- Time to time, pressing Ctrl-s does not execute the script, especially on Linux boxes. It instead accepts the text pane instead of executing. I cannot really reproduce it (I do not have a linux right now), but students have experienced this several times
- When the UI thread crashes, a new easel has to be opened. For example, execute the script:
view nodes: (1 to: 20)
It will raise a debugger. Remove the "self foo", and press the check or Cmd-s, then I have the same error, even though "self foo" is not in the script.
- Examples are crucially missing.
These 3 points are quite disturbing for the students. It would be cool to have a sprint on the new easel. I like the fact it is the same UI concept than the rest of the Moose UI.
Shall I open issues for each of these points?
Alexandre Bergel http://www.bergel.eu
Labels: Type-Defect Priority-Medium
New issue 645 by cy.delau...(a)gmail.com: we should keep the current selected
tab in the moose panel
In the moose finder, If I click on an entity, I have a new pane that open
on the right.
In this new pane, if I select any tab, this one should stay selected when I
click on other entities
During Smalltalks conference, we started with Mariano and Doru to do an
experiment: to use Mondrian to visualize the graph that is being serialized
I want to make two questions about that:
1) Is it fine how I installed Mondrian?
(ConfigurationOfMondrian project latestVersion) load.
2) For large graphs, I would like to show them lazily, maybe drawing some
expandable nodes (+). Do you understand what I mean? Is that possible?