I have updated the PR to use DoubleProperties for the pivots and added 2
BooleanProperties for the normalized coordinates toggle on Node. To the
Rotate/ScaleTransitions I added only the pivot properties that update those
of the node. It's a prototype, so ignore docs and other miscellania.
I also
The problem I have with additional booleans is that they are not
reflected in the transitions, and to a lesser extent in the transforms.
I'm going to have to write an implementation and test it out to know how
well this works and how much trouble it really saves.
And while we could use NaN as an
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
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
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
Yes, calling it „relativePivot“ might have been a poor naming choice. The
purpose was to toggle between normalized/non-normalized coordinates,
effectively allowing developers to customize the „computed pivot“.
So instead of ignoring the specified X/Y/Z pivot coordinates and computing
the center
The special case of "center of the node" (the computed pivot) is the
current behavior, and it needs to be preserved for backwards compatibility.
This is why we were discussing the out of band values issues to begin with.
Reading the rest of what you wrote makes me think I didn't understand your
I think that „computed pivot“ is both an unnecessary terminology, and
really only one special case of a pivot coordinate in unit space where 0/0
is the top-left corner of the node, and 1/1 is the bottom-right corner of
the node (which is what I referred to as „relative“ coordinates).
Quite often,
I didn't page in enough of the discussion before. I remember now why we
need separate pivots for rotate and scale, so thank you for reminding
me. Btw, I don't think that necessarily means we need a separate switch
for whether to use computed vs explicit for each (but that would be a
