* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every
single operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
? I do not get why.
Athens has indeed fast primitives to do this. We will
probably consider using them this once Athens will be part of Pharo.
I do not understand why you insist on saying that.
Even if Athens would not be part of Pharo Moose should use it!
I do not get why you want to wait that 3.0 is out. Because may be we should all wait that
igor leave RMoD do give him feedback.
Right now Athens takes 2 lines to load in Pharo3.0.
* Point 2:
missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
[ ... ]
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
We thought about using matrixes. And the nice things is to be able to do rotation, thing
that we cannot do right now in Roassal because we do not have matrixes. We are wondering
whether we should wait for Athens to be part of Roassal to use matrix or doing it our way.
Use Athens because igor is much better than us on vector graphics and Athens has all that.
By the way, using a matrix implies more operations
that Roassal actually does, because doing v * M has more operations than the method
#virtualToRealPoint:. However this does not really matter since this is rather cheap.
But your code in virtualToRealPoint: is not efficient: / float conversion….
then rounding it and then adding int.
* Point 3
about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
this has nothing to do with traits.
why you do not have
ROArrrow reversed
could probably works.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev