19 Dec
2016
19 Dec
'16
11:16 a.m.
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(a)inf.unibe.ch
On 17 December 2016 at 12:13, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
I do not understand. Is this a CodeCity problem or a
Roassal problem?
Alexandre
CodeCity. So
I took this script from CCScriptExamples>>cityOfJavaSystem:
packageNormalizer
|
packageNormalizer.
#parentScope.
the
previous builder object:
].
2)) @
(e model position z + (e model width / 2)) ].
contentBoundingVolume depth / 2))
positioning the boxes that corresponds to packages.
> > Op 14 dec. 2016 om 17:06 heeft Tudor Girba <tudor(a)tudorgirba.com>
het volgende geschreven:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
On Dec 16, 2016, at 8:50 PM, Leonel Merino
<merino(a)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(a)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(a)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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| models builder |
models := MooseModel root allModels.
builder := CCBuilder new.
models notEmpty
ifTrue: [
> | namespaces classes classNormalizer 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: 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:
> 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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 / els2
do: [ :e |
e
translateTo:
> (e model position x + (e model
> @ (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 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(a)inf.unibe.ch
2016-12-14 18:32 GMT+01:00 Stephan Eggermont
<stephan(a)stack.nl>nl>:
A pre-spur pre-pharo5, that is.
Stephan
Verstuurd vanaf mijn iPhone
>
> Code City should work in Pharo 5.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev