Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 516 by tudor.gi...(a)gmail.com: System Complexity displays more
than the classes in the group
http://code.google.com/p/moose-technology/issues/detail?id=516
Currently, the algorithm to identify the hierarchies does not limit the
result to the current class group, but it takes all the subclasses of the
superclass. This means that if you have a group with Object inside, you
will end up with a system complexity with all classes.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 944 by cunningh...(a)gmail.com: EyeSee chart Legend issues
http://code.google.com/p/moose-technology/issues/detail?id=944
When creating a chart, I would like to include a legend, and EyeSee allows
for this. However, the legend is always top left of chart (even with
#legendBelow sent) and obscures the Y axis label; or it is to right (when
#verticalLegend is sent) and writes over the right axis if that axis is
used.
Example code for first issue:
i := 0.
series1 := OrderedCollection new: 7.
20130601 to: 20130607 do: [ :dt| series1 add: { dt. i := i + 1. }].
series2 := OrderedCollection new: 7.
i := i + 1.
20130601 to: 20130607 do: [ :dt| series2 add: {dt. i := i -1. }].
series3 := OrderedCollection new: 7.
20130601 to: 20130607 do: [ :dt| series3 add: {dt. 4. }].
colors := { Color red. Color blue. Color green. }.
parts := OrderedCollection new: 3.
{ series1. series2. series3. } withIndexDo: [ :ls :ind |
parts addLast: (ESLineDiagram new
y: #second;
preferredAxisMaxY: 7;
lineWidth: 2;
models: ls;
defaultColor: (colors at: ind);
yourself).
ind = 1 ifTrue: [
parts last
identifier: #first;
rotatedLabels: true;
xAxisLabel: 'Dates';
regularAxis;
axisColor: Color black;
yAxisLabel: 'Some Measurement that will Collide with Legend'
].
].
chart := ESDiagramRenderer new.
composite := chart compositeDiagram.
parts do: [ :chartPart| composite add: chartPart ].
composite yPadding: 30; height: 600; width: 800.
parts first
displayLegend: true;
legendBelow;
colorDict: (Dictionary keys: #( 'Series1' 'Series2' 'Series3') values:
colors).
chart open.
Example code for second (vertical) issue:
i := 0.
series1 := OrderedCollection new: 7.
20130601 to: 20130607 do: [ :dt| series1 add: { dt. i := i + 1. }].
series2 := OrderedCollection new: 7.
i := i + 1.
20130601 to: 20130607 do: [ :dt| series2 add: {dt. i := i -1. }].
series3 := OrderedCollection new: 7.
20130601 to: 20130607 do: [ :dt| series3 add: {dt. 4. }].
seriesRight := OrderedCollection new: 7.
20130601 to: 20130607 do: [ :dt| seriesRight add: {dt. 6. }].
colors := { Color red. Color blue. Color green. Color yellow. }.
parts := OrderedCollection new: 4.
{ series1. series2. series3. } withIndexDo: [ :ls :ind |
parts addLast: (ESLineDiagram new
y: #second;
preferredAxisMaxY: 7;
lineWidth: 2;
models: ls;
defaultColor: (colors at: ind);
yourself).
ind = 1 ifTrue: [
parts last
identifier: #first;
rotatedLabels: true;
xAxisLabel: 'Dates';
regularAxis;
axisColor: Color black;
yAxisLabel: 'Some Measurement that will Collide with Legend'
].
].
parts addLast: (ESLineDiagram new
rightYAxis
y: #second;
preferredAxisMaxY: 7;
lineWidth: 2;
models: seriesRight;
defaultColor: colors last;
regularAxis;
axisColor: Color black;
yAxisLabel: 'Another Measurement that will Collide with Legend'
yourself).
chart := ESDiagramRenderer new.
composite := chart compositeDiagram.
parts do: [ :chartPart| composite add: chartPart ].
composite yPadding: 30; height: 600; width: 800.
parts first
displayLegend: true;
verticalLegend;
colorDict: (Dictionary keys: #( 'Series1' 'Series2' 'Series3' 'Series4')
values: colors).
chart open.
This occurs in the current Moose dev (4.8 of recent origin), on Windows.
Type-Defect
Component-EyeSee
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Milestone-4.3
New issue 526 by tudor.gi...(a)gmail.com: Add explicit Interface in Famix
http://code.google.com/p/moose-technology/issues/detail?id=526
We should have a FAMIXInterface.
Hi,
Today I looked at getting Glamour and Torch working in Pharo 3.0
- ConfigurationOfMondrian refers to a stable version of ProfStef, which isn't defined for 3.0
- GLMUITheme has UThemeWatery2 as ancestor, which is removed. UIThemeWatery works fine
- RectangleMorph behavior was moved to BorderedMorph, so GLMPaneScroller needs a different
ancestor
- old version of Grease-Pharo-Core is loaded, using BlockContext (refering to squeaksource instead
of smalltalkhub)
With those changes, most browsers work. GLMBasicExamples open works, most examples work.
Action List -> Inspect has a problem.
(ConfigurationOfTorch project version: '1.4') load
misses AST-Semantic
should refer to smalltalkhub
refers to an older version of ConfigurationOfGlamour
AST changes seem to be substantial. Changes needed in TCParser?
Stephan
Hello,
I know that Hapax possibly isn't fully ported to Pharo, but running
the Hapax tests causes my Moose 4.5 image to hang (I've loaded
everything in the SqS Hapax repository). What image and package
loading order should one use to load Hapax? I'm interested in the
information retrieval part for natural language analysis, could that
part be repackaged in its own package?
Cheers,
Hernán
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 914 by cunningh...(a)gmail.com: withCenteredText not centering text
correctly
http://code.google.com/p/moose-technology/issues/detail?id=914
When I ask for centeredText, I would expect it to be centered horizontally
in the area that it is displaying in. Instead, it appears to be bumped up
vertically above the location where it should be.
If you add the following (missing?) method:
ROMondrianExample>>centeredText
"
self new centeredText
"
| view |
view := ROMondrianViewBuilder new.
self centeredTextOn: view.
view open
and then run ROMondrianExample new centeredText, you will see the issue.
How to reproduce the problem: step by step if necessary
This is from the latest (2013-02-14) Moose Suite 4.7 from the
MooseTechnology.org download page, on Windows 7 os.
Labels: Type-Defect Component-Roassal
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 904 by benjamin...(a)gmail.com: Roassal dragging subtrees (feature
contribution)
http://code.google.com/p/moose-technology/issues/detail?id=904
With a tree layout, when dragging an element I needed to drag all the
children at the same time. I knocked up a solution sufficient to my needs
in about 40 minutes - see attached changeset. I might be a nice general
feature to add to Roassal but its a bit rough. It will likely need some
critical love to polish it before integration. Later it might be made to
work with ROSelection and multi-selected elements - but that is out of my
scope for the moment.
Attachments:
RODraggableWithOthers.2.cs 1.3 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Roassal
New issue 938 by tu...(a)tudorgirba.com: RadialTreeLayout should translate
the graph
http://code.google.com/p/moose-technology/issues/detail?id=938
Try this:
view nodes: (Collection withAllSubclasses).
view edgesFrom: #superclass.
view radialTreeLayout.
The center of the graph is placed at 0@0, and this is annoying because you
do not see half of the graph. The layout should translate the graph to make
it start at 0@0
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: tu...(a)tudorgirba.com
CC: chisvasi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Glamour
New issue 884 by tu...(a)tudorgirba.com: The Roassal presentation should
react to custom ports
http://code.google.com/p/moose-technology/issues/detail?id=884
The current implementation of the Roassal presentation relies only on the
original entity. However, given that Roassal can handle various animations,
we would benefit from an extra ability of the presentation to react to
other ports.
For example, the list presentation reacts to #selection. Similarly, Roassal
should be able to react to it or others as well. Only, given that Roassal
is generic, the reaction should be customisable, too.
Perhaps something like this:
a roassal
painting: [:view :entity | ... ]
on: #customPort do: [ :view :customValue | ... ]
Hi,
I would like to signal that Diego and Stephan worked on some internal
changes to Moose-Core that can have impact on other code. So, here is a
little review to start the discussion:
- mooseName is now cached. This can have an impact if you rely on your
model to be more dynamic. If you have a custom entity that can receive
sub-entities at runtime, you might want to resetMooseName. For example, if
you modify the scope of a FAMIXType, the mooseName has to be reset:
FAMIXType>>container: aContainerEntity
container := FMMultivalueLink on: self
update: #types
from: self container
to: aContainerEntity.
*self resetMooseName*
This is supposed to be an optimization, but it makes the code more
complicated. To see if it is actually worth it, we should benchmark the
impact.
@Diego, @Stephan: Did you do some benchmarking on this?
- An entity now answers if it hasUniqueMooseNameInModel. This is at the
moment used when caching the entity by name in groups. For example,
Associations do not have a unique name and thus, they are not cached.
- There are some parts of the code I do not understand. For example, the
need of this code:
MooseGroupStorage>>becomeKind: elementStorageClass
...
*self do: [ :each | each hasUniqueMooseNameInModel ifTrue: [ each
privateClearMooseName ] ].*
...
Did I miss anything?
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"