Transform point using localToSceneTransform

[Pedro Duque Vieira]

Hi,

I think worrying about retaining backwards compatibility at this stage, so
early in the life of javafx might be an overkill, and jeopardize the future
of the platform. I personally think this should be questioned more and not
taken as an absolute truth.

Backwards compatibility has already been seriously broken from 1.3 to 2.0
and everybody thought it was a good thing you did it.

If the problem is the auto-update of javafx maybe this could be shut down.
And isn't backwards compatibility already being broken although not in a
deliberate way on each release. I remember at least some code changes I had
to make when I transitioned from 2.0 to 2.1 in order to make my app work.

Just my 2 cents, thanks and best regards,




> On 1.8.2012 18:01, Pavel Safrata wrote:
> > On 28.7.2012 0:06, Richard Bair wrote:
> >> Vector3D extends Point3D?
> >
> > No. Vector is not point and point is not vector. As Kevin suggested
> > they may have a common parent - Tuple.
> >
> > Here is the list of things that currently use Point3D as a vector (all
> > of them on class Rotate):
> >
> > X_AXIS, Y_AXIS, Z_AXIS
> >     we would have to deprecate those and define different ones with
> > some uglier names
> >
> > Rotate(double angle, Point3D axis)
> > Rotate(double angle, double pivotX, double pivotY, double pivotZ,
> > Point3D axis)
> >     we would have to deprecate those and overload them with another
> > ones taking Vector3D
> >
> > Point3D getAxis()
> > void setAxis(Point3D value)
> > ObjectProperty<Point3D> axisProperty()
> >     this is the biggest issue, even if we wanted to deprecate the
> > property I don't know what name could have the new one, also we would
> > have to maintain them both, bound to each other, until the old one is
> > removed.
> >
> And on Node:
> void setRotationAxis(Point3D value)
> Point3D getRotationAxis()
> ObjectProperty<Point3D> rotationAxisProperty()
> I've been thinking about this over and over and I'm not happy to say
> that I think I'm starting to change my mind. As I'm still completely
> convinced that separating vector from point is the right thing to do, in
> our situation it would nearly destroy our rotation API (which is very
> unfortunate because axis is not point in any sense! - But at least its
> name is now 'axis'). I don't like merging the two species in Point3D but
> at least this way we can do our best to minimize the damage by designing
> the new API somehow sensitively..
> Pavel
> > This is quite a serious argument against separating point and vector.
> >
> > Looks like on one side we have ugly Rotate with some deprecated stuff,
> > on the other side we have ugly Point with nonsense methods and a bit
> > ugly methods in Affine. I still vote for separating because ugly
> > property name seems lesser evil than wrong concept and weird method
> > names. Anyway, this is a backward compatibility issue and Richard will
> > probably have the final word here.
> >
> > Pavel
> >
> >>
> >> On Jul 27, 2012, at 2:19 PM, Jim Graham wrote:
> >>
> >>> This is starting to make sense to me as I see more examples of how
> >>> the 2 are used.  I'm definitely seeing the value of separate types
> >>> for making code readable and for encouraging proper math.  It's like
> >>> making our geometry code "strongly typed" - in the Java spirit...
> >>>
> >>>             ...jim
> >>>
> >>> On 7/26/2012 7:35 AM, Pedro Duque Vieira wrote:
> >>>> Hi again,
> >>>>
> >>>>
> >>>>> Hi Kirill,
> >>>>> On 26.7.2012 10:10, Kirill.Prazdnikov wrote:
> >>>>>> On 26.07.2012 10:20, Pavel Safrata wrote:
> >>>>>>> Exactly, I think the point is that 'point' is not 'vector'
> >>>>>>> regardless
> >>>>>>> of what workarounds we introduce in method naming and
> >>>>>>> documentation.
> >>>>>>> Those methods would look really weird on Point.
> >>>>>> Both are from the same R3 space, right ?
> >>>>> Right.
> >>>>>> And we can add them together :
> >>>>>>   Vector speed, position;
> >>>>>>    position += time * speed;
> >>>>>>
> >>>>>> I vote for Jim`s approach.
> >>>>> Does it make sense to add two points? I think it doesn't. So if we
> >>>>> have
> >>>>> Point and Vector, we need something like Point.add(Vector) or
> >>>>> Point.shift(Vector). In Jim's approach we need Point.add(Point) with
> >>>>> documentation stating that one of the points represents a point
> >>>>> and the
> >>>>> other one represents a vector. So what is the advantage?
> >>>> Exactly. Adding two points doesn't make sense.
> >>>>
> >>>>
> >>>>
> >>>>>> If a transform is { M3x3 + Translate }, them
> >>>>>>   - transformPoint (normal transform) would be { P*M3x3 +
> >>>>>> Translate }
> >>>>>>   - transformVector (delta transform) would be { P*M3x3 }
> >>>>> We already know that it is possible to represent both things by one
> >>>>> class and move the distinction to method names and documentation. But
> >>>>> please explain what is the advantage of it (except the obvious one of
> >>>>> having lower class count).
> >>>>> Thanks,
> >>>>> Pavel
> >>>>>> -Kirill
> >>>>
> >>>> If you go this way with point you could go this way with a lot of
> >>>> other
> >>>> framework classes: say you could use Point2d to represent a
> >>>> Dimension2d, a
> >>>> BoundingBox to represent a Rectangle2D or Insets, etc.
> >>>> I personally don't really think this is a good approach.
> >>>>
> >>>> Thanks, best regards,
> >>>>
> >
> >


-- 
Pedro Duque Vieira