On Wed, 16 Apr 2025 18:43:01 GMT, Michael Strauß wrote:
>> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
>> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
>> apply the value before notifying the listeners.
>
> Michael Strauß has updated
On Wed, 16 Apr 2025 20:26:17 GMT, Kevin Rushforth wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8169285: SWT tests should run with IS_FULL_TEST
>
> build.gradle line 3085:
>
>> 3083:
>> 3084: test {
>> 3085:
On Wed, 16 Apr 2025 23:27:23 GMT, John Hendrikx wrote:
> If you still need one, I can provide a bit of code.
Thanks, that's ok, I would rather add the Dialog page to the MT, as it will
allow for more extensive testing.
>> modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.ja
On Wed, 16 Apr 2025 20:59:28 GMT, Andy Goryachev wrote:
> An SCCE would have been nice, to help with the review/testing.
>
> edit: alternatively, I'll add the (missing) Dialog/DialogPane page to the
> monkey tester. 🐒🔬
If you still need one, I can provide a bit of code. It basically is just
On Wed, 16 Apr 2025 21:30:11 GMT, Andy Goryachev wrote:
> yes, we still need `SWT_TEST` so we can disable it on mac.
If that flag is the mechanism we need to use to disable it on macOS, then we
will need the following additional change:
// Specifies whether to run system tests that depend on
On Wed, 16 Apr 2025 21:51:42 GMT, Kevin Rushforth wrote:
> > yes, we still need `SWT_TEST` so we can disable it on mac.
>
> If that flag is the mechanism we need to use to disable it on macOS, then we
> will need the following additional change:
>
> ```
> // Specifies whether to run system te
On Wed, 16 Apr 2025 21:22:28 GMT, Kevin Rushforth wrote:
> we can leave it enabled by default, in which case the only flag you would
> need is -PFULL_TEST=true.
I realize my statement might be ambiguous. I am not suggesting further changes
to build.gradle: you can leave it as:
enabled =
On Wed, 16 Apr 2025 21:17:16 GMT, Marius Hanl wrote:
>> With this change, you can now run the `swt` tests as easy as: `:swt:test
>> -PSWT_TEST=true`.
>> 
>>
>> Note: At one point `IS_FULL_TEST` was used as
On Wed, 16 Apr 2025 08:51:36 GMT, John Hendrikx wrote:
> The "show details" hyperlink button in an alert dialog that has an expandable
> detail area wipes out its base style class by overwriting all styles. This
> means styling in modena.css that targets `.hyperlink` is no longer applied,
> li
On Wed, 16 Apr 2025 19:00:53 GMT, Marius Hanl wrote:
> Linux fails with `org.eclipse.swt.SWTError: No more handles [gtk_init_check()
> failed]` when creating the `Display`.
does it fail with `IS_FULL_TEST=true`?
-
PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810
Tries to address the mystery of missing graphic in the TabPane overflow menu:
# Overflow Menu Graphic Property in the TabPaneSkin
Andy Goryachev
## Summary
Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates
the current limitation of this skin
in supporting menu
On Wed, 16 Apr 2025 18:48:09 GMT, Marius Hanl wrote:
> Note: At one point IS_FULL_TEST was used as well for the enablement of the
> tests. I don't see any reason for it.
All headful tests are qualified by `IS_FULL_TEST`, so this should remain here,
too. We do the same thing when enabling robot
On Wed, 16 Apr 2025 08:51:36 GMT, John Hendrikx wrote:
> The "show details" hyperlink button in an alert dialog that has an expandable
> detail area wipes out its base style class by overwriting all styles. This
> means styling in modena.css that targets `.hyperlink` is no longer applied,
> li
On Wed, 16 Apr 2025 17:07:09 GMT, Kevin Rushforth wrote:
>> Gopal Pattnaik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java
>
On Wed, 16 Apr 2025 20:10:56 GMT, Andy Goryachev wrote:
> > default factory should not be a `null` value.
>
> oh, I see. I think it makes the life easier, since there is no need to
> publish the pointer to the deficient `DEFAULT_FACTORY`.
>
> This property can be qualified with "override" to m
On Wed, 16 Apr 2025 15:13:23 GMT, Gopal Pattnaik wrote:
>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be
>> insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
On Wed, 16 Apr 2025 16:35:39 GMT, Kevin Rushforth wrote:
>> Andy Goryachev 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
>> com
> The code should not set the `Task.state` value to `CANCELLED` if the said
> task is already `SUCCEEDED` or `FAILED`.
>
> This is a product bug.
>
> Added `@RepeatedTest(50)` to the tests that used to fail intermittently -
> this made the test failed more reliably without the fix.
Andy Goryac
On Wed, 16 Apr 2025 20:03:14 GMT, Michael Strauß wrote:
> default factory should not be a `null` value.
oh, I see. I think it makes the life easier, since there is no need to publish
the pointer to the deficient `DEFAULT_FACTORY`.
This property can be qualified with "override" to make it clea
With this change, you can now run the `swt` tests as easy as: `:swt:test
-PSWT_TEST=true`.

Note: At one point `IS_FULL_TEST` was used as well for the enablement of the
tests. I don't see any reason for it,
On Wed, 16 Apr 2025 15:13:23 GMT, Gopal Pattnaik wrote:
>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be
>> insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
On Wed, 16 Apr 2025 19:27:10 GMT, Andy Goryachev wrote:
> > then have null mean "I want no overflow menu"
>
> An interesting suggestion.
>
> This would be a much larger change, since we would have to remove the button
> as well. Also, the `menuGraphicFactory` seems rather unrelated to the
> o
On Wed, 16 Apr 2025 16:23:14 GMT, Kevin Rushforth wrote:
>> Andy Goryachev 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
>> com
On Wed, 16 Apr 2025 18:48:09 GMT, Marius Hanl wrote:
> With this change, you can now run the `swt` tests as easy as: `:swt:test
> -PSWT_TEST=true`.
> 
>
> Note: At one point `IS_FULL_TEST` was used as well
On Wed, 16 Apr 2025 18:23:07 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 996:
>>
>>> 994: // Needs to be set before needsLayout is updated, as otherwise
>>> a listener that
>>> 995: // calls isNeedsLayout() might see the old
On Wed, 16 Apr 2025 17:05:55 GMT, Andy Goryachev wrote:
>> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
>> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
>> apply the value before notifying the listeners.
>
> modules/javafx.graphics/sr
On Wed, 16 Apr 2025 18:43:01 GMT, Michael Strauß wrote:
>> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
>> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
>> apply the value before notifying the listeners.
>
> Michael Strauß has updated
On 4/16/25 3:04 AM, Glavo wrote:
* Different image APIs have to repeatedly implement support for
reading the same image format (such as JPEG).
In fact, AWT, JavaFX, and Android now each implement reading JPEG
images.
This is a waste.
I was initially frustrated by the split between Java (A
On Wed, 16 Apr 2025 19:22:00 GMT, Michael Strauß wrote:
> then have null mean "I want no overflow menu"
An interesting suggestion.
This would be a much larger change, since we would have to remove the button as
well. Also, the `menuGraphicFactory` seems rather unrelated to the overflow
menu
On Fri, 11 Apr 2025 18:17:59 GMT, Andy Goryachev wrote:
> Tries to address the mystery of missing graphic in the TabPane overflow menu:
>
> # Overflow Menu Graphic Property in the TabPaneSkin
>
> Andy Goryachev
>
>
>
>
> ## Summary
>
> Introduce a `menuGraphicFactory` property in the `TabP
On Wed, 16 Apr 2025 18:23:01 GMT, Marius Hanl wrote:
> As discussed in #1778, those test does not need to be parameterized, we
> therefore can replace `@ParameterizedTest` and `@MethodSource` with `@Test`.
looks good. thank you for making changes!
-
Marked as reviewed by angorya
> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
> apply the value before notifying the listeners.
Michael Strauß has updated the pull request with a new target base due to a
merge or a re
On Wed, 16 Apr 2025 16:45:32 GMT, Andy Goryachev wrote:
>> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
>> property getter returns the wrapper itself, but what it should be doing is
>> return the read-only getter instead.
>>
>> A single reviewer should be sufficient
On Wed, 16 Apr 2025 18:29:18 GMT, Andy Goryachev wrote:
>> It's very unlikely to cause regressions, because `needsLayoutProperty()` is
>> not used anywhere in JavaFX. The only thing that is different now is that a
>> listener added to this property will see the correct value when calling
>> `i
On Wed, 16 Apr 2025 16:45:32 GMT, Andy Goryachev wrote:
> Looks good.
>
> Do you know if there is an easy way to find similar issues elsewhere?
Nothing comes to mind, short of checking all usages of the *Wrapper
implementations.
-
PR Comment: https://git.openjdk.org/jfx/pull/1780
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
Th
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
Se
As discussed in #1778, those test does not need to be parameterized, we
therefore can replace `@ParameterizedTest` and `@MethodSource` with `@Test`.
-
Commit messages:
- 8354794: [TestBug] LocalDateTimeStringConverterTest: Not all Tests needs to
be parameterized
Changes: https://g
On Tue, 15 Apr 2025 20:16:04 GMT, Marius Hanl wrote:
> [JDK-8297316](https://bugs.openjdk.org/browse/JDK-8297316) added a Workaround
> for the Japanese Date Converter, which is different on JDK20 and newer. Since
> our Boot JDK is Java 22 as of April 2025, we can remove the workaround.
>
> We
On Fri, 11 Apr 2025 20:36:48 GMT, Marius Hanl wrote:
> These are the remaining bits and pieces in order to completely remove the
> JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as
> information) or close
> [JDK-82962
On Wed, 16 Apr 2025 10:31:50 GMT, Michael Strauß wrote:
> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
> apply the value before notifying the listeners.
modules/javafx.graphics/src/main
On Thu, 10 Apr 2025 12:41:44 GMT, Ziad El Midaoui
wrote:
> When the Root TreeItem is set to null, need to relayout to show the children
> items
if you merge the latest `master` branch it'll get rid of the build error on
windows.
-
PR Comment: https://git.openjdk.org/jfx/pull/176
On Fri, 11 Apr 2025 17:06:38 GMT, Andy Goryachev wrote:
>> The code should not set the `Task.state` value to `CANCELLED` if the said
>> task is already `SUCCEEDED` or `FAILED`.
>>
>> This is a product bug.
>>
>> Added `@RepeatedTest(50)` to the tests that used to fail intermittently -
>> this
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
Lo
> Implementation of [CSS media
> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
Michael Strauß has updated the pull request incrementally with one additional
commit since the last revision:
reorder fields
-
Changes:
- all: https://git.openjdk.org/jfx
> Implementation of [CSS media
> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
Michael Strauß has updated the pull request incrementally with one additional
commit since the last revision:
remove ReadOnlyBooleanWrapper
-
Changes:
- all: https://git.
On Mon, 14 Apr 2025 12:44:42 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java
>> line 246:
>>
>>> 244: }
>>> 245:
>>> 246: public synchronized void fireValueChangedIfNecessary() {
>>
>> I notic
> Implementation of [CSS media
> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
Michael Strauß has updated the pull request incrementally with one additional
commit since the last revision:
Scene preferences only actively observe platform preferences when the scene
On Wed, 16 Apr 2025 15:13:23 GMT, Gopal Pattnaik wrote:
>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be
>> insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be
> insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
>
> Verification:
> Tested in Windows 11, and the Assert fai
Sounds good. Have you tried a prototype implementation for a built-in
JavaFX control/Pane, just to see how well it works?
On Wed, Apr 16, 2025 at 5:50 PM Andy Goryachev
wrote:
> This might be a good idea from an API perspective, but please be careful -
> this optimization might break the behavio
This might be a good idea from an API perspective, but please be careful - this
optimization might break the behavior. For instance, the scroll bar might
change as a result of a key event in the TextArea, so the text layout is still
needed, however expensive.
(and I like Michael's suggestion of
On Wed, 16 Apr 2025 08:31:16 GMT, Marius Hanl wrote:
> check the two other tickets
will do!
-
PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2809801813
On Wed, 16 Apr 2025 08:19:46 GMT, Marius Hanl wrote:
>> These are the remaining bits and pieces in order to completely remove the
>> JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as
>> information) or close
>> [JDK-
When the Root TreeItem is set to null, need to relayout to show the children
items
-
Commit messages:
- Fixed issue with TreeTableView not showing the root's children when set to
null
Changes: https://git.openjdk.org/jfx/pull/1767/files
Webrev: https://webrevs.openjdk.org/?repo=
On Thu, 10 Apr 2025 12:41:44 GMT, Ziad El Midaoui
wrote:
> When the Root TreeItem is set to null, need to relayout to show the children
> items
Good job, the fix seems to be working.
You can also try using the monkey tester to test various scenarios, I've
updated it to include null values fo
On Wed, 16 Apr 2025 08:56:26 GMT, John Hendrikx wrote:
>> Sure. I'll look into it.
>
> To be honest, I don't understand why we specify this at all. "white" surely
> won't be the default when running on dark theme... I'm pretty sure on Windows
> it isn't even white, it's some light gray.
When
Yes, this does seem useful.
-- Kevin
On 4/16/2025 1:36 AM, Michael Strauß wrote:
This sounds like a useful addition. Maybe it should be named
requestLayoutChildren() to indicate what will be happening.
On Wed, 16 Apr 2025 08:19:46 GMT, Marius Hanl wrote:
>> These are the remaining bits and pieces in order to completely remove the
>> JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
>> After that, we should either document, that JUnit5 is used (just as
>> information) or close
>> [JDK-
On Wed, 16 Apr 2025 10:31:50 GMT, Michael Strauß wrote:
> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
> apply the value before notifying the listeners.
Looks good to me. I didn't see
On Wed, 16 Apr 2025 09:47:14 GMT, Gopal Pattnaik wrote:
>> There was a Assertion fail issue in mouse location test case JDK-8296554,
>> Reason: We felt the one mili second delay time for the Robot test may be
>> insufficient in few OS.
>> Solution: We Changed the delay time to three mili second.
On Wed, 16 Apr 2025 10:10:36 GMT, Ambarish Rapte wrote:
>> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
>> property getter returns the wrapper itself, but what it should be doing is
>> return the read-only getter instead.
>>
>> A single reviewer should be sufficient
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
Ma
A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
apply the value before notifying the listeners.
-
Commit messages:
- fix
- failing test
Changes: https://git.openjdk.org/jfx/pul
Hi,
I’d like to get your thoughts on what the expected behavior should be when
setting the size of a window while it's in a maximized state.
Here are the options I’ve considered:
a) Ignore the resize while maximized, and when restored, revert to the size
before it was maximized
b) Demaximize the
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
lg
Currently, there are multiple different image APIs in the Java ecosystem:
AWT, JavaFX, Android, etc.
What's worse, the Android platform does not provide support for AWT, making
the Java ecosystem even more fragmented.
There are some obvious problems with the current situation:
* Third-party libra
> There was a Assertion fail issue in mouse location test case JDK-8296554,
> Reason: We felt the one mili second delay time for the Robot test may be
> insufficient in few OS.
> Solution: We Changed the delay time to three mili second.
>
> Verification:
> Tested in Windows 11, and the Assert fai
`Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
property getter returns the wrapper itself, but what it should be doing is
return the read-only getter instead.
A single reviewer should be sufficient.
-
Commit messages:
- fix
- failing test
Changes: https
On Tue, 15 Apr 2025 17:18:48 GMT, Thiago Milczarek Sayao
wrote:
>> If it's a bug, could you please create a JBS ticket?
>
> Sure. I'll look into it.
To be honest, I don't understand why we specify this at all. "white" surely
won't be the default when running on dark theme... I'm pretty sure o
The "show details" hyperlink button in an alert dialog that has an expandable
detail area wipes out its base style class by overwriting all styles. This
means styling in modena.css that targets `.hyperlink` is no longer applied,
like the default text fill colors.
The culprit is this code in Dia
This sounds like a useful addition. Maybe it should be named
requestLayoutChildren() to indicate what will be happening.
On Tue, 15 Apr 2025 22:19:24 GMT, Kevin Rushforth wrote:
> Yes, I would prefer a new JBS ticket. It would be OK to combine that as part
> of this PR, since both are test fixes touching the same file. It would also
> be OK to leave it for another day. Either is fine.
I created [JDK-8354794](htt
On Tue, 15 Apr 2025 22:32:38 GMT, Kevin Rushforth wrote:
> One option for [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285)
> would be to enable it -- optionally on the `SWT_TEST` flag -- as part of
> _this_ PR. If you choose to do that, add that issue to this PR with`/issue
> add`.
> These are the remaining bits and pieces in order to completely remove the
> JUnit Vintage Engine, and therefore JUnit 4 from JavaFX.
> After that, we should either document, that JUnit5 is used (just as
> information) or close
> [JDK-8296284](https://bugs.openjdk.org/browse/JDK-8296284) (Since
On Tue, 15 Apr 2025 22:14:11 GMT, Kevin Rushforth wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix SWT Tests
>
> modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTTest.java line 2:
>
>> 1: /*
>> 2: * Co
76 matches
Mail list logo