Transform point using localToSceneTransform

[Pavel Safrata]

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,
>>>>>>
>>>
>