 
            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 notEmptyifTrue: [| namespaces classes classNormalizerpackageNormalizer |
builder packingLayout.namespaces := models first allModelNamespaces.classes := namespaces flatCollect: #classes.packageNormalizer := CCColorNormalizer newlow: (Color gray: 0.6);high: (Color gray: 0.95);transformation: #nestingLevel;population: namespaces.builder shapeBuilder platform color:packageNormalizer.
builder nodes: namespaces.classNormalizer := CCColorNormalizer newlow: (Color gray: 0.25);high: Color blue;transformation: #numberOfLinesOfCode;population: classes.builder shapeBuilder boxcolor: 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 |etranslateTo:(e model position x + (e modelcontentBoundingVolume depth / 2))
@ (e model position z + (e modelcontentBoundingVolume 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