Hi Alex,
I would not say that it's a problem of CodeCity/Roassal, but my limited understanding of the implementation of CodeCity. I will follow the Ricky's suggestion regarding to explore the nesting model.
Thanks!
Leonel Merino PhD student University of Bern +41 78 405 43 38 merino@inf.unibe.ch
On 17 December 2016 at 12:13, Alexandre Bergel alexandre.bergel@me.com wrote:
I do not understand. Is this a CodeCity problem or a Roassal problem?
Alexandre
On Dec 16, 2016, at 8:50 PM, Leonel Merino merino@inf.unibe.ch wrote:
Hi Alex,
I want to try the CodeCity visualization in a VR system. So I want to
extract nodes attributes (size, color, position) from the Pharo implementation. As first step I wanted to see whether the data I am gathering are correct by mapping the top view in Roassal2, so I could compare both.
In the script that I pasted, the objects in the model of RTElements are
CCNodes from which I extract the attributes (size, color and position). I managed to extract all attributes for classes, but for packages the position does not map well.
Regarding your questions: contentBoundingVolume is part of the CC
implementation as well as the layout.
To reproduce it, you need to have CodeCity, Moose and a FAMIX model.
Then you can run both scrips that I pasted in my previous message.
Best regards Leonel
On Fri, 16 Dec 2016 at 18:24, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Leonel,
I guess you wish to have the GTInspector facilities, which is why you
have using Roassal on this?
How can I reproduce the problem? Where contentBoundingVolume comes from?
Where is the layout?
Cheers,
Alexandre
On Dec 16, 2016, at 11:18 AM, Leonel Merino merino@inf.unibe.ch
wrote:
Hi all,
Thanks for the replies. Let me ask you one more question.
As an exercise, I want to reproduce in Roassal2 the top view of
CodeCity. So I took this script from CCScriptExamples>>cityOfJavaSystem:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| models builder |
models := MooseModel root allModels.
builder := CCBuilder new.
models notEmpty
ifTrue: [
| namespaces classes classNormalizer
packageNormalizer |
builder packingLayout.
namespaces := models first allModelNamespaces.
classes := namespaces flatCollect: #classes.
packageNormalizer := CCColorNormalizer new
low: (Color gray: 0.6);
high: (Color gray: 0.95);
transformation: #nestingLevel;
population: namespaces.
builder shapeBuilder platform color:
packageNormalizer.
builder nodes: namespaces.
classNormalizer := CCColorNormalizer new
low: (Color gray: 0.25);
high: Color blue;
transformation: #numberOfLinesOfCode;
population: classes.
builder shapeBuilder box
color: classNormalizer;
height: #numberOfMethods;
width: #numberOfAttributes;
depth: #numberOfAttributes.
builder nodes: classes.
builder nest: namespaces node: #yourself in:
#parentScope.
builder nest: classes node: #yourself in:
#namespaceScope ].
builder open
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
It produced this view:
<image.png>
Then I produced the following Roassal2 script based on the nodes from
the previous builder object:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
v := RTView new.
classes := builder nodes reject: [ :e | e model class = FAMIXNamespace
].
packages := builder nodes select: [ :e | e model class =
FAMIXNamespace ].
els1 := (RTBox new
height: #depth;
width: #width;
color: #color) elementsOn: classes.
els2 := (RTBox new
height: [ :e | e contentBoundingVolume depth ];
width: [ :e | e contentBoundingVolume width ];
color: #color) elementsOn: packages.
els1
do: [ :e | e translateTo: (e model position x + (e model depth /
2)) @ (e model position z + (e model width / 2)) ].
els2
do: [ :e |
e
translateTo:
(e model position x + (e model
contentBoundingVolume depth / 2))
@ (e model position z + (e model
contentBoundingVolume width / 2)) ].
v addAll: els2 , els1.
els2 @ RTDraggable.
v
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Although the boxes that represent classes seem correct, I have trouble
positioning the boxes that corresponds to packages.
Does anyone have an idea of how to fix this?
<image.png>
Best regards,
Leonel Merino
PhD student
University of Bern
+41 78 405 43 38
merino@inf.unibe.ch
2016-12-14 18:32 GMT+01:00 Stephan Eggermont stephan@stack.nl:
A pre-spur pre-pharo5, that is.
Stephan
Verstuurd vanaf mijn iPhone
Op 14 dec. 2016 om 17:06 heeft Tudor Girba tudor@tudorgirba.com
het volgende geschreven:
Code City should work in Pharo 5.
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev