[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]
From:       Nir Lisker <nlisker () gmail ! com>
Date:       2021-08-27 23:56:35
Message-ID: CA+0ynh8wzyGA_9CDttO7y9LO5O=7s9rEv+cK+4qwFDDZJQFB=w () mail ! gmail ! com
[Download RAW message or body]

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.rushforth@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 fo=
r
> 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 b=
y
> what ImagePattern does. It defines a "proportional" property as follows:
>
> "a boolean that indicates whether start and end locations are proportiona=
l
> 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 fals=
e,
> 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 tru=
e.
>
> What do you think?
>
> -- Kevin
>
>
>
> On 8/23/2021 7:25 PM, Michael Strau=C3=9F 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 <nlisker@gmail.com> <nlisker@g=
mail.com> wrote:
>
> Now I understand what you meant. However, the concept of normalized coord=
inates does not appear anywhere in JavaFX (at least not in these contexts).=
 I still think that coordinate transformations should be handled via dedica=
ted means, like coordinate system transformations are. Maybe when we work o=
n mapped bindings (I forgot that I need to review that) this pain point wil=
l 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 be=
havior remains.
> Another relevant point is that Transitions do something similar with thei=
r from_,  to_ and by_ methods. They start with Double.NaN to signal that th=
e 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.
>
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]