Transform point using localToSceneTransform

[Pedro Duque Vieira]

Hi,

Ok, I'll just say that I don't think there are any running javafx applets
out there.

Thanks, cheers,


> Hello,
> it was already discussed on this mailing list. We cannot shut down
> auto-updates because they are required for security reasons in
> connection with running applets. We are doing our best to achieve
> backward compatibility and a failure in the early releases (deliberate
> or not) doesn't justify for future violations.
> Thanks,
> Pavel
> On 9.8.2012 21:21, Pedro Duque Vieira wrote:
> > 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