Labels: Type-Enhancement Priority-High Component-Kumpel
New issue 579 by junker.m...(a)gmail.com: [Kumpel] Incremental
loading/Updating of Kumpel Projects
The KMPProjectHistory should offer the possibility to update the model to
the current head revision.
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.
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
Labels: Type-Enhancement Priority-Medium Component-Metanool Milestone-4.6
New issue 726 by andreho...(a)gmail.com: FM3PropertyDescription>>getRawFrom:
should return false in Boolean properties instead of nil
It avoids to use the binary message into the Finder with meta-annotated
Boolean properties when using Metanool.
For example, instead of:
each annotations hugeClasses = true
each annotations hugeClasses
What do you think?
Code to fix it is below.
^ element privateState
attributeAt: self name
(self type = FM3 boolean)
ifFalse: [nil] ]