I definitely don't like having a "magic" initial value that can't be
reset, so that won't work. And while we could use NaN as an out of band
value meaning "computed", that still runs into the problem of allowing
for the odd case where X is computed and Y is specified.
If we do go with the idea of allowing the coordinates to be a percentage
of the bounding box, with 0.5 as the default, then we could be informed
by what ImagePattern does. It defines a "proportional" property as follows:
"a boolean that indicates whether start and end locations are
proportional or absolute. If this flag is true, the two end points are
defined in a coordinate space where coordinates in the range |[0..1]|
are scaled to map onto the bounds of the shape that the pattern fills.
If this flag is false, then the coordinates are specified in the local
coordinate system of the node."
That's basically what we are doing if we go with Michael's idea. So if
we do this, the two boolean properties could be named something like
scalePivotProportional and rotatePivotProportional, with a default of true.
What do you think?
-- Kevin
On 8/23/2021 7:25 PM, Michael Strauß wrote:
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.
