On Mon, 21 Jul 2025 17:17:38 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> There first needs to be a new bug filed. Once there is, and a fix is
> available, we can see how
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Sat, 5 Jul 2025 02:32:18 GMT, Glavo wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
>
> I know this is a problem with our app
On Sat, 5 Jul 2025 02:32:18 GMT, Glavo wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
>
> I know this is a problem with our app
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Mon, 24 Mar 2025 21:30:50 GMT, Andy Goryachev wrote:
>> Yes, sorry, this was addressed in the larger discussion. I've left this
>> as-is to keep the PR focus'd on one thing.
>>
>> The calculation here is using 3 snapped values, and one can reasonably
>> assume the result is "nearly" snappe
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 23:11:45 GMT, Andy Goryachev wrote:
>>> good point!
>>>
>>> This is exactly the reason for the code in ScaledMath:71
>>>
>>> ```
>>> return Math.ceil(d - Math.ulp(d)) / scale;
>>> ```
>>
>> Yeah, but I think we may want to subtract more than just 1 ulp. A one ulp
>> diffe
On Mon, 24 Feb 2025 17:30:29 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
> 2049:
>
>> 2047:
On Mon, 24 Mar 2025 21:26:53 GMT, John Hendrikx wrote:
> Any "near" snapped values won't accidentally get rounded up to the next
> higher pixel
I like this idea!
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010953537
On Mon, 24 Mar 2025 17:59:03 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
>> 2093:
>>
>>> 2091: double right = margin != null ? snapSpaceX(margin.getRight(),
>>> snap) : 0;
>>> 2092:
>>> 2093: return width - left - r
On Mon, 24 Mar 2025 17:55:50 GMT, Kevin Rushforth wrote:
>> I think you are onto something here. It almost feels like we shouldn't be
>> doing ceil/floor at all, rounding to the closest pixel instead.
>
> This would be a much larger change, though. Perhaps something to consider for
> a future
On Mon, 24 Feb 2025 17:21:10 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
> 2093:
>
>> 2091:
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Tue, 25 Feb 2025 00:42:04 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two additional
>> comm
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Fri, 28 Feb 2025 23:08:23 GMT, Andy Goryachev wrote:
> I think the main concern with the reformatting/tangentially related changes
> coming from the maintainers is the general pain associated with conflicts
> created when merging and backporting.
It's not just this, it's also about avoiding
On Mon, 24 Feb 2025 20:54:05 GMT, Andy Goryachev wrote:
>> Yeah, or possibly zero included. What I meant here is that these are
>> **real** values, and don't have a "special" value `-1` meaning
>> absent/unavailable.
>
> A _very quick_ test with the monkey tester showed it never entered
> `bo
On Fri, 28 Feb 2025 21:35:30 GMT, John Hendrikx wrote:
>> In theory, all these calculations end up being used by the layoutChildren()
>> which always (?) snap the values.
>>
>> So the question is whether this small error gets accumulated enough to shift
>> the result to a wrong value. Given a
On Fri, 28 Feb 2025 21:14:54 GMT, Andy Goryachev wrote:
>> I just copied the style that was being used, but can make any changes
>> desired of course (at the expense of increasing the diff and amount of code
>> to review).
>
> I know it's a general policy not to do unrelated changes or reformat
On Fri, 28 Feb 2025 21:52:36 GMT, John Hendrikx wrote:
>> Come to think of it, most the issues here are caused by using functions like
>> `floor` and `ceil`. It might be an idea to change these functions to bias
>> them slightly towards rounding to the closest value, instead of always doing
>
On Fri, 28 Feb 2025 22:09:19 GMT, John Hendrikx wrote:
>> I know it's a general policy not to do unrelated changes or reformatting,
>> but I think in this case
>> a) it's a test and
>> b) you already touched it
>> so might as well.
>
> I can do this, but realize that the test is large, and ther
On Fri, 28 Feb 2025 21:46:13 GMT, Andy Goryachev wrote:
>> That's absolutely true, however this can change quickly when large values
>> are added or subtracted to/from small values, or when division or
>> multiplication gets involved. So I'd say its relatively safe to do simple
>> calculation
On Fri, 28 Feb 2025 21:48:54 GMT, John Hendrikx wrote:
>> good point!
>>
>> This is exactly the reason for the code in ScaledMath:71
>>
>> return Math.ceil(d - Math.ulp(d)) / scale;
>
> Come to think of it, most the issues here are caused by using functions like
> `floor` and `ceil`. It might
On Fri, 28 Feb 2025 21:09:30 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java
>> line 349:
>>
>>> 347: assertEquals(240 /* l + r + c*/, borderpane.prefHeight(-1),
>>> 1e-10);
>>> 348: assertEquals(110, borderpane.mi
On Mon, 24 Feb 2025 20:48:38 GMT, Andy Goryachev wrote:
>> LOL, I think I may have said that :) However, perhaps the problem is not as
>> bad as I made it out to be. It's definitely true that any operation on a
>> floating point value may slightly nudge it away from a true snapped value
>> (
> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when
> its fill width property is set to `false`. This manifests itself with labels
> that have their wrap text property set to `true`, and the container is not
> wide enough to hold the text on a single line (in other w
> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when
> its fill width property is set to `false`. This manifests itself with labels
> that have their wrap text property set to `true`, and the container is not
> wide enough to hold the text on a single line (in other w
On Fri, 28 Feb 2025 19:54:22 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two additional
>> commi
On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
Thank you for detecting and fixing this issue guys. I have spent many days /
weeks chasing issues related to this issue. It often came up with my custom
controls and I was always assuming that it is me making a mistake. I never even
considered that this might be a bug in the layout code.
Dirk
On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Mon, 24 Feb 2025 20:30:17 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and the container
>> is
On Mon, 24 Feb 2025 20:41:29 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
>> 2044:
>>
>>> 2042: * # content width/heights:
>>> 2043: *
>>> 2044: * The space allocated to a child, minus its margins. These are
>>> never -1
On Mon, 24 Feb 2025 20:39:01 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
>> 2020:
>>
>>> 2018: double baseline = child.getBaselineOffset();
>>> 2019: if (child.isResizable() && baseline ==
>>> BASELINE_OFFSET_S
On Mon, 24 Feb 2025 17:19:58 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two additional
>> commi
> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when
> its fill width property is set to `false`. This manifests itself with labels
> that have their wrap text property set to `true`, and the container is not
> wide enough to hold the text on a single line (in other w
On Sat, 22 Feb 2025 15:57:28 GMT, John Hendrikx wrote:
> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when
> its fill width property is set to `false`. This manifests itself with labels
> that have their wrap text property set to `true`, and the container is not
>
On Sat, 22 Feb 2025 15:57:28 GMT, John Hendrikx wrote:
> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when
> its fill width property is set to `false`. This manifests itself with labels
> that have their wrap text property set to `true`, and the container is not
>
45 matches
Mail list logo
