On Thu, 16 Jan 2025 22:46:39 GMT, Andy Goryachev wrote:
>> Good to know, we should document your solution in more detail (and with the
>> concrete fix -> code snippet from the RTA) together with the HSB bug as a
>> new ticket probably? Then we may already have a potential solution with
>> code
On Thu, 16 Jan 2025 15:47:04 GMT, Andy Goryachev wrote:
>> That is right, but the `pulse` call will call `layout`, which will call
>> `layoutChildren` (when needed). I could also just call `layout` directly,
>> but want to keep it the same way as the actual Application would behave.
>
> Relying
On Thu, 16 Jan 2025 19:51:29 GMT, Andy Goryachev wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java
>> line 221:
>>
>>> 219: /** {@inheritDoc} */
>>> 220: @Override protected void layoutChildren(double x, double y, double
>>> w, double h) {
On Thu, 16 Jan 2025 20:50:47 GMT, Andy Goryachev wrote:
> The not-so-good news is that there is a configuration when the HSB remains,
> but once you click on it it disappears (might be hard to reproduce). In both
> this PR and with the master branch, the HSB remains even though it's not
> need
On Thu, 16 Jan 2025 12:26:19 GMT, Marius Hanl wrote:
>> This is more likely an 'accidential' fix. I changed this code because the
>> code in the super class changed (e.g. `updateCells` and `updateChildren`).
>> So while I see your point, if possible I would not tr
irtualFlow` sheet (as
> children). This will cause them to actually do the layout when requested, and
> especially when the height of the `TableView` changed drastically (e.g. from
> 50 visible cells to just 10), we have 40 cells laying around, receiving the
> layout request I added t
On Thu, 16 Jan 2025 12:18:03 GMT, Marius Hanl wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java
>> line 221:
>>
>>> 219: /** {@inheritDoc} */
>>> 220: @Override protected void layoutChildren(double
irtualFlow` sheet (as
> children). This will cause them to actually do the layout when requested, and
> especially when the height of the `TableView` changed drastically (e.g. from
> 50 visible cells to just 10), we have 40 cells laying around, receiving the
> layout request I added
On Wed, 15 Jan 2025 19:22:50 GMT, Jose Pereda wrote:
>> Marius Hanl has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
On Thu, 16 Jan 2025 11:12:25 GMT, Jose Pereda wrote:
>> Unfortunately I don't think there is any other way. The `VirtualFlow` needs
>> two pulses (in real life applications) as the first time, the layout is not
>> yet correct for some cases (e.g. for `No ScrollBar` -> `ScrollBar`). I even
>> u
On Wed, 15 Jan 2025 18:50:58 GMT, Jose Pereda wrote:
>> Marius Hanl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains four commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/j
On Thu, 16 Jan 2025 07:18:07 GMT, Johan Vos wrote:
>> Marius Hanl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains four commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/j
irtualFlow` sheet (as
> children). This will cause them to actually do the layout when requested, and
> especially when the height of the `TableView` changed drastically (e.g. from
> 50 visible cells to just 10), we have 40 cells laying around, receiving the
> layout request I added t
On Tue, 10 Dec 2024 23:28:05 GMT, Andy Goryachev wrote:
>> It will be much better after https://github.com/openjdk/jfx/pull/1644 :)
>
> can you apply the same treatment as in #1644? there at least it makes sense.
I would say, lets merge https://github.com/openjdk/jfx/pull/1644 first and then
i
On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote:
> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not
> modify the layout of `VirtualFlow`.
>
> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`,
> which made many calculat
On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote:
> The JUnit Platform got some updates over the last years, so it is a good idea
> to update it to the newest version.
>
> That is from `5.8.1` to `5.11.3`.
> Affected dependencies:
> - `junit.jupiter`
> - `junit.plat
On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote:
> This PR fixes a latent test bug in test bug in
> `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather
> than relying on a quirk of JUnit 5.8.1.
>
> I discovered this while testing PR #1662 which updates JUnit to 5
On Thu, 12 Dec 2024 19:52:53 GMT, Andy Goryachev wrote:
> please address the merge conflict.
?
-
PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2540033618
On Tue, 10 Dec 2024 22:03:04 GMT, Andy Goryachev wrote:
>> Yes, IntelliJ actually gave me the hint.
>> `isVisible` can only be `false`, when a `fixedCellSize` is set. So the else
>> branch can only ever be executed when `fixedCellSize > 0`
>
> it's hard to tell (for me): there are just too many
On Tue, 10 Dec 2024 21:10:54 GMT, Andy Goryachev wrote:
>> Marius Hanl 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 contain
The JUnit Platform got some updates over the last years, so it is a good idea
to update it to the newest version.
That is from `5.8.1` to `5.11.3`.
Affected dependencies:
- `junit.jupiter`
- `junit.platform`
- `opentest4j`
Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/
Note:
org/browse/JDK-8246745).
> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887)
> (https://github.com/openjdk/jfx/pull/1644), but as written above, not
> required as there is no (visible) effect.
Marius Hanl has updated the pull request with a new target base due
gt; When a Rectangle is used as clip without any effect or opacity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happ
On Thu, 5 Dec 2024 15:32:33 GMT, Andy Goryachev wrote:
> By the way, a Tree/TableView with 500 columns is barely usable - locks up the
> UI giving me a macOS spinning beach ball quite often. Not that it's a
> reasonable use case. 200 is ok. May be the 500 case can be used for profiling?
With f
irtualFlow` sheet (as
> children). This will cause them to actually do the layout when requested, and
> especially when the height of the `TableView` changed drastically (e.g. from
> 50 visible cells to just 10), we have 40 cells laying around, receiving the
> layout request I added t
On Thu, 5 Dec 2024 09:24:13 GMT, Marius Hanl wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java
>> line 228:
>>
>>> 226: if (disclosureNodeDirty) {
>>> 227: updat
On Wed, 4 Dec 2024 09:18:41 GMT, Ambarish Rapte wrote:
> I tested the PR changes with a few a11y scenarios, and did not observe any
> issues.
Thank you for testing!
Out of interesting, is it 'enough' to test with the `Narrator` application on
Windows 11?
-
PR Comment: https://git
On Wed, 4 Dec 2024 12:27:54 GMT, Ambarish Rapte wrote:
>> Marius Hanl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jfx
On Wed, 4 Dec 2024 20:13:31 GMT, Andy Goryachev wrote:
> It feels like the horizontal scrolling has improved a bit, the vertical
> exhibits the same slight hiccups as with the master branch.
Yes, especially if you try with many columns (> 100), scrolling up and down is
much faster (especially
On Wed, 4 Dec 2024 19:59:37 GMT, Andy Goryachev wrote:
>> Marius Hanl has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
On Wed, 4 Dec 2024 16:22:18 GMT, Andy Goryachev wrote:
>> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup
>> for the `fixedCellSize` instead of adding listener just to update
>> variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be
>> also ju
On Wed, 4 Dec 2024 16:20:48 GMT, Andy Goryachev wrote:
>> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup
>> for the `fixedCellSize` instead of adding listener just to update
>> variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be
>> also ju
I like this idea and also agree that Modena looks dated.I also understand John's concerns.
In my mind, I would mix both approaches:- A new Theme that follows modern approaches and make use of the new features like media queries- The theme is therefore more accessible (by default), takes into accoun
I also agree that this is a good idea. As of now, we can only change the theme by reacting to the Platform Preferences (listener) and change the Stylesheet of the Scene(s). I'm not sure how well this works as I never tried it as of now (Might even be problematic for Tooltips, Dialogs and Dialogs wi
On Sat, 23 Nov 2024 23:42:42 GMT, Marius Hanl wrote:
> This PR changes all `RT-` references to `JDK-XXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>
> As discussed, this will help a lot when looking up old issues, especially
> since not
On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote:
> A small refactoring of the Dimension classes.
>
> * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by
> `com.sun.javafx.geom.Dimension2D`.
> * `com.sun.javafx.geom.Dimension2D` became a record.
> * `javafx.geometry.Di
On Thu, 28 Nov 2024 12:52:33 GMT, Marius Hanl wrote:
>> This PR changes all `RT-` references to `JDK-XXX`.
>> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>>
>> As discussed, this will help a lot when looking up old issues, especially
` number in the
> JIRA.
>
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes
> the following files:
> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
Marius Hanl has updated the pull request with
On Wed, 27 Nov 2024 14:52:51 GMT, Kevin Rushforth wrote:
> Looks good except for a few changes in `StylesheetTest.java` where the
> `RT-n` refers to a filename and thus should be reverted.
Checked the whole project with: `JDK-[\d]*.[\w]` and `JDK-[\d]*-`. No other
occurrences found other t
` number in the
> JIRA.
>
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes
> the following files:
> - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
Marius Hanl has updated the pull request
On Wed, 27 Nov 2024 14:49:43 GMT, Kevin Rushforth wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8344899: Remove occurrences of old JIRA tickets
>>
>> Including:
>>
On Tue, 26 Nov 2024 18:50:18 GMT, Nir Lisker wrote:
>> Centralizes version numbers in a single place. This is not the best way of
>> doing it in Gradle, but it's an improvement that will simplify other
>> changes. I used the `build.properties` file because other versions are
>> already written
` number in the
> JIRA.
>
> Thanks to @kevinrushforth who provided the mapping!
> I wrote a small Java program that replaces all the occurrences. This includes
> the following files:
> - .`java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp`
Marius Hanl has updated the pull request
On Mon, 25 Nov 2024 12:35:49 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 607:
>>
>>> 605: * CSS state (see {@link Node#initialCssState}.
>>> 606: */
>>> 607: private final Set clearInitialCssStateNodes =
>>> Collections.newSetFr
On Mon, 21 Oct 2024 15:32:28 GMT, Michael Strauß wrote:
> When the initial value of a styleable property is not specified in a
> stylesheet, no transition is started:
>
> .button {
> transition: -fx-opacity 1s;
> }
>
> .button:hover {
> -fx-opacity: 0.5;
> }
On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker wrote:
> A batch of typo and grammar fixes that were found by the spellchecker.
>
> Integration can wait until RDP 1/2.
The corrections look good to me.
-
Marked as reviewed by mhanl (Committer).
PR Review: https://git.openjdk.org/jfx/
On Sat, 23 Nov 2024 23:42:42 GMT, Marius Hanl wrote:
> This PR changes all `RT-` references to `JDK-XXX`.
> It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
>
> As discussed, this will help a lot when looking up old issues, especially
> since not
This PR changes all `RT-` references to `JDK-XXX`.
It also removes all `http://javafx-jira.kenai.com/browse/` occurrences.
As discussed, this will help a lot when looking up old issues, especially since
not everybody know how to do a lookup with the `RT-` number in the JIRA.
Thanks t
On Sat, 16 Nov 2024 00:58:47 GMT, Marius Hanl wrote:
> There are multiple issues in the `TableMenu` logic that result in a memory
> leak.
>
> The following problems are now fixed with this PR:
> - The listener, that is registered to the `col.visibleProperty()` was not
> we
On Fri, 22 Nov 2024 18:09:07 GMT, Andy Goryachev wrote:
>> maybe we we should do a small cleanup ticket where we replace all `JBS-` and
>> `RT-` references with the `JDK-` one? A quick check led to around 120
>> occurrences.
>
> and maybe fix the RT- references as well, though it might be a bit
On Fri, 22 Nov 2024 20:55:27 GMT, Kevin Rushforth wrote:
> We will need to check that this doesn't impact accessibility, since there are
> some "interesting" cases where cells are requested and a layout pass is done
> even when they aren't visible.
Good point! Checking `getPrivateCell`, I wond
On Fri, 22 Nov 2024 20:31:08 GMT, Marius Hanl wrote:
> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup
> for the `fixedCellSize` instead of adding listener just to update
> variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be
&g
This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup
for the `fixedCellSize` instead of adding listener just to update
variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be
also just lookup'd without the hassle of listeners.
While this is mostly a
On Mon, 18 Nov 2024 16:13:35 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8341687: Add more tests
>
> modules/javafx.controls/src/main/java/javafx/scene/co
On Mon, 18 Nov 2024 20:21:29 GMT, Andy Goryachev wrote:
>> I tried, but it isn't that easy - since the memory is not leaked because we
>> keep some references we should not keep - rather we are adding listener
>> again and again and again. So we can not assert things to be collectable, as
>> t
The fix is to add the listeners once - when the `MenuItem` is created.
> This way, when the `TableMenu` is rebuild and the cached `MenuItem` is used,
> the whole listener logic is not run again for the column
Marius Hanl has updated the pull request incrementally with one additional
commit sin
irtualFlow` sheet (as
> children). This will cause them to actually do the layout when requested, and
> especially when the height of the `TableView` changed drastically (e.g. from
> 50 visible cells to just 10), we have 40 cells laying around, receiving the
> layout request I added
This PR fixes the horizontal virtualization performed in the
`TableRowSkinBase`, which significantly improves performance with many columns
(and thus many cells). Scrolling up and down as well as scrolling left and
right feels much more snappy.
In order to do that, there are multiple things nee
On Mon, 18 Nov 2024 16:19:20 GMT, Andy Goryachev wrote:
>> There are multiple issues in the `TableMenu` logic that result in a memory
>> leak.
>>
>> The following problems are now fixed with this PR:
>> - The listener, that is registered to the `col.visibleProperty()` was not
>> weak nor was i
There are multiple issues in the `TableMenu` logic that result in a memory leak.
The following problems are now fixed with this PR:
- The listener, that is registered to the `col.visibleProperty()` was not weak
nor was it ever unregistered
- The fix is to do pretty much the same that was alrea
On Thu, 14 Jul 2022 19:48:04 GMT, John Hendrikx wrote:
>> This is an initial (incomplete) implementation of 8290037 for evaluation.
>>
>> If the approach is agreed, I will modify the rest of the `*PropertyBase`
>> classes which use weak listeners, and add some tests.
>>
>> I didn't use `Cleane
gt; When a Rectangle is used as clip without any effect or opacity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happ
On Tue, 12 Nov 2024 21:11:56 GMT, Marius Hanl wrote:
> This PR fixes a bug where the `TableCell` indices can be outdated (not
> synchronized) with the `TableRow` index.
>
> What normally happens is:
> - Index is changed: Cell update is requested when the row is empty (ot
uarantee that the item changed, as we can see
> in the example, where the cell is reused).
>
> ---
>
> Also made sure that the issues linked in the code and ticket do not regress:
> - https://bugs.openjdk.org/browse/JDK-8095357
> - https://bugs.openjdk.org/browse/JDK-8115269
Marius Hanl has
On Wed, 13 Nov 2024 18:10:49 GMT, Andy Goryachev wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java
>> line 222:
>>
>>> 220: row.updateIndex(0);
>>> 221:
>>> 222: List> cells =
>>> row.getChildrenUnmodifiable().stream().
>>
>> mino
On Wed, 13 Nov 2024 18:07:37 GMT, Andy Goryachev wrote:
> The bug is present in TableView and TreeTableView, but not TreeView - is this
> correct?
Yes since `ListView` and `TreeView` do not need to do any synchronization when
their index or item changed. But I did not test them.
> modules/jav
This PR fixes a bug where the `TableCell` indices can be outdated (not
synchronized) with the `TableRow` index.
What normally happens is:
- Index is changed: Cell update is requested when the row is empty (otherwise
noop)
- Item is changed: Cell update is requested, which will now update the ind
Vote: Yes.-- MariusAm 08.11.24, 14:50 schrieb Kevin Rushforth :
I hereby nominate Jayathirth D V [1] to OpenJFX Committer.
Jay is a member of the JavaFX team at Oracle who has contributed 12
commits [2] to OpenJFX. He has contributed an additional 5 commits to
the OpenJFX jfx-tests repo [3].
Vo
On Tue, 4 Jun 2024 12:33:06 GMT, Marius Hanl wrote:
>> you are right: I see the focus rectangle jitter at 175% scale on win 11 (w/o
>> the fix), so it must be a different issue. At this scale, it merely shows a
>> thinner line, perhaps that's why I did not notice i
ct or opacity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happens at the low level (`NGNode`) side of JavaFX.
> .
(although the nested event loop code is the same as for
> Mac) (I would appreciate if someone can do this as I have no access to an iOS
> device)
> - [x] Adjust copyright
> - [x] Write Systemtest
> - [x] Document the new behaviour - in general, there should be more
> inform
In my opinion this is a nice change.
Modernizing the Windows backend of JavaFX is a good idea and will also enable us to use more modern features if needed.
There should be some performance improvements as well.
Even though Direct3d9 works and is not deprecated, I still think it is good to move
I've been thinking about this for a few weeks and agree with the general consensus.
For me personally, it will make things more tricky as big customers (that usually have their own IT department) stick to 'LTS' versions and there is not too much you can do against that (I tried).
Sometimes there
On Wed, 25 Sep 2024 21:08:41 GMT, Kevin Rushforth wrote:
> A `SECURITY.md` file was recently added to the jdk repo. GitHub will show
> that policy if you click on the ["Security"
> tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are
> logged in, you may need to further
On Fri, 20 Sep 2024 18:21:04 GMT, Kevin Rushforth wrote:
>> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not
>> have an explicit `@Timeout` on either the methods or the class, and a
>> default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`,
>> `@Bef
On Mon, 23 Sep 2024 09:14:02 GMT, Lukasz Kostyra wrote:
>> This PR converts all tests in `modules/javafx.graphics` to use JUnit5.
>>
>> ## Details
>>
>> Trivial changes resolved by first four commits:
>> - Import changes to use `org.junit.jupiter` package instead of `org.junit`
>> or `junit.fr
On Fri, 20 Sep 2024 13:31:06 GMT, Lukasz Kostyra wrote:
>> This PR converts all tests in `modules/javafx.graphics` to use JUnit5.
>>
>> ## Details
>>
>> Trivial changes resolved by first four commits:
>> - Import changes to use `org.junit.jupiter` package instead of `org.junit`
>> or `junit.fr
On Wed, 18 Sep 2024 15:36:53 GMT, Andy Goryachev wrote:
>> Converting control module tests to junit5.
>>
>> The following notes might help reviewers and people migrating other parts of
>> https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes:
>> https://github.com/andy-gory
On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote:
>> Converting control module tests to junit5.
>>
>> The following notes might help reviewers and people migrating other parts of
>> https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes:
>> https://github.com/andy-gory
On Thu, 19 Sep 2024 09:34:20 GMT, Lukasz Kostyra wrote:
>> modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java
>> line 76:
>>
>>> 74: return Stream.concat(stream, Stream.of(arg));
>>> 75: }
>>> 76:
>>
>> same comment: `List` might also work
On Wed, 18 Sep 2024 11:09:29 GMT, Kevin Rushforth wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java
>> line 261:
>>
>>> 259: @Test
>>> 260: public void testCloseValues() {
>>> 261: assertTimeout(Duration.ofMillis(1000), () -> {
>>
>> Co
On Tue, 17 Sep 2024 13:48:50 GMT, Jay Bhaskar wrote:
>> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests
>> are fully compliant with the JUnit 5 framework.
>
> Jay Bhaskar has updated the pull request incrementally with one additional
> commit since the last revision
On Mon, 16 Sep 2024 16:34:39 GMT, Andy Goryachev wrote:
>> Converting control module tests to junit5.
>>
>> The following notes might help reviewers and people migrating other parts of
>> https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes:
>> https://github.com/andy-gory
On Mon, 16 Sep 2024 15:23:48 GMT, Andy Goryachev wrote:
>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java
>> line 39:
>>
>>> 37:
>>> 38: @Test
>>> 39: public void focusGainedIsCaughtByBehavior() {
>>
>> Wait, is this an empt
On Mon, 16 Sep 2024 11:04:24 GMT, Ajit Ghaisas wrote:
>> This converts FXML module tests to junit5.
>>
>> All changes are trivial API replacements from junit4 to junit5.
>> There are no parameterized tests in this module.
>
> Ajit Ghaisas has updated the pull request incrementally with one addit
On Fri, 13 Sep 2024 14:52:22 GMT, Kevin Rushforth wrote:
> This PR enables the `removal` lint option, along with `-Werror`, for
> compiling shims and test classes. In order to do that, I had to also do the
> following:
>
> * Disable the `options` lint warning as is done for the `javafx.swing`
On Sun, 15 Sep 2024 23:53:20 GMT, Jay Bhaskar wrote:
>> modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java
>> line 99:
>>
>>> 97: @ParameterizedTest
>>> 98: @MethodSource("dataProvider")
>>> 99: public void testScriptTagWithCorrectHashValue() {
>>
On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote:
> Converting control module tests to junit5.
>
> The following notes might help reviewers and people migrating other parts of
> https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes:
> https://github.com/andy-goryachev
On Sun, 15 Sep 2024 12:31:03 GMT, Jay Bhaskar wrote:
> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests
> are fully compliant with the JUnit 5 framework.
Also one note: The copyright year was not updated, but this could also be done
by the script afterwards I guess.
On Fri, 13 Sep 2024 10:45:33 GMT, Ajit Ghaisas wrote:
> This converts FXML module tests to junit5.
>
> All changes are trivial API replacements from junit4 to junit5.
> There are no parameterized tests in this module.
Looks good to me too, just some formatting is off (as Andy also noticed)
mod
On Sun, 15 Sep 2024 12:31:03 GMT, Jay Bhaskar wrote:
> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests
> are fully compliant with the JUnit 5 framework.
There is one major issue with the parameterized test as far as I can see. Some
minor style guide things, looks g
On Tue, 10 Sep 2024 23:11:12 GMT, Andy Goryachev wrote:
> It's pretty surprising that junit people thought it will be a good idea to
> drop support for class-wide parameterized tests...
Well, I would rephrase it:
- In Junit4, you were very restricted how to write parameterized tests. You
alwa
On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote:
> Converting control module tests to junit5.
>
> Most of the changes are trivial, except for the following:
>
> 1. assertEquals() and similar methods: the message can be confused with the
> expected argument (junit5 moved the message to t
ct or opacity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happens at the low level (`NGNode`) side of JavaFX.
> .
On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote:
> This PR removes the pausing logic from AbstractPrimaryTimer. The test that
> is using it wasn't actually testing anything in AbstractPrimaryTimer itself,
> and no other code needs this pausing code.
Looks good to me too and always good t
I think this is a good idea.I have checked the CSS code some time myself and also removed all the special property checks just to see what will happen and why it is needed.With the gathered knowledge, I can confirm what you wrote down in your proposal and that you have the correct idea to sol
On Mon, 19 Aug 2024 00:06:07 GMT, Thiago Milczarek Sayao
wrote:
> It always failing for me, with this PR or without.
Since I wrote them, maybe we can fix those tests for you as well and make them
more stable across Linux.
I think generally those tests are good to have as they can catch serious
I also think this might be a good addition to the JFX Core.
This behavior should be off by default, but can be turned on via CSS or Code.
Another idea could be a new Control that extends from Label.
-- Marius
Gesendet: Freitag, 16. August 2024 um 12:12 Uhr
Von: "Dirk Lemmermann"
An: "ope
On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
1 - 100 of 588 matches
Mail list logo
