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 posted in a comment an interactive test app. It should be simple enough to modify it for local testing.
I wasn't sure if the boolean properties should also be added to the transitions. The rotation axis and pivot properties are mostly a convenience since those can be updated on the node directly. My greatest concern is the confusion that happens with transforms: I need to be very careful when mixing those in since they use a different coordinate system by default. In a way, if Node and the transitions find it more natural to use normalized coordinates, shouldn't transforms find it natural too? Not sure if this is inconvenient only for me. On Sat, Aug 28, 2021 at 2:56 AM Nir Lisker <nlis...@gmail.com> wrote: > 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 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. > > > I don't see this as a problem. Each direction is independent. The bigger > problem I see is the surprise factor of NaN as a computed value. > > On Tue, Aug 24, 2021 at 6:16 PM Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> 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> >> <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. >> >> >> >>