I think normalized coordinates are a very natural fit for the definition of a pivot point, which is why the current default value is an implicitly-specified normalized coordinate. Adding general-purpose coordinate transformations here feels like bringing a sledgehammer to crack a nut.
Having a property with an automagically updated "initial" value is quite non-standard behavior for properties. It would appear as if the property was bound, yet there's no binding. That's markedly different from a Transition's 'from' and 'to' properties, which are standard properties with normal behavior. A running transition doesn't bind to those properties, it uses a snapshot of their values when the transition starts. On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker <nlis...@gmail.com> wrote: > > Now I understand what you meant. However, the concept of normalized > coordinates does not appear anywhere in JavaFX (at least not in these > contexts). I still think that coordinate transformations should be handled > via dedicated means, like coordinate system transformations are. Maybe when > we work on mapped bindings (I forgot that I need to review that) this pain > point will be alleviated. > > Kevin, what if we only set the initial value of the pivot (doesn't matter > what the implementation detail is) to the center of the node for backwards > compatibility, but if the developer changes it to a custom value then it's on > them to compute the value again if they want to go back? The default behavior > remains. > Another relevant point is that Transitions do something similar with their > from_, to_ and by_ methods. They start with Double.NaN to signal that the > value should be ignored. While the developer can reset the value to NaN, it > is not something that is likely to happen during, say, an interpolation or as > a result of a binding. >
