Change in class blueprint
by Alexandre Bergel
Hi!
I am updating some code found in class blueprint. I have migrated the method:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
createEdgesFor: aClass andLayers: layers on: view
(RTEdge
buildEdgesFromObjects: aClass incomingAccesses
from: #from
to: #to
using:
(RTLine new
color: Color lightBlue;
attachPoint: RTHorizontalAttachPoint instance)
inView: view) do: [ :each | each moveBehind: (layers flatCollect: #value) ].
(RTEdge
buildEdgesFromObjects: aClass outgoingInvocations
from: #from
to: [ :each | each candidates detect: [ :c | c typeScope = aClass ] ifNone: [ nil ] ]
using: (RTLine new attachPoint: RTHorizontalAttachPoint instance)
inView: view) do: [ :each | each moveBehind: (layers flatCollect: #value) ]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
to:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
createEdgesFor: aClass andLayers: layers on: view
| eb edges to |
eb := RTEdgeBuilder new.
eb view: view.
eb shape line; color: Color lightBlue; horizontalAttachPoint.
edges := aClass incomingAccesses flatCollect: [ :acc | eb connectFrom: acc from to: acc to ].
edges do: [ :each | each moveBehind: (layers flatCollect: #value) ].
eb := RTEdgeBuilder new.
eb view: view.
eb shape line; horizontalAttachPoint.
to := [ :each | each candidates detect: [ :c | c typeScope = aClass ] ifNone: [ nil ] ].
edges := aClass outgoingInvocations flatCollect: [ :acc |
eb connectFrom: acc from to: (to value: acc) ].
edges do: [ :each | each moveBehind: (layers flatCollect: #value) ]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I thought about a #source: on the EdgeBuilder, but I am not sure this will be really useful...
I think this does not change the behavior… but we never know.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 1 month
Roassal RTAttachPoint inverted
by Peter Uhnák
Hi Alex,
I've noticed that with addition of DoubleArrowedLine you've also added
concept of "inverted" to attach points.
This seems really strange from the perspective that all methods
startingPointOf:
and
endingPointOf:
are identical only with swapped ifTrue:/ifFalse:
for example
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
startingPointOf: anEdge
^ (inverted ifTrue:[anEdge to] ifFalse:[anEdge from]) position
endingPointOf: anEdge
^ (inverted ifTrue: [anEdge from] ifFalse: [anEdge to]) position
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
this is harder to read and more error-prone than
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
startingPointOf: anEdge
^ anEdge from position
endingPointOf: anEdge
^ anEdge to position
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plus there is code duplication. And this is just the simplest attach point.
Since I should also add "inverted" to my attach points that are in Roassal
(RTRectangleAttachPoint, ...)
maybe the actual computation should be delegated?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RTAttachPoint>>startingPointOf: anEdge
^ inverted
ifTrue: [ self basicEndingPointOf: anEdge ]
ifFalse: [ self basicStartingPointOf: anEdge ]
RTAttachPoint>>endingPointOf: anEdge
^ inverted
ifTrue: [ self basicStartingPointOf: anEdge ]
ifFalse: [ self basicEndingPointOf: anEdge ]
RTAttachPoint>>basicStartingPointOf: anEdge
^ self subclassResponsibility
RTAttachPoint>>basicEndingPointOf: anEdge
^ self subclassResponsibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This also will not break current implementation but it will give
opportunity to improve them.
And if there was a situation where the implementation would be actually
different for inverted (and not just swapped values), than you could still
just implement startingPointOf:/endingPointOf:
Thanks,
Peter
8 years, 1 month
Roassal on Bloc on not Pharo
by Peter Uhnák
Hi,
I am wondering... how will moving Roassal to Bloc affect other platforms
such as VisualWorks? Because it seems it would be unportable with Bloc, no?
Peter
8 years, 1 month
TRCanvas inspector
by Peter Uhnák
Why is TRCanvas rendered in inspector using RTView?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TRCanvas>>gtInspectorViewIn: composite
<gtInspectorPresentationOrder: -10>
composite roassal2
title: 'Canvas';
initializeView: [ RTView new setCanvas: self ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shouldn't this be isolated from Roassal layer?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TRCanvas>>gtInspectorCanvasIn: composite
<gtInspectorPresentationOrder: -20>
composite morph
title: 'Canvas';
morph: [
self buildMorph.
self morph ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter
8 years, 1 month
Refactoring GT Presentations
by Sean P. DeNigris
It would be nice if the implementations were a bit more standard. I was
trying to extract "render in scroll pane" from the Magritte presentation,
but each presentation has a slightly different message to create the morph
e.g. #magritteMorphFor:, #morph, and #morphFor:, so I had to do something
uglier than I wanted.
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Refactoring-GT-Presentations-tp4840672.html
Sent from the Moose mailing list archive at Nabble.com.
8 years, 1 month
Large API vs Builder like API
by Alexandre Bergel
Hi!
It would be great to get feedback from you guys.
We have the class TRConstraint that allows for roassal elements to be aligned (cf Section 10 in https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0... <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0...>).
Currently, you can write:
TRConstraint use: centralDot alignFromTop: negativeElements
Which align all the elements contained in the collection negativeElements against a fix point, centralDot.
It looks pretty easy to read. However, the class TRConstraint has many methods (alignFromBottom:, alignFromLeft:, use: aShape alignFromBottom: shapes, …) which are essentially all duplicated code.
So, I though about creating a compact class, called RTAlignment. You can now write:
RTAlignment new elements: negativeElements; fixedElement: centralDot; top
But, I find that less nice to read. Any opinion?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 years, 1 month
