From tsayao at openjdk.org Tue Nov 1 01:28:35 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 1 Nov 2022 01:28:35 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v18] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in update_window_constraints; > - Frame extents (the window decoration size used for "total window size": > - frame extents are received in process_property_notify; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size; > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix https://bugs.openjdk.org/browse/JDK-8271054 > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize` Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Request focus on map ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/4a2ed9e6..d3f551fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=16-17 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From mhanl at openjdk.org Tue Nov 1 12:35:46 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 1 Nov 2022 12:35:46 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ?? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error I would like to give this PR a bump. I still think this is a nice and safe improvement. @jgneff this branch needs to be updated as it has merge conflicts now. ------------- PR: https://git.openjdk.org/jfx/pull/488 From kcr at openjdk.org Tue Nov 1 13:04:52 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Nov 2022 13:04:52 GMT Subject: [jfx17u] RFR: 8290527: Bump macOS GitHub actions to macOS 11 Message-ID: Clean backport to jfx17u. ------------- Commit messages: - 8290527: Bump macOS GitHub actions to macOS 11 Changes: https://git.openjdk.org/jfx17u/pull/87/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=87&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290527 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/87.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/87/head:pull/87 PR: https://git.openjdk.org/jfx17u/pull/87 From kcr at openjdk.org Tue Nov 1 13:06:47 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Nov 2022 13:06:47 GMT Subject: [jfx17u] RFR: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Message-ID: <9yK0JIM8x7ZS2KQAnjYsHSyErxSy9v8yeshrQ80pzlo=.885d4acf-dfc5-412f-b3e9-5f67c191d76b@github.com> Clean backport to jfx17u. ------------- Commit messages: - 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Changes: https://git.openjdk.org/jfx17u/pull/88/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=88&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292549 Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx17u/pull/88.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/88/head:pull/88 PR: https://git.openjdk.org/jfx17u/pull/88 From kcr at openjdk.org Tue Nov 1 13:20:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Nov 2022 13:20:24 GMT Subject: [jfx17u] Integrated: 8290527: Bump macOS GitHub actions to macOS 11 In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 12:56:48 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. This pull request has now been integrated. Changeset: 90422e8e Author: Kevin Rushforth URL: https://git.openjdk.org/jfx17u/commit/90422e8e0f29922144f1eddaf3f405f90f708351 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8290527: Bump macOS GitHub actions to macOS 11 Backport-of: 49a2efbbfba017101e5f57b590bf820307863bc3 ------------- PR: https://git.openjdk.org/jfx17u/pull/87 From kcr at openjdk.org Tue Nov 1 13:21:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Nov 2022 13:21:31 GMT Subject: [jfx17u] Integrated: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant In-Reply-To: <9yK0JIM8x7ZS2KQAnjYsHSyErxSy9v8yeshrQ80pzlo=.885d4acf-dfc5-412f-b3e9-5f67c191d76b@github.com> References: <9yK0JIM8x7ZS2KQAnjYsHSyErxSy9v8yeshrQ80pzlo=.885d4acf-dfc5-412f-b3e9-5f67c191d76b@github.com> Message-ID: On Tue, 1 Nov 2022 12:59:01 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. This pull request has now been integrated. Changeset: 54ebc275 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx17u/commit/54ebc275e32b99d96b4c3fa8c5ae427cd922ef12 Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Backport-of: cedc17cc26bb0ad3e2d0693bd174f118ad5f0b82 ------------- PR: https://git.openjdk.org/jfx17u/pull/88 From kevin.rushforth at oracle.com Tue Nov 1 20:59:34 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 Nov 2022 13:59:34 -0700 Subject: Proposed schedule for JavaFX 20 Message-ID: <7e1dcc31-ac9c-b5ff-75a6-cb504c77bdac@oracle.com> Here is the proposed schedule for JavaFX 20. RDP1: Jan 12, 2023 (aka ?feature freeze?) RDP2: Feb 2, 2023 Freeze: March 2, 2023 GA: March 21, 2023 We plan to fork a jfx20 stabilization branch at RDP1. The start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From kevin.rushforth at oracle.com Tue Nov 1 21:14:52 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 Nov 2022 14:14:52 -0700 Subject: JavaFX @ JavaOne 2022 Message-ID: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> JavaOne 2022 was the week of Oct 17-20, and there were two sessions of interest to JavaFX: * During the technical keynote [1], I announced that Oracle would start delivering JavaFX builds, beginning with JavaFX 20 early access, on jdk.java.net [2][3]. * I gave a technical session titled "JavaFX 19 and Beyond". You can download the presentation [4]. Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX. -- Kevin [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ [2] https://inside.java/2022/10/20/javafx-early-access-builds/ [3] https://jdk.java.net/javafx20/ [4] http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf [5] https://inside.java/podcast/ From nlisker at gmail.com Wed Nov 2 00:50:34 2022 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 2 Nov 2022 02:50:34 +0200 Subject: JavaFX @ JavaOne 2022 In-Reply-To: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> References: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> Message-ID: Very nice! Was the technical session recorded? Were there any interesting questions in the Q&A? On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth wrote: > JavaOne 2022 was the week of Oct 17-20, and there were two sessions of > interest to JavaFX: > > * During the technical keynote [1], I announced that Oracle would start > delivering JavaFX builds, beginning with JavaFX 20 early access, on > jdk.java.net [2][3]. > > * I gave a technical session titled "JavaFX 19 and Beyond". You can > download the presentation [4]. > > Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX. > > -- Kevin > > [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ > [2] https://inside.java/2022/10/20/javafx-early-access-builds/ > [3] https://jdk.java.net/javafx20/ > [4] > > http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf > [5] https://inside.java/podcast/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Nov 2 01:02:16 2022 From: philip.race at oracle.com (Philip Race) Date: Tue, 1 Nov 2022 18:02:16 -0700 Subject: JavaFX @ JavaOne 2022 In-Reply-To: References: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> Message-ID: > Very nice! Was the technical session recorded? In theory, yes, but we are still waiting to see to be sure since so far only key notes have been posted. My understanding is that if works out it'll be on the java dev-rel youtube channel phil. On 11/1/22 5:50 PM, Nir Lisker wrote: > Very nice! Was the technical session recorded? Were there any > interesting questions in the Q&A? > > On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth > wrote: > > JavaOne 2022 was the week of Oct 17-20, and there were two > sessions of > interest to JavaFX: > > * During the technical keynote [1], I announced that Oracle would > start > delivering JavaFX builds, beginning with JavaFX 20 early access, on > jdk.java.net [2][3]. > > * I gave a technical session titled "JavaFX 19 and Beyond". You can > download the presentation [4]. > > Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX. > > -- Kevin > > [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ > [2] https://inside.java/2022/10/20/javafx-early-access-builds/ > [3] https://jdk.java.net/javafx20/ > [4] > http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf > [5] https://inside.java/podcast/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Nov 2 12:18:34 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 2 Nov 2022 12:18:34 GMT Subject: RFR: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 [v3] In-Reply-To: References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: <68NyNV8JpOLKeE51yugF8kT8WvlVeCdXNYVNkoF1kWk=.8aa5e2b4-206a-41cc-b07d-a059cc707a26@github.com> On Fri, 28 Oct 2022 19:41:35 GMT, Kevin Rushforth wrote: >> This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. >> >> The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. >> >> `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. >> >> [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). >> >> With this fix, a local build and test using JDK 19 passes. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years LGTM, tested on Mac. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/933 From arapte at openjdk.org Wed Nov 2 14:11:46 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 2 Nov 2022 14:11:46 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v2] In-Reply-To: References: Message-ID: On Thu, 13 Oct 2022 01:41:11 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Adjusted Copyright year modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 35: > 33: import javafx.stage.Stage; > 34: import org.junit.jupiter.params.ParameterizedTest; > 35: import org.junit.jupiter.params.provider.ValueSource; In our tests, we don't mix junit4 and junit5 APIs in single test class. Could you please find an alternate/junit4 way for these two. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mike at hydraulic.software Wed Nov 2 14:22:40 2022 From: mike at hydraulic.software (Mike Hearn) Date: Wed, 2 Nov 2022 15:22:40 +0100 Subject: Conveyor: a new packaging tool Message-ID: Hello, I hope this is of interest to the OpenJFX community. Conveyor is a new packaging tool that launched a few months ago. It's similar to jpackage, except with some useful additional features: - Handles online updates. - You can build for every OS from your own choice of OS: - Cross-builds and cross-signs packages (i.e. you can sign and notarize Mac packages from Windows, Windows packages from Mac, etc). - Does icon conversion for you. - Generates the needed CSRs if you want to buy certificates. - Very good for Linux CI. - Generates a download/updates site for you, with a big green button that detects the user's CPU/OS. - Configured via HOCON instead of CLI arguments. - Can do self-signed packages, if you don't want to buy certificates. The user is given instructions for how to install the app on the download page. - Integrates with jlink and jdeps to minimize the bundled JVM. You can learn more here: https://hydraulic.software/ There's an example of how to use it with the AtlantaFX Sampler app: https://github.com/mkpaz/atlantafx Look at the conveyor.conf file at the top level. It also has a `generate` command that can make a simple JavaFX hello world app with packaging pre-integrated. It's free for open source projects. I hope it proves useful ! thanks, -mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at hydraulic.software Wed Nov 2 14:26:17 2022 From: mike at hydraulic.software (Mike Hearn) Date: Wed, 2 Nov 2022 15:26:17 +0100 Subject: Switching to ANGLE ? Message-ID: On a topic unrelated to Conveyor, I saw the JavaFX roadmap document presented at JavaOne and the mention of a Metal pipeline. It prompted a thought I've never got around to exploring - does it make sense to switch JavaFX to using Google's ANGLE library i.e. to decommission all but the GL backend and then use it on every OS? This would have three big and obvious advantages: 1. A big reduction in the maintenance burden. A metal port is maybe no longer required. 2. A component or canvas that exposes a GL context (implicitly, on the current thread) could then be provided relatively easily, allowing easier integration of arbitrary drawing with the scene graph without compromising portability. 3. In turn that would unblock enabling WebGL in the WebView control, fixing Google Maps. It's mostly a question of curiosity but I'm wondering if that approach has ever been prototyped or explored. thanks, -mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Wed Nov 2 14:50:48 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 2 Nov 2022 14:50:48 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v2] In-Reply-To: References: Message-ID: <2D5xnquNkoLb-f0GD6SXY68HoIKVS7gO8Wf0J213J1Y=.89124cfb-b557-4171-8f6b-262fdca2f348@github.com> On Wed, 2 Nov 2022 14:07:23 GMT, Ambarish Rapte wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Adjusted Copyright year > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 35: > >> 33: import javafx.stage.Stage; >> 34: import org.junit.jupiter.params.ParameterizedTest; >> 35: import org.junit.jupiter.params.provider.ValueSource; > > In our tests, we don't mix junit4 and junit5 APIs in single test class. > Could you please find an alternate/junit4 way for these two. There is not really an alternative for this in junit4. I can create a new test class instead. ------------- PR: https://git.openjdk.org/jfx/pull/910 From jvos at openjdk.org Wed Nov 2 15:03:41 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 15:03:41 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: <9rS3WN4H_85ttR9oUINeeGFTcJWFuyGPFyBxyuI97AI=.09a31174-8438-4b15-bc97-9e4f29f65cd2@github.com> On Tue, 25 Oct 2022 21:31:01 GMT, Alexander Matveev wrote: >> - Added support for libavcodec 59. >> - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. >> - No changes to avplugin when used with 58 or below. >> - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8294400: Provide media support for libavcodec version 59 [v2] Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/932 From jvos at openjdk.org Wed Nov 2 15:03:41 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 15:03:41 GMT Subject: RFR: 8294400: Provide media support for libavcodec version 59 [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 11:49:05 GMT, Kevin Rushforth wrote: > > Works fine, but fails to build on win32. > > That is surprising since the libav changes are limited to Linux-specific code. Have you confirmed that the win32 build passes without this fix and fails with this fix? How does it fail? Failures were CI-related. They are fixed now, and everything looks good. ------------- PR: https://git.openjdk.org/jfx/pull/932 From mstrauss at openjdk.org Wed Nov 2 15:05:46 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 2 Nov 2022 15:05:46 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v2] In-Reply-To: <2D5xnquNkoLb-f0GD6SXY68HoIKVS7gO8Wf0J213J1Y=.89124cfb-b557-4171-8f6b-262fdca2f348@github.com> References: <2D5xnquNkoLb-f0GD6SXY68HoIKVS7gO8Wf0J213J1Y=.89124cfb-b557-4171-8f6b-262fdca2f348@github.com> Message-ID: On Wed, 2 Nov 2022 14:48:44 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 35: >> >>> 33: import javafx.stage.Stage; >>> 34: import org.junit.jupiter.params.ParameterizedTest; >>> 35: import org.junit.jupiter.params.provider.ValueSource; >> >> In our tests, we don't mix junit4 and junit5 APIs in single test class. >> Could you please find an alternate/junit4 way for these two. > > There is not really an alternative for this in junit4. I can create a new test class instead. There's no need to do that. `AnchorPaneTest` works just as well if you simply use the JUnit5 imports exclusively. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Wed Nov 2 15:18:15 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 2 Nov 2022 15:18:15 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v2] In-Reply-To: References: <2D5xnquNkoLb-f0GD6SXY68HoIKVS7gO8Wf0J213J1Y=.89124cfb-b557-4171-8f6b-262fdca2f348@github.com> Message-ID: On Wed, 2 Nov 2022 15:01:59 GMT, Michael Strau? wrote: >> There is not really an alternative for this in junit4. I can create a new test class instead. > > There's no need to do that. `AnchorPaneTest` works just as well if you simply use the JUnit5 imports exclusively. good point, that will be the better solution. ------------- PR: https://git.openjdk.org/jfx/pull/910 From jgneff at openjdk.org Wed Nov 2 16:20:48 2022 From: jgneff at openjdk.org (John Neffenger) Date: Wed, 2 Nov 2022 16:20:48 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 1 Nov 2022 12:33:13 GMT, Marius Hanl wrote: > I would like to give this PR a bump. I still think this is a nice and safe improvement. Thanks, Marius. I appreciate the time you gave for a thorough review. Nonetheless, it may have served its purpose. Searching for WINSDK_DIR on Google gives me the following results: 1. "build on win10 fails ? Issue 288 ? javafxports/openjdk-jfx" 2. A Visual Studio 2008 problem 3. A Visual Studio 2015 problem 4. "[JDK-8266396] Save VSCMD_DEBUG output in Windows build" The first result is an issue in the old sandbox repository. It ends with the following comment linking to the bug report associated with this pull request (also the fourth result): > Since this issue is pretty common and many others could get here in search of a solution, I found it here: [JDK-8266396][1] Building on Windows is [surprisingly easy][2], but it took me four years to get there. Perhaps it's time for a more fundamental solution: move the build instructions into the repository, just like the [OpenJDK project did][3], so that we all can participate in keeping them up to date. Changes to the instructions would be made in the same pull requests that change the build. [1]: https://bugs.openjdk.java.net/browse/JDK-8266396?jql=text%20~%20%22WINSDK_DIR%22%20ORDER%20BY%20created%20DESC [2]: https://github.com/jgneff/jfxbuild/blob/main/win10/bin/jfxbuild.env [3]: https://github.com/openjdk/jdk/blob/master/doc/building.md ------------- PR: https://git.openjdk.org/jfx/pull/488 From duke at openjdk.org Wed Nov 2 17:12:16 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Wed, 2 Nov 2022 17:12:16 GMT Subject: RFR: 8265835: Exception in Quantum due to null platformWindow Message-ID: Reproduction code was not provided, I wasn't able to reproduce the circumstances in which the issue occurs. On our side it seems like `WindowStage.getPlatformWindow()` will not return null, however it is also difficult to reject the possibility that some custom user code might trigger an edge-case where a null will be returned. Adding these checks is not an intrusive change to our code, it is in fact an extra null-check added to already existing checks, but it might prevent the exception from appearing in the future. I checked other places in our code using `WindowStage.getPlatformWindow()` and none require a null check. ------------- Commit messages: - JDK-8265835: Exception in Quantum due to null platformWindow Changes: https://git.openjdk.org/jfx/pull/935/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8265835 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/935.diff Fetch: git fetch https://git.openjdk.org/jfx pull/935/head:pull/935 PR: https://git.openjdk.org/jfx/pull/935 From kcr at openjdk.org Wed Nov 2 17:18:47 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Nov 2022 17:18:47 GMT Subject: Integrated: 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 In-Reply-To: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> References: <-xIyPwkC1ji1JUYwN5_8wxyon1SX8Hgv3rQt53wSel4=.f2e64174-a8e5-46c9-8521-82019e542006@github.com> Message-ID: On Wed, 26 Oct 2022 22:38:15 GMT, Kevin Rushforth wrote: > This PR replaces all occurrences of `State` with `Worker.State` in `javafx.concurrent.Task`. > > The `javafx.concurrent.Task` class implements `javafx.concurrent.Worker` and extends `java.util.concurrent.FutureTask`, which in turn implements `java.util.concurrent.Future`. > > `Worker` has a nested `State` enum, which is used in the implementing `Task` class without being qualified -- since `Task` is a `Worker`, we can just say `State` instead of `Worker.State`. > > [JDK-8277090](https://bugs.openjdk.org/browse/JDK-8277090) added a nested `State` enum to the `java.util.concurrent.Future` interface in JDK 19, so an unqualified reference to `State` from the `Task` class is now ambiguous when using JDK 19 to build. The javadoc task fails with an error (and the only reason the javac task doesn't is that we use `--release 17`). > > With this fix, a local build and test using JDK 19 passes. This pull request has now been integrated. Changeset: 4a2afb4c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/4a2afb4ce28b46ee463b1dc8d38d1c81962e3c88 Stats: 30 lines in 5 files changed: 2 ins; 1 del; 27 mod 8295962: Reference to State in Task.java is ambiguous when building with JDK 19 Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/933 From jvos at openjdk.org Wed Nov 2 18:54:08 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 18:54:08 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Fri, 28 Oct 2022 23:29:36 GMT, Kevin Rushforth wrote: >> Depending on the desired result, we use `Math.floor`, `Math.ceil`, or `Math.round` -- it's important to pick the right one. >> >> But yes, using one of those is (almost always) better than just casting to `(int)` if the value might be negative. > > I think in this case, `Math.floor()` is what you want. I wonder, though, whether it needs to be converted to an `int` at all? It looks like everywhere it is used, it can be kept as a double. > > Btw, I almost wrote a comment asking a question as to whether you were using the values of x, y, width, and height correctly, because I got confused that you were using a Dimension to hold an x,y point. If you decide to keep it as a Dimension, I might suggest adding a clarifying comment. We need the int values, as they are used to invoke `mouseEvent`, `scrollEvent` and `menuEvent` on `com.sun.javafx.embed.EmbeddedSceneInterface` . For some reason, `scrollEvent` takes doubles, but `mouseEvent` and `menuEvent` take ints. I'll use `Math.floor()` instead of the `int` cast. The key thing here is that the strategy for the mouse/scroll/menu events should be the same as the strategy for the window location changes. ------------- PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Wed Nov 2 18:54:08 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 18:54:08 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Wed, 2 Nov 2022 18:50:44 GMT, Johan Vos wrote: >> I think in this case, `Math.floor()` is what you want. I wonder, though, whether it needs to be converted to an `int` at all? It looks like everywhere it is used, it can be kept as a double. >> >> Btw, I almost wrote a comment asking a question as to whether you were using the values of x, y, width, and height correctly, because I got confused that you were using a Dimension to hold an x,y point. If you decide to keep it as a Dimension, I might suggest adding a clarifying comment. > > We need the int values, as they are used to invoke `mouseEvent`, `scrollEvent` and `menuEvent` on `com.sun.javafx.embed.EmbeddedSceneInterface` . > For some reason, `scrollEvent` takes doubles, but `mouseEvent` and `menuEvent` take ints. > I'll use `Math.floor()` instead of the `int` cast. The key thing here is that the strategy for the mouse/scroll/menu events should be the same as the strategy for the window location changes. > And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) Point2D provides much more functionality -- but has 2 fields only. So it should not be an overhead at all, hence I'll switch to Point2D. Thanks for Pointing that out :) ------------- PR: https://git.openjdk.org/jfx/pull/924 From angorya at openjdk.org Wed Nov 2 19:14:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 2 Nov 2022 19:14:34 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Wed, 2 Nov 2022 18:51:56 GMT, Johan Vos wrote: >> We need the int values, as they are used to invoke `mouseEvent`, `scrollEvent` and `menuEvent` on `com.sun.javafx.embed.EmbeddedSceneInterface` . >> For some reason, `scrollEvent` takes doubles, but `mouseEvent` and `menuEvent` take ints. >> I'll use `Math.floor()` instead of the `int` cast. The key thing here is that the strategy for the mouse/scroll/menu events should be the same as the strategy for the window location changes. > >> And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) > > Point2D provides much more functionality -- but has 2 fields only. So it should not be an overhead at all, hence I'll switch to Point2D. Thanks for Pointing that out :) I suspect Math.floor() would be incorrect - we should use Math.round() for coordinates and Math.floor() for sizes (sizes will always be positive, I hope, and the rounded size will be slightly smaller than the original value). But for coordinates we should use (int)Math.round() ------------- PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Wed Nov 2 19:58:15 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 19:58:15 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v3] In-Reply-To: References: Message-ID: > The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. > The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. > I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process reviewer comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/924/files - new: https://git.openjdk.org/jfx/pull/924/files/af931bed..783c45a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=01-02 Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/924.diff Fetch: git fetch https://git.openjdk.org/jfx pull/924/head:pull/924 PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Wed Nov 2 19:58:17 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 19:58:17 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 23:42:30 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> address reviewer comments >> Fix detection on screen, based on awtScale factors > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 400: > >> 398: float py = screen.getPlatformY(); >> 399: newx = sx + (wx - px) * awtScaleX / pScaleX; >> 400: newy = sy + (wy - py) * awtScaleY / pScaleY; > > `px` and `py` are already (scaled) "FX" coordinates, so I'm not sure AWT scale should be applied to that. I might be missing something here. Without this correction, there is an offset on Linux (where awtScaleX = 1 and pScaleX =2 for example). TBH, I think the relations between the different scale factors should be written out clearly somewhere, as I think there are a number of places where we face platform-specific differences. ------------- PR: https://git.openjdk.org/jfx/pull/924 From jvos at openjdk.org Wed Nov 2 20:09:45 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 2 Nov 2022 20:09:45 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v3] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: On Wed, 2 Nov 2022 19:10:49 GMT, Andy Goryachev wrote: >>> And yes, I did not see Dimension2D - we probably should remove confusion and use Point2D (why does it have more overhead?) >> >> Point2D provides much more functionality -- but has 2 fields only. So it should not be an overhead at all, hence I'll switch to Point2D. Thanks for Pointing that out :) > > I suspect Math.floor() would be incorrect - we should use Math.round() for coordinates and Math.floor() for sizes (sizes will always be positive, I hope, and the rounded size will be slightly smaller than the original value). > > But for coordinates we should use (int)Math.round() I'll change it to Math.round, although I doubt it doesn't improve anything (but it won't make it worse either). The reason we need the transformation on those coordinates is to position new windows, *relative* against the location of the root window that we are given by Swing. Hence, if the operation applied to the window location coordinates (in sendMoveEventToFX) is the same as the operation applied to the mouse point (in sendMouseEventToFX), we are good. A bigger problem imho is that mouseEvents, scrollEvents and menuEvents are dealing with different precisions in the EmbeddedSceneInterface -- but that is a different problem. ------------- PR: https://git.openjdk.org/jfx/pull/924 From almatvee at openjdk.org Wed Nov 2 20:24:52 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 2 Nov 2022 20:24:52 GMT Subject: Integrated: 8294400: Provide media support for libavcodec version 59 In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 05:07:05 GMT, Alexander Matveev wrote: > - Added support for libavcodec 59. > - libavcodec 59 removed several deprecated APIs and avplugin code was updated to use replacement APIs instead. > - No changes to avplugin when used with 58 or below. > - Note: Support for libavcodec 59 was added based on ffmpeg only. libav does not have version 59. This pull request has now been integrated. Changeset: ac8382bd Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/ac8382bd378c7b51ccd625af46bdf10d24176692 Stats: 140 lines in 10 files changed: 108 ins; 0 del; 32 mod 8294400: Provide media support for libavcodec version 59 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/932 From kcr at openjdk.org Wed Nov 2 21:21:41 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Nov 2022 21:21:41 GMT Subject: RFR: 8295327: JavaFX - IllegalArgumentException when printing with margins equal to 0 In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 21:30:51 GMT, Phil Race wrote: > If floating point error caused a small negative value in the conversions needed from ISO to US measurements, then this will cause the IAE reported. > The code doing the rounding should not have used Math.abs() Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/934 From tsayao at openjdk.org Wed Nov 2 23:43:31 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 2 Nov 2022 23:43:31 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v19] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in update_window_constraints; > - Frame extents (the window decoration size used for "total window size": > - frame extents are received in process_property_notify; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size; > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix https://bugs.openjdk.org/browse/JDK-8271054 > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize` Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Replace activate_window() with gtk_window_present - which calls activate ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/d3f551fc..a1844375 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=17-18 Stats: 26 lines in 2 files changed: 0 ins; 25 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Thu Nov 3 01:20:47 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 3 Nov 2022 01:20:47 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v20] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in update_window_constraints; > - Frame extents (the window decoration size used for "total window size": > - frame extents are received in process_property_notify; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size; > - `gtk_window_set_focus_on_map` to fix https://bugs.openjdk.org/browse/JDK-8292922 and re-fix https://bugs.openjdk.org/browse/JDK-8271054 > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize` Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: restore focus on map ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/a1844375..6e63bb52 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=18-19 Stats: 30 lines in 3 files changed: 13 ins; 7 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From jgneff at openjdk.org Thu Nov 3 01:28:43 2022 From: jgneff at openjdk.org (John Neffenger) Date: Thu, 3 Nov 2022 01:28:43 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ?? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error My previous comment is confusing no matter how many times I edit it. ? Let me try again. > I would like to give this PR a bump. Actually, I was planning to close it. One of my goals was to document how to find the true source of the WINSDK_DIR error, and that seems to have worked (see above). It's also very easy to find this pull request by searching the repository for the error message. That visibility might be even better than the fix. Unless you want to take it over, I'll close it later this month. ------------- PR: https://git.openjdk.org/jfx/pull/488 From aghaisas at openjdk.org Thu Nov 3 11:35:56 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Nov 2022 11:35:56 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 20:20:11 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: added tests > - 8187145: clear selected tree table row when setting null selection model > - 8187145: clear selection when setting selection model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: whitespace > - 8187145: clear focus > - 8187145: tree table view > - 8187145: fall through > - ... and 1 more: https://git.openjdk.org/jfx/compare/7cb8d679...fed5dfdb modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java line 274: > 272: protected void simpleSelect(MouseButton button, int clickCount, boolean shortcutDown) { > 273: final int index = getIndex(); > 274: boolean isAlreadySelected; Code simplification: if `isAlreadySelected` is initialized to `false` on this line, then we can have only `if(sm != null)` condition below instead of if-else. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java line 203: > 201: protected void simpleSelect(MouseButton button, int clickCount, boolean shortcutDown) { > 202: final TableSelectionModel sm = getSelectionModel(); > 203: boolean isAlreadySelected; Code simplification: if `isAlreadySelected` is initialized to `false` on this line, then we can have only `if(sm != null)` condition below instead of if-else. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 178: > 176: return null; > 177: } > 178: // fall through There is no "fall through" here as we return from all conditions in previous case. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 192: > 190: return null; > 191: } > 192: // fall through There is no "fall through" here as we return from all conditions in previous case. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 486: > 484: return null; > 485: } > 486: // fall through There is no "fall through" here as we return from all conditions in previous case. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 500: > 498: return null; > 499: } > 500: // fall through There is no "fall through" here as we return from all conditions in previous case. ------------- PR: https://git.openjdk.org/jfx/pull/876 From aghaisas at openjdk.org Thu Nov 3 11:36:30 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Nov 2022 11:36:30 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:42:34 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: review comments Overall this looks fine. I have identified some minor javadoc style issues. I don't think we need to redo the CSR just for these corrections. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 86: > 84: * @implNote > 85: * Skins only need to implement {@code install} if they need to make direct changes to the control > 86: * like overwriting properties or event handlers. Such skins should ensure these changes are undone in Very minor : There are two spaces before `Such skins...` modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 94: > 92: > 93: /** > 94: * Called when a previously installed skin is about to be removed from its associated control. Use @code tag for `Skin` and `Control` in this description. modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 39: > 37: public interface Skinnable { > 38: /** > 39: * The Skin responsible for rendering this {@code Skinnable}. From the Use @code tag for `Skin` ------------- PR: https://git.openjdk.org/jfx/pull/845 From mhanl at openjdk.org Thu Nov 3 12:31:29 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Nov 2022 12:31:29 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: <4ikLN0z27QI56OvWTZqmBw426UnqlCz4iozkY_tD4lc=.a525f7e1-07dd-44f5-9f93-92470fad8ccd@github.com> On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ?? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error > Building on Windows is [surprisingly easy](https://github.com/jgneff/jfxbuild/blob/main/win10/bin/jfxbuild.env), but it took me four years to get there. Perhaps it's time for a more fundamental solution: move the build instructions into the repository, just like the [OpenJDK project did](https://github.com/openjdk/jdk/blob/master/doc/building.md), so that we all can participate in keeping them up to date. Changes to the instructions would be made in the same pull requests that change the build. I agree and really like this idea. We might need to pitch this idea in the mailing list as well. > Actually, I was planning to close it Okay, I understand. I still think it might be worth documenting it, maybe via your idea above (in some kind of building.md). ------------- PR: https://git.openjdk.org/jfx/pull/488 From kcr at openjdk.org Thu Nov 3 12:55:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Nov 2022 12:55:50 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <4ikLN0z27QI56OvWTZqmBw426UnqlCz4iozkY_tD4lc=.a525f7e1-07dd-44f5-9f93-92470fad8ccd@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> <4ikLN0z27QI56OvWTZqmBw426UnqlCz4iozkY_tD4lc=.a525f7e1-07dd-44f5-9f93-92470fad8ccd@github.com> Message-ID: On Thu, 3 Nov 2022 12:27:39 GMT, Marius Hanl wrote: > > Perhaps it's time for a more fundamental solution: move the build instructions into the repository, just like the [OpenJDK project did](https://github.com/openjdk/jdk/blob/master/doc/building.md), so that we all can participate in keeping them up to date. Changes to the instructions would be made in the same pull requests that change the build. > > I agree and really like this idea. We might need to pitch this idea in the mailing list as well. I also like this idea. @andy-goryachev-oracle also mentioned something similar to me in a slightly different context that got me thinking we should do it here as well. ------------- PR: https://git.openjdk.org/jfx/pull/488 From arapte at openjdk.org Thu Nov 3 13:46:21 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 3 Nov 2022 13:46:21 GMT Subject: RFR: 8265835: Exception in Quantum due to null platformWindow In-Reply-To: References: Message-ID: <7ssFIXCsYuJouTHjvv7Kt5kyMhnbXAKkO3vPr1FwFyg=.d87af6a7-cc5a-4899-bd41-4e06bb0b853e@github.com> On Wed, 2 Nov 2022 17:05:10 GMT, Lukasz Kostyra wrote: > Reproduction code was not provided, I wasn't able to reproduce the circumstances in which the issue occurs. On our side it seems like `WindowStage.getPlatformWindow()` will not return null, however it is also difficult to reject the possibility that some custom user code might trigger an edge-case where a null will be returned. > > Adding these checks is not an intrusive change to our code, it is in fact an extra null-check added to already existing checks, but it might prevent the exception from appearing in the future. > > I checked other places in our code using `WindowStage.getPlatformWindow()` and none require a null check. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/935 From prr at openjdk.org Thu Nov 3 15:28:38 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 3 Nov 2022 15:28:38 GMT Subject: Integrated: 8295327: JavaFX - IllegalArgumentException when printing with margins equal to 0 In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 21:30:51 GMT, Phil Race wrote: > If floating point error caused a small negative value in the conversions needed from ISO to US measurements, then this will cause the IAE reported. > The code doing the rounding should not have used Math.abs() This pull request has now been integrated. Changeset: 748107a0 Author: Phil Race URL: https://git.openjdk.org/jfx/commit/748107a09949594828a600abcccbabb6ca381c2d Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8295327: JavaFX - IllegalArgumentException when printing with margins equal to 0 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/934 From duke at openjdk.org Thu Nov 3 15:38:44 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Thu, 3 Nov 2022 15:38:44 GMT Subject: Integrated: 8265835: Exception in Quantum due to null platformWindow In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:05:10 GMT, Lukasz Kostyra wrote: > Reproduction code was not provided, I wasn't able to reproduce the circumstances in which the issue occurs. On our side it seems like `WindowStage.getPlatformWindow()` will not return null, however it is also difficult to reject the possibility that some custom user code might trigger an edge-case where a null will be returned. > > Adding these checks is not an intrusive change to our code, it is in fact an extra null-check added to already existing checks, but it might prevent the exception from appearing in the future. > > I checked other places in our code using `WindowStage.getPlatformWindow()` and none require a null check. This pull request has now been integrated. Changeset: 01735b33 Author: Lukasz Kostyra Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/01735b3389536be69e34c224e5d9de0ce7e39886 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8265835: Exception in Quantum due to null platformWindow Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/935 From angorya at openjdk.org Thu Nov 3 15:49:07 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 15:49:07 GMT Subject: RFR: 8290844: Add Skin.install() method [v20] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/627ae3c4..8ed29277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=18-19 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Nov 3 16:05:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:05:12 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 08:05:24 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: added tests >> - 8187145: clear selected tree table row when setting null selection model >> - 8187145: clear selection when setting selection model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: whitespace >> - 8187145: clear focus >> - 8187145: tree table view >> - 8187145: fall through >> - ... and 1 more: https://git.openjdk.org/jfx/compare/7cb8d679...fed5dfdb > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java line 274: > >> 272: protected void simpleSelect(MouseButton button, int clickCount, boolean shortcutDown) { >> 273: final int index = getIndex(); >> 274: boolean isAlreadySelected; > > Code simplification: if `isAlreadySelected` is initialized to `false` on this line, then we can have only `if(sm != null)` condition below instead of if-else. it's not: `isAlreadySelected` is set on line 278 or 280. Line 274 is just a declaration. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java line 203: > >> 201: protected void simpleSelect(MouseButton button, int clickCount, boolean shortcutDown) { >> 202: final TableSelectionModel sm = getSelectionModel(); >> 203: boolean isAlreadySelected; > > Code simplification: if `isAlreadySelected` is initialized to `false` on this line, then we can have only `if(sm != null)` condition below instead of if-else. same thing: `isAlreadySelected` is set on line 206 or 210. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 178: > >> 176: return null; >> 177: } >> 178: // fall through > > There is no "fall through" here as we return from all conditions in previous case. there is a fall through (return is inside an `if` on line 173). The original code is a bit confusing, it took me a while to see the fall through cases, that's why I added explicit comments. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 192: > >> 190: return null; >> 191: } >> 192: // fall through > > There is no "fall through" here as we return from all conditions in previous case. same comment, there is a fall through. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 486: > >> 484: return null; >> 485: } >> 486: // fall through > > There is no "fall through" here as we return from all conditions in previous case. same comment, there is a fall through. ------------- PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Nov 3 16:11:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:11:47 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 10:21:57 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: added tests >> - 8187145: clear selected tree table row when setting null selection model >> - 8187145: clear selection when setting selection model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: whitespace >> - 8187145: clear focus >> - 8187145: tree table view >> - 8187145: fall through >> - ... and 1 more: https://git.openjdk.org/jfx/compare/7cb8d679...fed5dfdb > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 500: > >> 498: return null; >> 499: } >> 500: // fall through > > There is no "fall through" here as we return from all conditions in previous case. same response: there is. ------------- PR: https://git.openjdk.org/jfx/pull/876 From kcr at openjdk.org Thu Nov 3 16:13:04 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Nov 2022 16:13:04 GMT Subject: RFR: 8290844: Add Skin.install() method [v20] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 15:49:07 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/845 From aghaisas at openjdk.org Thu Nov 3 16:13:08 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Nov 2022 16:13:08 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 09:43:39 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290844: review comments > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 94: > >> 92: >> 93: /** >> 94: * Called when a previously installed skin is about to be removed from its associated control. > > Use @code tag for `Skin` and `Control` in this description. I think, you accidentally marked this as resolved :) ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Nov 3 16:13:08 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:13:08 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 16:07:32 GMT, Ajit Ghaisas wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 94: >> >>> 92: >>> 93: /** >>> 94: * Called when a previously installed skin is about to be removed from its associated control. >> >> Use @code tag for `Skin` and `Control` in this description. > > I think, you accidentally marked this as resolved :) did I miss a requested change somewhere? ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Nov 3 16:17:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Nov 2022 16:17:03 GMT Subject: RFR: 8290844: Add Skin.install() method [v19] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 16:10:16 GMT, Andy Goryachev wrote: >> I think, you accidentally marked this as resolved :) > > did I miss a requested change somewhere? In this sentence, `skin` and `control` are lower-case (so don't refer to a class) and don't refer to a specific `@param` argument, so I don't think they don't need code case. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Nov 3 16:18:54 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:18:54 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 20:20:11 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: added tests > - 8187145: clear selected tree table row when setting null selection model > - 8187145: clear selection when setting selection model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: whitespace > - 8187145: clear focus > - 8187145: tree table view > - 8187145: fall through > - ... and 1 more: https://git.openjdk.org/jfx/compare/7cb8d679...fed5dfdb 26 minutes since the last push, jira does not see the changes. what gives? ------------- PR: https://git.openjdk.org/jfx/pull/876 From aghaisas at openjdk.org Thu Nov 3 16:25:52 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Nov 2022 16:25:52 GMT Subject: RFR: 8290844: Add Skin.install() method [v20] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 15:49:07 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/845 From aghaisas at openjdk.org Thu Nov 3 16:27:14 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Nov 2022 16:27:14 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 15:56:33 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java line 274: >> >>> 272: protected void simpleSelect(MouseButton button, int clickCount, boolean shortcutDown) { >>> 273: final int index = getIndex(); >>> 274: boolean isAlreadySelected; >> >> Code simplification: if `isAlreadySelected` is initialized to `false` on this line, then we can have only `if(sm != null)` condition below instead of if-else. > > it's not: `isAlreadySelected` is set on line 278 or 280. Line 274 is just a declaration. What I mean by code simplification is - boolean isAlreadySelected = false; MultipleSelectionModel sm = getSelectionModel(); if (sm != null) { isAlreadySelected = sm.isSelected(index); if (isAlreadySelected && shortcutDown) { sm.clearSelection(index); getFocusModel().focus(index); isAlreadySelected = false; } else { sm.clearAndSelect(index); } } >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 178: >> >>> 176: return null; >>> 177: } >>> 178: // fall through >> >> There is no "fall through" here as we return from all conditions in previous case. > > there is a fall through (return is inside an `if` on line 173). > The original code is a bit confusing, it took me a while to see the fall through cases, that's why I added explicit comments. There is a `return null` on line 176. In that case, we will return from either line 173 or line 176. Hence, there is no fall through. ------------- PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Nov 3 16:27:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:27:14 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: <46QWM9Z74db6QM4WiyLVdM81jcnKmGRVa_pekN7a5Pg=.8a4718ba-2d83-461f-b17c-369a5658d3e1@github.com> On Thu, 3 Nov 2022 16:17:09 GMT, Ajit Ghaisas wrote: >> it's not: `isAlreadySelected` is set on line 278 or 280. Line 274 is just a declaration. > > What I mean by code simplification is - > > boolean isAlreadySelected = false; > MultipleSelectionModel sm = getSelectionModel(); > if (sm != null) { > isAlreadySelected = sm.isSelected(index); > > if (isAlreadySelected && shortcutDown) { > sm.clearSelection(index); > getFocusModel().focus(index); > isAlreadySelected = false; > } else { > sm.clearAndSelect(index); > } > } in this version, there are code paths where you assign the same variable twice. I don't do that, I don't like doing that. Is this required or in the code style? ------------- PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Nov 3 16:33:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:33:14 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v6] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - 8187145: github - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: added tests - 8187145: clear selected tree table row when setting null selection model - 8187145: clear selection when setting selection model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: whitespace - 8187145: clear focus - ... and 3 more: https://git.openjdk.org/jfx/compare/01735b33...efe84b7a ------------- Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=05 Stats: 423 lines in 13 files changed: 330 ins; 11 del; 82 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Nov 3 16:43:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:43:25 GMT Subject: Integrated: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 19:22:48 GMT, Andy Goryachev wrote: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) This pull request has now been integrated. Changeset: 7f17447a Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7f17447aa44fbf5b09aaa2b699266dac8b50cea1 Stats: 120 lines in 5 files changed: 92 ins; 8 del; 20 mod 8290844: Add Skin.install() method Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Nov 3 16:57:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:57:11 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin Message-ID: Using new Skin.install() method to properly install and uninstall inputMethodTextChanged and inputMethodRequests properties on TextInputControl. This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8268877.input.method - Merge branch '8290844.skin.install' into 8268877.input.method - 8290844: review comments - 8290844: spelling - 8290844: review comments - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: review comments - ... and 31 more: https://git.openjdk.org/jfx/compare/7f17447a...04f4911e Changes: https://git.openjdk.org/jfx/pull/903/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=903&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8268877 Stats: 203 lines in 2 files changed: 118 ins; 40 del; 45 mod Patch: https://git.openjdk.org/jfx/pull/903.diff Fetch: git fetch https://git.openjdk.org/jfx pull/903/head:pull/903 PR: https://git.openjdk.org/jfx/pull/903 From fastegal at openjdk.org Thu Nov 3 16:57:13 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 3 Nov 2022 16:57:13 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly install and uninstall inputMethodTextChanged and inputMethodRequests properties on TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 340: > 338: control.setOnInputMethodTextChanged(inputMethodTextChangedHandler); > 339: } > 340: for the record: this pattern is incorrect (no matter _where_ the skin implements it ;) - a skin should not set a singleton event handler on its control (see [JDK-8093590](https://bugs.openjdk.org/browse/JDK-8093590)). Not sure how we should procede in this case: moving to install fixes the issue on face value (not overwriting a user-installed handler) but not the incorrect handler registration (should be replaced by an added listener as done in the fix of JDK-8093590) - the latter could be done in a follow-up issue, adding a code comment here? ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Thu Nov 3 16:57:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 16:57:14 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 09:29:06 GMT, Jeanette Winzenburg wrote: >> Using new Skin.install() method to properly install and uninstall inputMethodTextChanged and inputMethodRequests properties on TextInputControl. >> >> This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. >> >> This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 340: > >> 338: control.setOnInputMethodTextChanged(inputMethodTextChangedHandler); >> 339: } >> 340: > > for the record: this pattern is incorrect (no matter _where_ the skin implements it ;) - a skin should not set a singleton event handler on its control (see [JDK-8093590](https://bugs.openjdk.org/browse/JDK-8093590)). > > Not sure how we should procede in this case: moving to install fixes the issue on face value (not overwriting a user-installed handler) but not the incorrect handler registration (should be replaced by an added listener as done in the fix of JDK-8093590) - the latter could be done in a follow-up issue, adding a code comment here? Thank you. You are right - we can use addEventHandler(). ------------- PR: https://git.openjdk.org/jfx/pull/903 From kevin.rushforth at oracle.com Thu Nov 3 17:05:44 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 Nov 2022 10:05:44 -0700 Subject: CFV: New OpenJFX Committer: Andy Goryachev Message-ID: I hereby nominate Andy Goryachev [1] to OpenJFX Committer. Andy is a member of the JavaFX team at Oracle who has contributed 22 commits [2] to OpenJFX. Votes are due by November 17, 2022 at 18:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#angorya [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Andy+Goryachev%22&s=author-date&type=commits [3] https://openjdk.org/census#openjfx [4] https://openjdk.org/bylaws#lazy-consensus [5] https://openjdk.org/projects#project-committer From kevin.rushforth at oracle.com Thu Nov 3 17:07:42 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 Nov 2022 10:07:42 -0700 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: <384394a8-1802-2755-0343-a0b925e7c4bf@oracle.com> Vote: YES On 11/3/2022 10:05 AM, Kevin Rushforth wrote: > I hereby nominate Andy Goryachev [1] to OpenJFX Committer. From philip.race at oracle.com Thu Nov 3 17:12:21 2022 From: philip.race at oracle.com (Philip Race) Date: Thu, 3 Nov 2022 10:12:21 -0700 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: <8e383adf-22d8-403f-1bf3-78397532e7c8@oracle.com> Yes -Phil. From mhanl at openjdk.org Thu Nov 3 21:20:21 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Nov 2022 21:20:21 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests Message-ID: While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. The goal of this PR is to add snapping tests for all layout container. After that we can create issues for all broken layout container, fix them and comment in the corresponding line. ------------- Commit messages: - 8296330: Tests: Add layout container snapping tests Changes: https://git.openjdk.org/jfx/pull/936/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296330 Stats: 165 lines in 1 file changed: 165 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Thu Nov 3 21:21:42 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Nov 2022 21:21:42 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: > The problem here is, that the `AnchorPane` does not use its snapped insets. > Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. > > Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. > Line 2995 in `modena.css`: > > .titled-pane > .content > AnchorPane { > -fx-padding: 0.8em; > } > > which translates to 9.6px. > > EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8295078: Replace JUnit4 with Junit5 imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/910/files - new: https://git.openjdk.org/jfx/pull/910/files/901416db..9fa887b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/910.diff Fetch: git fetch https://git.openjdk.org/jfx pull/910/head:pull/910 PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 3 21:43:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Nov 2022 21:43:33 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v6] In-Reply-To: References: <3ENx-4GXr9i0N08c2eeDPzOOEDhJVGG5RWgHg4t_S9w=.e65f9e55-b2e1-4cd5-936b-85442cdbacff@github.com> Message-ID: On Fri, 28 Oct 2022 20:02:40 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 222: >> >>> 220: * @since 20 >>> 221: */ >>> 222: protected ListenerHelper listenerHelper() { >> >> This would make it part of the public API, so you will need to find some other way to do this without adding anything to the public API surface. > > I *do* want this as public API. > > I can change the code to use an accessor, but it gets really ugly: > > > ListenerHelper.get(PaginationSkin.this).addListChangeListener(getSkinnable().getStyleClass(), (ch) -> { > > > Besides, what's the harm of adding a [better] public API? I do want ListenerHelper to be public anyway. changed the code to remove listenerHelper() to avoid changing the public API. For now, will be using accessor, and using a local variable in skins where we have many calls to LH (in constructors, for example). ------------- PR: https://git.openjdk.org/jfx/pull/908 From john at status6.com Thu Nov 3 22:11:05 2022 From: john at status6.com (John Neffenger) Date: Thu, 3 Nov 2022 15:11:05 -0700 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: Vote: YES On 11/3/22 10:05 AM, Kevin Rushforth wrote: > I hereby nominate Andy Goryachev [1] to OpenJFX Committer. From tsayao at openjdk.org Fri Nov 4 01:27:58 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 4 Nov 2022 01:27:58 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v21] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <0BGWeab4xxoax-SaFc-yWXGytGMPVgtPO-0C88pSfhA=.2248fda3-d525-40bf-bb2a-f0c38bb530c0@github.com> > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in update_window_constraints; > - Frame extents (the window decoration size used for "total window size": > - frame extents are received in process_property_notify; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size; > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Back to gtk_window_set_focus_on_map FALSE to avoid the WM to tamper with window order ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/6e63bb52..f7d93814 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=19-20 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From aghaisas at openjdk.org Fri Nov 4 05:09:57 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 4 Nov 2022 05:09:57 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: <46QWM9Z74db6QM4WiyLVdM81jcnKmGRVa_pekN7a5Pg=.8a4718ba-2d83-461f-b17c-369a5658d3e1@github.com> References: <46QWM9Z74db6QM4WiyLVdM81jcnKmGRVa_pekN7a5Pg=.8a4718ba-2d83-461f-b17c-369a5658d3e1@github.com> Message-ID: On Thu, 3 Nov 2022 16:23:51 GMT, Andy Goryachev wrote: >> What I mean by code simplification is - >> >> boolean isAlreadySelected = false; >> MultipleSelectionModel sm = getSelectionModel(); >> if (sm != null) { >> isAlreadySelected = sm.isSelected(index); >> >> if (isAlreadySelected && shortcutDown) { >> sm.clearSelection(index); >> getFocusModel().focus(index); >> isAlreadySelected = false; >> } else { >> sm.clearAndSelect(index); >> } >> } > > in this version, there are code paths where you assign the same variable twice. I don't do that, I don't like doing that. Is this required or in the code style? It may not be the code style requirement, but generally, it is a good practice to initialize the variable explicitly at the time of declaration. My version saves an `else` block as well. Anyway, I will not insist on this as it is a trivial code style preference. ------------- PR: https://git.openjdk.org/jfx/pull/876 From aghaisas at openjdk.org Fri Nov 4 05:09:59 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 4 Nov 2022 05:09:59 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 16:21:20 GMT, Ajit Ghaisas wrote: >> there is a fall through (return is inside an `if` on line 173). >> The original code is a bit confusing, it took me a while to see the fall through cases, that's why I added explicit comments. > > There is a `return null` on line 176. > In that case, we will return from either line 173 or line 176. Hence, there is no fall through. Any comments on this? ------------- PR: https://git.openjdk.org/jfx/pull/876 From kcr at openjdk.org Fri Nov 4 11:48:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 11:48:48 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: <2Dvk4xV5_C_rUKUobMlsXjtgNGmx2tr07FbYCShqGX8=.0f1d2975-192b-44c3-af1c-62fa4ae33f41@github.com> On Thu, 3 Nov 2022 16:00:30 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 192: >> >>> 190: return null; >>> 191: } >>> 192: // fall through >> >> There is no "fall through" here as we return from all conditions in previous case. > > same comment, there is a fall through. No, there isn't. ------------- PR: https://git.openjdk.org/jfx/pull/876 From fastegal at openjdk.org Fri Nov 4 14:19:39 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 4 Nov 2022 14:19:39 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 05:07:17 GMT, Ajit Ghaisas wrote: >> There is a `return null` on line 176. >> In that case, we will return from either line 173 or line 176. Hence, there is no fall through. > > Any comments on this? hmm .. maybe this is a mis-understanding: - the case selected_items looks fishy (also in the original) - seems to not return if the selection is empty or now if the selection is null - every known case should return under any condition, IMO, delegating to super is done only for unhandled cases Also, selected_items looks weird to return from inside the loop across the selected cells on the very first iteration. Might be a bug. BTW: did I ever mention that we need tests for everything we change ;) See the equivalent fix for ListView for how to .. ------------- PR: https://git.openjdk.org/jfx/pull/876 From powers.anirvan at gmail.com Fri Nov 4 15:53:59 2022 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Fri, 4 Nov 2022 21:23:59 +0530 Subject: Switching to ANGLE ? In-Reply-To: References: Message-ID: There is an ANGLE RFE [1]. It is closed as a duplicate of an older WebGL RFE [2]. [1] : https://bugs.openjdk.org/browse/JDK-8134841 [2] : https://bugs.openjdk.org/browse/JDK-8091035 On Wed, 2 Nov 2022 at 7:56 PM, Mike Hearn wrote: > On a topic unrelated to Conveyor, I saw the JavaFX roadmap document > presented at JavaOne and the mention of a Metal pipeline. > > It prompted a thought I've never got around to exploring - does it make > sense to switch JavaFX to using Google's ANGLE library i.e. to decommission > all but the GL backend and then use it on every OS? This would have three > big and obvious advantages: > > 1. A big reduction in the maintenance burden. A metal port is maybe no > longer required. > > 2. A component or canvas that exposes a GL context (implicitly, on the > current thread) could then be provided relatively easily, allowing easier > integration of arbitrary drawing with the scene graph without compromising > portability. > > 3. In turn that would unblock enabling WebGL in the WebView control, > fixing Google Maps. > > It's mostly a question of curiosity but I'm wondering if that approach has > ever been prototyped or explored. > > thanks, > -mike > -- Anirvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Nov 4 15:59:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 15:59:47 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: <2Dvk4xV5_C_rUKUobMlsXjtgNGmx2tr07FbYCShqGX8=.0f1d2975-192b-44c3-af1c-62fa4ae33f41@github.com> References: <2Dvk4xV5_C_rUKUobMlsXjtgNGmx2tr07FbYCShqGX8=.0f1d2975-192b-44c3-af1c-62fa4ae33f41@github.com> Message-ID: On Fri, 4 Nov 2022 11:45:06 GMT, Kevin Rushforth wrote: >> same comment, there is a fall through. > > No, there isn't. this is embarrassing - you are right. the only fall through case is on line 169, but it's clearly wrong, as it should not be falling through to CELL_AT_ROW_COLUMN. in the case of a null selection model, should queryAccessibleAttribute(SELECTED_ITEMS) return null or an empty list? ------------- PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 16:04:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 16:04:43 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:15:43 GMT, Jeanette Winzenburg wrote: >> Any comments on this? > > hmm .. maybe this is a mis-understanding: > > - the case selected_items looks fishy (also in the original) - seems to not return if the selection is empty or now if the selection is null > - every known case should return under any condition, IMO, delegating to super is done only for unhandled cases > > Also, selected_items looks weird to return from inside the loop across the selected cells on the very first iteration. Might be a bug. > > BTW: did I ever mention that we need tests for everything we change ;) See the equivalent fix for ListView for how to .. I am clearly in the wrong, sorry. There is only one possible fall through for SELECTED_ITEMS -> CELL_AT_ROW_COLUMN which is not correct. Q is, what should it return - a null or an empty list? (I am in favor of a null because selection is impossible, as opposed to "nothing is selected". Whether the attribute can be null should be specified in javafx.scene.AccessibleAttribute, do you think? ------------- PR: https://git.openjdk.org/jfx/pull/876 From dwookey at openjdk.org Fri Nov 4 16:15:06 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Fri, 4 Nov 2022 16:15:06 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed Message-ID: When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. This pull request just removes the redundant code in the MenuButtonSkinBase. ------------- Commit messages: - 8296409: Stop additional change listeners being added Changes: https://git.openjdk.org/jfx/pull/937/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296409 Stats: 26 lines in 2 files changed: 16 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/937.diff Fetch: git fetch https://git.openjdk.org/jfx pull/937/head:pull/937 PR: https://git.openjdk.org/jfx/pull/937 From kevin.rushforth at oracle.com Fri Nov 4 16:22:40 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 Nov 2022 09:22:40 -0700 Subject: Switching to ANGLE ? In-Reply-To: References: Message-ID: <25a0227a-a4bb-c21b-492c-f9d984a5da87@oracle.com> We briefly considered this several years ago. We are unlikely to switch Prism rendering to Angle. Having a dependency on another large third-party library in our core renderer is not a direction we plan to go. As a note, WebGL wouldn't fall out for free from this anyway, since the way WebKit's WebGL integrates with Angle is different from what would happen if Prism used Angle internally, so there would still be effort needed to integrate them. -- Kevin On 11/4/2022 8:53 AM, Anirvan Sarkar wrote: > There is an ANGLE RFE [1]. > It is closed as a duplicate of an older WebGL RFE [2]. > > [1] : > https://bugs.openjdk.org/browse/JDK-8134841 > [2] : > https://bugs.openjdk.org/browse/JDK-8091035 > > > > On Wed, 2 Nov 2022 at 7:56 PM, Mike Hearn wrote: > > On a topic unrelated to Conveyor, I saw the JavaFX roadmap > document presented at JavaOne and the mention of a Metal pipeline. > > It prompted a thought I've never got around to exploring - does it > make sense to switch JavaFX to using Google's ANGLE library i.e. > to decommission all but the GL backend and then use it on every > OS? This would have three big and obvious advantages: > > 1. A big reduction in the maintenance burden. A metal port is > maybe no longer required. > > 2. A component or canvas that exposes a GL context (implicitly, on > the current thread) could then be provided relatively easily, > allowing easier integration of arbitrary drawing with the scene > graph without compromising portability. > > 3. In turn that would unblock enabling WebGL in the WebView > control, fixing Google Maps. > > It's mostly a question of curiosity?but I'm wondering if that > approach has ever been prototyped or explored. > > thanks, > -mike > > -- > Anirvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Nov 4 16:35:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 16:35:45 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:15:43 GMT, Jeanette Winzenburg wrote: >> Any comments on this? > > hmm .. maybe this is a mis-understanding: > > - the case selected_items looks fishy (also in the original) - seems to not return if the selection is empty or now if the selection is null > - every known case should return under any condition, IMO, delegating to super is done only for unhandled cases > > Also, selected_items looks weird to return from inside the loop across the selected cells on the very first iteration. Might be a bug. > > BTW: did I ever mention that we need tests for everything we change ;) See the equivalent fix for ListView for how to .. And thank you @kleopatra for reference and reminder about test. Out of this comes [JDK-8296413](https://bugs.openjdk.org/browse/JDK-8296413) TableView with null focus model throws NPE in queryAccessibleAttribute(AccessibleAttribute.FOCUS_ITEM) ------------- PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 16:38:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 16:38:26 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v7] In-Reply-To: References: Message-ID: <39z3-M3n8Tpyc8ad77-sGCQERAoYpmRRZ89iJp-IoCs=.e680e984-ac53-4b6d-88c6-2cdc2ef92609@github.com> > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/efe84b7a..45b2e03a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=05-06 Stats: 31 lines in 2 files changed: 26 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 16:40:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 16:40:30 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v8] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: review comments - 8187145: github - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: added tests - 8187145: clear selected tree table row when setting null selection model - 8187145: clear selection when setting selection model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - ... and 5 more: https://git.openjdk.org/jfx/compare/7f17447a...df3aed13 ------------- Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=07 Stats: 449 lines in 14 files changed: 354 ins; 12 del; 83 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 16:48:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 16:48:59 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v9] In-Reply-To: References: Message-ID: <0mIPruZzCEzpfKs8SvmFTLpPoJsvdSjv6c7HdsVxWv4=.c20cd4bc-3e63-4f28-992f-2b865e7eca2f@github.com> > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/df3aed13..f2feee5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 17:06:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 17:06:05 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v10] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: also tree table view ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/f2feee5b..5e3b0076 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=08-09 Stats: 32 lines in 2 files changed: 28 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Fri Nov 4 17:29:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 17:29:46 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 16:07:54 GMT, Dean Wookey wrote: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. I wonder if changes in [JDK-8295426](https://bugs.openjdk.org/browse/JDK-8295426): MenuButtonSkin: memory leak when changing skin would impact this PR or vice versa. ------------- PR: https://git.openjdk.org/jfx/pull/937 From kcr at openjdk.org Fri Nov 4 17:53:53 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 17:53:53 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v3] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:58:15 GMT, Johan Vos wrote: >> The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. >> The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. >> I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments Looks good. If you want to switch to using `Math.round` I'll reapprove. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Fri Nov 4 17:53:53 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 17:53:53 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:54:00 GMT, Johan Vos wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 400: >> >>> 398: float py = screen.getPlatformY(); >>> 399: newx = sx + (wx - px) * awtScaleX / pScaleX; >>> 400: newy = sy + (wy - py) * awtScaleY / pScaleY; >> >> `px` and `py` are already (scaled) "FX" coordinates, so I'm not sure AWT scale should be applied to that. I might be missing something here. > > Without this correction, there is an offset on Linux (when awtScaleX = 1 and pScaleX =2 for example, versus 1.5 for both on Windows). > TBH, I think the relations between the different scale factors should be written out clearly somewhere, as I think there are a number of places where we face platform-specific differences. Yeah, I agree this should be more clearly documented. I've tested it on macOS and Windows and it works fine, so I expect that this is correct as you have it. ------------- PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Fri Nov 4 17:53:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 17:53:54 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v3] In-Reply-To: References: <6E9g4Pg7kY2-APS31PUXCrxPS9da9_8BHdmsyusd_vE=.55ea53e4-1f6c-47a5-bfae-0f0a01ef8395@github.com> Message-ID: <5S4dB7d42YZJpcs631qjyc-qD9BC8Z4emLsw_RZKojs=.6b1b758c-b960-4b57-bd89-bb6f7b1ec6ba@github.com> On Wed, 2 Nov 2022 20:07:22 GMT, Johan Vos wrote: >> I suspect Math.floor() would be incorrect - we should use Math.round() for coordinates and Math.floor() for sizes (sizes will always be positive, I hope, and the rounded size will be slightly smaller than the original value). >> >> But for coordinates we should use (int)Math.round() > > I'll change it to Math.round, although I doubt it doesn't improve anything (but it won't make it worse either). > The reason we need the transformation on those coordinates is to position new windows, *relative* against the location of the root window that we are given by Swing. Hence, if the operation applied to the window location coordinates (in sendMoveEventToFX) is the same as the operation applied to the mouse point (in sendMouseEventToFX), we are good. > A bigger problem imho is that mouseEvents, scrollEvents and menuEvents are dealing with different precisions in the EmbeddedSceneInterface -- but that is a different problem. I also expect that it won't make much of a difference here, but Andy is right that, for snapping positions, `Math.round` is preferred. That's what layout panes do in `Region::snapPositionX/Y` ------------- PR: https://git.openjdk.org/jfx/pull/924 From kcr at openjdk.org Fri Nov 4 19:07:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 19:07:50 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v8] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:45:51 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8294809: whitespace Before reviewing the code itself, I have a couple global comments and a small number of inline comments. Since `ListenerHelper` is now an internal implementation detail, we can defer the longer discussion of whether and how to expose this as public API. In its current incarnation, it seems like a helpful utility to fix a number of skin memory leaks, and will likely be an eventual replacement for the (also internal) `LambdaMultiplePropertyChangeListenerHandler` utility class. If this ever does become public API in the future, we will need a naming discussion as part of the larger discussion of what form the API should take. For example, we wouldn't use `IDisconnectable` as the name of a public interface in the JavaFX API (we don't use the pattern a leading `I` for interfaces anywhere in JavaFX or in the JDK); also, we would need more descriptive names for `ChLi`, `MaChLi`, and so forth (presuming they need to be exposed). The larger discussion, though, will first need to clearly identify what the purpose of this utility is. If it is specific to control skins, then whatever minimal public API surface that needs to be exposed to do that job so third-party controls could use it is what we would want. If it is to be more general, then it doesn't belong in the `javafx.controls` module at all, but belongs in `javafx.base`. In the either case, but especially for an API in `javafx.base`, we need to ensure that this is generally useful to application developers, and not just for our own internal UI controls. Also, we would need to see how it fits with the existing APIs in `javafx.base`, and the newly proposed APIs in PR #830. Btw, the existing implementation is not suitable to be generic, since it references classes like `Task`, `Node`, `Scene`, `Label`, and `TableColumn`. As I mentioned above, we don't need to have this discussion unless and until there is a desire to make this public API some future release. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/IDisconnectable.java line 32: > 30: * Original code is re-licensed to Oracle by the author. > 31: * https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/common/util/Disconnectable.java > 32: * Copyright ? 2021-2022 Andy Goryachev Copyright and licensing information doesn't belong in the javadocs. I recommend putting this in a separate ordinary comment block (`/*` rather than `/**`) right above the class docs. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/IDisconnectable.java line 35: > 33: */ > 34: @FunctionalInterface > 35: public interface IDisconnectable { We don't use the pattern of naming interfaces with a leading `I` in JavaFX (or in the JDK), but since this isn't public API, you can leave it for now. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/IDisconnectable.java line 41: > 39: */ > 40: public void disconnect(); > 41: } Minor: end the class with a newline modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 69: > 67: * Original code is re-licensed to Oracle by the author. > 68: * https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > 69: * Copyright ? 2021-2022 Andy Goryachev Copyright and licensing information doesn't belong in the javadocs. I recommend putting this in a separate ordinary comment block right above the class docs. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 94: > 92: ListenerHelper h = get(skin); > 93: h.disconnect(); > 94: } Minor: This method might not be needed, since the client code can call: ListenerHelper.get(this).disconnect(); modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 514: > 512: } > 513: } > 514: } Minor: end the class with a newline modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 225: > 223: * Returns the skin's instance of {@link ListenerHelper}, creating it if necessary. > 224: * > 225: * @since 20 This isn't public API, so you should remove the `@since` tag ------------- PR: https://git.openjdk.org/jfx/pull/908 From thiago.sayao at gmail.com Fri Nov 4 19:25:37 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 4 Nov 2022 16:25:37 -0300 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: Vote: YES Em qui., 3 de nov. de 2022 ?s 14:06, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I hereby nominate Andy Goryachev [1] to OpenJFX Committer. > > Andy is a member of the JavaFX team at Oracle who has contributed 22 > commits [2] to OpenJFX. > > Votes are due by November 17, 2022 at 18:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#angorya > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Andy+Goryachev%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Nov 4 19:31:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 19:31:33 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 16:07:54 GMT, Dean Wookey wrote: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. @DeanWookey : the newly added test still fails with [JDK-8295426](https://bugs.openjdk.org/browse/JDK-8295426) changes, so I think we might want to address/integrate this PR first. ------------- PR: https://git.openjdk.org/jfx/pull/937 From kcr at openjdk.org Fri Nov 4 19:47:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 19:47:34 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v8] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:45:51 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8294809: whitespace @arapte and @aghaisas Can you also review this? It really needs to be done in connection with one of the existing Draft PRs that will take advantage of it, such as PR #925 , since the purpose is to make it easier for skins to avoid memory leaks. ------------- PR: https://git.openjdk.org/jfx/pull/908 From kcr at openjdk.org Fri Nov 4 19:52:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 19:52:38 GMT Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 11:43:41 GMT, Ambarish Rapte wrote: >> Don't set TabHeader to mouseTransparent, since it might get stuck in that state (e.g. in case an Alert is shown). >> The TabPaneSkin deals with the dragging internally, and does not require the dragged node to be mouseTransparent. > > The fix looks good to me. Testing looks good. > But I am not sure why I had included this call at the time of implementation. > Requesting @kevinrushforth to take a look. @arapte can you also review? ------------- PR: https://git.openjdk.org/jfx/pull/895 From kcr at openjdk.org Fri Nov 4 19:55:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 19:55:39 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 16:07:54 GMT, Dean Wookey wrote: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. Reviewers: @arapte @andy-goryachev-oracle ------------- PR: https://git.openjdk.org/jfx/pull/937 From kcr at openjdk.org Fri Nov 4 20:00:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:00:33 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests In-Reply-To: References: Message-ID: <9wujWPmlezEh42YRh_mR6wAVjazRPWD4RY_ZKUoXOqg=.9319f910-a757-48e3-8cf3-6504ce766909@github.com> On Thu, 3 Nov 2022 21:15:08 GMT, Marius Hanl wrote: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. NOTE: this is blocked by the fix for [JDK-8296283](https://bugs.openjdk.org/browse/JDK-8296283), which @arapte plans to do next week. ------------- PR: https://git.openjdk.org/jfx/pull/936 From kcr at openjdk.org Fri Nov 4 20:06:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:06:34 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports NOTE: this is blocked by the fix for [JDK-8296283](https://bugs.openjdk.org/browse/JDK-8296283), which @arapte plans to do next week. ------------- PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Fri Nov 4 20:23:27 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:23:27 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly install and uninstall inputMethodTextChanged and inputMethodRequests properties on TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). If this is changed to adding an `EventHandler` rather than calling `setOnInputMethodTextChanged`, do you still want / need to move the initialization logic to the `Skin::install` method? I presume you do, so we will need to highlight the potential behavioral incompatibility, in the API docs (maybe via an `@implNote`, since the only compatibility concern is with subclasses that make assumptions about undocumented behavior of their superclass) or a release note or both. ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Fri Nov 4 20:25:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 20:25:39 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v8] In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 16:45:51 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8294809: whitespace I fully agree with the need for a wider discussion. Any suggestions for changing of names etc. are always welcomed. The use case for a public ListenerHelper is to provide a convenient way to disconnect any listeners when a certain application-level UI (panel, window) is closed and gets discarded. For instance, a financial application might have a short-lived popup with a chart, multiple subscriptions to real time data, and so on; and there is a single moment when this popup gets closed and discarded. In this situation, it is better to disconnect all data subscriptions as well as all listeners that has been added to various application components, at that exact moment. For this PR, the goal is not to extend the public API surface and keep things as implementation detail. ChLi and other can be made package private or private. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Fri Nov 4 20:25:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 20:25:39 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v8] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:58:16 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8294809: whitespace > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/IDisconnectable.java line 35: > >> 33: */ >> 34: @FunctionalInterface >> 35: public interface IDisconnectable { > > We don't use the pattern of naming interfaces with a leading `I` in JavaFX (or in the JDK), but since this isn't public API, you can leave it for now. leaving as is for now. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Fri Nov 4 20:30:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 20:30:53 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: Message-ID: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> > Introduction > > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). > > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > Proposal > > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: > > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. > - keeps track of the listeners and the corresponding ObservableValues > - provides a single disconnect() method to remove all the listeners in one go. > - optionally, it should be possible to add a lambda (Runnable) to a group of properties > - optionally, there should be a boolean flag to fire the lambda immediately > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method > > Make it Public Later > > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. > > Where It Will Be Useful > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. > > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft > > https://github.com/openjdk/jfx/pull/914 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 24 additional commits since the last revision: - 8294809: review comments - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - 8294809: whitespace - 8294809: no public api - 8294809: map change listener - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - 8294809: generics - 8294809: is alive - Revert "8294809: removed weak listeners support" This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. - 8294809: removed weak listeners support - ... and 14 more: https://git.openjdk.org/jfx/compare/1912f9bd...470f42c1 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/908/files - new: https://git.openjdk.org/jfx/pull/908/files/e0e0aabb..470f42c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=07-08 Stats: 343 lines in 26 files changed: 210 ins; 39 del; 94 mod Patch: https://git.openjdk.org/jfx/pull/908.diff Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908 PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Fri Nov 4 20:39:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 20:39:40 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 20:19:52 GMT, Kevin Rushforth wrote: > do you still want / need to move the initialization logic to the `Skin::install` method? good question. In the case of `setOnInputMethodTextChanged` -> `control.addEventHandler(InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` the code remains in the constructor, so no behavioral changes are expected. But `control.setInputMethodRequests(inputMethodRequests);` must be done in `install()` since it's setting the property. Another question is whether we should use ListenerHelper for `control.addEventHandler(InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` , but that would move this PR into a draft stage until ListenerHelper is integrated. Or perhaps it could be done as a part of [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076). ------------- PR: https://git.openjdk.org/jfx/pull/903 From kcr at openjdk.org Fri Nov 4 20:40:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:40:40 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v3] In-Reply-To: References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Fri, 28 Oct 2022 13:54:40 GMT, eduardsdv wrote: >> This fixes a race condition between application and 'Print Job Thread' threads when printing. >> >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. >> >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. > > eduardsdv has updated the pull request incrementally with two additional commits since the last revision: > > - 8295324: Fix skipping of pages when printing > > This occurs in print(Graphics, PageFormat, int) if the 'jobDone' flag > was previously set by the 'endJob()' method. > - 8295324: Adjust the J2DPrinterJobTest > > The test now also checks for the second race condition around 'jobDone' > flag, which is in the print(Graphics, PageFormat, int) method. @prrace Can you review this? ------------- PR: https://git.openjdk.org/jfx/pull/916 From kcr at openjdk.org Fri Nov 4 20:43:45 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:43:45 GMT Subject: RFR: 8230231: font-family not updated in HTMLEditor [v3] In-Reply-To: References: Message-ID: <9rS2fUVK_VfnVsKMg09WVXEOujMp4r1Qqu1Hsx4YGK8=.4e27419d-fe81-4632-b04e-51ed3280f29e@github.com> On Wed, 21 Jul 2021 14:56:11 GMT, Hadzic Samir wrote: >> Fix for https://github.com/javafxports/openjdk-jfx/issues/573 >> >> Issue on JBS bug tracking : https://bugs.openjdk.java.net/browse/JDK-8230231 >> >> Fix: Check for quote when updating the font-family comboBox. >> >> A new font is added as a resource for the test. This font is same as modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKitWeightWatcher100.ttf > > Hadzic Samir has updated the pull request incrementally with one additional commit since the last revision: > > Add a unit test Reviewers: @arapte @jaybhaskar ------------- PR: https://git.openjdk.org/jfx/pull/12 From angorya at openjdk.org Fri Nov 4 20:48:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 20:48:31 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:15:08 GMT, Marius Hanl wrote: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. minor questions and suggestions, otherwise looks good. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 46: > 44: import static org.junit.jupiter.api.Assertions.*; > 45: > 46: class SnappingTest { should it be `public class SnappingTest`? Also, perhaps a brief javadoc explaining the purpose of this test might help. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 85: > 83: @MethodSource(value = { "getContainerInstruction" }) > 84: void testContainerSnappingScale200(ContainerInstruction containerInstruction) { > 85: testContainerSnappingImpl(containerInstruction, 2); minor: do you think there is a need for other scale factors? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 127: > 125: > 126: assertEquals(widthHeight + snappedPaddingX, container.prefWidth(-1), 0.00001, className); > 127: assertEquals(widthHeight + snappedPaddingY, container.prefHeight(-1), 0.00001, className); perhaps this should be a constant? ------------- PR: https://git.openjdk.org/jfx/pull/936 From kcr at openjdk.org Fri Nov 4 20:58:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 20:58:28 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: <_ur9iIEpTwGNzY8XcgxM-VV-0ZfkDw21l5glAEkAgdI=.07160882-bf54-4fd6-9bb6-41df51d08ebb@github.com> On Fri, 4 Nov 2022 20:36:00 GMT, Andy Goryachev wrote: > > do you still want / need to move the initialization logic to the `Skin::install` method? > > good question. In the case of `setOnInputMethodTextChanged` -> `control.addEventHandler(InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` the code remains in the constructor, so no behavioral changes are expected. > > But `control.setInputMethodRequests(inputMethodRequests);` must be done in `install()` since it's setting the property. In that case, depending on which direction you go, we may or may not need an impl note (and I wouldn't bother with a release note, since I think the compatibility risk is small enough anyway; I could be talked into a release note if others feel differently). > Another question is whether we should use ListenerHelper for `control.addEventHandler(InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` , but that would move this PR into a draft stage until ListenerHelper is integrated. Or perhaps it could be done as a part of [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076). Doing it as part of JDK-8296076 seems best. ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Fri Nov 4 21:06:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 21:06:39 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly set and remove inputMethodRequests property in TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). I wonder if this even needs an implementation note, as it is a bug fix. We did add one in [JDK-8292212](https://bugs.openjdk.org/browse/JDK-8292212) Skin.install(), should be sufficient. ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Fri Nov 4 21:16:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 21:16:43 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 16:07:54 GMT, Dean Wookey wrote: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 154: > 152: sceneChangeListener = (scene, oldValue, newValue) -> { > 153: if (oldValue != null) { > 154: ControlAcceleratorSupport.removeAcceleratorsFromScene(getSkinnable().getItems(), oldValue); will it handle a case where the menu button gets attached to a different scene? could you add a second test for this scenario please? And i wonder if the problem is in ControlAcceleratorSupport rather than here. We do have a similar code in Control:380, do we have a problem there? ------------- PR: https://git.openjdk.org/jfx/pull/937 From kcr at openjdk.org Fri Nov 4 21:54:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Nov 2022 21:54:31 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly set and remove inputMethodRequests property in TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). Maybe not then. ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Fri Nov 4 22:01:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Nov 2022 22:01:50 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v11] In-Reply-To: References: Message-ID: <7jpqV6igoqkYhSeobTqboIT8eQHPlBF58PUBdHL_xrs=.d3832b97-0961-434e-b656-c5db7878224b@github.com> > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/5e3b0076..8065548c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From tsayao at openjdk.org Sat Nov 5 01:06:56 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 5 Nov 2022 01:06:56 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v22] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <7oUMMeyiQeC5fkzBJ20tqiB28UsTef-MUfbgj8YZbxI=.2dd45bdd-eb3d-464e-9dfa-4371a6dfa619@github.com> > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on request_focus(); > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix focus ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/f7d93814..58bb987f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=21 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=20-21 Stats: 8 lines in 1 file changed: 1 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From mhanl at openjdk.org Sat Nov 5 13:11:59 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 5 Nov 2022 13:11:59 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 20:42:07 GMT, Andy Goryachev wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 46: > >> 44: import static org.junit.jupiter.api.Assertions.*; >> 45: >> 46: class SnappingTest { > > should it be `public class SnappingTest`? > > Also, perhaps a brief javadoc explaining the purpose of this test might help. JUnit5 classes do not need to be public. Sure, I will add javadoc. :) > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 85: > >> 83: @MethodSource(value = { "getContainerInstruction" }) >> 84: void testContainerSnappingScale200(ContainerInstruction containerInstruction) { >> 85: testContainerSnappingImpl(containerInstruction, 2); > > minor: do you think there is a need for other scale factors? I don't think so. We could add more but I don't see how this will give us any more information/benefits. > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 127: > >> 125: >> 126: assertEquals(widthHeight + snappedPaddingX, container.prefWidth(-1), 0.00001, className); >> 127: assertEquals(widthHeight + snappedPaddingY, container.prefHeight(-1), 0.00001, className); > > perhaps this should be a constant? Sure, will do. ------------- PR: https://git.openjdk.org/jfx/pull/936 From jhendrikx at openjdk.org Sun Nov 6 00:24:27 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Nov 2022 00:24:27 GMT Subject: RFR: 8221708 Update Eclipse project files Message-ID: See https://bugs.openjdk.org/browse/JDK-8221708 ------------- Commit messages: - Fix line endings for Eclipse project files - Add Eclipse encoding files (UTF8) - Add buildship Eclipse files to all gradle projects - Remove Eclipse files from non-projects - Fix 3DLighting project - Add swt-debug jar to manualTests-swt - Rename top level project to jfx in Eclipse project files - Add project files for manual tests - Created Eclipse projects for all the testapps - Remove reference to Java 11 container - ... and 6 more: https://git.openjdk.org/jfx/compare/b3eec1d6...57048ba6 Changes: https://git.openjdk.org/jfx/pull/930/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221708 Stats: 2070 lines in 123 files changed: 1810 ins; 244 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/930.diff Fetch: git fetch https://git.openjdk.org/jfx pull/930/head:pull/930 PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:29 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:29 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 This is the review for /apps. apps itself is a gradle project as specific in the root project build.gradle file. I think that a gradle file should be generated there and the gradle nature added to it (the removal of the java nature is correct), but as I'm having build errors with gradle, I don't see any. Review for /tests: * /tests itself, despite being a top level folder, is neither a gradle nor a java project, so its peoject and classpath files need to be removed. /tests/system is the project that is configured by the root project. * Will need to think how to treat /manual. There doesn't seem to be normal structure with source folders. The changes to the graphics module's classpath file should be removed. It was updated in a more recent PR. The changes here should only apply to apps and tests (unless I find something else to fix while on it). I'll go over each folder to see what's misconfigured after all this time. It looks like a lot of projects under tests weren't configured. You can also remove the classpath of the root project as it's not a java project, just a gradle one. In the project file, maybe its name can be changed to jfx. I'm not sure if the name is auto-generated by gradle as specified in the comment. This is lumping in https://bugs.openjdk.org/browse/JDK-8293185. Yes, looking at, e.g., `src/testapp7/java`, the `mymod` folder needs to be a source folder for the module-info to be placed correctly, but then `src/testapp7/resources` has to be placed in a different project. I don't see an Eclipse-level solution here. I think that the contents of the folder need to be rearranged. I'm using the wrapper, which is 7.3. I managed to solve is using `gradlew --write-verification-metadata sha256 help`. The manual says it should be run after updating a dependency, so I wonder why I'm the only one with this problem. Looks good. Waiting on tests/manual. We also need to check the viability of running the gradle projects with gradle. I will write to the mailing list later. In your screenshot I see that apps is a Java project. That is wrong already. Also, none of the modules were touched, so the errors are from somewhere else. apps is a project, but not a java project. The new screenshot looks more correct, but now `controls` is a gradle project for some reason even though the project fil doesn't define it as such. I can't tell what errors you get on the modules projects, but these should not be affected at all since they weren't touched. I imported all projects as Java projects (not through the Gradle import) and got no errors except for the missing SWT dependency in the manual test. In addition, I have tested removing the project files on apps and tests/system (the Gradle 2 projects defined in the root project). I saw no problem. Buildship knows how to read them from their parents, so they don't need to be Gradle projects themselves. The only difference is the icon displayed in the Gradle Tasks view. I suggest removing these 2 files. Another test I made is with regards to the root project name (part of https://bugs.openjdk.org/browse/JDK-8293185 that we can probably close as a duplicate of this). Changing it didn't seems to have an effect on functionality. However, it's confusing both for the user and for Buildship if the project name and the folder name are different. Buildship shows both of them, but one has an error marker on it, while the other is functioning normally. Since the root folder might be named differently for different users as it's a repository base, I don't know if there's a solution that works for everyone. I can only suggest to rename it to `jfx` because that's the default folder name (and remove the comment in the project file). Previously (on mercurial) it was `rt`, that's where the current name comes from. I'll give the new classpath files under /tests one more look, but aside from that the PR will be ready as far as I'm concerned. * > Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs These files are in this PR, for example, https://github.com/openjdk/jfx/pull/930/files#diff-4b7911fda8890aa89f0b972959f282b0fa10750a81f2f20a8ab253b492ac05d9. * > import as gradle project, following the standard recipe from https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX produces 45K errors. A modified procedure described below produces 20K errors. What errors are these? Where do they come from? If you are getting "___ cannot be resolved" errors as you have shown above, then check if the resource that has them is defined on that project. If it is, then I don't understand why you get them. Even more so, it looks like you are getting them on module projects, while module projects weren't touched in this PR. I have deleted all the project and imported them in various ways at least 10 times while reviewing and never got those errors. I suspect it's local. The question is if other new users will have these issues too. I tested both importing as Gradle and as Existing projects, even one directly after the other to see what happens. Once the Gradle-generated files are reverted to the ones in this PR, most errors are gone (there is still the SWT error, but we know why). I'm looking at the `javax.script.AbstractScriptEngine` error in your screenshot. It is part of the `java.scripting` module in the JDK. Go to the project build path and under the Module Dependencies tab check that you have that module listed: ![image](https://user-images.githubusercontent.com/37422899/198723720-c09d0240-d760-4baf-9a8d-4f6259c519cd.png) 1. I'm not aware of a way to that stops Buildship from creating Eclipse files. If we had, it would have saved some trouble long ago. I'll try to look into it. 2. I don't know what causes that. I did notice that in all my importing and reimporting new files were not created in the bin after I deleted them. This will also require looking into. 3. The wizard uses the same process as in point 1. I don't think the wizard is the problem. I think that the end goal is to allow users to choose what tools they want to work with. If someone doesn't want to use Gradle from within Eclipse (and only from the command line) that's fine. Same for someone who does want that. I think that I should clarify a few things, just to be on the safe side. Using Gradle is essential to the development process. Developers in Eclipse can choose to either use Gradle externally (from the command line), or use built-in Gradle integrations in Eclipse. Those who choose to use Gradle externally don't need Buildship (or whatever other Gradle plugin there is) at all and no config files like those in `.settings`. This should always be a viable options and I know developers of JavaFX that use this option. Those who choose to use Gradle from within Eclipse (Buildship allows the Task View, custom Gradle run configurations, multiple consoles...) either need the config files given to them, or have Buildship generate it for them. When Buildship generates these, it also generates the project/classpath files, which need to be reverted. I don't think it's possible to separate the processes. There were also sentiments against checking in Bulldship files in the past. As I see it, we have 3 paths: 1. Don't provide any Gradle files and let those who want to use Gradle in Eclipse generate files locally (either via a Gradle import or a Refresh Gradle Project), reverting the wrong ones. 2. Provide all the Gradle files and explicitly say not to generate your own files or you will mess up your workspace. If you don't use Gradle from Eclipse then you don't care about these files. 3. Modify the Gradle build file to generate the correct Eclipse files and remove all Eclipse files from the repo. This was discussed a few years ago in the previous jfx repo at https://github.com/javafxports/openjdk-jfx/issues/4. Perhaps it's worth taking a look at again. > I haven't been able to reproduce the bin problem in any way after I manually deleted all of them. Same here. They might appear at some point later, though. > A few projects don't work correctly with Gradle (Ensemble8, 3DViewer and Modena), need to decide how to handle this, either: a) Fix their configuration in Gradle, or b) Remove the Gradle nature I don't use them myself. [Kevin commented](https://github.com/openjdk/jfx/pull/930#issuecomment-1293399112) about them. One cleanup pass has been made in [DK-8269259](https://bugs.openjdk.org/browse/JDK-8269259) and there should be another one, perhaps touching on these. If they stay, I think that Gradle tasks should be added to run these, including the 3DLighting project and maybe others. System tests could also use ready-made commands to run as specified [here](https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-RunningsystemtestswithRobot). This is probably for a different PR. > After everything works, we'll need to update the wiki I update it from time to time and I already have a draft writeup for its next update after we decide what we want to do about Gradle. apps/samples/3DViewer/.classpath line 14: > 12: > 13: > 14: These 2 look empty. If you don't see that these exist then they should be removed. apps/toys/ColorCube/.project line 4: > 2: > 3: ColorCube > 4: This change doesn't do anything as far as I know. It can be reverted. It can also stay. tests/system/.classpath line 153: > 151: > 152: > 153: I don't think this is right. No need to specify Java 11, just use the configured jdk as in all other projects. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:29 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 tens of thousand of errors in eclipse. looks like some projects are misconfigured. Changes requested by angorya (Author). removed the project, imported back as a gradle project, reverted the gradle changes (the usual process). now it shows 44,980 errors in controls, fxml, systemTests, web projects. Nir: apps is a project (there is a .project file in apps). the second import (a clean import of John's branch) shows apps with no errors. Screen Shot 2022-10-25 at 17 02 36 looks like Eclipse gets confused by something. I closed 'controls' project, reopened it and Eclipse showed additional files modified by gradle. Reverted those, and now all builds except for systemTests. 20,186 errors in systemTests project. The open/close trick does not work with systemTests. One difference I see is that the official process to import the project, according to https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK , is to use `Import as Gradle Project` rather than import as existing project. It's even worse: import as a gradle project, let gradle create a bunch of .project and .classpath files, refresh, the *revert* everything gradle did, refresh. That results in a gradle project in eclipse, with gradle tasks and everything ( I am still using command line gradle to build). If I do this with your latest build, I see: - 20K errors in systemTests project due to misconfigured source paths - none of the projects inside systemTests My first instinct is try removing systemTests .project file so all the nested projects in there become visible. Another issue is that I don't see projects in tests/manual as eclipse projects, so something isn't right (probably because of the nested projects or the way gradle works with eclipse?) Thank you for suggesting closing and reopening projects - it does something beyond F5 refresh and gets eclipse in sync. I think there is a problem with the projects still: - import an existing project (with Search for nested projects option enabled) first causes "Creation Problems" (see attached), and then produces 3 errors and 30 warnings. Description Resource Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs 3DViewer Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Ensemble8 Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Modena - import as gradle project, following the standard recipe from https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX produces 45K errors. A modified procedure described below produces 20K errors. Modified procedure: - import as gradle project - let gradle plugin work, that produces some changes visible in Git Staging view - refresh - revert all changes, see 45K errors - close all projects from Package Explorer, reopen - for some reason, after reopening Git Staging shows some more changes left. revert those - see 20K errors - Project -> clean all does not help, 20K errors I do not understand why you guys don't see this. are you importing as a gradle project? Screen Shot 2022-10-28 at 12 53 27 yes, something is wrong with test projects. Nir's screenshot shows a project-like Properties UI, mine shows a different UI: Screen Shot 2022-10-28 at 13 34 58 (also, Nir, you have some .classpath modified in your screenshot) Something gets messed up between gradle and eclipse project hierarchy. What could it be? Nir: I think I see errors appear in step 2, so something is definitely wrong. Looks like steps 3 and 4 are new steps. is it possible not to add these extra steps, or have eclipse files configured such that the extra steps are not necessary, as the case is with the current master branch? I've tried to follow what John proposed (with one exception - I did not clone the repo, used an existing repository). Run a command line gradle build, imported all projects as existing projects (General -> Existing Projects...). Got 3 errors and 30 warnings (first 3 entries are errors): Description Resource Type Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs 3DViewer Gradle Project Configuration Marker Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Ensemble8 Gradle Project Configuration Marker Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Modena Gradle Project Configuration Marker Project '3DLighting' has no explicit encoding set 3DLighting No explicit project encoding Project 'DragDrop' has no explicit encoding set DragDrop No explicit project encoding Project 'FX8-3DFeatures' has no explicit encoding set FX8-3DFeatures No explicit project encoding Project 'Hello' has no explicit encoding set Hello No explicit project encoding Project 'LayoutDemo' has no explicit encoding set LayoutDemo No explicit project encoding Project 'MandelbrotSet' has no explicit encoding set MandelbrotSet No explicit project encoding Project 'manualTests-controls' has no explicit encoding set manualTests-controls No explicit project encoding Project 'manualTests-desktop' has no explicit encoding set manualTests-desktop No explicit project encoding Project 'manualTests-dnd' has no explicit encoding set manualTests-dnd No explicit project encoding Project 'manualTests-events' has no explicit encoding set manualTests-events No explicit project encoding Project 'manualTests-graphics' has no explicit encoding set manualTests-graphics No explicit project encoding Project 'manualTests-media' has no explicit encoding set manualTests-media No explicit project encoding Project 'manualTests-printing' has no explicit encoding set manualTests-printing No explicit project encoding Project 'manualTests-swing' has no explicit encoding set manualTests-swing No explicit project encoding Project 'manualTests-swt' has no explicit encoding set manualTests-swt No explicit project encoding Project 'manualTests-text' has no explicit encoding set manualTests-text No explicit project encoding Project 'manualTests-UI' has no explicit encoding set manualTests-UI No explicit project encoding Project 'manualTests-web' has no explicit encoding set manualTests-web No explicit project encoding Project 'PickTest3D' has no explicit encoding set PickTest3D No explicit project encoding Project 'Robot' has no explicit encoding set Robot No explicit project encoding Project 'systemTests-test' has no explicit encoding set systemTests-test No explicit project encoding Project 'systemTests-testapp1' has no explicit encoding set systemTests-testapp1 No explicit project encoding Project 'systemTests-testapp2' has no explicit encoding set systemTests-testapp2 No explicit project encoding Project 'systemTests-testapp3' has no explicit encoding set systemTests-testapp3 No explicit project encoding Project 'systemTests-testapp4' has no explicit encoding set systemTests-testapp4 No explicit project encoding Project 'systemTests-testapp5' has no explicit encoding set systemTests-testapp5 No explicit project encoding Project 'systemTests-testapp6' has no explicit encoding set systemTests-testapp6 No explicit project encoding Project 'systemTests-testapp7' has no explicit encoding set systemTests-testapp7 No explicit project encoding Project 'systemTests-testscriptapp1' has no explicit encoding set systemTests-testscriptapp1 No explicit project encoding Project 'systemTests-testscriptapp2' has no explicit encoding set systemTests-testscriptapp2 No explicit project encoding I wonder if bin/ is created by the eclipse. What happens when you do Project -> Clean? John, I generally support the idea of importing eclipse projects rather than importing as gradle and then reverting the changes. A straightforward import seems better, it imports all nested projects, and we all seem to use gradle on command line anyway. And the last thing - I would recommend against checking in launch configurations as it might contain user- or platform- specific constructs. Your suggestion to override dependencies with -Djava.library.path="../../../modules/javafx.graphics/build/module-lib" --add-modules=javafx.controls does work. (and yes, we should check in missing `org.eclipse.core.resources.prefs`, but I don't know what to do with "missing Gradle project configuration file") After everything works, we'll need to update the wiki https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK (perhaps as a separate effort, and perhaps also extract Eclipse sections into a separate page) .project line 3: > 1: > 2: > 3: jfx this may cause issues with internal setup at oracle ------------- Changes requested by angorya (Author). PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: <9PHyT88IehhgKAqlqoYEv2Wr5VH4XO_HKeRmAZ7CjNc=.f420ddbd-f14f-4b51-a0ca-303317b19ae8@github.com> On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 @andy-goryachev-oracle can you also take a look at this? ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:30 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <9PHyT88IehhgKAqlqoYEv2Wr5VH4XO_HKeRmAZ7CjNc=.f420ddbd-f14f-4b51-a0ca-303317b19ae8@github.com> References: <9PHyT88IehhgKAqlqoYEv2Wr5VH4XO_HKeRmAZ7CjNc=.f420ddbd-f14f-4b51-a0ca-303317b19ae8@github.com> Message-ID: On Sat, 22 Oct 2022 12:03:46 GMT, Kevin Rushforth wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > @andy-goryachev-oracle can you also take a look at this? @kevinrushforth I'm getting errors on a gradle build. Is it just me or do we need to change some configuration? The supplied phased action failed with an exception. Dependency verification failed for configuration 'classpath' 14 artifacts failed verification: - annotations-13.0.jar (org.jetbrains:annotations:13.0) from repository Gradle Central Plugin Repository - gradle-versions-plugin-0.43.0.jar (com.github.ben-manes:gradle-versions-plugin:0.43.0) from repository Gradle Central Plugin Repository - kotlin-reflect-1.6.21.jar (org.jetbrains.kotlin:kotlin-reflect:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-common-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-common:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-jdk7-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-jdk8-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.21) from repository Gradle Central Plugin Repository - moshi-1.12.0.jar (com.squareup.moshi:moshi:1.12.0) from repository Gradle Central Plugin Repository - moshi-kotlin-1.12.0.jar (com.squareup.moshi:moshi-kotlin:1.12.0) from repository Gradle Central Plugin Repository - mxparser-1.2.2.jar (io.github.x-stream:mxparser:1.2.2) from repository Gradle Central Plugin Repository - okhttp-4.9.3.jar (com.squareup.okhttp3:okhttp:4.9.3) from repository Gradle Central Plugin Repository - okio-jvm-2.10.0.jar (com.squareup.okio:okio:2.10.0) from repository Gradle Central Plugin Repository - xmlpull-1.1.3.1.jar (xmlpull:xmlpull:1.1.3.1) from repository Gradle Central Plugin Repository - xstream-1.4.19.jar (com.thoughtworks.xstream:xstream:1.4.19) from repository Gradle Central Plugin Repository If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at https://docs.gradle.org/7.3/userguide/dependency_verification.html#sec:troubleshooting-verification Open this report for more details: file:///C:/Users/Nir/git/jfx/build/reports/dependency-verification/at-1666481211728/dependency-verification-report.html Stack trace: org.gradle.tooling.BuildActionFailureException: The supplied phased action failed with an exception. at org.gradle.tooling.internal.consumer.connection.PhasedActionAwareConsumerConnection.run(PhasedActionAwareConsumerConnection.java:58) at org.gradle.tooling.internal.consumer.connection.ParameterValidatingConsumerConnection.run(ParameterValidatingConsumerConnection.java:62) at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter$1.run(DefaultPhasedBuildActionExecuter.java:78) at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter$1.run(DefaultPhasedBuildActionExecuter.java:70) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:143) at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45) at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61) at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38) at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:67) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46) at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter.run(DefaultPhasedBuildActionExecuter.java:63) at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter.run(DefaultPhasedBuildActionExecuter.java:31) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runPhasedModelQuery(EclipseModelUtils.java:111) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryCompositeModelWithRuntimInfo(EclipseModelUtils.java:86) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryModels(EclipseModelUtils.java:60) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$4(DefaultModelProvider.java:75) at org.eclipse.buildship.core.internal.DefaultGradleBuild$GradleConnectionOperation.runInToolingApi(DefaultGradleBuild.java:329) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild.withConnection(DefaultGradleBuild.java:122) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$5(DefaultModelProvider.java:75) at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4853) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045) at com.google.common.cache.LocalCache.get(LocalCache.java:3951) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4848) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.getFromCache(DefaultModelProvider.java:98) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.executeOperation(DefaultModelProvider.java:90) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.fetchEclipseProjectAndRunSyncTasks(DefaultModelProvider.java:72) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.runInToolingApi(DefaultGradleBuild.java:226) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.run(DefaultGradleBuild.java:192) at org.eclipse.buildship.core.internal.DefaultGradleBuild.synchronize(DefaultGradleBuild.java:100) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:64) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:30) at org.eclipse.buildship.core.internal.operation.ToolingApiJob$1.runInToolingApi(ToolingApiJob.java:54) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.operation.ToolingApiJob.run(ToolingApiJob.java:65) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: org.gradle.api.InvalidUserDataException: Dependency verification failed for configuration 'classpath' 14 artifacts failed verification: - annotations-13.0.jar (org.jetbrains:annotations:13.0) from repository Gradle Central Plugin Repository - gradle-versions-plugin-0.43.0.jar (com.github.ben-manes:gradle-versions-plugin:0.43.0) from repository Gradle Central Plugin Repository - kotlin-reflect-1.6.21.jar (org.jetbrains.kotlin:kotlin-reflect:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-common-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-common:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-jdk7-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.21) from repository Gradle Central Plugin Repository - kotlin-stdlib-jdk8-1.6.21.jar (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.21) from repository Gradle Central Plugin Repository - moshi-1.12.0.jar (com.squareup.moshi:moshi:1.12.0) from repository Gradle Central Plugin Repository - moshi-kotlin-1.12.0.jar (com.squareup.moshi:moshi-kotlin:1.12.0) from repository Gradle Central Plugin Repository - mxparser-1.2.2.jar (io.github.x-stream:mxparser:1.2.2) from repository Gradle Central Plugin Repository - okhttp-4.9.3.jar (com.squareup.okhttp3:okhttp:4.9.3) from repository Gradle Central Plugin Repository - okio-jvm-2.10.0.jar (com.squareup.okio:okio:2.10.0) from repository Gradle Central Plugin Repository - xmlpull-1.1.3.1.jar (xmlpull:xmlpull:1.1.3.1) from repository Gradle Central Plugin Repository - xstream-1.4.19.jar (com.thoughtworks.xstream:xstream:1.4.19) from repository Gradle Central Plugin Repository If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at https://docs.gradle.org/7.3/userguide/dependency_verification.html#sec:troubleshooting-verification Open this report for more details: file:///C:/Users/Nir/git/jfx/build/reports/dependency-verification/at-1666481211728/dependency-verification-report.html at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.verification.ChecksumAndSignatureVerificationOverride.artifactsAccessed(ChecksumAndSignatureVerificationOverride.java:182) at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.StartParameterResolutionOverride$DisablingVerificationOverride.artifactsAccessed(StartParameterResolutionOverride.java:280) at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$2.run(DefaultLenientConfiguration.java:239) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68) at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.visitArtifactsWithBuildOperation(DefaultLenientConfiguration.java:235) at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.access$200(DefaultLenientConfiguration.java:73) at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$1.visitArtifacts(DefaultLenientConfiguration.java:138) at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitContents(DefaultConfiguration.java:1393) at org.gradle.api.internal.file.AbstractFileCollection.getFiles(AbstractFileCollection.java:130) at org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollection.java:176) at org.gradle.internal.classpath.DefaultClassPath.of(DefaultClassPath.java:52) at org.gradle.api.internal.initialization.DefaultScriptClassPathResolver.resolveClassPath(DefaultScriptClassPathResolver.java:51) at org.gradle.api.internal.initialization.DefaultScriptHandler.getNonInstrumentedScriptClassPath(DefaultScriptHandler.java:95) at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.defineScriptHandlerClassScope(DefaultPluginRequestApplicator.java:160) at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.applyPlugins(DefaultPluginRequestApplicator.java:80) at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:117) at org.gradle.configuration.BuildOperationScriptPlugin$1.run(BuildOperationScriptPlugin.java:65) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68) at org.gradle.configuration.BuildOperationScriptPlugin.lambda$apply$0(BuildOperationScriptPlugin.java:62) at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.apply(DefaultUserCodeApplicationContext.java:44) at org.gradle.configuration.BuildOperationScriptPlugin.apply(BuildOperationScriptPlugin.java:62) at org.gradle.configuration.DefaultInitScriptProcessor.process(DefaultInitScriptProcessor.java:50) at org.gradle.initialization.InitScriptHandler$1.run(InitScriptHandler.java:56) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68) at org.gradle.initialization.InitScriptHandler.executeScripts(InitScriptHandler.java:51) at org.gradle.initialization.InitScriptHandlingSettingsLoader.findAndLoadSettings(InitScriptHandlingSettingsLoader.java:33) at org.gradle.initialization.GradlePropertiesHandlingSettingsLoader.findAndLoadSettings(GradlePropertiesHandlingSettingsLoader.java:39) at org.gradle.initialization.DefaultSettingsPreparer.prepareSettings(DefaultSettingsPreparer.java:31) at org.gradle.initialization.BuildOperationFiringSettingsPreparer$LoadBuild.doLoadBuild(BuildOperationFiringSettingsPreparer.java:62) at org.gradle.initialization.BuildOperationFiringSettingsPreparer$LoadBuild.run(BuildOperationFiringSettingsPreparer.java:57) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29) at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47) at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68) at org.gradle.initialization.BuildOperationFiringSettingsPreparer.prepareSettings(BuildOperationFiringSettingsPreparer.java:45) at org.gradle.initialization.VintageBuildModelController.lambda$prepareSettings$0(VintageBuildModelController.java:89) at org.gradle.internal.build.StateTransitionController.lambda$doTransition$1(StateTransitionController.java:222) at org.gradle.internal.build.StateTransitionController.doTransition(StateTransitionController.java:243) at org.gradle.internal.build.StateTransitionController.doTransition(StateTransitionController.java:221) at org.gradle.internal.build.StateTransitionController.transitionIfNotPreviously(StateTransitionController.java:190) at org.gradle.initialization.VintageBuildModelController.prepareSettings(VintageBuildModelController.java:89) at org.gradle.initialization.VintageBuildModelController.doBuildStages(VintageBuildModelController.java:73) at org.gradle.initialization.VintageBuildModelController.getConfiguredModel(VintageBuildModelController.java:58) at org.gradle.internal.build.StateTransitionController.notInStateIgnoreOtherThreads(StateTransitionController.java:89) at org.gradle.internal.build.DefaultBuildLifecycleController.getConfiguredBuild(DefaultBuildLifecycleController.java:98) at org.gradle.internal.build.AbstractBuildState.ensureProjectsConfigured(AbstractBuildState.java:65) at org.gradle.internal.buildtree.DefaultBuildTreeModelCreator$DefaultBuildToolingModelController.locateBuilderForTarget(DefaultBuildTreeModelCreator.java:90) at org.gradle.internal.buildtree.DefaultBuildTreeModelCreator$DefaultBuildToolingModelController.locateBuilderForDefaultTarget(DefaultBuildTreeModelCreator.java:82) at org.gradle.tooling.internal.provider.runner.DefaultBuildController$DefaultTargetModel.locate(DefaultBuildController.java:239) at org.gradle.tooling.internal.provider.runner.DefaultBuildController.getToolingModelBuilder(DefaultBuildController.java:184) at org.gradle.tooling.internal.provider.runner.DefaultBuildController.getModel(DefaultBuildController.java:98) at org.gradle.tooling.internal.consumer.connection.ParameterAwareBuildControllerAdapter.getModel(ParameterAwareBuildControllerAdapter.java:39) at org.gradle.tooling.internal.consumer.connection.UnparameterizedBuildController.getModel(UnparameterizedBuildController.java:113) at org.gradle.tooling.internal.consumer.connection.NestedActionAwareBuildControllerAdapter.getModel(NestedActionAwareBuildControllerAdapter.java:31) at org.gradle.tooling.internal.consumer.connection.UnparameterizedBuildController.getModel(UnparameterizedBuildController.java:76) at org.gradle.tooling.internal.consumer.connection.NestedActionAwareBuildControllerAdapter.getModel(NestedActionAwareBuildControllerAdapter.java:31) at org.gradle.tooling.internal.consumer.connection.UnparameterizedBuildController.getModel(UnparameterizedBuildController.java:61) at org.gradle.tooling.internal.consumer.connection.NestedActionAwareBuildControllerAdapter.getModel(NestedActionAwareBuildControllerAdapter.java:31) at org.eclipse.buildship.core.internal.workspace.TellGradleToRunSynchronizationTasks.execute(TellGradleToRunSynchronizationTasks.java:22) at org.eclipse.buildship.core.internal.workspace.TellGradleToRunSynchronizationTasks.execute(TellGradleToRunSynchronizationTasks.java:18) at org.eclipse.buildship.core.internal.workspace.BuildActionSequence.execute(BuildActionSequence.java:31) at org.eclipse.buildship.core.internal.workspace.BuildActionSequence.execute(BuildActionSequence.java:18) at org.gradle.tooling.internal.consumer.connection.InternalBuildActionAdapter.execute(InternalBuildActionAdapter.java:64) at org.gradle.tooling.internal.provider.runner.AbstractClientProvidedBuildActionRunner$ActionAdapter.runAction(AbstractClientProvidedBuildActionRunner.java:131) at org.gradle.tooling.internal.provider.runner.AbstractClientProvidedBuildActionRunner$ActionAdapter.beforeTasks(AbstractClientProvidedBuildActionRunner.java:99) at org.gradle.internal.buildtree.DefaultBuildTreeModelCreator.beforeTasks(DefaultBuildTreeModelCreator.java:57) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.lambda$fromBuildModel$1(DefaultBuildTreeLifecycleController.java:72) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.lambda$runBuild$4(DefaultBuildTreeLifecycleController.java:103) at org.gradle.internal.build.StateTransitionController.lambda$transition$0(StateTransitionController.java:145) at org.gradle.internal.build.StateTransitionController.doTransition(StateTransitionController.java:243) at org.gradle.internal.build.StateTransitionController.transition(StateTransitionController.java:145) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.runBuild(DefaultBuildTreeLifecycleController.java:100) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.fromBuildModel(DefaultBuildTreeLifecycleController.java:71) at org.gradle.tooling.internal.provider.runner.AbstractClientProvidedBuildActionRunner.runClientAction(AbstractClientProvidedBuildActionRunner.java:43) at org.gradle.tooling.internal.provider.runner.ClientProvidedPhasedActionRunner.run(ClientProvidedPhasedActionRunner.java:53) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) at org.gradle.internal.buildtree.ProblemReportingBuildActionRunner.run(ProblemReportingBuildActionRunner.java:49) at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:69) at org.gradle.tooling.internal.provider.FileSystemWatchingBuildActionRunner.run(FileSystemWatchingBuildActionRunner.java:114) at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:41) at org.gradle.launcher.exec.RootBuildLifecycleBuildActionExecutor.lambda$execute$0(RootBuildLifecycleBuildActionExecutor.java:40) at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:155) at org.gradle.launcher.exec.RootBuildLifecycleBuildActionExecutor.execute(RootBuildLifecycleBuildActionExecutor.java:40) at org.gradle.internal.buildtree.DefaultBuildTreeContext.execute(DefaultBuildTreeContext.java:40) at org.gradle.launcher.exec.BuildTreeLifecycleBuildActionExecutor.lambda$execute$0(BuildTreeLifecycleBuildActionExecutor.java:65) at org.gradle.internal.buildtree.BuildTreeState.run(BuildTreeState.java:53) at org.gradle.launcher.exec.BuildTreeLifecycleBuildActionExecutor.execute(BuildTreeLifecycleBuildActionExecutor.java:65) at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor$3.call(RunAsBuildOperationBuildActionExecutor.java:61) at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor$3.call(RunAsBuildOperationBuildActionExecutor.java:57) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66) at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157) at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59) at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53) at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73) at org.gradle.launcher.exec.RunAsBuildOperationBuildActionExecutor.execute(RunAsBuildOperationBuildActionExecutor.java:57) at org.gradle.launcher.exec.RunAsWorkerThreadBuildActionExecutor.lambda$execute$0(RunAsWorkerThreadBuildActionExecutor.java:38) at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:211) at org.gradle.launcher.exec.RunAsWorkerThreadBuildActionExecutor.execute(RunAsWorkerThreadBuildActionExecutor.java:38) at org.gradle.tooling.internal.provider.ContinuousBuildActionExecutor.execute(ContinuousBuildActionExecutor.java:103) at org.gradle.tooling.internal.provider.SubscribableBuildActionExecutor.execute(SubscribableBuildActionExecutor.java:64) at org.gradle.internal.session.DefaultBuildSessionContext.execute(DefaultBuildSessionContext.java:46) at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:100) at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:88) at org.gradle.internal.session.BuildSessionState.run(BuildSessionState.java:69) at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:62) at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:41) at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36) at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25) at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:63) at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:31) at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:58) at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:42) at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:47) at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:31) at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:65) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78) at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75) at org.gradle.util.internal.Swapper.swap(Swapper.java:38) at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:84) at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37) at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104) at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52) at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61) ------------- PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 6 00:24:30 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 I took a look at the tests folder. There are several nested testapps in this folder. These give compile errors because they're not using the correct source root folder (they use `/src/testapp3/java` with a `module-info.java` nested in `mymod`). This is incorrect as module info needs to live in the root. Fixing the source folder to `src/testapp3/java/mymod` is not allowed in a single project as there will be multiple `module-info.java`'s at the same level. The solution seems to be that each module-info needs to have its own Eclipse project as Eclipse project == module. I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around. It looks like this for me: ![image](https://user-images.githubusercontent.com/995917/197948897-463c267c-ed26-4be9-82a6-009e522e0ac6.png) The error that is still visible is missing SWT libraries. I do this with import eclipse projects, and letting it search for nesting projects. Unfortunately, it finds some project files in `bin` folders which are copied there by something I haven't discovered yet. You need to unselect those. I've rebased this on master. For some reason I mistakenly based this on some old version of master. I do notice the same kind of problems Andy experienced. Eclipse can give many errors when switching branches. Closing all projects and reopening them solved all the errors for me though. I've just done the following: 1) Deleted all projects in Eclipse (without contents). Eclipse was empty after this. 2) Do a Gradle import, with all default settings. Now there are about two dozen errors all related to projects that can't be build. 3) Pressed refresh on EGit, and reverted all project files except the `tests/.project` which is not in the repository. I now have exactly 2 errors, both related to the file `DoubleShortcutProcessingTest.java`. I suspect I missed something on the classpath for that one. 4) Also deleted the `tests/.project` and did a rebuild of all projects. No changes, still 2 errors. Now, something is wrong I think. The test projects are not showing up as Eclipse projects. Nested projects seem to have been ignored (perhaps this is an option in Gradle import?). Package explorer only shows the standard 11 gradle projects. So: 5) I import nested Eclipse projects, carefully unselecting the top level project (jfx) and all the projects with `bin` in their name. I now have all projects back in package explorer, and still only the same 2 errors. 6) I deleted the two errors from the problems view about `DoubleShortcutProcessingTest.java`, as it seems they were related to the main project `systemTests` instead of `systemTests-test`. Refreshing all projects, and they did not come back. Probably something that went wrong during the gradle import, and it was just a random unlucky file that Eclipse may have attempt to compile first. Okay, so, I'm unsure why or how, but when Andy imports using the Gradle import wizard, a gradle build starts in the background. This doesn't happen on my system. The gradle build shouldn't be needed during the import. What I'd like to know what the end game is were aiming for here. Is it the use of the Gradle import wizard, or is it the import of (nested) Eclipse projects? For the latter, Eclipse will still see the projects as gradle projects as the project files will include the gradle nature. Also for the latter, I think that's the only one we're going to be able to get it working perfectly without error every time. What I'd like to see is the following: 1) Ensure we have a process that does NOT create any Eclipse project files -- they're in the repository already, they're correct, we don't want them overwritten. This may mean removing something from the build script (some kind of Eclipse helper plugin is there I suspect). 2) Prevent Eclipse project files being copied to `bin` folders. Something is doing this, and I'd like to tweak the build so this no longer happens as it causes duplicate projects to be found resulting in errors and confusion. 3) Use import as Eclipse projects, not the Gradle wizard; this is because the wizard creates the wrong files. The end situation is the same (after reverting all those files), and Gradle is still usable as the Gradle nature is present. The process to set up JavaFX for Eclipse would then become: 1) Git clone repository 2) Do a full build 3) Open Eclipse, import Eclipse projects (do not use gradle import) Thoughts? I may be misunderstanding something fundamental about Gradle and Buildship. So the situation is this: 1. JavaFX provides correct project/classpath files in its repository for Eclipse 2. Buildship import creates project/classpath files based on `build.gradle` for situations where you don't have Eclipse project files; that's AFAIK what import does: analyze `build.gradle` and create suitable Eclipse project files Why would you do 2 when you already have 1? It's impossible to make 2 deliver correct results due to how complicated the JFX project structure is, the many options Gradle offers and the limited ways this can be represented in Eclipse. In fact, we revert all those changes (literally all of them) to still end up in situation 1 -- it's literally as if 2 never happened (no other changes were made on the filesystem that could affect the Eclipse setup in any way). Because the included project files contain the Gradle nature, all the other functionality of the Buildship plugin should still work as normal, including running a build. So I may be missing something, but I see no need to run a Gradle import as it is an unnecessary, detrimental step that requires all changes it made to be reverted to go back to the situation you were already in before running it... I haven't been able to reproduce the `bin` problem in any way after I manually deleted all of them. I suspect it was a local file on my end (probably a `.classpath` file in the top level folder `apps` or `test`) that was causing this. A launch file example looks like this, and contains no local stuff (but I'm fine with excluding them): I implemented option 2 from Nir Lisker's last comment ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: <9PHyT88IehhgKAqlqoYEv2Wr5VH4XO_HKeRmAZ7CjNc=.f420ddbd-f14f-4b51-a0ca-303317b19ae8@github.com> Message-ID: On Sun, 23 Oct 2022 00:33:22 GMT, Nir Lisker wrote: > I'm getting errors on a gradle build. Is it just me or do we need to change some configuration? I don't see any errors, and we aren't seeing any on GitHub actions runs, so it is likely something in your configuration. What version of gradle are you running? ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 13:25:37 GMT, Nir Lisker wrote: > I managed to solve is using `gradlew --write-verification-metadata sha256 help`. The manual says it should be run after updating a dependency, so I wonder why I'm the only one with this problem. That should not be necessary, since no dependencies have been updated recently. I suspect something else is at work here. You might want to try from a clean repo (after reverting the changes to `verification-metadata.xml`). ------------- PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:30 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> Message-ID: On Tue, 25 Oct 2022 16:43:48 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around. @hjohn I've got 59,937 errors after switching to your branch (all errors in apps and systemTests). Once thing I noticed right away is that it hasn't been synched up with 'master' recently. It is also possible that the project needs to be removed and added back to eclipse workspace. Here is the screenshot - are the top level projects the same as yours? Screen Shot 2022-10-25 at 16 43 07 ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> Message-ID: On Wed, 26 Oct 2022 08:10:15 GMT, John Hendrikx wrote: > I've rebased this on master. For some reason I mistakenly based this on some old version of master. As a reminder, please use `git merge master` rather than `git rebase master` (the latter of which requires a force push and makes incremental reviews harder), especially once this goes `rfr`. Since it is still a Draft PR, a rebase is OK, but a merge is usually preferred. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:31 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> Message-ID: <9ChlvX2PW9EKG8uDO_jlm7RKT6QUnTBOJxegLVWVhJk=.1911f8b4-959a-4ebc-a2e3-0d9f204fd04d@github.com> On Wed, 26 Oct 2022 11:16:19 GMT, Kevin Rushforth wrote: >> I've rebased this on master. For some reason I mistakenly based this on some old version of master. >> >> I do notice the same kind of problems Andy experienced. Eclipse can give many errors when switching branches. Closing all projects and reopening them solved all the errors for me though. > >> I've rebased this on master. For some reason I mistakenly based this on some old version of master. > > As a reminder, please use `git merge master` rather than `git rebase master` (the latter of which requires a force push and makes incremental reviews harder), especially once this goes `rfr`. Since it is still a Draft PR, a rebase is OK, but a merge is usually preferred. @kevinrushforth Maybe you can shed some light on these points: * John's comment above: > I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around. * John and I found out that trying to run the Gradle projects under apps/samples with Gradle (the `run` taks) fails with an error message saying that these projects are not part of the root `settings.gradle` file. This is true, except for the modules, the other listed projects are `apps` and `systemTests`, neither of which are actual Gradle projects. Is this correct behavior? Why are they Gradle projects? * I find it odd that `systemTests` is a subfolder of `tests`, yet it's defined as a Gradle project while `tests` isn't. What is the reason? ------------- PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <9ChlvX2PW9EKG8uDO_jlm7RKT6QUnTBOJxegLVWVhJk=.1911f8b4-959a-4ebc-a2e3-0d9f204fd04d@github.com> References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> <9ChlvX2PW9EKG8uDO_jlm7RKT6QUnTBOJxegLVWVhJk=.1911f8b4-959a-4ebc-a2e3-0d9f204fd04d@github.com> Message-ID: On Wed, 26 Oct 2022 17:00:03 GMT, Nir Lisker wrote: >>> I've rebased this on master. For some reason I mistakenly based this on some old version of master. >> >> As a reminder, please use `git merge master` rather than `git rebase master` (the latter of which requires a force push and makes incremental reviews harder), especially once this goes `rfr`. Since it is still a Draft PR, a rebase is OK, but a merge is usually preferred. > > @kevinrushforth Maybe you can shed some light on these points: > > * John's comment above: > > I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around. > > * John and I found out that trying to run the Gradle projects under apps/samples with Gradle (the `run` taks) fails with an error message saying that these projects are not part of the root `settings.gradle` file. This is true, except for the modules, the other listed projects are `apps` and `systemTests`, neither of which are actual Gradle projects. Is this correct behavior? Why are they Gradle projects? > > * I find it odd that `systemTests` is a subfolder of `tests`, yet it's defined as a Gradle project while `tests` isn't. What is the reason? @nlisker : regarding the project name 'rt' and the directory name 'jfx' created by git clone - there is a historical reason why the directory name should in fact be 'rt' and not 'jfx', @kevinrushforth could you please explain? I know the likelihood of any changes to the git project configuration is zero, but perhaps we need to have some explanation of the discrepancy in the name. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:31 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 16:48:34 GMT, Andy Goryachev wrote: > One difference I see is that the official process to import the project, according to https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK , is to use `Import as Gradle Project` rather than import as existing project. After you clone the repository for the first time, you have to let Gradle build all sorts of artifacts, and you need to do it once. When you import as a Gradle project, it does it for you. After that you can reimport whichever way you like. You can also import for the first time as Java projects, but Eclipse will fail to build them because you still need to run the Gradle task externally. When we finish updating the Eclipse files here, I intend to rewrite that section, noting the differences between importing as Gradle and Java projects, and detailing the project structures. > regarding the project name 'rt' and the directory name 'jfx' created by git clone - there is a historical reason why the directory name should in fact be 'rt' and not 'jfx', @kevinrushforth could you please explain? > I know the likelihood of any changes to the git project configuration is zero, but perhaps we need to have some explanation of the discrepancy in the name. The project name change in Eclipse is rather superficial (as I suspected, and confirmed today) - it only changes the display names in various places, but if that name and the folder name are not the same, there's some duplication confusion attached to it where there will be 2 projects displayed. Even then, one will function correctly and the other will be a stub, so no real harm done. Even if the `rt` name is used inside the Gradle build file, it doesn't interact with the Eclipse files. Apparently, when Buildship imports fresh Gradle projects, it derives the name from the folder name (this is what I tested, I didn't check the specs, if there are any on this). So, changing the name should be safe. The reason for the current discrepancy, I gather, is that the current project file in the repo was checked in when the project was on Mercurial with a different folder name, and now that the folder name has changed in GitHub we get this "conflict". > (also, Nir, you have some .classpath modified in your screenshot) That's the /manual swt project that requires an external jar as noted in one of the comments above. > Now, something is wrong I think. The test projects are not showing up as Eclipse projects. Nested projects seem to have been ignored (perhaps this is an option in Gradle import?). Importing through Gradle only imports projects that are configured in the root Gradle script (the modules, `systemTests`, and `apps`). To have the other projects, like tests/manual and /performance, you will need to import nested projects as Java projects. Maybe some of them should be hooked up to the root Gradle script to automate this for first-time users, but that's another issue for another time. > I think I see errors appear in step 2, so something is definitely wrong. If they are in the modules, you will need to figure out the difference between before and after this patch, because there shouldn't be any. > Looks like steps 3 and 4 are new steps. is it possible not to add these extra steps, or have eclipse files configured such that the extra steps are not necessary, as the case is with the current master branch? They are not needed if you don't need the non-Gradle projects. The current master branch also get errors when you import as Gradle, you need to revert its changes anyway. Also, step 4 might not be needed once John updates the PR to remove the project files from those. ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> Message-ID: <0S0_RxKfgR-h5Wmcp8JrGeF0RCoDU_DgdCtW4gQf8Gg=.19d3981d-b7b4-4ed3-b633-906f7fa4786f@github.com> On Wed, 26 Oct 2022 11:16:19 GMT, Kevin Rushforth wrote: >> I've rebased this on master. For some reason I mistakenly based this on some old version of master. >> >> I do notice the same kind of problems Andy experienced. Eclipse can give many errors when switching branches. Closing all projects and reopening them solved all the errors for me though. > >> I've rebased this on master. For some reason I mistakenly based this on some old version of master. > > As a reminder, please use `git merge master` rather than `git rebase master` (the latter of which requires a force push and makes incremental reviews harder), especially once this goes `rfr`. Since it is still a Draft PR, a rebase is OK, but a merge is usually preferred. > @kevinrushforth Maybe you can shed some light on these points: > > * John's comment above: > > I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around. The lack of a `main` method in `DNDWebViewTest` was likely an oversight. It's optional for classes that extend `java.application.Application` -- they can be launched without a `main` method, but it confuses IDEs (not just Eclipse) so it's good to add a main method (although not as part of this PR). The `swt-debug.jar` library is copied to build/libs as part of `gradle sdk`, so it's at least available (maybe just needs to be pointed to)? > * John and I found out that trying to run the Gradle projects under apps/samples with Gradle (the `run` taks) fails with an error message saying that these projects are not part of the root `settings.gradle` file. This is true, except for the modules, the other listed projects are `apps` and `systemTests`, neither of which are actual Gradle projects. Is this correct behavior? Why are they Gradle projects? `apps` is a special case. It's listed in `settings.gradle` as a project, but is built entirely using `ant`. `systemTests` is a gradle sub-project just like `javafx.base`, etc. Everything is built using gradle, so I don't know what you mean. > * I find it odd that `systemTests` is a subfolder of `tests`, yet it's defined as a Gradle project while `tests` isn't. What is the reason? the `tests` dir is just there as a way to hold a number of groups of tests. The only one that gradle knows about is systemTests. tests isn't really a project (or at least I don't think it should be) on its own. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:31 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <0S0_RxKfgR-h5Wmcp8JrGeF0RCoDU_DgdCtW4gQf8Gg=.19d3981d-b7b4-4ed3-b633-906f7fa4786f@github.com> References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> <0S0_RxKfgR-h5Wmcp8JrGeF0RCoDU_DgdCtW4gQf8Gg=.19d3981d-b7b4-4ed3-b633-906f7fa4786f@github.com> Message-ID: On Wed, 26 Oct 2022 23:34:39 GMT, Kevin Rushforth wrote: > The swt-debug.jar library is copied to build/libs as part of gradle sdk, so it's at least available (maybe just needs to be pointed to)? I previously added it to the project's classpath and the error wasn't being resolved so I assumed it wasn't the correct fix. Now I tried adding it to the module path and the error was resolved. @hjohn Add to the .classpath file. > apps is a special case. It's listed in settings.gradle as a project, but is built entirely using ant. > systemTests is a gradle sub-project just like javafx.base, etc. Everything is built using gradle, so I don't know what you mean. I didn't explain this well. There are 3 projects under apps/samples that have a `build.gradle` file with the `application` plugin: Ensemble8, 3DViewer and Modena. This implies that these can be run with Gradle. However, doing so causes the error I posted. The error message is correct in that these 3 projects are not defined in `settings.gradle`, but then why are they Gradle projects? ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:31 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: <_t_DgPPa7Kh2X-5VHMa0OBWQVq65IEced2-tsOAzqKc=.22b4c6ce-958f-4e3d-a1f9-447b16c29519@github.com> <0S0_RxKfgR-h5Wmcp8JrGeF0RCoDU_DgdCtW4gQf8Gg=.19d3981d-b7b4-4ed3-b633-906f7fa4786f@github.com> Message-ID: On Thu, 27 Oct 2022 00:11:48 GMT, Nir Lisker wrote: > I didn't explain this well. There are 3 projects under apps/samples that have a `build.gradle` file with the `application` plugin: Ensemble8, 3DViewer and Modena. This implies that these can be run with Gradle. However, doing so causes the error I posted. The error message is correct in that these 3 projects are not defined in `settings.gradle`, but then why are they Gradle projects? I had forgotten about those. They aren't used at all in our build and should either be deleted or fixed up. ------------- PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 6 00:24:32 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: <17gJfDLtAMj8ad-1Tc84-W0j2YPMVqdiZ8i5f_47gew=.d203dba4-e4f7-49db-8a98-50141fac01b4@github.com> On Fri, 28 Oct 2022 20:38:18 GMT, Andy Goryachev wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > yes, something is wrong with test projects. > Nir's screenshot shows a project-like Properties UI, mine shows a different UI: > > Screen Shot 2022-10-28 at 13 34 58 > > > (also, Nir, you have some .classpath modified in your screenshot) > > Something gets messed up between gradle and eclipse project hierarchy. What could it be? @andy-goryachev-oracle I think your `systemTests` project is probably incorrect. Under builders it should only have `Gradle Project Builder` and nothing else. It looks like it may have the Java nature or a Java source folder configured somehow. Can you give us the contents of it's `.project` file and the files in `.settings` ? It shouldn't have a `.classpath` file, but if it does, also that one. > I've tried to follow what John proposed (with one exception - I did not clone the repo, used an existing repository). Run a command line gradle build, imported all projects as existing projects (General -> Existing Projects...). > > Got 3 errors and 30 warnings (first 3 entries are errors): > > > Description Resource Type > Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs 3DViewer Gradle Project Configuration Marker > Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Ensemble8 Gradle Project Configuration Marker > Missing Gradle project configuration file: .settings/org.eclipse.buildship.core.prefs Modena Gradle Project Configuration Marker > Project '3DLighting' has no explicit encoding set 3DLighting No explicit project encoding > Project 'DragDrop' has no explicit encoding set DragDrop No explicit project encoding > Project 'FX8-3DFeatures' has no explicit encoding set FX8-3DFeatures No explicit project encoding > Project 'Hello' has no explicit encoding set Hello No explicit project encoding > Project 'LayoutDemo' has no explicit encoding set LayoutDemo No explicit project encoding > Project 'MandelbrotSet' has no explicit encoding set MandelbrotSet No explicit project encoding > Project 'manualTests-controls' has no explicit encoding set manualTests-controls No explicit project encoding > Project 'manualTests-desktop' has no explicit encoding set manualTests-desktop No explicit project encoding > Project 'manualTests-dnd' has no explicit encoding set manualTests-dnd No explicit project encoding > Project 'manualTests-events' has no explicit encoding set manualTests-events No explicit project encoding > Project 'manualTests-graphics' has no explicit encoding set manualTests-graphics No explicit project encoding > Project 'manualTests-media' has no explicit encoding set manualTests-media No explicit project encoding > Project 'manualTests-printing' has no explicit encoding set manualTests-printing No explicit project encoding > Project 'manualTests-swing' has no explicit encoding set manualTests-swing No explicit project encoding > Project 'manualTests-swt' has no explicit encoding set manualTests-swt No explicit project encoding > Project 'manualTests-text' has no explicit encoding set manualTests-text No explicit project encoding > Project 'manualTests-UI' has no explicit encoding set manualTests-UI No explicit project encoding > Project 'manualTests-web' has no explicit encoding set manualTests-web No explicit project encoding > Project 'PickTest3D' has no explicit encoding set PickTest3D No explicit project encoding > Project 'Robot' has no explicit encoding set Robot No explicit project encoding > Project 'systemTests-test' has no explicit encoding set systemTests-test No explicit project encoding > Project 'systemTests-testapp1' has no explicit encoding set systemTests-testapp1 No explicit project encoding > Project 'systemTests-testapp2' has no explicit encoding set systemTests-testapp2 No explicit project encoding > Project 'systemTests-testapp3' has no explicit encoding set systemTests-testapp3 No explicit project encoding > Project 'systemTests-testapp4' has no explicit encoding set systemTests-testapp4 No explicit project encoding > Project 'systemTests-testapp5' has no explicit encoding set systemTests-testapp5 No explicit project encoding > Project 'systemTests-testapp6' has no explicit encoding set systemTests-testapp6 No explicit project encoding > Project 'systemTests-testapp7' has no explicit encoding set systemTests-testapp7 No explicit project encoding > Project 'systemTests-testscriptapp1' has no explicit encoding set systemTests-testscriptapp1 No explicit project encoding > Project 'systemTests-testscriptapp2' has no explicit encoding set systemTests-testscriptapp2 No explicit project encoding @andy-goryachev-oracle Thanks for trying this. The 3 errors you are seeing is because the build ship plugin has never generated its local preference file for those projects (I think this is because they're not actually correctly configured in Gradle). All other projects will have this file generated locally for working Gradle projects. I've copied these locally to make the error disappear. I think the solution here is to add these files to the repository (and remove the `.gitignore` for it). Then we also don't need to rely on the Buildship import to generate these the first time around (a completely clean check out shouldn't have them, and all projects would have this error AFAIK). As for the warnings, those are from missing `org.eclipse.core.resources.prefs` files. I suggest to add these to the repository as well (they are already there in many places, but not for the new projects I added, I didn't see the warning in between the 1000's of others). So, if all agreed the next step would be: 1) Remove `org.eclipse.buildship.core.prefs` ignore from `.gitignore` 2) Add these prefs files in `.settings` folder for all locations that have the Gradle nature 3) Add the missing `org.eclipse.core.resources.prefs` for all new projects 4) Still figure out what's copying to `bin`. I even see nested copies now after another build (`bin/bin`). 5) A few projects don't work correctly with Gradle (Ensemble8, 3DViewer and Modena), need to decide how to handle this, either: a) Fix their configuration in Gradle, or b) Remove the Gradle nature About point 5, these projects can already be run directly from Eclipse. To run `3DLighting`, just run the main class (`LightingsSample`) with a configuration that includes: -Djava.library.path="../../../modules/javafx.graphics/build/module-lib" --add-modules=javafx.controls I created launch files for these that could be committed so that Eclipse can run them without having to tweak their run configuration. ------------- PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: <17gJfDLtAMj8ad-1Tc84-W0j2YPMVqdiZ8i5f_47gew=.d203dba4-e4f7-49db-8a98-50141fac01b4@github.com> References: <17gJfDLtAMj8ad-1Tc84-W0j2YPMVqdiZ8i5f_47gew=.d203dba4-e4f7-49db-8a98-50141fac01b4@github.com> Message-ID: On Fri, 28 Oct 2022 20:42:39 GMT, John Hendrikx wrote: >> yes, something is wrong with test projects. >> Nir's screenshot shows a project-like Properties UI, mine shows a different UI: >> >> Screen Shot 2022-10-28 at 13 34 58 >> >> >> (also, Nir, you have some .classpath modified in your screenshot) >> >> Something gets messed up between gradle and eclipse project hierarchy. What could it be? > > @andy-goryachev-oracle I think your `systemTests` project is probably incorrect. Under builders it should only have `Gradle Project Builder` and nothing else. It looks like it may have the Java nature or a Java source folder configured somehow. Can you give us the contents of it's `.project` file and the files in `.settings` ? It shouldn't have a `.classpath` file, but if it does, also that one. @hjohn : how could be my systemTests/.project be incorrect if I am using your branch, commit 93c47400a34e2cace3041dc158f3d1f585e4270f and zero changes? anyway, here it is: systemTests org.eclipse.buildship.core.gradleprojectbuilder org.eclipse.buildship.core.gradleprojectnature ------------- PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:47:21 GMT, Nir Lisker wrote: > but that's another issue for another time. I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. @nlisker : could you repeat the documented steps and import John's branch (with zero modifications) as a new gradle project? I don't understand why your Properties UI for ystemTests/testscriptapp1 looks different than mine. What about your setup, John? ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:32 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:49:47 GMT, Andy Goryachev wrote: > > but that's another issue for another time. > > I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. But this patch just fixes the Eclipse setup. Changing the Gradle root script is something that should be done when considering the whole repository. If you just import as Gradle projects you will not have the non-Gradle projects anyway, so you won't get any errors on them because Eclipse only builds source folders. > I don't understand why your Properties UI for ystemTests/testscriptapp1 looks different than mine. Because yours appears to not be a project, hence no "Project build path" window. I can't see your whole tree, but if Eclipse generates errors on them then it is specified as a source folder somewhere. > could you repeat the documented steps and import John's branch (with zero modifications) as a new gradle project? After you delete all projects from the workspace (not from the disk), this will be the same as a new user (only a new user will not have the artifacts that Gradle generates on the first time): 1. Import as Gradle project the root project. The preview should show you that it will import the modules, apps, and systemTests. ![image](https://user-images.githubusercontent.com/37422899/198732741-a742a3aa-cfac-4d8d-b624-b332e8799464.png) Everything else will appear as regular folders because Gradle doesn't know about projects not configured in its script. 2. Revert all changes the Gradle import made to the repository. At this point the module projects, at the very least, should not have any errors on them. If they do, then there's something else that's wrong. 3. Import "Existing projects into workspace" and check the "search for nested projects" while specifying the root. Ignore all projects that appear under `bin` directories (the project file is sometimes copied into there for some reason). At this point all the projects should have no errors except for specifically the projects `apps` and `systemTests` that should not be projects at all (this PR should remove their Eclipse files). 4. Delete these 2 projects from the workspace **without deleting nested projects**. Effectively, it just removes their .project file. This is what it looks like now: ![image](https://user-images.githubusercontent.com/37422899/198734514-5295937b-8bed-432c-ba04-74c2f8c08e0e.png) ------------- PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 6 00:24:32 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 21:18:54 GMT, Nir Lisker wrote: >>> but that's another issue for another time. >> >> I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. > >> > but that's another issue for another time. >> >> I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. > > But this patch just fixes the Eclipse setup. Changing the Gradle root script is something that should be done when considering the whole repository. If you just import as Gradle projects you will not have the non-Gradle projects anyway, so you won't get any errors on them because Eclipse only builds source folders. > >> I don't understand why your Properties UI for ystemTests/testscriptapp1 looks different than mine. > > Because yours appears to not be a project, hence no "Project build path" window. I can't see your whole tree, but if Eclipse generates errors on them then it is specified as a source folder somewhere. > >> could you repeat the documented steps and import John's branch (with zero modifications) as a new gradle project? > > After you delete all projects from the workspace (not from the disk), this will be the same as a new user (only a new user will not have the artifacts that Gradle generates on the first time): > > 1. Import as Gradle project the root project. The preview should show you that it will import the modules, apps, and systemTests. > > ![image](https://user-images.githubusercontent.com/37422899/198732741-a742a3aa-cfac-4d8d-b624-b332e8799464.png) > > Everything else will appear as regular folders because Gradle doesn't know about projects not configured in its script. > > 2. Revert all changes the Gradle import made to the repository. At this point the module projects, at the very least, should not have any errors on them. If they do, then there's something else that's wrong. > 3. Import "Existing projects into workspace" and check the "search for nested projects" while specifying the root. Ignore all projects that appear under `bin` directories (the project file is sometimes copied into there for some reason). At this point all the projects should have no errors except for specifically the projects `apps` and `systemTests` that should not be projects at all (this PR should remove their Eclipse files). > 4. Delete these 2 projects from the workspace **without deleting nested projects**. Effectively, it just removes their .project file. This is what it looks like now: > > ![image](https://user-images.githubusercontent.com/37422899/198734514-5295937b-8bed-432c-ba04-74c2f8c08e0e.png) @nlisker What Eclipse version do you have? I have 4.22 and Andy has 4.25 ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:32 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:32 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: <_2Z_8sh0bbZxcKxBF7_EkGqgRB9I2v-o8LdW2SaOgRA=.69d9d8a5-129a-4d7a-9403-dcaedcdd220e@github.com> On Fri, 28 Oct 2022 21:18:54 GMT, Nir Lisker wrote: >>> but that's another issue for another time. >> >> I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. > >> > but that's another issue for another time. >> >> I respectfully disagree - the initial import (with all the documented extra steps) should result in a clean state - as it is currently with the master branch. > > But this patch just fixes the Eclipse setup. Changing the Gradle root script is something that should be done when considering the whole repository. If you just import as Gradle projects you will not have the non-Gradle projects anyway, so you won't get any errors on them because Eclipse only builds source folders. > >> I don't understand why your Properties UI for ystemTests/testscriptapp1 looks different than mine. > > Because yours appears to not be a project, hence no "Project build path" window. I can't see your whole tree, but if Eclipse generates errors on them then it is specified as a source folder somewhere. > >> could you repeat the documented steps and import John's branch (with zero modifications) as a new gradle project? > > After you delete all projects from the workspace (not from the disk), this will be the same as a new user (only a new user will not have the artifacts that Gradle generates on the first time): > > 1. Import as Gradle project the root project. The preview should show you that it will import the modules, apps, and systemTests. > > ![image](https://user-images.githubusercontent.com/37422899/198732741-a742a3aa-cfac-4d8d-b624-b332e8799464.png) > > Everything else will appear as regular folders because Gradle doesn't know about projects not configured in its script. > > 2. Revert all changes the Gradle import made to the repository. At this point the module projects, at the very least, should not have any errors on them. If they do, then there's something else that's wrong. > 3. Import "Existing projects into workspace" and check the "search for nested projects" while specifying the root. Ignore all projects that appear under `bin` directories (the project file is sometimes copied into there for some reason). At this point all the projects should have no errors except for specifically the projects `apps` and `systemTests` that should not be projects at all (this PR should remove their Eclipse files). > 4. Delete these 2 projects from the workspace **without deleting nested projects**. Effectively, it just removes their .project file. This is what it looks like now: > > ![image](https://user-images.githubusercontent.com/37422899/198734514-5295937b-8bed-432c-ba04-74c2f8c08e0e.png) > @nlisker What Eclipse version do you have? I have 4.22 and Andy has 4.25 4.25 with Buildship 3.1.6. ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:33 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 21:18:54 GMT, Nir Lisker wrote: > But this patch just fixes the Eclipse setup. Changing the Gradle root script is something that should be done when considering the whole repository. I agree with @nlisker, and don't want to see changes to the gradle scripts as part of what is otherwise an IDE-only change. ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:33 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 22:51:10 GMT, Andy Goryachev wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > .project line 3: > >> 1: >> 2: >> 3: jfx > > this may cause issues with internal setup at oracle We do still clone the repo into a directory named `rt` when doing a closed build, but I doubt this change will cause problems. Maybe Andy can check? As Nir mentioned, people can (and do) name the root directory whatever they want and it doesn't seem to matter to Eclipse other than it looks a little odd. I agree with the general point that it might be nice to match the default name, but it doesn't matter one way or the other to me. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:24:33 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:24:33 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 23:20:30 GMT, Kevin Rushforth wrote: >> .project line 3: >> >>> 1: >>> 2: >>> 3: jfx >> >> this may cause issues with internal setup at oracle > > We do still clone the repo into a directory named `rt` when doing a closed build, but I doubt this change will cause problems. Maybe Andy can check? As Nir mentioned, people can (and do) name the root directory whatever they want and it doesn't seem to matter to Eclipse other than it looks a little odd. I agree with the general point that it might be nice to match the default name, but it doesn't matter one way or the other to me. I don't see how a closed build will be affected by Eclipse files. ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Sun Nov 6 00:24:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sun, 6 Nov 2022 00:24:33 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 23:24:20 GMT, Nir Lisker wrote: >> We do still clone the repo into a directory named `rt` when doing a closed build, but I doubt this change will cause problems. Maybe Andy can check? As Nir mentioned, people can (and do) name the root directory whatever they want and it doesn't seem to matter to Eclipse other than it looks a little odd. I agree with the general point that it might be nice to match the default name, but it doesn't matter one way or the other to me. > > I don't see how a closed build will be affected by Eclipse files. Nor do I. The build doesn't care, and if a developer clones the repo into `rt` after the name is changed to `jfx` it will be no different than someone who clones the repo into, say, `javafx` or `jfx20` or ... ------------- PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Sun Nov 6 00:24:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sun, 6 Nov 2022 00:24:33 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 11:41:27 GMT, Kevin Rushforth wrote: >> I don't see how a closed build will be affected by Eclipse files. > > Nor do I. The build doesn't care, and if a developer clones the repo into `rt` after the name is changed to `jfx` it will be no different than someone who clones the repo into, say, `javafx` or `jfx20` or ... the closed repo is also called jfx, but I withdraw my objection. If one were to create an eclipse project in the closed repo (if only to use egit UI, for instance), that project must be named differently (closed-jfx for instance) because eclipse cannot have two projects with the same name in the same workspace. therefore, we can rename the open project to jfx. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 6 00:29:43 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 00:29:43 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 Alright, we'll go with option 2 then and keep option 3 for further research. The new changes look fine, I'll do a formal review soon. ------------- PR: https://git.openjdk.org/jfx/pull/930 From john.hendrikx at gmail.com Sun Nov 6 14:09:47 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 6 Nov 2022 15:09:47 +0100 Subject: [External] : Re: JDK-8091393: Observable collections for ObservableMap views In-Reply-To: References: <732c2991-b2e2-0048-e86d-b894fd95640c@bestsolution.at> <2cc3e30a-2b92-a78d-8b9d-f7f1a2aba155@gmail.com> Message-ID: <39915657-fff4-c61e-59d0-56b11233441a@gmail.com> I've done some searching with Google using this query: ???? "javafx.collections.ObservableMap" "implements ObservableMap" And found what I think are only two distinct pieces of code that implements ObservableMap (aside from the ones in JavaFX). One is in the Griffon framework which still seems to be an active project.? See these files: https://github.com/griffon/griffon/blob/development_3_X/subprojects/griffon-javafx/src/main/java/griffon/javafx/collections/transformation/TransformationMap.java https://github.com/griffon/griffon/blob/development_3_X/subprojects/griffon-javafx/src/main/java/griffon/javafx/collections/ObservableMapBase.java The ObservableMapBase is declared as: ??? public abstract class ObservableMapBase extends AbstractMap implements ObservableMap Aside from Griffon framework, there is another use in a `SharedKeysMap`: ??? public class SharedKeysMap extends AbstractMap implements ObservableMap { It's described as a map which stores its values in an array and which can share its keys with other `SharedKeysMap`s.? I can't find anything about where this might be used, so it's probably a personal project. That said, it doesn't look like this occurs in any of the more popular frameworks used with JavaFX.? I'm not sure about Griffon's popularity (first I heard of it). It's actively developed so if there is a migration path we might be able to contribute a solution.? I also checked more directly code in ControlsFX, ReactFX, RichTextFX and JFXtras. --John On 28/10/2022 23:56, Stuart Marks wrote: > > Hi, > > I'm impressed you found that compatibility report. :-) > > The most severe compatibility issues indeed occur if the keySet(), > values(), and entrySet() methods are overridden to have a covariant > return type. Issues will arise with subclasses that already override > any of those methods, either with the return types from Map, or with > covariant overrides of their own. > > It's true that bridge methods will be generated if this is done, and > they take care of the most common compatibility issues. However, there > is a compatibility matrix to be explored. My compatibility analysis > considered old-binary, recompiled-source, and modified-source cases > for both a library that has an at-risk subclass as well as an > application that uses that library subclass. Some startling things > emerged. What pushed me over the edge to decide against covariant > overrides (in this part of the Sequenced Collections JEP) was that the > behavior of a class could change silently upon recompilation, even if > the source code wasn't changed. > > Aside from this issue, there's a more fundamental semantic issue with > the object design. If I have some ObservableMap implementation, > presumably it provides a keySet() implementation that's not > observable. If ObservableMap is changed to have the covariant > overrides, this effectively imposes a new requirement that existing > implementations cannot possibly fulfill. Sure, you could tinker things > around so that things appear to work in some cases, but the semantics > of doing this are highly questionable. > > Now JavaFX could decide go ahead with this anyway, for a couple > reasons. One might be, JavaFX doesn't care as much as the JDK about > compatibility. It's (mostly) a different project, and it might have > different compatibility constraints. You folks need to decide that. A > second reason might be because there are vanishingly few or zero > implementations of ObservableMap "in the wild," so any incompatibility > would not cause any actual problems. This is difficult, but it's > possible to get some information by doing source code searches. > (Unfortunately there appear to be several libraries out there that > have something called "ObservableMap" which will complicate the analysis.) > > The alternative is to add observableKeySet/Values/EntrySet() default > methods instead of covariant overrides. This is safer, but it does add > some clutter to the API. > > s'marks > > On 10/26/22 1:24 PM, Nir Lisker wrote: >> I'm CC'ing Stuart Marks who has recently dealt with a similar issue >> when working on Sequenced Collections [1], and wrote a compatibility >> report [2] that?includes an item?about covariant overrides >> ("Covariant Overrides of `SequencedMap` View Collection Methods"), >> which is similar to what is discussed here. I contacted him off list >> to get his insights into the risks involved here. >> >> To recap, ObservableMap inherits keySet(), entrySet() and values() >> from Map, which return the standard Set and Collection interfaces. >> ObservableMap should provide ObservableSet and perhaps the >> not-yet-existing ObservableCollection. There are 2 options here: one >> is to add additional default methods to ObservableMap that return >> observable collection, the second is to override the methods >> inherited from Map and change the return value. The latter has some >> backwards compatibility issues. It comes down to implementations of >> ObservableMap in the wild. I have yet to see any, personally. JavaFX >> does not itself expose any of its implementations, as ObservableMaps >> are obtained through FXCollections static methods. >> >> I'd like to continue this discussion about the API side. I have >> already had some advances on the implementation. >> >> [1] https://openjdk.org/jeps/431 >> [2] https://bugs.openjdk.org/browse/JDK-8266572 >> >> On Tue, May 31, 2022 at 12:02 AM Nir Lisker wrote: >> >> Then?maybe a solution would be around adding new methods like >> observableKeySet(). These will need to be default methods, and >> the implementation could test if keySet() already returns an >> ObservableSet, in which case it returns it, and if not it wraps >> the Set in an ObservableSetWrapper or something like that. >> >> On Mon, May 30, 2022 at 11:50 AM John Hendrikx >> wrote: >> >> Sorry, I misunderstood, I missed that the methods weren't >> already >> defined in ObservableMap, so no existing signature is changed. >> >> --John >> >> On 30/05/2022 09:39, Tom Schindl wrote: >> > Hi, >> > >> > Well the binary compat IMHO is not a problem. If your subtype >> > overwrites the return type of a method the compiler will >> inserts a >> > bridge method: >> > >> > Take this example >> > >> > package bla; >> > >> > import java.util.ArrayList; >> > import java.util.Collection; >> > import java.util.List; >> > >> > public class Test { >> > ????public interface IB { >> > ??????? public Collection get(); >> > ????} >> > >> > ????public interface I extends IB { >> > ??????? public List get(); >> > ????} >> > >> > ????public class C implements I { >> > ??????? public ArrayList get() { >> > ??????????? return new ArrayList(); >> > ??????? } >> > ????} >> > } >> > >> > if you look at C with javap you'll notice >> > >> > Compiled from "Test.java" >> > public class bla.Test$C implements bla.Test$I { >> > ? final bla.Test this$0; >> > ? public bla.Test$C(bla.Test); >> > ? public java.util.ArrayList get(); >> > ? public java.util.Collection get(); >> > ? public java.util.List get(); >> > } >> > >> > >> > The problem is more that if someone directly implemented >> ObservableMap >> > him/her self that it won't compile anymore. So it is a source >> > incompatible change. >> > >> > Tom >> > >> > Am 30.05.22 um 08:58 schrieb John Hendrikx: >> >> It's not binary compatible, as changing the return type >> results in a >> >> new method that compiled code won't be able to find. >> >> >> >> See also "change result type (including void)" here: >> >> >> https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods >> >> >> >> >> >> >> >> --John >> >> >> >> On 30/05/2022 03:22, Nir Lisker wrote: >> >>> Hi, >> >>> >> >>> Picking up an old issue, JDK-8091393 [1], I went ahead >> and looked at >> >>> the >> >>> work needed to implement it. >> >>> >> >>> keySet() and entrySet() can both be made to return >> ObservableSet rather >> >>> easily. values() will probably require an >> ObservableCollection type. >> >>> >> >>> Before discussing these details, my question is: is it >> backwards >> >>> compatible >> >>> to require that these? methods now return a more refined >> type? I >> >>> think that >> >>> it will break implementations of ObservableMap out in the >> wild if it >> >>> overrides these methods in Map. What is the assessment here? >> >>> >> >>> https://bugs.openjdk.java.net/browse/JDK-8091393 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sun Nov 6 17:06:33 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Nov 2022 17:06:33 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v8] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Wed, 26 Oct 2022 07:56:52 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix javadoc error I think the most important open point for this PR is the name for the new operation to be added to `ObservableValue`. Currently in this PR it is called `when`. Some background first to help with the decision; all fluent methods follow this basic pattern: source.operation( ... ) -> new target observable The proposed operation has a `ObservabeValue` parameter as its condition. It allows you to create a new observable that has the same value as its source, unless the associated condition is `false`, in which case it contains the last seen value of the source (it does **not** change to `null` or empty, so an `orElse` cannot be used to change the value when the condition is `false`.). The proposed operation differs from the other three available fluent methods (`map`, `flatMap` and `orElse`) that in order to determine its result it does not need to continuously observe its source -- the source value has no bearing on whether the target will or will not reflect the source value, only the condition controls this. This is unlike `map` for example, which **must** evaluate the source value to determine the target value, and also unlike a `filter` method (as seen in `Optional` or `Stream`) which must evaluate the source value to see if it passes the filter predicate in order to determine whether the target uses the source value or becomes empty. Because the source value is not needed to reach a decision for this new proposed operation, there is no need to constantly observe the source value for changes. When the conditional is `false`, the observer can be removed until such time that the conditional becomes `true`. This is in contrast to `map`, `orElse` or a potential future `filter` operation which have no choice but to observe their source at all times in order to correctly calculate their target value. There is also a clear intention that the condition changes at some point in the future and that it need not be a one time change (when condition becomes `true` again, the target again starts tracking the source value); if the condition never changes there is no need to use this new operation as one can just use the source observable (if condition is always `true`) or it becomes a constant value (if condition is always `false`). A quick overview of the differences between the existing and new operation: |Time|x|condition|x.map(x -> x * 2)|x.filter(x -> x % 2 == 0)|x.operation(condition)| |:-:|:-:|:-:|:-:|:-:|:-:| |0|2|true|4|2|2| |1|2|false|4|2|2| |2|3|false|6|null (empty)|2| |3|3|true|6|null (empty)|3| |4|4|true|8|4|4| ## Options for the name of this new operation The full signature for the newly proposed operation is: ObservableValue __operation__(ObservableValue condition) Possible options: 1. `while`, `if` 2. `conditionOn` (from ReactFX) 3. `skipUntil` + `takeWhile` or `skipWhile` + `takeUntil` (from ReactiveX) 4. When variations: `when`, `updateWhen`, `whenever` ### `while` and `if` Although `while` would fit the bill reasonably nice ("target becomes source value **while** condition (is true)"), it is a reserved keyword. `while` does have a time component to it, but does not so nicely communicate that the condition may become `true` again; one would have to clarify this with "target becomes source value whenever the **while** condition (is true)". `if` is also a reserved keyword, but does a slightly better job than `while`: "target becomes source value **if** condition (is true)". It does however not communicate that the condition is likely to change in the future, which is the whole point of this new operation. ### `conditionOn` ReactFX uses this term for the proposed operation. In english it could perhaps be formulated as: "target becomes source value on the condition that condition (is true)". This name seems a bit superfluous. The parameter of the proposed operation is already called `condition` and other similar methods don't re-iterate this fact in their naming either. ### `skipUntil` + `takeWhile` or `skipWhile` + `takeUntil` In ReactiveX there is a similar operation for dealing with its streams. First note, there is an important difference between `ObservableValue` and ReactiveX's `Observable`: an `ObservableValue` always has a current value that can be queried and operated upon at any time. An `Observable` in ReactiveX has no current value, and when applying operations to its streams, these operations can only be applied if the source observable emits an event. ReactiveX is closer match for Java's `Stream` while `ObservableValue` is a closer match to Java's `Optional`. The operations allowed by ReactiveX cannot be used to achieve a similar effect as the proposed method by combining them (`x.skipUntil(c).takeWhile(c)`). This is because the operations allow one condition change only, which is pretty clear from their names. A better name that would match our operation would be `takeWhenever(c)` which is another variation of using "when". ### When variations: `when`, `updateWhen`, `whenever` Earlier, `if` proved to be quite a good match: "target becomes source value **if** condition (is true)", but did not communicate that well that the condition is almost certain to change in the future (as using the new operation would be pointless otherwise). In English, "when" distinguishes itself from "if" for something that is almost certain to happen at some point in the future. All of these are a good match. In the context of creating observables that are bound to each other (and thus update on changes of their source), there is little need to reiterate this in the name; all of the fluent methods will update their target in some fashion. In English, `whenever` is used for repeated occurrences, while `when` can mean a single occurrence (but doesn't preclude it AFAIK). This mean I think that both of these would be great matches. I would be inclined to go for the more compact `when`. This has been a long story; I hope we can reach a consensus on a name, perhaps people can respond with a ranked set of preferences. ------------- PR: https://git.openjdk.org/jfx/pull/830 From nlisker at openjdk.org Sun Nov 6 21:35:26 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Nov 2022 21:35:26 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 The new changes look good. I get a bogus error marker on the apps folder in Project Explorer, but in Package Explorer there is no error. Looks like some Eclipse hiccup. My only comment is about some classpath files that define more dependencies than needed. For example, manualTests-dnd can use this: Everything still works with the extra dependencies, but in general it's better to remove them. Do you want to do that? I can find the minimal dependencies. ------------- PR: https://git.openjdk.org/jfx/pull/930 From thiago.sayao at gmail.com Sun Nov 6 23:32:36 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 6 Nov 2022 20:32:36 -0300 Subject: requestFocus on setScene - is it right? Message-ID: Hi, While working on native linux glass code I observed that requestFocus() is called before show(). If the window is not shown (mapped on Xorg), It can't be focused. The code is on WindowStage.setScene() line 276. It might be the case when switching the scene, but should the window be focused in that case? If the user is "focused" on another window and the program decides to switch the scene the window would pop and steal the focus. Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sun Nov 6 23:44:18 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 6 Nov 2022 23:44:18 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v23] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call set_bounds again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `requested_bounds` removed - not necessary; > - `window_configure` incorporated in set_bounds with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao 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 contains one new commit since the last revision: 8260528: Clean glass-gtk sizing and positioning code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/58bb987f..c5c796fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=22 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=21-22 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From thiago.sayao at gmail.com Sun Nov 6 23:47:37 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 6 Nov 2022 20:47:37 -0300 Subject: Help testing 8260528 / PR #915 Message-ID: Hi Gregor, Last time you helped with testing. I have improved the PR in: https://github.com/openjdk/jfx/pull/915 I think it's ready to be tested. Would you help testing it? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Mon Nov 7 00:01:29 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 7 Nov 2022 00:01:29 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v24] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <4E-CsrddoyuKN9R9XNRnmagSuEzVsA5-_I1NRN5j5cc=.f842372e-264c-487e-9652-272113ea0f5a@github.com> > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary includes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/c5c796fc..e551968f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=23 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=22-23 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Mon Nov 7 00:05:22 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 7 Nov 2022 00:05:22 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao 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 contains one new commit since the last revision: 8260528: Clean glass-gtk sizing and positioning code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/e551968f..b113d919 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=24 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=23-24 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Mon Nov 7 01:16:26 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 7 Nov 2022 01:16:26 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v26] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: show_now breaks transparency ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/b113d919..65ab4912 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=25 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Mon Nov 7 01:21:06 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 7 Nov 2022 01:21:06 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - `gtk_widget_show_now` will wait the window to actually be mapped on X11 throught `XMapWindow()` so when focus is requested the window will guaranteed to be maped. > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao 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 contains one new commit since the last revision: 8260528: Clean glass-gtk sizing and positioning code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/65ab4912..46f6eba2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=26 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=25-26 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From jhendrikx at openjdk.org Mon Nov 7 08:32:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 7 Nov 2022 08:32:22 GMT Subject: RFR: 8221708 Update Eclipse project files [v2] In-Reply-To: References: Message-ID: > See https://bugs.openjdk.org/browse/JDK-8221708 John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Update Eclipse classpath files - Stripped dependencies to a minimum - Added ".settings" to exclusion for projects with sources in root folder ------------- Changes: - all: https://git.openjdk.org/jfx/pull/930/files - new: https://git.openjdk.org/jfx/pull/930/files/57048ba6..c27beb6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=00-01 Stats: 299 lines in 21 files changed: 0 ins; 289 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/930.diff Fetch: git fetch https://git.openjdk.org/jfx pull/930/head:pull/930 PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Mon Nov 7 08:32:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 7 Nov 2022 08:32:24 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 21:31:49 GMT, Nir Lisker wrote: > The new changes look good. I get a bogus error marker on the apps folder in Project Explorer, but in Package Explorer there is no error. Looks like some Eclipse hiccup. Yes, this happens sometimes to me as well. The import process of so many projects sometimes seems to cause an error. If after deleting the error from the problem view + rebuilding, the error doesn't return, then it is likely a bug in Eclipse. > Everything still works with the extra dependencies, but in general it's better to remove them. Do you want to do that? I can find the minimal dependencies. I've stripped all the unnecessary dependencies. Also added `.settings` to ignore for a few projects that have sources in their root folder to avoid it being copied to `bin`. ------------- PR: https://git.openjdk.org/jfx/pull/930 From john.hendrikx at gmail.com Mon Nov 7 08:42:43 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 7 Nov 2022 09:42:43 +0100 Subject: requestFocus on setScene - is it right? In-Reply-To: References: Message-ID: On 07/11/2022 00:32, Thiago Milczarek Say?o wrote: > While working on native linux glass code I observed that > requestFocus() is called before show(). > If the window is not shown (mapped on Xorg), It can't be focused. Have you observed this to be a problem? I believe the actual focus acquisition is delayed. > > The code is on WindowStage.setScene() line 276. > > It might be the case when switching the scene, but should the window > be focused in that case? > > If the user is "focused" on another window and the program decides to > switch the scene the window would pop and steal the focus. Most window managers won't allow this, even if an application does request focus.? Instead they'll indicate this in the task bar that a window wants the focus. Is this actually happening? --John From ajit.ghaisas at oracle.com Mon Nov 7 09:18:58 2022 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 7 Nov 2022 09:18:58 +0000 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: Vote : Yes Regards, Ajit > On 03-Nov-2022, at 10:35 PM, Kevin Rushforth wrote: > > I hereby nominate Andy Goryachev [1] to OpenJFX Committer. > > Andy is a member of the JavaFX team at Oracle who has contributed 22 commits [2] to OpenJFX. > > Votes are due by November 17, 2022 at 18:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#angorya > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Andy+Goryachev%22&s=author-date&type=commits > > [3] https://openjdk.org/census#openjfx > > [4] https://openjdk.org/bylaws#lazy-consensus > > [5] https://openjdk.org/projects#project-committer > From dwookey at openjdk.org Mon Nov 7 12:03:38 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Mon, 7 Nov 2022 12:03:38 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: Added changing scene tests for accelerator change listeners ------------- Changes: - all: https://git.openjdk.org/jfx/pull/937/files - new: https://git.openjdk.org/jfx/pull/937/files/0dae693a..52a98813 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=937&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=937&range=00-01 Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/937.diff Fetch: git fetch https://git.openjdk.org/jfx pull/937/head:pull/937 PR: https://git.openjdk.org/jfx/pull/937 From arapte at openjdk.org Mon Nov 7 13:18:52 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 13:18:52 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile Message-ID: This issue was uncovered when running the test added in a PR in commit #1+#2: https://github.com/openjdk/jfx/pull/924 The JUnit5 tests using Params API fails to compile. Fix: Change dependency of `junit-jupiter-params` from runtime to compile time. From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) It seems that changing dependency of this one package is sufficient for this fix. ------------- Commit messages: - Change junit-jupiter-params to compilation dependency Changes: https://git.openjdk.org/jfx/pull/939/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=939&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296283 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/939.diff Fetch: git fetch https://git.openjdk.org/jfx pull/939/head:pull/939 PR: https://git.openjdk.org/jfx/pull/939 From nlisker at gmail.com Mon Nov 7 13:19:03 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 7 Nov 2022 15:19:03 +0200 Subject: CFV: New OpenJFX Committer: Andy Goryachev In-Reply-To: References: Message-ID: Vote: YES On Mon, Nov 7, 2022 at 11:19 AM Ajit Ghaisas wrote: > Vote : Yes > > Regards, > Ajit > > > On 03-Nov-2022, at 10:35 PM, Kevin Rushforth > wrote: > > > > I hereby nominate Andy Goryachev [1] to OpenJFX Committer. > > > > Andy is a member of the JavaFX team at Oracle who has contributed 22 > commits [2] to OpenJFX. > > > > Votes are due by November 17, 2022 at 18:00 UTC. > > > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.org/census#angorya > > > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Andy+Goryachev%22&s=author-date&type=commits > > > > [3] https://openjdk.org/census#openjfx > > > > [4] https://openjdk.org/bylaws#lazy-consensus > > > > [5] https://openjdk.org/projects#project-committer > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariushanl at web.de Mon Nov 7 13:24:41 2022 From: mariushanl at web.de (Marius Hanl) Date: Mon, 7 Nov 2022 14:24:41 +0100 Subject: =?UTF-8?Q?Aw=3A=C2=A0CFV=3A_New_OpenJFX_Committer=3A_Andy_Goryachev?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Nov 7 13:34:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 13:34:11 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 13:11:27 GMT, Ambarish Rapte wrote: > This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/924 > The JUnit5 tests using Params API fails to compile. > > Fix: > Change dependency of `junit-jupiter-params` from runtime to compile time. > From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and > JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) > > It seems that changing dependency of this one package is sufficient for this fix. Looks good, pending my question about `junit-platform-commons`. build.gradle line 1995: > 1993: testRuntimeOnly group: "org.apiguardian", name: "apiguardian-api", version: "1.1.2" > 1994: testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-engine", version: "5.8.1" > 1995: testRuntimeOnly group: "org.junit.platform", name: "junit-platform-commons", version: "1.8.1" Have you checked whether the `junit-platform-commons` jar file, which also has public JUnit5 API, needs the same treatment? I might recommend also moving that one to `testImplementation` as well. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/939 From thiago.sayao at gmail.com Mon Nov 7 14:38:23 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 7 Nov 2022 11:38:23 -0300 Subject: requestFocus on setScene - is it right? In-Reply-To: References: Message-ID: It was a problem in the past gtk glass, but now it checks if visible to request the focus. But, there are two situations: 1 - Most common - there is one Scene and it's created before the window is shown. In this case, there is no point to request focus; 2 - The scene has changed. Do we want to issue notifications or flash the taskbar because the Scene has changed? If 2 is "no", then I think this line should be removed. If 2 is "yes", then I think we should have an API to request attention. Em seg., 7 de nov. de 2022 ?s 05:42, John Hendrikx escreveu: > On 07/11/2022 00:32, Thiago Milczarek Say?o wrote: > > While working on native linux glass code I observed that > > requestFocus() is called before show(). > > If the window is not shown (mapped on Xorg), It can't be focused. > Have you observed this to be a problem? I believe the actual focus > acquisition is delayed. > > > > The code is on WindowStage.setScene() line 276. > > > > It might be the case when switching the scene, but should the window > > be focused in that case? > > > > If the user is "focused" on another window and the program decides to > > switch the scene the window would pop and steal the focus. > > Most window managers won't allow this, even if an application does > request focus. Instead they'll indicate this in the task bar that a > window wants the focus. > > Is this actually happening? > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Mon Nov 7 16:19:48 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 7 Nov 2022 17:19:48 +0100 Subject: requestFocus on setScene - is it right? In-Reply-To: References: Message-ID: <1a224872-f093-d35f-96bb-4b0d8acb3ad9@gmail.com> Sorry, I was confused which requestFocus you meant, I was looking at Scene#requestFocus(Node). --John On 07/11/2022 15:38, Thiago Milczarek Say?o wrote: > It was a problem in the past gtk glass, but now it checks if visible > to request the focus. > > But, there are two situations: > > 1 - Most common - there is one Scene and it's created before the > window is shown. In this case, > there is no point to request focus; > > 2 - The scene has changed. Do we want to issue notifications or flash > the taskbar because the Scene has changed? > > If 2 is "no", then I think this line should be removed. > > If 2 is "yes", then I think we should have an API to request attention. > > Em seg., 7 de nov. de 2022 ?s 05:42, John Hendrikx > escreveu: > > On 07/11/2022 00:32, Thiago Milczarek Say?o wrote: > > While working on native linux glass code I observed that > > requestFocus() is called before show(). > > If the window is not shown (mapped on Xorg), It can't be focused. > Have you observed this to be a problem? I believe the actual focus > acquisition is delayed. > > > > The code is on WindowStage.setScene() line 276. > > > > It might be the case when switching the scene, but should the > window > > be focused in that case? > > > > If the user is "focused" on another window and the program > decides to > > switch the scene the window would pop and steal the focus. > > Most window managers won't allow this, even if an application does > request focus.? Instead they'll indicate this in the task bar that a > window wants the focus. > > Is this actually happening? > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Nov 7 16:29:42 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 16:29:42 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: > This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 > The JUnit5 tests using Params API fails to compile. > > Fix: > Change dependency of `junit-jupiter-params` from runtime to compile time. > From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and > JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) > > It seems that changing dependency of this one package is sufficient for this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: add test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/939/files - new: https://git.openjdk.org/jfx/pull/939/files/5693eba4..64ba3a96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=939&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=939&range=00-01 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/939.diff Fetch: git fetch https://git.openjdk.org/jfx pull/939/head:pull/939 PR: https://git.openjdk.org/jfx/pull/939 From arapte at openjdk.org Mon Nov 7 16:29:42 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 16:29:42 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 13:31:50 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> add test > > Looks good, pending my question about `junit-platform-commons`. @kevinrushforth Added a test as you suggested offline. The checks inside test may not be required, please suggest if any modifications required. > build.gradle line 1995: > >> 1993: testRuntimeOnly group: "org.apiguardian", name: "apiguardian-api", version: "1.1.2" >> 1994: testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-engine", version: "5.8.1" >> 1995: testRuntimeOnly group: "org.junit.platform", name: "junit-platform-commons", version: "1.8.1" > > Have you checked whether the `junit-platform-commons` jar file, which also has public JUnit5 API, needs the same treatment? I might recommend also moving that one to `testImplementation` as well. Hi Kevin, Thanks for the pointer. As we checked that the jupiter-platform classes are used for test framework development, a change for them is not required for now. ------------- PR: https://git.openjdk.org/jfx/pull/939 From angorya at openjdk.org Mon Nov 7 16:38:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 16:38:38 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:29:42 GMT, Ambarish Rapte wrote: >> This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 >> The JUnit5 tests using Params API fails to compile. >> >> Fix: >> Change dependency of `junit-jupiter-params` from runtime to compile time. >> From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and >> JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) >> >> It seems that changing dependency of this one package is sufficient for this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > add test We have other tests which use `@RunWith(Parameterized.class)` just fine (for example, SkinMemoryLeakTest). Is this about mixing junit4 and junit5 classes? Do we need to make changes in other tests? ------------- PR: https://git.openjdk.org/jfx/pull/939 From nlisker at openjdk.org Mon Nov 7 16:41:34 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 7 Nov 2022 16:41:34 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:29:42 GMT, Ambarish Rapte wrote: >> This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 >> The JUnit5 tests using Params API fails to compile. >> >> Fix: >> Change dependency of `junit-jupiter-params` from runtime to compile time. >> From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and >> JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) >> >> It seems that changing dependency of this one package is sufficient for this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > add test It could be a good idea in a follow-up PR to move the version numbers to a constant so that we don't need to update each separately, like the Junit "5.8.1" version. ------------- PR: https://git.openjdk.org/jfx/pull/939 From angorya at openjdk.org Mon Nov 7 17:05:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 17:05:38 GMT Subject: RFR: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 08:26:58 GMT, John Hendrikx wrote: >> The new changes look good. I get a bogus error marker on the apps folder in Project Explorer, but in Package Explorer there is no error. Looks like some Eclipse hiccup. >> >> My only comment is about some classpath files that define more dependencies than needed. For example, manualTests-dnd can use this: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Everything still works with the extra dependencies, but in general it's better to remove them. Do you want to do that? I can find the minimal dependencies. > >> The new changes look good. I get a bogus error marker on the apps folder in Project Explorer, but in Package Explorer there is no error. Looks like some Eclipse hiccup. > > Yes, this happens sometimes to me as well. The import process of so many projects sometimes seems to cause an error. If after deleting the error from the problem view + rebuilding, the error doesn't return, then it is likely a bug in Eclipse. > >> Everything still works with the extra dependencies, but in general it's better to remove them. Do you want to do that? I can find the minimal dependencies. > > I've stripped all the unnecessary dependencies. Also added `.settings` to ignore for a few projects that have sources in their root folder to avoid it being copied to `bin`. Import as existing project + search for nested projects, 0 errors and 0 warnings. Excellent job, @hjohn ! ------------- PR: https://git.openjdk.org/jfx/pull/930 From kcr at openjdk.org Mon Nov 7 17:13:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 17:13:42 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:29:42 GMT, Ambarish Rapte wrote: >> This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 >> The JUnit5 tests using Params API fails to compile. >> >> Fix: >> Change dependency of `junit-jupiter-params` from runtime to compile time. >> From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and >> JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) >> >> It seems that changing dependency of this one package is sufficient for this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > add test The test looks good. I left a couple minor comments. modules/javafx.base/src/test/java/test/JUnit5Test.java line 49: > 47: static int callCount; > 48: static int[] intValues = {1, 2, 3}; > 49: @ValueSource(ints = {1, 2, 3}) Minor: maybe add a blank line before this line? modules/javafx.base/src/test/java/test/JUnit5Test.java line 68: > 66: if (i != 0) { > 67: fail("Test method not called for Value " + i); > 68: } Minor: could simplify this to: assertEquals(0, i, "Test method not called for Value " + i); ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/939 From angorya at openjdk.org Mon Nov 7 17:13:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 17:13:43 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:29:42 GMT, Ambarish Rapte wrote: >> This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 >> The JUnit5 tests using Params API fails to compile. >> >> Fix: >> Change dependency of `junit-jupiter-params` from runtime to compile time. >> From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and >> JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) >> >> It seems that changing dependency of this one package is sufficient for this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > add test thank you for clarifications. ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/939 From arapte at openjdk.org Mon Nov 7 17:13:43 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 17:13:43 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:34:54 GMT, Andy Goryachev wrote: > We have other tests which use `@RunWith(Parameterized.class)` just fine (for example, SkinMemoryLeakTest). Is this about mixing junit4 and junit5 classes? It is not about mixing. The JUnit5 test added in PR https://github.com/openjdk/jfx/pull/910 which uses annotations from `org.junit.jupiter.params` failed to compile on my local machine throwing following errors: error: package org.junit.jupiter.params does not exist error: package org.junit.jupiter.params.provider does not exist error: cannot find symbol @ValueSource error: cannot find symbol @ParameterizedTest This PR fixes that compilation error. I am not sure how it worked on GHA. > Do we need to make changes in other tests? It won't need any changes in existing tests. ------------- PR: https://git.openjdk.org/jfx/pull/939 From kcr at openjdk.org Mon Nov 7 17:13:43 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 17:13:43 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 16:34:54 GMT, Andy Goryachev wrote: > We have other tests which use `@RunWith(Parameterized.class)` just fine (for example, SkinMemoryLeakTest). Is this about mixing junit4 and junit5 classes? > > Do we need to make changes in other tests? No, this bug is about specific APIs that are part of the `junit-jupiter-params` jar file. Specifically, the `ValueSource` and `ParameterizedTest` annotations not being available at compile time in all cases. It works accidentally without the `build.gradle` fix for open builds (e.g., GHA) and fails in our CI build without this change. ------------- PR: https://git.openjdk.org/jfx/pull/939 From kcr at openjdk.org Mon Nov 7 17:18:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 17:18:37 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: <-JbfjqKe5nOwtO2joJ-uhS_CxK6OLhT7NduYqAEsjpQ=.783bbb3e-193d-4d1b-8b29-f63990ac9310@github.com> On Mon, 7 Nov 2022 16:39:19 GMT, Nir Lisker wrote: > It could be a good idea in a follow-up PR to move the version numbers to a constant so that we don't need to update each separately, like the Junit "5.8.1" version. Yes, this is a good idea. @arapte can you file a follow-on issue? ------------- PR: https://git.openjdk.org/jfx/pull/939 From dwookey at openjdk.org Mon Nov 7 18:15:17 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Mon, 7 Nov 2022 18:15:17 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 21:14:20 GMT, Andy Goryachev wrote: >> Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added changing scene tests for accelerator change listeners > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 154: > >> 152: sceneChangeListener = (scene, oldValue, newValue) -> { >> 153: if (oldValue != null) { >> 154: ControlAcceleratorSupport.removeAcceleratorsFromScene(getSkinnable().getItems(), oldValue); > > will it handle a case where the menu button gets attached to a different scene? > could you add a second test for this scenario please? > > And i wonder if the problem is in ControlAcceleratorSupport rather than here. We do have a similar code in Control:380, do we have a problem there? The code in ControlAcceleratorSupport adds its own scene listeners for each node added. MenuButtonSkinBase does the same, unlike Control which only calls it once. I think we could fix it in ControlAcceleratorSupport alternatively or in addition to this fix. The code in ControlAcceleratorSupport appears to do everything this would've done. I've added the test for changing scenes. ------------- PR: https://git.openjdk.org/jfx/pull/937 From angorya at openjdk.org Mon Nov 7 19:01:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 19:01:38 GMT Subject: RFR: 8221708 Update Eclipse project files [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 08:32:22 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse classpath files > > - Stripped dependencies to a minimum > - Added ".settings" to exclusion for projects with sources in root > folder beautiful! ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/930 From mhanl at openjdk.org Mon Nov 7 19:46:08 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 7 Nov 2022 19:46:08 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator ------------- Changes: - all: https://git.openjdk.org/jfx/pull/936/files - new: https://git.openjdk.org/jfx/pull/936/files/d5ff752a..83080ec6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=00-01 Stats: 47 lines in 1 file changed: 13 ins; 3 del; 31 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 19:46:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 19:46:09 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:42:01 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 137: > 135: > 136: assertEquals(widthHeight + snappedPaddingX, container.prefWidth(-1), DELTA, className); > 137: assertEquals(widthHeight + snappedPaddingY, container.prefHeight(-1), DELTA, className); sorry, should have specified in my previous comment - this constant is typically called EPSILON (a Greek letter denoting a very small number) ------------- PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 19:49:20 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 19:49:20 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:46:08 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 155: > 153: // new ContainerCreator<>(StackPane::new), > 154: // new ContainerCreator<>(BorderPane::new), > 155: // new ContainerCreator<>(node -> { 1. should we create corresponding bug reports for the commented out containers? 2. should we also test other descendants of Pane (am I correct in guessing it's a Pane you call "container")? ------------- PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Mon Nov 7 19:56:03 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 7 Nov 2022 19:56:03 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:42:01 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 137: > >> 135: >> 136: assertEquals(widthHeight + snappedPaddingX, container.prefWidth(-1), DELTA, className); >> 137: assertEquals(widthHeight + snappedPaddingY, container.prefHeight(-1), DELTA, className); > > sorry, should have specified in my previous comment - this constant is typically called EPSILON (a Greek letter denoting a very small number) While this is correct, the `assertEquals` method in JUnit calls this variable `delta`, so I think both namings are understandable and fine ------------- PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Mon Nov 7 19:55:59 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 7 Nov 2022 19:55:59 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v3] In-Reply-To: References: Message-ID: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8296330: Missed two :P ------------- Changes: - all: https://git.openjdk.org/jfx/pull/936/files - new: https://git.openjdk.org/jfx/pull/936/files/83080ec6..2d5e5801 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Mon Nov 7 20:00:28 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 7 Nov 2022 20:00:28 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> On Mon, 7 Nov 2022 19:46:41 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 155: > >> 153: // new ContainerCreator<>(StackPane::new), >> 154: // new ContainerCreator<>(BorderPane::new), >> 155: // new ContainerCreator<>(node -> { > > 1. should we create corresponding bug reports for the commented out containers? > 2. should we also test other descendants of Pane (am I correct in guessing it's a Pane you call "container")? 1. Yes. We may want to create something like an 'epic'. I see that in the past it was called an 'umbrella issue' 2. Yeah we should, but the goal of this PR is to test all layout container, specified in `javafx.scene.layout`. Other nodes needs more special test cases, e.g. can't be solved in a generic test. `Control` nodes are also mostly fine since the `layoutChildren` method in the `SkinBase` will receive the already snapped insets (so it is harder to do the wrong thing). ------------- PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 20:15:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 20:15:29 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> References: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> Message-ID: On Mon, 7 Nov 2022 19:57:39 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 155: >> >>> 153: // new ContainerCreator<>(StackPane::new), >>> 154: // new ContainerCreator<>(BorderPane::new), >>> 155: // new ContainerCreator<>(node -> { >> >> 1. should we create corresponding bug reports for the commented out containers? >> 2. should we also test other descendants of Pane (am I correct in guessing it's a Pane you call "container")? > > 1. Yes. We may want to create something like an 'epic'. I see that in the past it was called an 'umbrella issue' > 2. Yeah we should, but the goal of this PR is to test all layout container, specified in `javafx.scene.layout`. > > Other nodes needs more special test cases, e.g. can't be solved in a generic test. `Control` nodes are also mostly fine since the `layoutChildren` method in the `SkinBase` will receive the already snapped insets (so it is harder to do the wrong thing). could you please create an umbrella ticket listing all the types that need to be added to the test and/or fixed? here is an example of such ticket (with an umbrella unicode): [JDK-8241364](https://bugs.openjdk.org/browse/JDK-8241364) ------------- PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 20:25:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 20:25:37 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:55:59 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Missed two :P Changes requested by angorya (Author). ------------- PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 20:25:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 20:25:38 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:51:04 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 137: >> >>> 135: >>> 136: assertEquals(widthHeight + snappedPaddingX, container.prefWidth(-1), DELTA, className); >>> 137: assertEquals(widthHeight + snappedPaddingY, container.prefHeight(-1), DELTA, className); >> >> sorry, should have specified in my previous comment - this constant is typically called EPSILON (a Greek letter denoting a very small number) > > While this is correct, the `assertEquals` method in JUnit calls this variable `delta`, so I think both namings are understandable and fine Mathematically speaking, it is not a delta (change), it is a small quantity (epsilon). it's a minor nit pick, but in this context it should be an EPSILON. (There is one in TableUtil, but search in the code base and you'll find ~ 4K matches ------------- PR: https://git.openjdk.org/jfx/pull/936 From angorya at openjdk.org Mon Nov 7 20:31:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 7 Nov 2022 20:31:53 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v8] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Wed, 26 Oct 2022 07:56:52 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix javadoc error I am not a native speaker, but to me `whenever` sounds event better than `conditionOn`. I might be wrong, but it does suggest that the binding becomes active *again* when the condition turns `true`. ------------- PR: https://git.openjdk.org/jfx/pull/830 From arapte at openjdk.org Mon Nov 7 20:32:53 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 20:32:53 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v3] In-Reply-To: References: Message-ID: > This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 > The JUnit5 tests using Params API fails to compile. > > Fix: > Change dependency of `junit-jupiter-params` from runtime to compile time. > From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and > JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) > > It seems that changing dependency of this one package is sufficient for this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/939/files - new: https://git.openjdk.org/jfx/pull/939/files/64ba3a96..ff684bec Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=939&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=939&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/939.diff Fetch: git fetch https://git.openjdk.org/jfx pull/939/head:pull/939 PR: https://git.openjdk.org/jfx/pull/939 From arapte at openjdk.org Mon Nov 7 20:32:53 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Nov 2022 20:32:53 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:04:35 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> add test > > modules/javafx.base/src/test/java/test/JUnit5Test.java line 49: > >> 47: static int callCount; >> 48: static int[] intValues = {1, 2, 3}; >> 49: @ValueSource(ints = {1, 2, 3}) > > Minor: maybe add a blank line before this line? Added new line. > modules/javafx.base/src/test/java/test/JUnit5Test.java line 68: > >> 66: if (i != 0) { >> 67: fail("Test method not called for Value " + i); >> 68: } > > Minor: could simplify this to: > > > assertEquals(0, i, "Test method not called for Value " + i); Changed the assert. ------------- PR: https://git.openjdk.org/jfx/pull/939 From kcr at openjdk.org Mon Nov 7 23:10:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 23:10:33 GMT Subject: RFR: 8296283: JUnit5 tests using Params API fails to compile [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:32:53 GMT, Ambarish Rapte wrote: >> This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 >> The JUnit5 tests using Params API fails to compile. >> >> Fix: >> Change dependency of `junit-jupiter-params` from runtime to compile time. >> From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and >> JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) >> >> It seems that changing dependency of this one package is sufficient for this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/939 From kcr at openjdk.org Mon Nov 7 23:24:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Nov 2022 23:24:42 GMT Subject: RFR: 8221708 Update Eclipse project files [v2] In-Reply-To: References: Message-ID: <-Mhq_K5ZDTRUR1nFOfWAOfaO-Pxe47SUh2fWfQb87KA=.1cbeacba-5788-4feb-9057-48768312bf6e@github.com> On Mon, 7 Nov 2022 08:32:22 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse classpath files > > - Stripped dependencies to a minimum > - Added ".settings" to exclusion for projects with sources in root > folder Not a review, but I took a quick look at the (minor) changes to non-Eclipse files -- the Java files in `tests/manual/web/dnd` and `tests/performance/3DLighting` -- and they look fine to me. ------------- PR: https://git.openjdk.org/jfx/pull/930 From arapte at openjdk.org Tue Nov 8 06:07:14 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 8 Nov 2022 06:07:14 GMT Subject: Integrated: 8296283: JUnit5 tests using Params API fails to compile In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 13:11:27 GMT, Ambarish Rapte wrote: > This issue was uncovered when running the test added in PR: https://github.com/openjdk/jfx/pull/910 > The JUnit5 tests using Params API fails to compile. > > Fix: > Change dependency of `junit-jupiter-params` from runtime to compile time. > From: https://junit.org/junit5/docs/current/user-guide/#overview-what-is-junit-5: it can be understood that packages of JUnit Jupiter other than `TestEngine` are required for test compilation and > JUnit Platform serves as a foundation for [launching testing frameworks](https://junit.org/junit5/docs/current/user-guide/#launcher-api) > > It seems that changing dependency of this one package is sufficient for this fix. This pull request has now been integrated. Changeset: b08f1359 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/b08f1359902882ba97cfdbae64280d1bf10179e3 Stats: 31 lines in 2 files changed: 30 ins; 1 del; 0 mod 8296283: JUnit5 tests using Params API fails to compile Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/939 From dwookey at openjdk.org Tue Nov 8 10:11:42 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Tue, 8 Nov 2022 10:11:42 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 18:11:28 GMT, Dean Wookey wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java line 154: >> >>> 152: sceneChangeListener = (scene, oldValue, newValue) -> { >>> 153: if (oldValue != null) { >>> 154: ControlAcceleratorSupport.removeAcceleratorsFromScene(getSkinnable().getItems(), oldValue); >> >> will it handle a case where the menu button gets attached to a different scene? >> could you add a second test for this scenario please? >> >> And i wonder if the problem is in ControlAcceleratorSupport rather than here. We do have a similar code in Control:380, do we have a problem there? > > The code in ControlAcceleratorSupport adds its own scene listeners for each node added. MenuButtonSkinBase does the same, unlike Control which only calls it once. > > I think we could fix it in ControlAcceleratorSupport alternatively or in addition to this fix. The code in ControlAcceleratorSupport appears to do everything this would've done. > > I've added the test for changing scenes. Here is an alternative fix: https://github.com/openjdk/jfx/commit/80971d89c46f3f74cb8584d4907cc6818809e2f6 I just reverted the MenuButtonSkinBase changes. The tests pass with this fix, or with both. I'm a little more nervous about that one because I had to remove the code that removed and then added a scene listener. I'm not sure why it was done because the listener is independent of a specific scene. Basically, that fix only does the install if the install wasn't already done on that anchor meaning it can get called any number of times safely stopping duplicate accelerators being added. I would go with either both fixes together, or just the MenuButtonSkinBase one. ------------- PR: https://git.openjdk.org/jfx/pull/937 From dwookey at openjdk.org Tue Nov 8 10:13:41 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Tue, 8 Nov 2022 10:13:41 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 19:51:53 GMT, Kevin Rushforth wrote: >> When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. >> >> MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. >> >> When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. >> >> This pull request just removes the redundant code in the MenuButtonSkinBase. > > Reviewers: @arapte @andy-goryachev-oracle @kevinrushforth, @arapte I clicked the request review on andy and it removed arapte for some reason. I guess that button shouldn't be clicked. Oops. ------------- PR: https://git.openjdk.org/jfx/pull/937 From arapte at openjdk.org Tue Nov 8 12:22:43 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 8 Nov 2022 12:22:43 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Tue Nov 8 13:06:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Nov 2022 13:06:55 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 10:11:40 GMT, Dean Wookey wrote: > I clicked the request review on andy and it removed arapte for some reason. I guess that button shouldn't be clicked. Oops. That seems like a GitHub UI problem. I'll re-request a review from @arapte ------------- PR: https://git.openjdk.org/jfx/pull/937 From angorya at openjdk.org Tue Nov 8 16:43:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 16:43:09 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 353: > 351: > 352: if (leftAnchor != null) { > 353: x = snappedLeftInset() + leftAnchor; Question: should we use unsnapped coordinates in the computations, and only snap at the final stage? For example, if leftAnchor is 0.5 the child will be positioned between the pixels, so to speak. Or is this indeed an intended functionality? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 765: > 763: double snappedPaddingY = child.snapPositionY(padding); > 764: > 765: assertEquals(snappedPaddingX, boundsInParent.getMinX(), 0.0001); EPSILON constant perhaps? ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Tue Nov 8 17:38:23 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 17:38:23 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 16:40:11 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 765: > >> 763: double snappedPaddingY = child.snapPositionY(padding); >> 764: >> 765: assertEquals(snappedPaddingX, boundsInParent.getMinX(), 0.0001); > > EPSILON constant perhaps? Not sure if this is worth it for just 2 occurrences. In general I always try not to clutter the test class with things used in only one or two test methods. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Tue Nov 8 17:43:33 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 17:43:33 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 16:38:02 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 353: > >> 351: >> 352: if (leftAnchor != null) { >> 353: x = snappedLeftInset() + leftAnchor; > > Question: should we use unsnapped coordinates in the computations, and only snap at the final stage? > > For example, if leftAnchor is 0.5 the child will be positioned between the pixels, so to speak. > > Or is this indeed an intended functionality? Not 100% sure about this. It sounds somewhat logical. If we set the left anchor to be 5. Do we expect it to be 10 with a render scale of 2 -> 200% resolution? ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Tue Nov 8 17:44:39 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 17:44:39 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v4] In-Reply-To: References: Message-ID: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. 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 contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into 8296330-snapping-tests - 8296330: Renamed DELTA to EPSILON - 8296330: Missed two :P - 8296330: Added javadoc, made delta a constant, reordered working container on top and renamed ContainerInstruction to ContainerCreator - 8296330: Tests: Add layout container snapping tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/936/files - new: https://git.openjdk.org/jfx/pull/936/files/2d5e5801..fa8bc1ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=02-03 Stats: 436 lines in 112 files changed: 239 ins; 13 del; 184 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From jvos at openjdk.org Tue Nov 8 18:16:52 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 8 Nov 2022 18:16:52 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v4] In-Reply-To: References: Message-ID: > The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. > The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. > I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process reviewer comments. Use Math.round() instead of Math.floor() for coordinates ------------- Changes: - all: https://git.openjdk.org/jfx/pull/924/files - new: https://git.openjdk.org/jfx/pull/924/files/783c45a5..4dd021c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=924&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/924.diff Fetch: git fetch https://git.openjdk.org/jfx pull/924/head:pull/924 PR: https://git.openjdk.org/jfx/pull/924 From angorya at openjdk.org Tue Nov 8 18:17:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 18:17:42 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 17:36:18 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 765: >> >>> 763: double snappedPaddingY = child.snapPositionY(padding); >>> 764: >>> 765: assertEquals(snappedPaddingX, boundsInParent.getMinX(), 0.0001); >> >> EPSILON constant perhaps? > > Not sure if this is worth it for just 2 occurrences. In general I always try not to clutter the test class with things used in only one or two test methods. I see 6 occurrences only in this method ;-) ------------- PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Tue Nov 8 18:21:04 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Nov 2022 18:21:04 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v4] In-Reply-To: References: Message-ID: <4nUaGvpW5gcEdsxO0DR-njovNJBBgrWYfo9LtkJS9Fg=.cc9115c7-b066-4434-9cb1-e59ce9d8719a@github.com> On Tue, 8 Nov 2022 18:16:52 GMT, Johan Vos wrote: >> The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. >> The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. >> I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments. Use Math.round() instead of Math.floor() for coordinates Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/924 From angorya at openjdk.org Tue Nov 8 18:27:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 18:27:37 GMT Subject: RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors [v4] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 18:16:52 GMT, Johan Vos wrote: >> The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. >> The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. >> I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments. Use Math.round() instead of Math.floor() for coordinates Marked as reviewed by angorya (Author). ------------- PR: https://git.openjdk.org/jfx/pull/924 From mhanl at openjdk.org Tue Nov 8 18:30:30 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 18:30:30 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 18:13:59 GMT, Andy Goryachev wrote: >> Not sure if this is worth it for just 2 occurrences. In general I always try not to clutter the test class with things used in only one or two test methods. > > I see 6 occurrences only in this method ;-) ok :D still not sure if it is worth it for just one test. ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Tue Nov 8 18:41:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 18:41:30 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports Changes requested by angorya (Author). modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 364: > 362: } > 363: > 364: child.resizeRelocate(x, y, w, h); snapping should be done at this moment, I think, something like this: child.resizeRelocate( snapPositionX(x), snapPositionY(y), snapSizeX(w), snapSizeY(h)); and keep the original (unsnapped) code prior to this. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 742: > 740: StackPane child = new StackPane(); > 741: AnchorPane anchorpane = new AnchorPane(child); > 742: anchorpane.setStyle("-fx-padding: " + padding + "px;"); There might be two cases: when snapToPixel=true (this is the default case), and when =false. Should we test the case snapToPixel=false? ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Tue Nov 8 18:41:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 18:41:31 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 17:39:27 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 353: >> >>> 351: >>> 352: if (leftAnchor != null) { >>> 353: x = snappedLeftInset() + leftAnchor; >> >> Question: should we use unsnapped coordinates in the computations, and only snap at the final stage? >> >> For example, if leftAnchor is 0.5 the child will be positioned between the pixels, so to speak. >> >> Or is this indeed an intended functionality? > > Not 100% sure about this. It sounds somewhat logical. If we set the left anchor to be 5. Do we expect it to be 10 with a render scale of 2 -> 200% resolution? Not sure about render scale - it should be done elsewhere. As for snapping, I think this code might be incorrect - it should honor Region.snapToPixel setting. All the intermediary computations need to use unsnapped (original) values, then, at the last moment, call proper Region.snap*() which either rounds or not, depending on the `snapToPixel`. The only exception for this rule (of using snapped values in the intermediary computations) is to ensure some kind of specific alignment, which I believe is not the case here. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Tue Nov 8 20:32:52 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 20:32:52 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 18:31:33 GMT, Andy Goryachev wrote: >> Not 100% sure about this. It sounds somewhat logical. If we set the left anchor to be 5. Do we expect it to be 10 with a render scale of 2 -> 200% resolution? > > Not sure about render scale - it should be done elsewhere. > > As for snapping, I think this code might be incorrect - it should honor Region.snapToPixel setting. All the intermediary computations need to use unsnapped (original) values, then, at the last moment, call proper Region.snap*() which either rounds or not, depending on the `snapToPixel`. > > The only exception for this rule (of using snapped values in the intermediary computations) is to ensure some kind of specific alignment, which I believe is not the case here. I'm not sure about this. Other places do the same, and there are lot of places actually which do something like `snappedLeftInsets` + `snappedRightInsets` or `final double w = snapSizeX(getWidth()) - x - snappedRightInset();` or similar. I think this was for a reason. And I have only oriented myself to the existing code in this case. If you are right, then this was done wrong everywhere. Btw. I had a look and other container do snap their constraints, e.g. `H/VBox` its spacing, `GridPane` his `H/VGap`. So pretty sure we also should snap the anchor values. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Tue Nov 8 20:32:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 20:32:53 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: <_g6NZ8t3eRagR7xgAmW3L-CDkptMLudcyJniqW0rse4=.a8f282eb-dc48-468d-adf7-32f9ca1a37b9@github.com> On Tue, 8 Nov 2022 18:37:16 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java line 742: > >> 740: StackPane child = new StackPane(); >> 741: AnchorPane anchorpane = new AnchorPane(child); >> 742: anchorpane.setStyle("-fx-padding: " + padding + "px;"); > > There might be two cases: when snapToPixel=true (this is the default case), and when =false. Should we test the case snapToPixel=false? We can, but that should do the same as before. As before the values were not snapped at all. And that worked, I guess ? ------------- PR: https://git.openjdk.org/jfx/pull/910 From thiago.sayao at gmail.com Tue Nov 8 20:36:25 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 8 Nov 2022 17:36:25 -0300 Subject: JavaFX @ JavaOne 2022 In-Reply-To: References: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> Message-ID: I'm interested in watching the recording. All I found is young Kevin :) https://www.youtube.com/watch?v=B5EhaFSo8W0 Em ter., 1 de nov. de 2022 ?s 22:02, Philip Race escreveu: > > Very nice! Was the technical session recorded? > > In theory, yes, but we are still waiting to see to be sure since so far > only key notes have been posted. > > My understanding is that if works out it'll be on the java dev-rel youtube > channel > > phil. > > On 11/1/22 5:50 PM, Nir Lisker wrote: > > Very nice! Was the technical session recorded? Were there any interesting > questions in the Q&A? > > On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> JavaOne 2022 was the week of Oct 17-20, and there were two sessions of >> interest to JavaFX: >> >> * During the technical keynote [1], I announced that Oracle would start >> delivering JavaFX builds, beginning with JavaFX 20 early access, on >> jdk.java.net [2][3]. >> >> * I gave a technical session titled "JavaFX 19 and Beyond". You can >> download the presentation [4]. >> >> Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX. >> >> -- Kevin >> >> [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ >> [2] https://inside.java/2022/10/20/javafx-early-access-builds/ >> [3] https://jdk.java.net/javafx20/ >> [4] >> >> http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf >> [5] https://inside.java/podcast/ >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Tue Nov 8 20:40:37 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 8 Nov 2022 20:40:37 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> Message-ID: On Mon, 7 Nov 2022 20:13:18 GMT, Andy Goryachev wrote: >> 1. Yes. We may want to create something like an 'epic'. I see that in the past it was called an 'umbrella issue' >> 2. Yeah we should, but the goal of this PR is to test all layout container, specified in `javafx.scene.layout`. >> >> Other nodes needs more special test cases, e.g. can't be solved in a generic test. `Control` nodes are also mostly fine since the `layoutChildren` method in the `SkinBase` will receive the already snapped insets (so it is harder to do the wrong thing). > > could you please create an umbrella ticket listing all the types that need to be added to the test and/or fixed? > > here is an example of such ticket (with an umbrella unicode): > [JDK-8241364](https://bugs.openjdk.org/browse/JDK-8241364) created https://bugs.openjdk.org/browse/JDK-8296609 ------------- PR: https://git.openjdk.org/jfx/pull/936 From thiago.sayao at gmail.com Tue Nov 8 20:45:20 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 8 Nov 2022 17:45:20 -0300 Subject: JavaFX @ JavaOne 2022 In-Reply-To: References: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> Message-ID: Found it: https://www.youtube.com/watch?v=4hUbmI0nplU Em ter., 8 de nov. de 2022 ?s 17:36, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > I'm interested in watching the recording. > > All I found is young Kevin :) > https://www.youtube.com/watch?v=B5EhaFSo8W0 > > > > Em ter., 1 de nov. de 2022 ?s 22:02, Philip Race > escreveu: > >> > Very nice! Was the technical session recorded? >> >> In theory, yes, but we are still waiting to see to be sure since so far >> only key notes have been posted. >> >> My understanding is that if works out it'll be on the java dev-rel >> youtube channel >> >> phil. >> >> On 11/1/22 5:50 PM, Nir Lisker wrote: >> >> Very nice! Was the technical session recorded? Were there any interesting >> questions in the Q&A? >> >> On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> JavaOne 2022 was the week of Oct 17-20, and there were two sessions of >>> interest to JavaFX: >>> >>> * During the technical keynote [1], I announced that Oracle would start >>> delivering JavaFX builds, beginning with JavaFX 20 early access, on >>> jdk.java.net [2][3]. >>> >>> * I gave a technical session titled "JavaFX 19 and Beyond". You can >>> download the presentation [4]. >>> >>> Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX. >>> >>> -- Kevin >>> >>> [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ >>> [2] https://inside.java/2022/10/20/javafx-early-access-builds/ >>> [3] https://jdk.java.net/javafx20/ >>> [4] >>> >>> http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf >>> [5] https://inside.java/podcast/ >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Nov 8 21:03:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 8 Nov 2022 21:03:34 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 20:29:40 GMT, Marius Hanl wrote: >> Not sure about render scale - it should be done elsewhere. >> >> As for snapping, I think this code might be incorrect - it should honor Region.snapToPixel setting. All the intermediary computations need to use unsnapped (original) values, then, at the last moment, call proper Region.snap*() which either rounds or not, depending on the `snapToPixel`. >> >> The only exception for this rule (of using snapped values in the intermediary computations) is to ensure some kind of specific alignment, which I believe is not the case here. > > I'm not sure about this. Other places do the same, and there are lot of places actually which do something like `snappedLeftInsets` + `snappedRightInsets` or `final double w = snapSizeX(getWidth()) - x - snappedRightInset();` or similar. > I think this was for a reason. > And I have only oriented myself to the existing code in this case. If you are right, then this was done wrong everywhere. > > Btw. I had a look and other container do snap their constraints, e.g. `H/VBox` its spacing, `GridPane` his `H/VGap`. So pretty sure we also should snap the anchor values. I think the idea is this (and it only applies when snapToPixels=true). We only need to use snapped coordinates/sizes when placing components. In order to avoid accumulating errors, which can be seen during gradual resizing for example, we should avoid snapping of intermediary results, UNLESS there is a possibility of introducing visual artifacts. What I mean by this is imagine a container that aligns its children in a table-like layout (similar to https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md). Depending on constraints, there might be a situation where rounding might shift certain children in relation to the vertical guide lines - we don't want that. So in this case we need to snap the guide lines as an intermediate step (i.e. compute the first guide line position, then compute the next column, snap, next column, etc.) Whereas in a simple case (one child node), we can simply use snapped*Inset() - we don't have intermediate computations. In the case of AnchorPane, I think, we should first sum insets and anchor, then snap - because developers might want to use or not to use snapToPixels, and might set a fractional anchor. ------------- PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Tue Nov 8 21:17:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Nov 2022 21:17:19 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 21:00:00 GMT, Andy Goryachev wrote: >> I'm not sure about this. Other places do the same, and there are lot of places actually which do something like `snappedLeftInsets` + `snappedRightInsets` or `final double w = snapSizeX(getWidth()) - x - snappedRightInset();` or similar. >> I think this was for a reason. >> And I have only oriented myself to the existing code in this case. If you are right, then this was done wrong everywhere. >> >> Btw. I had a look and other container do snap their constraints, e.g. `H/VBox` its spacing, `GridPane` his `H/VGap`. So pretty sure we also should snap the anchor values. > > I think the idea is this (and it only applies when snapToPixels=true). We only need to use snapped coordinates/sizes when placing components. In order to avoid accumulating errors, which can be seen during gradual resizing for example, we should avoid snapping of intermediary results, UNLESS there is a possibility of introducing visual artifacts. > > What I mean by this is imagine a container that aligns its children in a table-like layout (similar to https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md). Depending on constraints, there might be a situation where rounding might shift certain children in relation to the vertical guide lines - we don't want that. > > So in this case we need to snap the guide lines as an intermediate step (i.e. compute the first guide line position, then compute the next column, snap, next column, etc.) > > Whereas in a simple case (one child node), we can simply use snapped*Inset() - we don't have intermediate computations. > > In the case of AnchorPane, I think, we should first sum insets and anchor, then snap - because developers might want to use or not to use snapToPixels, and might set a fractional anchor. I initially had the same thought that Andy had, but I want to take a closer look -- especially at what similar layout panes do. As for the point about doing this only when `snapPixels == true`, yes, but you don't need to worry about that if you call the `snapXXX` methods in Region. All of them check the `snapToPixel` attribute. ------------- PR: https://git.openjdk.org/jfx/pull/910 From kevin.rushforth at oracle.com Tue Nov 8 23:50:31 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 8 Nov 2022 15:50:31 -0800 Subject: JavaFX @ JavaOne 2022 In-Reply-To: References: <8cbae4e4-5785-87a2-b1ea-f0b3abcf74a5@oracle.com> Message-ID: <4164270b-4b76-d501-e5e0-fa703350e668@oracle.com> That's the "Future of Java is You" community keynote linked in footnote [1]. As far as I know, the JavaFX 19 and Beyond talk isn't available yet. -- Kevin On 11/8/2022 12:45 PM, Thiago Milczarek Say?o wrote: > Found it: > https://www.youtube.com/watch?v=4hUbmI0nplU > > Em ter., 8 de nov. de 2022 ?s 17:36, Thiago Milczarek Say?o > escreveu: > > I'm interested in watching the recording. > > All I found is young Kevin :) > https://www.youtube.com/watch?v=B5EhaFSo8W0 > > > > Em ter., 1 de nov. de 2022 ?s 22:02, Philip Race > escreveu: > > > Very nice! Was the technical session recorded? > > In theory, yes, but we are still waiting to see to be sure > since so far only key notes have been posted. > > My understanding is that if works out it'll be on the java > dev-rel youtube channel > > phil. > > On 11/1/22 5:50 PM, Nir Lisker wrote: >> Very nice! Was the technical session recorded? Were there any >> interesting questions in the Q&A? >> >> On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth >> wrote: >> >> JavaOne 2022 was the week of Oct 17-20, and there were >> two sessions of >> interest to JavaFX: >> >> * During the technical keynote [1], I announced that >> Oracle would start >> delivering JavaFX builds, beginning with JavaFX 20 early >> access, on >> jdk.java.net [2][3]. >> >> * I gave a technical session titled "JavaFX 19 and >> Beyond". You can >> download the presentation [4]. >> >> Stay tuned for an upcoming Inside Java [5] podcast >> covering JavaFX. >> >> -- Kevin >> >> [1] https://inside.java/2022/10/27/the-future-of-java-is-you/ >> [2] >> https://inside.java/2022/10/20/javafx-early-access-builds/ >> [3] https://jdk.java.net/javafx20/ >> [4] >> http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf >> [5] https://inside.java/podcast/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Nov 9 00:43:40 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 8 Nov 2022 21:43:40 -0300 Subject: requestFocus on setScene - is it right? In-Reply-To: <1a224872-f093-d35f-96bb-4b0d8acb3ad9@gmail.com> References: <1a224872-f093-d35f-96bb-4b0d8acb3ad9@gmail.com> Message-ID: I have opened a bug about this: https://bugs.openjdk.org/browse/JDK-8296621 On Linux scene changes cause focus stealing. -- Thiago. Em seg., 7 de nov. de 2022 ?s 13:19, John Hendrikx escreveu: > Sorry, I was confused which requestFocus you meant, I was looking at > Scene#requestFocus(Node). > > --John > On 07/11/2022 15:38, Thiago Milczarek Say?o wrote: > > It was a problem in the past gtk glass, but now it checks if visible to > request the focus. > > But, there are two situations: > > 1 - Most common - there is one Scene and it's created before the window is > shown. In this case, > there is no point to request focus; > > 2 - The scene has changed. Do we want to issue notifications or flash the > taskbar because the Scene has changed? > > If 2 is "no", then I think this line should be removed. > > If 2 is "yes", then I think we should have an API to request attention. > > Em seg., 7 de nov. de 2022 ?s 05:42, John Hendrikx < > john.hendrikx at gmail.com> escreveu: > >> On 07/11/2022 00:32, Thiago Milczarek Say?o wrote: >> > While working on native linux glass code I observed that >> > requestFocus() is called before show(). >> > If the window is not shown (mapped on Xorg), It can't be focused. >> Have you observed this to be a problem? I believe the actual focus >> acquisition is delayed. >> > >> > The code is on WindowStage.setScene() line 276. >> > >> > It might be the case when switching the scene, but should the window >> > be focused in that case? >> > >> > If the user is "focused" on another window and the program decides to >> > switch the scene the window would pop and steal the focus. >> >> Most window managers won't allow this, even if an application does >> request focus. Instead they'll indicate this in the task bar that a >> window wants the focus. >> >> Is this actually happening? >> >> --John >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Wed Nov 9 00:59:07 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 9 Nov 2022 00:59:07 GMT Subject: RFR: 8296621 - Stage steals focus on scene change Message-ID: Simple fix to not requestFocus() on scene change. The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. ------------- Commit messages: - 8296621 - Stage steals focus on scene change - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - ... and 13 more: https://git.openjdk.org/jfx/compare/35675c8d...c3252bd0 Changes: https://git.openjdk.org/jfx/pull/940/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296621 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From arapte at openjdk.org Wed Nov 9 09:31:46 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 9 Nov 2022 09:31:46 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:55:59 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Missed two :P Test looks good. Provided with two minor typo corrections and a question. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 48: > 46: /** > 47: * Tests the snapping of all container inside {@link javafx.scene.layout}. > 48: * Containers must always snap their width/height as well as there insets, otherwise the children may look blurry or minor typo: there insets -> their insets modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 142: > 140: static Stream> getContainerCreators() { > 141: // TODO: Create issues and fix snapping for all commented out layout containers below. > 142: // Note that the working layout container do not necessary use the optimized snappedXXXInsets() methods, minor typo: 1. container -> containers 2. necessary -> necessarily ------------- PR: https://git.openjdk.org/jfx/pull/936 From arapte at openjdk.org Wed Nov 9 09:31:46 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 9 Nov 2022 09:31:46 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> Message-ID: On Tue, 8 Nov 2022 20:38:33 GMT, Marius Hanl wrote: >> could you please create an umbrella ticket listing all the types that need to be added to the test and/or fixed? >> >> here is an example of such ticket (with an umbrella unicode): >> [JDK-8241364](https://bugs.openjdk.org/browse/JDK-8241364) > > created https://bugs.openjdk.org/browse/JDK-8296609 Should this list include the class `Region` and `FlowPane` too? I see these classes use non-snapped insets. ------------- PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Wed Nov 9 09:46:10 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 9 Nov 2022 09:46:10 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v5] In-Reply-To: References: Message-ID: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8296330: Fixed typos, improved javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/936/files - new: https://git.openjdk.org/jfx/pull/936/files/fa8bc1ba..8ce4d3bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=03-04 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Wed Nov 9 09:46:14 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 9 Nov 2022 09:46:14 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 14:26:53 GMT, Ambarish Rapte wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296330: Missed two :P > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 48: > >> 46: /** >> 47: * Tests the snapping of all container inside {@link javafx.scene.layout}. >> 48: * Containers must always snap their width/height as well as there insets, otherwise the children may look blurry or > > minor typo: there insets -> their insets thanks! fixed. > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 142: > >> 140: static Stream> getContainerCreators() { >> 141: // TODO: Create issues and fix snapping for all commented out layout containers below. >> 142: // Note that the working layout container do not necessary use the optimized snappedXXXInsets() methods, > > minor typo: > 1. container -> containers > 2. necessary -> necessarily thanks! fixed. ------------- PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Wed Nov 9 09:46:15 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 9 Nov 2022 09:46:15 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v2] In-Reply-To: References: <1e6wyHyw_1y4kpUZo66GFXsENgl0zZyo8xikjgfmKGk=.12b3a8e2-7b14-494c-887f-613114df524f@github.com> Message-ID: <0xDmcn7fj8-zkVSHYj02FRRHsl6d-I8YaZg3nZPXE_I=.a8ee97b1-4097-4a1e-8d1a-f212ccc76896@github.com> On Wed, 9 Nov 2022 09:28:45 GMT, Ambarish Rapte wrote: >> created https://bugs.openjdk.org/browse/JDK-8296609 > > Should this list include the class `Region` and `FlowPane` too? I see these classes use non-snapped insets. `FlowPane` is included (the last line). We don't need `Region`, as `Pane` directly extends from it without further modification. Thats why I decided to include only `Pane`. :) ------------- PR: https://git.openjdk.org/jfx/pull/936 From arapte at openjdk.org Wed Nov 9 10:12:36 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 9 Nov 2022 10:12:36 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v5] In-Reply-To: References: Message-ID: <14MHDy7iUMCErDVP-nICBFR3jQ5ZbKcDI3dVPpvc_lc=.7464095d-bbb4-4b90-a1c4-196d149e7d77@github.com> On Wed, 9 Nov 2022 09:46:10 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Fixed typos, improved javadoc LGTM ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/936 From duke at openjdk.org Wed Nov 9 10:14:40 2022 From: duke at openjdk.org (pandaapo) Date: Wed, 9 Nov 2022 10:14:40 GMT Subject: RFR: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed Message-ID: Fixes [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) ------------- Commit messages: - Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed. Changes: https://git.openjdk.org/jfx/pull/942/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296618 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/942.diff Fetch: git fetch https://git.openjdk.org/jfx pull/942/head:pull/942 PR: https://git.openjdk.org/jfx/pull/942 From thiago.sayao at gmail.com Wed Nov 9 12:35:26 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 9 Nov 2022 09:35:26 -0300 Subject: Help testing 8260528 / PR #915 In-Reply-To: <4hiljo4kc9.fsf@qfs.de> References: <4hiljo4kc9.fsf@qfs.de> Message-ID: Thanks Gregor! Em qua., 9 de nov. de 2022 ?s 05:12, Gregor Schmid escreveu: > > Hi Thiago, > > of course, gladly. It just took me a while to remember how to fetch > the PR and build it :-). > > I ran our entire JavaFX suite against a build of your PR on an Ubuntu > 22.4 machine. Everything fine! > > Best regards, > Greg > > Thiago Milczarek Say?o writes: > > > Hi Gregor, > > > > Last time you helped with testing. > > I have improved the PR in: > > https://github.com/openjdk/jfx/pull/915 > > > > I think it's ready to be tested. > > > > Would you help testing it? > > > > Thanks. > > -- > Gregor Schmid > > E: gregor.schmid at qfs.de > T: +49 8171 38648-11 > F: +49 8171 38648-16 > > Quality First Software GmbH | www.qfs.de > B?rgermeister-Graf-Ring 10 | 82538 Geretsried | Germany > GF Gregor Schmid, Karlheinz Kellerer > HRB M?nchen 140833 > > The data protection information in accordance with the EU General Data > Protection Regulation applies to authorized representatives / > authorized representatives of "legal persons" in accordance with Art. > 12 ff. DS-GVO > https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Nov 9 14:00:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 14:00:09 GMT Subject: RFR: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:08:28 GMT, pandaapo wrote: > Fixes [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) Thank you for your offer to contribute. It might be somewhat premature, since we are still looking into whether the test can be fixed soon (in which case we would not want to skip it). See [JDK-8285503](https://bugs.openjdk.org/browse/JDK-8285503). We can leave this PR open until we know one way or the other. ------------- PR: https://git.openjdk.org/jfx/pull/942 From kcr at openjdk.org Wed Nov 9 15:00:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 15:00:13 GMT Subject: RFR: 8296592: Skip failing test StraightLineTest on Linux Message-ID: Skip `StraightLineTest` on Linux until [JDK-8296590](https://bugs.openjdk.org/browse/JDK-8296590) is fixed. ------------- Commit messages: - 8296592: Skip failing test StraightLineTest on Linux Changes: https://git.openjdk.org/jfx/pull/943/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296592 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/943.diff Fetch: git fetch https://git.openjdk.org/jfx pull/943/head:pull/943 PR: https://git.openjdk.org/jfx/pull/943 From angorya at openjdk.org Wed Nov 9 15:57:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 15:57:42 GMT Subject: RFR: 8296592: Skip failing test StraightLineTest on Linux In-Reply-To: References: Message-ID: <7YmEdtZYJFzHv-z21AwWLuzExoZIIguqkXcer5DErGg=.6cd09957-b590-42af-a575-400b7ab2d89e@github.com> On Wed, 9 Nov 2022 14:33:37 GMT, Kevin Rushforth wrote: > Skip `StraightLineTest` on Linux until [JDK-8296590](https://bugs.openjdk.org/browse/JDK-8296590) is fixed. Marked as reviewed by angorya (Author). ------------- PR: https://git.openjdk.org/jfx/pull/943 From angorya at openjdk.org Wed Nov 9 16:08:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 16:08:38 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v5] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:46:10 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Fixed typos, improved javadoc modules/javafx.graphics/src/test/java/test/javafx/scene/layout/SnappingTest.java line 144: > 142: > 143: static Stream> getContainerCreators() { > 144: // TODO: Create issues and fix snapping for all commented out layout containers below. should we refer to the ticket you've created? JDK-8296609, right? ------------- PR: https://git.openjdk.org/jfx/pull/936 From arapte at openjdk.org Wed Nov 9 16:41:33 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 9 Nov 2022 16:41:33 GMT Subject: RFR: 8296592: Skip failing test StraightLineTest on Linux In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 14:33:37 GMT, Kevin Rushforth wrote: > Skip `StraightLineTest` on Linux until [JDK-8296590](https://bugs.openjdk.org/browse/JDK-8296590) is fixed. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/943 From angorya at openjdk.org Wed Nov 9 18:10:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 18:10:06 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Wed, 9 Nov 2022 18:00:31 GMT, Lukasz Kostyra wrote: > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: > 187: > 188: private void compareColor(Color exp, Color act) { > 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); I am curious: what is the source of these differences? Is it color model (and could we explicitly set the CM?) Or is it differences in anti-aliasing or some such? ------------- PR: https://git.openjdk.org/jfx/pull/944 From duke at openjdk.org Wed Nov 9 18:10:04 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Wed, 9 Nov 2022 18:10:04 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems Message-ID: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Issue happening on some hardware due to slightly different pixel values being returned. Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). ------------- Commit messages: - 8296589: PixelBufferDrawTest fails on some systems Changes: https://git.openjdk.org/jfx/pull/944/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=944&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296589 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/944.diff Fetch: git fetch https://git.openjdk.org/jfx pull/944/head:pull/944 PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Wed Nov 9 18:25:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 18:25:49 GMT Subject: Integrated: 8296592: Skip failing test StraightLineTest on Linux In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 14:33:37 GMT, Kevin Rushforth wrote: > Skip `StraightLineTest` on Linux until [JDK-8296590](https://bugs.openjdk.org/browse/JDK-8296590) is fixed. This pull request has now been integrated. Changeset: 706261bb Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/706261bb3bc23af214d9e6f4ae429cb47c0fba0d Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8296592: Skip failing test StraightLineTest on Linux Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/943 From kcr at openjdk.org Wed Nov 9 18:32:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 18:32:37 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: <9V1cDFizl5LTR60T97E5BpN7feE5P7NyNoF4KWQn5So=.7788c7f6-7d6f-4d8e-a8f7-feeec1c9e1dd@github.com> On Wed, 9 Nov 2022 18:05:22 GMT, Andy Goryachev wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: > >> 187: >> 188: private void compareColor(Color exp, Color act) { >> 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); > > I am curious: what is the source of these differences? > Is it color model (and could we explicitly set the CM?) > Or is it differences in anti-aliasing or some such? It's a good question, but I note that any number of things can cause such differences on some systems. As I mentioned in the bug report, most of our robot-based tests use `0.07` as a tolerance value. The idea being that these tests aren't trying to check whether the rendering is pixel perfect or that the shaders, etc., produce an exact value. They are just checking whether the pixel is red versus green versus orange, etc. ------------- PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Wed Nov 9 18:41:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 18:41:54 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Wed, 9 Nov 2022 18:00:31 GMT, Lukasz Kostyra wrote: > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). I confirm that the updated test passes on my Mac M1 system (the existing version fails always). tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: > 187: > 188: private void compareColor(Color exp, Color act) { > 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); Since the tolerance value is used 4 times, maybe consider using a variable? Since this is preexisting, I'll approve it anyway and leave it up to you as to whether to change it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/944 From angorya at openjdk.org Wed Nov 9 19:16:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 19:16:49 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Wed, 9 Nov 2022 18:38:27 GMT, Kevin Rushforth wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: > >> 187: >> 188: private void compareColor(Color exp, Color act) { >> 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); > > Since the tolerance value is used 4 times, maybe consider using a variable? Since this is preexisting, I'll approve it anyway and leave it up to you as to whether to change it. Since someone initially chose a value w/o justification, perhaps we should create a constant and describe it (using Kevin's comment as a starting point). ------------- PR: https://git.openjdk.org/jfx/pull/944 From angorya at openjdk.org Wed Nov 9 19:31:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 9 Nov 2022 19:31:46 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: <_SFkOITAG4qcSmM12jVt6VJSwJs7BC4pNUxEfr_I0gw=.2115c5f4-ba78-48fe-9e2a-da93d380bcd3@github.com> On Tue, 8 Nov 2022 10:07:54 GMT, Dean Wookey wrote: >> The code in ControlAcceleratorSupport adds its own scene listeners for each node added. MenuButtonSkinBase does the same, unlike Control which only calls it once. >> >> I think we could fix it in ControlAcceleratorSupport alternatively or in addition to this fix. The code in ControlAcceleratorSupport appears to do everything this would've done. >> >> I've added the test for changing scenes. > > Here is an alternative fix: https://github.com/openjdk/jfx/commit/80971d89c46f3f74cb8584d4907cc6818809e2f6 > I just reverted the MenuButtonSkinBase changes. The tests pass with this fix, or with both. > > I'm a little more nervous about that one because I had to remove the code that removed and then added a scene listener. I'm not sure why it was done because the listener is independent of a specific scene. > > Basically, that fix only does the install if the install wasn't already done on that anchor meaning it can get called any number of times safely stopping duplicate accelerators being added. > > I would go with either both fixes together, or just the MenuButtonSkinBase one. please forgive me - it might take me a bit longer to review. ------------- PR: https://git.openjdk.org/jfx/pull/937 From kcr at openjdk.org Wed Nov 9 19:38:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 19:38:38 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports Not a complete review, but I did leave some inline comments. I note that there is precedent for using the snapped insets in intermediate computations, so that part of the change seems OK to me. If that is going to be the pattern, you need to make sure that you are snapping the values you add to the snapped insets. I'd like @arapte to take a closer look as well. modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 283: > 281: } > 282: > 283: return snappedLeftInset() + max + snappedRightInset(); Have you verified that `max` ends up as a snapped value in all cases? Some of the values that are used in the computation of max clearly are snapped, such as `computeChildPrefAreaWidth` (which is a method in the Region superclass that returns a snapped result), but others might not be. ------------- PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Wed Nov 9 19:38:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 19:38:38 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Tue, 8 Nov 2022 21:13:27 GMT, Kevin Rushforth wrote: >> I think the idea is this (and it only applies when snapToPixels=true). We only need to use snapped coordinates/sizes when placing components. In order to avoid accumulating errors, which can be seen during gradual resizing for example, we should avoid snapping of intermediary results, UNLESS there is a possibility of introducing visual artifacts. >> >> What I mean by this is imagine a container that aligns its children in a table-like layout (similar to https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md). Depending on constraints, there might be a situation where rounding might shift certain children in relation to the vertical guide lines - we don't want that. >> >> So in this case we need to snap the guide lines as an intermediate step (i.e. compute the first guide line position, then compute the next column, snap, next column, etc.) >> >> Whereas in a simple case (one child node), we can simply use snapped*Inset() - we don't have intermediate computations. >> >> In the case of AnchorPane, I think, we should first sum insets and anchor, then snap - because developers might want to use or not to use snapToPixels, and might set a fractional anchor. > > I initially had the same thought that Andy had, but I want to take a closer look -- especially at what similar layout panes do. > > As for the point about doing this only when `snapPixels == true`, yes, but you don't need to worry about that if you call the `snapXXX` methods in Region. All of them check the `snapToPixel` attribute. I looked at the other layout panes and they already do something similar to what this PR does, using the snapped insets for intermediate compuation. I also note that some of the computation is calling superclass methods that do snapping already, and expect it to be added to snapped insets (if there are insets), for example, `computeWidth()`. In this particular case -- `snappedLeftInset() + leftAnchor` -- I don't think `leftAnchor` is snapped, but it probably should be. ------------- PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Wed Nov 9 19:38:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 19:38:38 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 18:34:09 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 364: > >> 362: } >> 363: >> 364: child.resizeRelocate(x, y, w, h); > > snapping should be done at this moment, I think, something like this: > > child.resizeRelocate( > snapPositionX(x), > snapPositionY(y), > snapSizeX(w), > snapSizeY(h)); > > and keep the original (unsnapped) code prior to this. It depends (see earlier discussion), but if we are going to snap the intermediate results, we need to be sure we are doing it consistently -- adding snapped insets to an unsnapped value is very likely the wrong thing to do. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mstrauss at openjdk.org Wed Nov 9 22:30:43 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:43 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept Message-ID: This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. ### New APIs in `javafx.graphics` The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. #### 1. StyleTheme A style theme is an implementation of the `javafx.css.StyleTheme` interface: /** * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all * JavaFX nodes in the scene graph. *

* The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, * enabling applications to create dynamic themes that respond to changing user preferences. *

* In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. */ public interface StyleTheme { /** * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. *

* If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list * change notifications. * * @implNote Implementations of this method that return an {@link ObservableList} are encouraged * to minimize the number of subsequent list change notifications that are fired by the * list, as each change notification causes the CSS subsystem to re-apply the referenced * stylesheets. */ List getStylesheets(); } A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): public class Application { ... /** * Specifies the user-agent stylesheet of the application. *

* A user-agent stylesheet is a global stylesheet that can be specified in addition to a * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. * It can be used to provide default styling for UI controls and other nodes. * A user-agent stylesheets has the lowest precedence in the CSS cascade. *

* Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} * property to a new instance of the corresponding theme class. *

* Note: this property must only be modified on the JavaFX application thread. */ public static StringProperty userAgentStylesheetProperty(); public static String getUserAgentStylesheet(); public static void setUserAgentStylesheet(String url); /** * Specifies the {@link StyleTheme} of the application. *

* {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the * scene graph. *

* Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. *

* Note: this property must only be modified on the JavaFX application thread. */ public static ObjectProperty styleThemeProperty(); public static StyleTheme getStyleTheme(); public static void setStyleTheme(StyleTheme theme); ... } `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. #### 2. PlatformPreferences `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: /** * Contains UI preferences of the current platform. *

* {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed * alternatives to the untyped {@link #get} method. *

* The preferences that are reported by the platform may be dependent on the operating system version. * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback * value if the preference is not available. */ public interface PlatformPreferences extends Map { String getString(String key); String getString(String key, String fallbackValue); Boolean getBoolean(String key); boolean getBoolean(String key, boolean fallbackValue); Color getColor(String key); Color getColor(String key, Color fallbackValue); void addListener(PlatformPreferencesListener listener); void removeListener(PlatformPreferencesListener listener); } An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. ### Usage In its simplest form, a style theme is just a static collection of stylesheets: Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); A dynamic theme can be created by returning an instance of `ObservableList`: public class MyCustomTheme implements StyleTheme { private final ObservableList stylesheets = FXCollections.observableArrayList("colors-light.css", "controls.css"); @Override public List getStylesheets() { return stylesheets; } public void setDarkMode(boolean enabled) { stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); } } `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: Application.setStyleTheme(new ModenaTheme() { { addFirst("stylesheet1.css"); addLast("stylesheet2.css"); } }); ------------- Commit messages: - Removed unrelated code from ThemeBase - StyleTheme implementation Changes: https://git.openjdk.org/jfx/pull/511/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267546 Stats: 2971 lines in 40 files changed: 2596 ins; 227 del; 148 mod Patch: https://git.openjdk.org/jfx/pull/511.diff Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511 PR: https://git.openjdk.org/jfx/pull/511 From duke at openjdk.org Wed Nov 9 22:30:43 2022 From: duke at openjdk.org (Mike Hearn) Date: Wed, 9 Nov 2022 22:30:43 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Looks great! I read through the code and nothing wrong jumped out - all the obvious missing parts were already raised on the mailing list and reasonable arguments provided for why it's about reducing maintenance costs. The only thing that seemed odd is the way you set a theme by providing a special string syntax+class name as a "stylesheet". Is there some reason a more direct API cannot be added instead, where you pass the actual `Class` constant instead, or simply construct the theme object yourself? Also the `Theme` interface looks suspiciously like an SPI. Rather than use a special pseudo-URI that devs would have to fish out of the theme's documentation to trigger loading, it might be better to use `ServiceLoader` to locate themes and then have some notion of priority, such that simply adding a theme module to your modulepath would automatically cause it to override the platform defaults. This would allow apps to take the next obvious step and allow themes to be plugins. As is this API wouldn't support it out of the box, because the app would have no way to know what the class name of the theme actually is, so a bunch of ad-hoc mechanisms would emerge to fill that gap. It seems Kevin wanted some more info on cost/benefit analysis on the mailing list, but it's a little unclear what sort of analysis or evidence would be wanted. I'll say that JavaFX apps I've written in the past would definitely have benefited from this. My CSS files always ended up being a mishmash of patches to Modena and actual app-specific styling. Additionally, whilst various JavaFX theme libraries exist and are popular, you normally have to do some manual integration work to use them which is a pity given that theming is, ultimately, entirely subjective and users frequently enjoy theming apps they work with a lot. I'll also say that the whole JavaFX theming system was a point of confusion for me when I first learned the API. It clearly *does* support themes, yet there's no actual API point called "theme" anywhere and exactly how themes, CSS and so on relate isn't obvious. So this PR has a learning and usability benefit too. Conclusion: to me the code looks really quite small, the benefits large (as most "real" JavaFX apps don't simply use Modena as-is), and it is at any rate mostly a refactoring and exposure of far more complex machinery already in the toolkit. Thumbs up! modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 93: > 91: > 92: FnRtlGetVersion* pRtlGetVersion; > 93: if (!loadFunction(hLibNtdll, pRtlGetVersion, "RtlGetVersion")) { Is this really the right way to get the Windows version these days? It used to be that everything in NTDLL was off limits. Seems there's an API now for detecting if you're on Windows 8+: https://docs.microsoft.com/en-us/windows/win32/sysinfo/version-helper-apis modules/javafx.graphics/src/test/java/test/javafx/application/ThemeTest.java line 16: > 14: public class ThemeTest { > 15: > 16: public static class PublicConstructor implements Theme { Rather than support varying constructor types to pass in the properties map, why not just specify the API as that platformThemeChanged will be called immediately after construction? That way there's only one code path that handles the properties map, and the way the class is constructed no longer matters. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:43 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:43 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: <_lMkq8y-yZqiFEcuEewVgz_JnNjmkawIVyJmELktTOs=.ce5c564b-8924-49d1-b04e-09a248f84932@github.com> On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Here's an update on the current state of this feature. The API has evolved a bit to offer more flexibility, and can be used in several different ways: ### 1. Ad-hoc themes An ad-hoc theme is a way to programmatically tie together a bunch of stylesheets with very little effort: var theme = Theme.of("stylesheet1.css", "stylesheet2.css"); Similarly, existing themes can be extended with additional stylesheets. The stylesheet order is retained such that base stylesheets always come before extension stylesheets, even if the list of base stylesheets changes. var theme = Theme.extensionOf(new ModenaTheme(), "stylesheet1.css", "stylesheet2.css"); ### 2. Theme classes When more control is desired, a theme can be implemented by extending the `Theme` class. In this example, a custom theme toggles a high-contrast stylesheet: public class MyTheme extends Theme { private final ObservableList stylesheets = FXCollections.observableArrayList(); public MyTheme() { stylesheets.add("stylesheet1.css"); platformThemeChanged(getPlatformThemeProperties()); } @Override public ObservableList getStylesheets() { return stylesheets; } @Override protected void platformThemeChanged(Map properties) { String value = properties.get("Windows.SPI_HighContrastOn"); if (value != null) { if (Boolean.parseBoolean(value)) { stylesheets.add("highconstrast.css"); } else { stylesheets.remove("highconstrast.css"); } } } } Similarly, an existing theme class can be extended by subclassing: public class MyTheme extends ModenaTheme { // concat existing stylesheets with new stylesheets, react to platform changes, etc. } ### 3. Usage Themes are collections of user-agent stylesheets, and as such, they can be used in all places where user-agent stylesheets can be used (that's in `Application`, `Scene` and `SubScene`). Themes, like user-agent stylesheets, must be specified with a URL to be able to use them with the existing `setUserAgentStylesheet(String)` APIs. There are three ways to specify a theme: #### 3.1. Class URLs The easiest option to reference a theme class is with the `theme` scheme: Application.setUserAgentStylesheet("theme:com.example.MyTheme"); The `theme` scheme works when the theme class is instantiable with a parameterless constructor. #### 3.2. Instance URLs Ad-hoc themes, or theme classes that require custom instantiation, can be referenced by their instance URL: var theme = Theme.of("stylesheet1.css", "stylesheet2.css"); Application.setUserAgentStylesheet(theme.toURL()); The URL returned by `Theme.toURL()` can be dereferenced as long as the theme instance is alive. It is not required to keep a reference to the theme instance around after `setUserAgentStylesheet` has been called, as the theming subsystem will keep the theme instance alive. #### 3.3. Legacy names Backwards compatibility is preserved by interpreting the names `CASPIAN` and `MODENA` as aliases for their corresponding theme class. Since themes can be used with all user-agent stylesheet APIs, we can now also use different themes in the same application: ------------- PR: https://git.openjdk.org/jfx/pull/511 From duke at openjdk.org Wed Nov 9 22:30:44 2022 From: duke at openjdk.org (airsquared) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Are there any plans for this to be merged or is there any work remaining for this? I'd love to use this instead of what I'm currently doing which is accessing private API in JavaFX with `--add-exports`. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:44 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 09:36:13 GMT, Mike Hearn wrote: >> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. >> >> ### New APIs in `javafx.graphics` >> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. >> #### 1. StyleTheme >> A style theme is an implementation of the `javafx.css.StyleTheme` interface: >> >> /** >> * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other >> * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all >> * JavaFX nodes in the scene graph. >> *

>> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, >> * enabling applications to create dynamic themes that respond to changing user preferences. >> *

>> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as >> * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade >> * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. >> */ >> public interface StyleTheme { >> /** >> * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. >> *

>> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this >> * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list >> * change notifications. >> * >> * @implNote Implementations of this method that return an {@link ObservableList} are encouraged >> * to minimize the number of subsequent list change notifications that are fired by the >> * list, as each change notification causes the CSS subsystem to re-apply the referenced >> * stylesheets. >> */ >> List getStylesheets(); >> } >> >> >> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): >> >> public class Application { >> ... >> /** >> * Specifies the user-agent stylesheet of the application. >> *

>> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a >> * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. >> * It can be used to provide default styling for UI controls and other nodes. >> * A user-agent stylesheets has the lowest precedence in the CSS cascade. >> *

>> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants >> * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning >> * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} >> * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} >> * property to a new instance of the corresponding theme class. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static StringProperty userAgentStylesheetProperty(); >> public static String getUserAgentStylesheet(); >> public static void setUserAgentStylesheet(String url); >> >> /** >> * Specifies the {@link StyleTheme} of the application. >> *

>> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. >> * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the >> * scene graph. >> *

>> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a >> * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static ObjectProperty styleThemeProperty(); >> public static StyleTheme getStyleTheme(); >> public static void setStyleTheme(StyleTheme theme); >> ... >> } >> >> >> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. >> >> #### 2. PlatformPreferences >> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: >> >> /** >> * Contains UI preferences of the current platform. >> *

>> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. >> * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed >> * alternatives to the untyped {@link #get} method. >> *

>> * The preferences that are reported by the platform may be dependent on the operating system version. >> * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, >> * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback >> * value if the preference is not available. >> */ >> public interface PlatformPreferences extends Map { >> String getString(String key); >> String getString(String key, String fallbackValue); >> >> Boolean getBoolean(String key); >> boolean getBoolean(String key, boolean fallbackValue); >> >> Color getColor(String key); >> Color getColor(String key, Color fallbackValue); >> >> void addListener(PlatformPreferencesListener listener); >> void removeListener(PlatformPreferencesListener listener); >> } >> >> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. >> >> ### Usage >> In its simplest form, a style theme is just a static collection of stylesheets: >> >> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); >> >> A dynamic theme can be created by returning an instance of `ObservableList`: >> >> public class MyCustomTheme implements StyleTheme { >> private final ObservableList stylesheets = >> FXCollections.observableArrayList("colors-light.css", "controls.css"); >> >> @Override >> public List getStylesheets() { >> return stylesheets; >> } >> >> public void setDarkMode(boolean enabled) { >> stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); >> } >> } >> >> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: >> >> Application.setStyleTheme(new ModenaTheme() { >> { >> addFirst("stylesheet1.css"); >> addLast("stylesheet2.css"); >> } >> }); > > modules/javafx.graphics/src/main/native-glass/win/RoActivationSupport.cpp line 93: > >> 91: >> 92: FnRtlGetVersion* pRtlGetVersion; >> 93: if (!loadFunction(hLibNtdll, pRtlGetVersion, "RtlGetVersion")) { > > Is this really the right way to get the Windows version these days? It used to be that everything in NTDLL was off limits. Seems there's an API now for detecting if you're on Windows 8+: > > https://docs.microsoft.com/en-us/windows/win32/sysinfo/version-helper-apis Thanks, I'll look into that. > modules/javafx.graphics/src/test/java/test/javafx/application/ThemeTest.java line 16: > >> 14: public class ThemeTest { >> 15: >> 16: public static class PublicConstructor implements Theme { > > Rather than support varying constructor types to pass in the properties map, why not just specify the API as that platformThemeChanged will be called immediately after construction? That way there's only one code path that handles the properties map, and the way the class is constructed no longer matters. Yes, the constructor argument is gone. As an alternative, there's `Theme.getPlatformThemeProperties()`, which can safely be called in the constructor of a theme class. ------------- PR: https://git.openjdk.org/jfx/pull/511 From jpereda at openjdk.org Wed Nov 9 22:30:44 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); modules/javafx.graphics/src/main/native-glass/win/ThemeSupport.cpp line 44: > 42: } > 43: > 44: void ThemeSupport::queryHighContrastScheme(jobject properties) @mstr2 Do you think it is possible to use here `Windows.UI.ViewManagement.AccessibleSettings` instead, same as you do in `queryWindows10ThemeColors` with `Windows.UI.ViewManagement.UISettings`? I believe `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a not localised string for the high contrast scheme, and that would allow solving https://bugs.openjdk.java.net/browse/JDK-8185447. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:44 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 16:55:04 GMT, Jose Pereda wrote: >> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. >> >> ### New APIs in `javafx.graphics` >> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. >> #### 1. StyleTheme >> A style theme is an implementation of the `javafx.css.StyleTheme` interface: >> >> /** >> * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other >> * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all >> * JavaFX nodes in the scene graph. >> *

>> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, >> * enabling applications to create dynamic themes that respond to changing user preferences. >> *

>> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as >> * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade >> * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. >> */ >> public interface StyleTheme { >> /** >> * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. >> *

>> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this >> * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list >> * change notifications. >> * >> * @implNote Implementations of this method that return an {@link ObservableList} are encouraged >> * to minimize the number of subsequent list change notifications that are fired by the >> * list, as each change notification causes the CSS subsystem to re-apply the referenced >> * stylesheets. >> */ >> List getStylesheets(); >> } >> >> >> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): >> >> public class Application { >> ... >> /** >> * Specifies the user-agent stylesheet of the application. >> *

>> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a >> * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. >> * It can be used to provide default styling for UI controls and other nodes. >> * A user-agent stylesheets has the lowest precedence in the CSS cascade. >> *

>> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants >> * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning >> * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} >> * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} >> * property to a new instance of the corresponding theme class. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static StringProperty userAgentStylesheetProperty(); >> public static String getUserAgentStylesheet(); >> public static void setUserAgentStylesheet(String url); >> >> /** >> * Specifies the {@link StyleTheme} of the application. >> *

>> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. >> * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the >> * scene graph. >> *

>> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a >> * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static ObjectProperty styleThemeProperty(); >> public static StyleTheme getStyleTheme(); >> public static void setStyleTheme(StyleTheme theme); >> ... >> } >> >> >> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. >> >> #### 2. PlatformPreferences >> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: >> >> /** >> * Contains UI preferences of the current platform. >> *

>> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. >> * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed >> * alternatives to the untyped {@link #get} method. >> *

>> * The preferences that are reported by the platform may be dependent on the operating system version. >> * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, >> * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback >> * value if the preference is not available. >> */ >> public interface PlatformPreferences extends Map { >> String getString(String key); >> String getString(String key, String fallbackValue); >> >> Boolean getBoolean(String key); >> boolean getBoolean(String key, boolean fallbackValue); >> >> Color getColor(String key); >> Color getColor(String key, Color fallbackValue); >> >> void addListener(PlatformPreferencesListener listener); >> void removeListener(PlatformPreferencesListener listener); >> } >> >> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. >> >> ### Usage >> In its simplest form, a style theme is just a static collection of stylesheets: >> >> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); >> >> A dynamic theme can be created by returning an instance of `ObservableList`: >> >> public class MyCustomTheme implements StyleTheme { >> private final ObservableList stylesheets = >> FXCollections.observableArrayList("colors-light.css", "controls.css"); >> >> @Override >> public List getStylesheets() { >> return stylesheets; >> } >> >> public void setDarkMode(boolean enabled) { >> stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); >> } >> } >> >> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: >> >> Application.setStyleTheme(new ModenaTheme() { >> { >> addFirst("stylesheet1.css"); >> addLast("stylesheet2.css"); >> } >> }); > > modules/javafx.graphics/src/main/native-glass/win/ThemeSupport.cpp line 44: > >> 42: } >> 43: >> 44: void ThemeSupport::queryHighContrastScheme(jobject properties) > > @mstr2 Do you think it is possible to use here `Windows.UI.ViewManagement.AccessibleSettings` instead, same as you do in `queryWindows10ThemeColors` with `Windows.UI.ViewManagement.UISettings`? > > I believe `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a not localised string for the high contrast scheme, and that would allow solving https://bugs.openjdk.java.net/browse/JDK-8185447. I just checked on Windows 10 v20H2 (build 19042.985), and unfortunately the `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a localized name for the high contrast scheme. ------------- PR: https://git.openjdk.org/jfx/pull/511 From jpereda at openjdk.org Wed Nov 9 22:30:44 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:07:39 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/native-glass/win/ThemeSupport.cpp line 44: >> >>> 42: } >>> 43: >>> 44: void ThemeSupport::queryHighContrastScheme(jobject properties) >> >> @mstr2 Do you think it is possible to use here `Windows.UI.ViewManagement.AccessibleSettings` instead, same as you do in `queryWindows10ThemeColors` with `Windows.UI.ViewManagement.UISettings`? >> >> I believe `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a not localised string for the high contrast scheme, and that would allow solving https://bugs.openjdk.java.net/browse/JDK-8185447. > > I just checked on Windows 10 v20H2 (build 19042.985), and unfortunately the `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a localized name for the high contrast scheme. Oh, too bad, but thanks for testing anyway. Do you know if there is such API that returns a non-localized string? I read it somewhere... ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:44 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:44 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:23:36 GMT, Jose Pereda wrote: >> I just checked on Windows 10 v20H2 (build 19042.985), and unfortunately the `Windows.UI.ViewManagement.AccessibleSettings.HighContrastScheme` contains a localized name for the high contrast scheme. > > Oh, too bad, but thanks for testing anyway. > Do you know if there is such API that returns a non-localized string? I read it somewhere... I don't know of such an API. Even when I change the locale of the current thread to English, the API returns the localized (non-English) name of the scheme. ------------- PR: https://git.openjdk.org/jfx/pull/511 From jpereda at openjdk.org Wed Nov 9 22:30:45 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 9 Nov 2022 22:30:45 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:34:14 GMT, Michael Strau? wrote: >> Oh, too bad, but thanks for testing anyway. >> Do you know if there is such API that returns a non-localized string? I read it somewhere... > > I don't know of such an API. Even when I change the locale of the current thread to English, the API returns the localized (non-English) name of the scheme. Yes, I know, I've got a possible fix for JDK-8185447 based precisely in using the localized high contrast scheme names (limited to the same languages supported in Controls). ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:45 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:45 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:40:19 GMT, Jose Pereda wrote: >> I don't know of such an API. Even when I change the locale of the current thread to English, the API returns the localized (non-English) name of the scheme. > > Yes, I know, I've got a possible fix for JDK-8185447 based precisely in using the localized high contrast scheme names (limited to the same languages supported in Controls). Just for reference: I've proposed [this enhancement](https://bugs.openjdk.java.net/browse/JDK-8267554) to load dynamic stylesheets that could be injected with the actual scheme colors. If added, this might be a better fix than matching color scheme names. ------------- PR: https://git.openjdk.org/jfx/pull/511 From jpereda at openjdk.org Wed Nov 9 22:30:45 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 9 Nov 2022 22:30:45 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:45:21 GMT, Michael Strau? wrote: >> Yes, I know, I've got a possible fix for JDK-8185447 based precisely in using the localized high contrast scheme names (limited to the same languages supported in Controls). > > Just for reference: I've proposed [this enhancement](https://bugs.openjdk.java.net/browse/JDK-8267554) to load dynamic stylesheets that could be injected with the actual scheme colors. If added, this might be a better fix than matching color scheme names. How would that help? How would the high contrast stylesheets be loaded? ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:30:45 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:30:45 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: <_AILueZNXnRLDp_V3qYax71iCHCFMXIEzji0_mll5bA=.d19fac9b-45f9-49e8-825c-4b3bd5bdf5b5@github.com> On Wed, 26 May 2021 17:52:35 GMT, Jose Pereda wrote: >> Just for reference: I've proposed [this enhancement](https://bugs.openjdk.java.net/browse/JDK-8267554) to load dynamic stylesheets that could be injected with the actual scheme colors. If added, this might be a better fix than matching color scheme names. > > How would that help? How would the high contrast stylesheets be loaded? Instead of hardcoding the colors in stylesheets such as Modena's `blackOnWhite.css`, you could use placeholder symbols inside of the stylesheet. Then, you could read the stylesheet into a string, replace the placeholders with the actual system colors, and load the modified stylesheet with a "data" URI. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Wed Nov 9 22:35:46 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 9 Nov 2022 22:35:46 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); I've iterated on this feature for several months, and I'm quite comfortable with the latest version. The API was changed considerably: there are no "theme URIs" masquerading as user-agent stylesheets any more. Instead there's an application-wide `Application.styleTheme` property. This simplifies the enhancement quite a lot. I've updated this PR with an overview of the API and some usage examples. ------------- PR: https://git.openjdk.org/jfx/pull/511 From kcr at openjdk.org Wed Nov 9 23:02:41 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 9 Nov 2022 23:02:41 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:30:28 GMT, Michael Strau? wrote: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); This will take a fair bit of discussion regarding how various applications might use such a feature, what the API should look like, etc. ------------- PR: https://git.openjdk.org/jfx/pull/511 From duke at openjdk.org Thu Nov 10 01:41:40 2022 From: duke at openjdk.org (pandaapo) Date: Thu, 10 Nov 2022 01:41:40 GMT Subject: RFR: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed In-Reply-To: References: Message-ID: <19dlLEprnnbQcfgkMOaiKQWNuQav-krXaDiCseDrOoE=.9555fd80-1c20-40cf-9671-61b8f34f0dc4@github.com> On Wed, 9 Nov 2022 13:56:41 GMT, Kevin Rushforth wrote: > Thank you for your offer to contribute. It might be somewhat premature, since we are still looking into whether the test can be fixed soon (in which case we would not want to skip it). See [JDK-8285503](https://bugs.openjdk.org/browse/JDK-8285503). We can leave this PR open until we know one way or the other. Thank you for your comment. I misunderstood the reporter's intention. I thought this should be fixed now when I found this issue in the JBS. ------------- PR: https://git.openjdk.org/jfx/pull/942 From aghaisas at openjdk.org Thu Nov 10 12:08:01 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 10 Nov 2022 12:08:01 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes Message-ID: Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. Fix: - Increased the sleep time to 500ms between `System.gc()` calls. - Reduced the number of SwingNodes by half as an additional step towards making the test lighter. Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed. ------------- Commit messages: - Fix 8285503 Changes: https://git.openjdk.org/jfx/pull/946/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285503 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/946.diff Fetch: git fetch https://git.openjdk.org/jfx pull/946/head:pull/946 PR: https://git.openjdk.org/jfx/pull/946 From jvos at openjdk.org Thu Nov 10 12:09:17 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 10 Nov 2022 12:09:17 GMT Subject: Integrated: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors In-Reply-To: References: Message-ID: <1P_q4gxRc33tKy_iIII06LmQv9AlshNQAwfUpyce-u8=.4da1addb-21df-4965-9a0c-406e84868791@github.com> On Thu, 20 Oct 2022 14:37:04 GMT, Johan Vos wrote: > The root problem is actually broader than stated in the JBS issue. This PR now translates screencoordinates from absolute coordinates into coordinates that take the platformScale into account. > The whole process is complicated by the fact that throughout our code, we use e.g. `x` and `y` without clearly stating if those are absolute, logical, screen or rendering coordinates. > I believe the most consistent approach is to have the different entry points (e.g. a Glass Window or a JFXPanel) to deal with platformScale before passing screen coordinates. This is already done in the Glass approach, and this PR does the same in JFXPanel. That means some code is duplicated, but since this is only about 12 lines, and said code lives in 2 different modules, I think it's not worth the hassle of moving that into e.g. the base module. This pull request has now been integrated. Changeset: f4e27e9d Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/f4e27e9d37439716455838671d2f06b8aca1d236 Stats: 54 lines in 2 files changed: 49 ins; 0 del; 5 mod 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/924 From duke at openjdk.org Thu Nov 10 12:49:39 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Thu, 10 Nov 2022 12:49:39 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Wed, 9 Nov 2022 19:14:10 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: >> >>> 187: >>> 188: private void compareColor(Color exp, Color act) { >>> 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); >> >> Since the tolerance value is used 4 times, maybe consider using a variable? Since this is preexisting, I'll approve it anyway and leave it up to you as to whether to change it. > > Since someone initially chose a value w/o justification, perhaps we should create a constant and describe it (using Kevin's comment as a starting point). I will update it. ------------- PR: https://git.openjdk.org/jfx/pull/944 From duke at openjdk.org Thu Nov 10 12:49:39 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Thu, 10 Nov 2022 12:49:39 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: <9V1cDFizl5LTR60T97E5BpN7feE5P7NyNoF4KWQn5So=.7788c7f6-7d6f-4d8e-a8f7-feeec1c9e1dd@github.com> References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> <9V1cDFizl5LTR60T97E5BpN7feE5P7NyNoF4KWQn5So=.7788c7f6-7d6f-4d8e-a8f7-feeec1c9e1dd@github.com> Message-ID: On Wed, 9 Nov 2022 18:30:26 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/PixelBufferDrawTest.java line 189: >> >>> 187: >>> 188: private void compareColor(Color exp, Color act) { >>> 189: Assert.assertEquals(exp.getRed(), act.getRed(), 0.01); >> >> I am curious: what is the source of these differences? >> Is it color model (and could we explicitly set the CM?) >> Or is it differences in anti-aliasing or some such? > > It's a good question, but I note that any number of things can cause such differences on some systems. As I mentioned in the bug report, most of our robot-based tests use `0.07` as a tolerance value. The idea being that these tests aren't trying to check whether the rendering is pixel perfect or that the shaders, etc., produce an exact value. They are just checking whether the pixel is red versus green versus orange, etc. I decided to do a bit more digging and I found out that those tests pass with original 0.005 tolerance if you plug in an external display and make it your main. In short: * Plugged in a 1080p display via HDMI port * Made the 1080p display the main display * To be sure tests will execute on it I mirrored 1080p display contents onto built-in Retina XDR display (I couldn't find an option to disable it). As a result, these tests started to pass again. Hard to say why exactly that happens, could be HiDPI-related, could be no HDR on my 1080p display, could be something else... Regardless, higher tolerance in these tests should still be okay as Kevin mentioned. ------------- PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Thu Nov 10 12:52:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 10 Nov 2022 12:52:42 GMT Subject: RFR: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:08:28 GMT, pandaapo wrote: > Fixes [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) You didn't misunderstand my comment -- I had intended for this test to be skipped right away. What happened is that after I filed the bug to skip the failing test, Ajit updated the bug tracking that test failure with his intention to fix the test. ------------- PR: https://git.openjdk.org/jfx/pull/942 From duke at openjdk.org Thu Nov 10 14:56:17 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Thu, 10 Nov 2022 14:56:17 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems [v2] In-Reply-To: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8296589: PixelBufferDrawTest fails on some systems Issue happening on some hardware due to slightly different pixel values being returned. Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is tighter than other tests which use 0.07). ------------- Changes: https://git.openjdk.org/jfx/pull/944/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=944&range=01 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/944.diff Fetch: git fetch https://git.openjdk.org/jfx pull/944/head:pull/944 PR: https://git.openjdk.org/jfx/pull/944 From angorya at openjdk.org Thu Nov 10 16:18:02 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 16:18:02 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems [v2] In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: <5IQyv11LI44HyKscnLgQW8VRY9v2Jo-2q7vphwXKNmA=.448f24e8-891f-4fd2-93cf-c82a4c959c30@github.com> On Thu, 10 Nov 2022 14:56:17 GMT, Lukasz Kostyra wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > Lukasz Kostyra 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 one additional commit since the last revision: > > 8296589: PixelBufferDrawTest fails on some systems > > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass > (0.01 delta is tighter than other tests which use 0.07). I would have made it a static field, but this is also acceptable. ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/944 From mhanl at openjdk.org Thu Nov 10 16:46:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 16:46:53 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v6] In-Reply-To: References: Message-ID: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8296330: Added JDK-8296609 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/936/files - new: https://git.openjdk.org/jfx/pull/936/files/8ce4d3bc..5ce2f7de Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=936&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/936.diff Fetch: git fetch https://git.openjdk.org/jfx pull/936/head:pull/936 PR: https://git.openjdk.org/jfx/pull/936 From mhanl at openjdk.org Thu Nov 10 16:49:05 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 16:49:05 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: <5SonBBk--nNbpPvQ0GVuMbg9gn7V61pHHLgAbvYYHtw=.8fcb7105-1841-4a84-ad88-232f585018c9@github.com> On Wed, 9 Nov 2022 19:08:05 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 283: > >> 281: } >> 282: >> 283: return snappedLeftInset() + max + snappedRightInset(); > > Have you verified that `max` ends up as a snapped value in all cases? Some of the values that are used in the computation of max clearly are snapped, such as `computeChildPrefAreaWidth` (which is a method in the Region superclass that returns a snapped result), but others might not be. besides the anchor everything is snapped properly here already. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Thu Nov 10 16:49:07 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 16:49:07 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Wed, 9 Nov 2022 19:29:30 GMT, Kevin Rushforth wrote: >> I initially had the same thought that Andy had, but I want to take a closer look -- especially at what similar layout panes do. >> >> As for the point about doing this only when `snapPixels == true`, yes, but you don't need to worry about that if you call the `snapXXX` methods in Region. All of them check the `snapToPixel` attribute. > > I looked at the other layout panes and they already do something similar to what this PR does, using the snapped insets for intermediate compuation. I also note that some of the computation is calling superclass methods that do snapping already, and expect it to be added to snapped insets (if there are insets), for example, `computeWidth()`. In this particular case -- `snappedLeftInset() + leftAnchor` -- I don't think `leftAnchor` is snapped, but it probably should be. Yeah I think so too. ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 10 17:22:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 17:22:36 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 21:21:42 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8295078: Replace JUnit4 with Junit5 imports Changes requested by angorya (Author). ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 10 17:22:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 17:22:37 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Thu, 10 Nov 2022 16:44:06 GMT, Marius Hanl wrote: >> I looked at the other layout panes and they already do something similar to what this PR does, using the snapped insets for intermediate compuation. I also note that some of the computation is calling superclass methods that do snapping already, and expect it to be added to snapped insets (if there are insets), for example, `computeWidth()`. In this particular case -- `snappedLeftInset() + leftAnchor` -- I don't think `leftAnchor` is snapped, but it probably should be. > > Yeah I think so too. I still think this code is incorrect. To illustrate, let's set insets to 0.8 and anchor to 0.5 Here is what I think it should do: snap=off result=1.3 snap=on result=1.0 (and not 1.5, as I think the proposed fix would produce) ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 10 17:22:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 17:22:37 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 19:32:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 364: >> >>> 362: } >>> 363: >>> 364: child.resizeRelocate(x, y, w, h); >> >> snapping should be done at this moment, I think, something like this: >> >> child.resizeRelocate( >> snapPositionX(x), >> snapPositionY(y), >> snapSizeX(w), >> snapSizeY(h)); >> >> and keep the original (unsnapped) code prior to this. > > It depends (see earlier discussion), but if we are going to snap the intermediate results, we need to be sure we are doing it consistently -- adding snapped insets to an unsnapped value is very likely the wrong thing to do. not only for consistency, but we should also understand whether it makes sense or not. for example, we might snap intermediate results such as guide lines, if that makes sense (e.g. for alignment), but most importantly, we must honor the snapToPixel setting for the end result. If it's true, then all child nodes must have integer coordinates and sizes. Would you agree? ------------- PR: https://git.openjdk.org/jfx/pull/910 From nlisker at openjdk.org Thu Nov 10 18:11:42 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 10 Nov 2022 18:11:42 GMT Subject: RFR: 8221708 Update Eclipse project files [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 08:32:22 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse classpath files > > - Stripped dependencies to a minimum > - Added ".settings" to exclusion for projects with sources in root > folder Some projects under tests have a lot of `add-exports` attributes that are not required. Leaving them doesn't cause trouble, but there's no reason to have them. I supplied a corrected .classpath file in all cases that you can use, or, you can remove them manually. Note that `systemTests-test` does require the `add-exports` attributes. After this change the PR can be committed. tests/manual/UI/.classpath line 29: > 27: > 28: > 29: tests/manual/controls/.classpath line 29: > 27: > 28: > 29: No need for all the "add exports". This is enough: tests/manual/desktop/.classpath line 29: > 27: > 28: > 29: Same: tests/manual/dnd/.classpath line 34: > 32: > 33: > 34: tests/manual/events/.classpath line 23: > 21: > 22: > 23: tests/manual/graphics/.classpath line 29: > 27: > 28: > 29: tests/manual/media/.classpath line 34: > 32: > 33: > 34: tests/manual/printing/.classpath line 35: > 33: > 34: > 35: tests/manual/swing/.classpath line 34: > 32: > 33: > 34: tests/manual/swt/.classpath line 39: > 37: > 38: > 39: tests/manual/text/.classpath line 23: > 21: > 22: > 23: tests/manual/web/.classpath line 35: > 33: > 34: > 35: tests/system/src/testapp1/.classpath line 29: > 27: > 28: > 29: tests/system/src/testapp2/.classpath line 29: > 27: > 28: > 29: tests/system/src/testapp3/.classpath line 29: > 27: > 28: > 29: tests/system/src/testapp4/.classpath line 29: > 27: > 28: > 29: tests/system/src/testapp5/.classpath line 35: > 33: > 34: > 35: tests/system/src/testapp6/.classpath line 35: > 33: > 34: > 35: tests/system/src/testapp7/.classpath line 41: > 39: > 40: > 41: tests/system/src/testscriptapp1/.classpath line 35: > 33: > 34: > 35: tests/system/src/testscriptapp2/.classpath line 35: > 33: > 34: > 35: ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/930 From angorya at openjdk.org Thu Nov 10 19:05:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 19:05:19 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue Message-ID: A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. Solution: initialize the derived color to transparent earlier to suppress the exception. This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8291853.class.cast - 8291853: initialize derived color early Changes: https://git.openjdk.org/jfx/pull/947/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=947&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291853 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/947.diff Fetch: git fetch https://git.openjdk.org/jfx pull/947/head:pull/947 PR: https://git.openjdk.org/jfx/pull/947 From mstrauss at openjdk.org Thu Nov 10 19:18:38 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 10 Nov 2022 19:18:38 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:20:17 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8295078: Replace JUnit4 with Junit5 imports > > Changes requested by angorya (Author). @andy-goryachev-oracle Snapping doesn't necessarily imply integer coordinates or sizes. The reason is that we're snapping to _pixels_, not integers. For example, with 200% scale, every other pixel will have a .5 coordinate. It's also important to not confuse snapping with rounding to integers because integer coordinates might not even fall on pixel boundaries for some scaling factors. ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 10 19:39:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 19:39:34 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 19:14:12 GMT, Michael Strau? wrote: >> Changes requested by angorya (Author). > > @andy-goryachev-oracle > Snapping doesn't necessarily imply integer coordinates or sizes. The reason is that we're snapping to _pixels_, not integers. For example, with 200% scale, every other pixel will have a .5 coordinate. It's also important to not confuse snapping with rounding to integers because integer coordinates might not even fall on pixel boundaries for some scaling factors. @mstr2 : You are right, I wasn't aware of scale. Snapping code looks like `Math.round(value * scale) / scale;`, so I take the 'whole integer' words back. Sorry for the confusion. Having said that, my earlier comment is still valid - if snapToPixel==true, the final location and sizes must go through snap*() methods. And the earlier example is also valid, assuming scale=1.0. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Thu Nov 10 20:02:37 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 20:02:37 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:52:50 GMT, Andy Goryachev wrote: > A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. > > Solution: initialize the derived color to transparent earlier to suppress the exception. > > This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 382: > 380: > 381: /* avoid race condition during initialization */ > 382: -fx-table-cell-border-color: transparent; A bit of a nitpick, but this should be next to the other cell colors, so in line 360 under `-fx-cell-focus-inner-border`. Also, we should probably add a description to the color like the other variables have here instead of explaining why it is here. :) ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Thu Nov 10 20:08:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 20:08:40 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:00:28 GMT, Marius Hanl wrote: >> A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. >> >> Solution: initialize the derived color to transparent earlier to suppress the exception. >> >> This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 > > modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 382: > >> 380: >> 381: /* avoid race condition during initialization */ >> 382: -fx-table-cell-border-color: transparent; > > A bit of a nitpick, but this should be next to the other cell colors, so in line 360 under `-fx-cell-focus-inner-border`. > Also, we should probably add a description to the color like the other variables have here instead of explaining why it is here. :) 1) good point, let's move it there 2) the color name is self-explanatory, but why it is there is not. Perhaps I should also include the ticket number for reference? ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Thu Nov 10 20:11:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 20:11:55 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: > A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. > > Solution: initialize the derived color to transparent earlier to suppress the exception. > > This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8291853: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/947/files - new: https://git.openjdk.org/jfx/pull/947/files/bce67a30..8f03d459 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=947&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=947&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/947.diff Fetch: git fetch https://git.openjdk.org/jfx pull/947/head:pull/947 PR: https://git.openjdk.org/jfx/pull/947 From mstrauss at openjdk.org Thu Nov 10 20:22:34 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 10 Nov 2022 20:22:34 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:11:55 GMT, Andy Goryachev wrote: >> A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. >> >> Solution: initialize the derived color to transparent earlier to suppress the exception. >> >> This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8291853: review comments Isn't it a bit strange that a valid CSS file would produce a `ClassCastException` in the first place? Maybe that should be fixed in the CSS subsystem instead. ------------- PR: https://git.openjdk.org/jfx/pull/947 From mstrauss at openjdk.org Thu Nov 10 20:29:18 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 10 Nov 2022 20:29:18 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v2] In-Reply-To: References: Message-ID: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Update PlatformPreferences when dark mode is enabled ------------- Changes: - all: https://git.openjdk.org/jfx/pull/511/files - new: https://git.openjdk.org/jfx/pull/511/files/da9d31e1..173de615 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/511.diff Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511 PR: https://git.openjdk.org/jfx/pull/511 From mhanl at openjdk.org Thu Nov 10 20:32:41 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 20:32:41 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Thu, 10 Nov 2022 17:14:56 GMT, Andy Goryachev wrote: >> Yeah I think so too. > > I still think this code is incorrect. > > To illustrate, let's set insets to 0.8 and anchor to 0.5 > Here is what I think it should do: > snap=off > result=1.3 > > snap=on > result=1.0 (and not 1.5, as I think the proposed fix would produce) I also never understood that completely. Hence I asked at the mailing list about snapping in the past: https://mail.openjdk.org/pipermail/openjfx-dev/2021-September/032166.html In my opinion it also makes sense to snap the values once. But that would be a huge refactoring and everything is affected. We can not just change this now. Thats why I would stick to the existing solution and refactor that later. But some clarification here would be helpful here, maybe ask the people who created this (if available)?. And I haven't looked yet, but how does Swing handle this? ------------- PR: https://git.openjdk.org/jfx/pull/910 From angorya at openjdk.org Thu Nov 10 20:42:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 20:42:41 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:20:33 GMT, Michael Strau? wrote: > Isn't it a bit strange that a valid CSS file would produce a `ClassCastException` in the first place? > Maybe that should be fixed in the CSS subsystem instead. The exception is benign: it tries to resolve a derived color which depends on something that has not been resolved yet, but will eventually get resolved. Like an isolated TableCell trying to applyCSS prior to its inclusion in a TableView. Trying to fix the CSS subsystem is much, much heavier task. Given the fact that the issue causes no visual effects whatsoever I'd say it's not worth the trouble. ------------- PR: https://git.openjdk.org/jfx/pull/947 From mhanl at openjdk.org Thu Nov 10 20:42:41 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 10 Nov 2022 20:42:41 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:11:55 GMT, Andy Goryachev wrote: >> A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. >> >> Solution: initialize the derived color to transparent earlier to suppress the exception. >> >> This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8291853: review comments So this really is not a bug in the CSS parser after all? modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 360: > 358: -fx-cell-focus-inner-border: derive(-fx-selection-bar,30%); > 359: > 360: /* Cell border color is initialized here to avoid a race condition during initialization */ I would still instead write something like `/**Border color for table cells. */` and _maybe_ link the JDK ticket. But developers looking in modena.css are more interested what the variables do than why they are there. But open for other opinions ------------- PR: https://git.openjdk.org/jfx/pull/947 From mstrauss at openjdk.org Thu Nov 10 20:42:41 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 10 Nov 2022 20:42:41 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:30:21 GMT, Andy Goryachev wrote: > The exception is benign: it tries to resolve a derived color which depends on something that has not been resolved yet, but will eventually get resolved. Like an isolated TableCell trying to applyCSS prior to its inclusion in a TableView. > > Trying to fix the CSS subsystem is much, much heavier task. Given the fact that the issue causes no visual effects whatsoever I'd say it's not worth the trouble. It seems to me that application developers could easily run into the same issue, and the proposed solution (initialize it with some value) is far from obvious. If the issue is not important enough to fix it for all application developers, then why is it important enough to fix it for Modena? ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Thu Nov 10 20:42:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 20:42:42 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: <50-PNzlMNo_7mR2kmZRGGYepRmGQ1W107YRLLHLDshY=.3a77651d-aa05-4ef1-b7f8-83f26439f2c6@github.com> On Thu, 10 Nov 2022 20:33:11 GMT, Marius Hanl wrote: > So this really is not a bug in the CSS parser after all? Not in the CssParser, but in the code that resolves the actual values at runtime (CssStyleHelper). May not be a bug per se, but rather a side effect of some specific order of initialization. Keep in mind that it gets resolved, eventually. ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Thu Nov 10 20:42:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 20:42:42 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: <7aBMgIdfUi8jvg3XbW4BKKOhgMxtiyqw_PtZpe56imc=.f29f4c8c-8bd5-49d4-b4b0-f3689c5f0c3c@github.com> On Thu, 10 Nov 2022 20:33:58 GMT, Michael Strau? wrote: > why is it important enough to fix it for Modena? came out of a test bug [JDK-8198604](https://bugs.openjdk.org/browse/JDK-8198604) ------------- PR: https://git.openjdk.org/jfx/pull/947 From kcr at openjdk.org Thu Nov 10 21:00:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 10 Nov 2022 21:00:34 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:33:58 GMT, Michael Strau? wrote: > If the issue is not important enough to fix it for all application developers, then why is it important enough to fix it for Modena? Because Modena is the default stylesheet. ------------- PR: https://git.openjdk.org/jfx/pull/947 From mstrauss at openjdk.org Thu Nov 10 21:08:34 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 10 Nov 2022 21:08:34 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:58:33 GMT, Kevin Rushforth wrote: > Because Modena is the default stylesheet. Then the underlying problem should probably be filed as a new JBS issue, especially since the exception doesn't communicate the cause of the problem to application developers who run into the same issue. ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Thu Nov 10 21:30:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 10 Nov 2022 21:30:42 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> Message-ID: On Fri, 4 Nov 2022 20:30:53 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > 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 24 additional commits since the last revision: > > - 8294809: review comments > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: whitespace > - 8294809: no public api > - 8294809: map change listener > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: generics > - 8294809: is alive > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8294809: removed weak listeners support > - ... and 14 more: https://git.openjdk.org/jfx/compare/17c57217...470f42c1 @arapte and @aghaisas : could you please take a look at this? there is a whole bunch of dependent PRs that will get unblocked once this change is in. Thank you ------------- PR: https://git.openjdk.org/jfx/pull/908 From jhendrikx at openjdk.org Thu Nov 10 23:40:35 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 10 Nov 2022 23:40:35 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:29:18 GMT, Michael Strau? wrote: >> This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. >> >> ### New APIs in `javafx.graphics` >> The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. >> #### 1. StyleTheme >> A style theme is an implementation of the `javafx.css.StyleTheme` interface: >> >> /** >> * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other >> * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all >> * JavaFX nodes in the scene graph. >> *

>> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, >> * enabling applications to create dynamic themes that respond to changing user preferences. >> *

>> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as >> * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade >> * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. >> */ >> public interface StyleTheme { >> /** >> * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. >> *

>> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this >> * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list >> * change notifications. >> * >> * @implNote Implementations of this method that return an {@link ObservableList} are encouraged >> * to minimize the number of subsequent list change notifications that are fired by the >> * list, as each change notification causes the CSS subsystem to re-apply the referenced >> * stylesheets. >> */ >> List getStylesheets(); >> } >> >> >> A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): >> >> public class Application { >> ... >> /** >> * Specifies the user-agent stylesheet of the application. >> *

>> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a >> * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. >> * It can be used to provide default styling for UI controls and other nodes. >> * A user-agent stylesheets has the lowest precedence in the CSS cascade. >> *

>> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants >> * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning >> * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} >> * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} >> * property to a new instance of the corresponding theme class. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static StringProperty userAgentStylesheetProperty(); >> public static String getUserAgentStylesheet(); >> public static void setUserAgentStylesheet(String url); >> >> /** >> * Specifies the {@link StyleTheme} of the application. >> *

>> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. >> * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the >> * scene graph. >> *

>> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a >> * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. >> *

>> * Note: this property must only be modified on the JavaFX application thread. >> */ >> public static ObjectProperty styleThemeProperty(); >> public static StyleTheme getStyleTheme(); >> public static void setStyleTheme(StyleTheme theme); >> ... >> } >> >> >> `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. >> >> #### 2. PlatformPreferences >> `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: >> >> /** >> * Contains UI preferences of the current platform. >> *

>> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. >> * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed >> * alternatives to the untyped {@link #get} method. >> *

>> * The preferences that are reported by the platform may be dependent on the operating system version. >> * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, >> * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback >> * value if the preference is not available. >> */ >> public interface PlatformPreferences extends Map { >> String getString(String key); >> String getString(String key, String fallbackValue); >> >> Boolean getBoolean(String key); >> boolean getBoolean(String key, boolean fallbackValue); >> >> Color getColor(String key); >> Color getColor(String key, Color fallbackValue); >> >> void addListener(PlatformPreferencesListener listener); >> void removeListener(PlatformPreferencesListener listener); >> } >> >> An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. >> >> ### Usage >> In its simplest form, a style theme is just a static collection of stylesheets: >> >> Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); >> >> A dynamic theme can be created by returning an instance of `ObservableList`: >> >> public class MyCustomTheme implements StyleTheme { >> private final ObservableList stylesheets = >> FXCollections.observableArrayList("colors-light.css", "controls.css"); >> >> @Override >> public List getStylesheets() { >> return stylesheets; >> } >> >> public void setDarkMode(boolean enabled) { >> stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); >> } >> } >> >> `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: >> >> Application.setStyleTheme(new ModenaTheme() { >> { >> addFirst("stylesheet1.css"); >> addLast("stylesheet2.css"); >> } >> }); > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update PlatformPreferences when dark mode is enabled This looks like quite a nice feature, would love to see this in JavaFX. modules/javafx.controls/src/main/java/javafx/scene/control/theme/StylesheetList.java line 52: > 50: values = new ArrayList<>(initialCapacity); > 51: } > 52: This looks unused and rather unnecessary. modules/javafx.graphics/src/main/java/javafx/application/PlatformPreferences.java line 117: > 115: * @since 20 > 116: */ > 117: public interface PlatformPreferences extends Map { Are you sure it is a good idea to expose these as a `Map`? It seems to me that this isn't that good a practice any more to have classes implement or extend lists/maps/sets as they pull in a huge amount of API surface that is mostly useless or too general for the class's purpose. The addition of the listener management methods also has me wondering, as `ObservableMap` does something similar. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Fri Nov 11 01:04:45 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 11 Nov 2022 01:04:45 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v3] In-Reply-To: References: Message-ID: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

> * The list of stylesheets that comprise a {@code StyleTheme} can be modified while the application is running, > * enabling applications to create dynamic themes that respond to changing user preferences. > *

> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are classified as > * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence in the CSS cascade > * than a stylesheet referenced by {@link Application#userAgentStylesheetProperty()}. > */ > public interface StyleTheme { > /** > * Gets the list of stylesheet URLs that comprise this {@code StyleTheme}. > *

> * If the list of stylesheets that comprise this {@code StyleTheme} is changed at runtime, this > * method must return an {@link ObservableList} to allow the CSS subsystem to subscribe to list > * change notifications. > * > * @implNote Implementations of this method that return an {@link ObservableList} are encouraged > * to minimize the number of subsequent list change notifications that are fired by the > * list, as each change notification causes the CSS subsystem to re-apply the referenced > * stylesheets. > */ > List getStylesheets(); > } > > > A new `styleTheme` property is added to `javafx.application.Application`, and `userAgentStylesheet` is promoted to a JavaFX property (currently, this is just a getter/setter pair): > > public class Application { > ... > /** > * Specifies the user-agent stylesheet of the application. > *

> * A user-agent stylesheet is a global stylesheet that can be specified in addition to a > * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in the scene graph. > * It can be used to provide default styling for UI controls and other nodes. > * A user-agent stylesheets has the lowest precedence in the CSS cascade. > *

> * Before JavaFX 20, built-in themes were selectable using the special user-agent stylesheet constants > * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For backwards compatibility, the meaning > * of these special constants is retained: setting the user-agent stylesheet to either {@code STYLESHEET_CASPIAN} > * or {@code STYLESHEET_MODENA} will also set the value of the {@link #styleThemeProperty() styleTheme} > * property to a new instance of the corresponding theme class. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static StringProperty userAgentStylesheetProperty(); > public static String getUserAgentStylesheet(); > public static void setUserAgentStylesheet(String url); > > /** > * Specifies the {@link StyleTheme} of the application. > *

> * {@code StyleTheme} is a collection of stylesheets that define the appearance of the application. > * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all JavaFX nodes in the > * scene graph. > *

> * Stylesheets that comprise a {@code StyleTheme} have a higher precedence in the CSS cascade than a > * stylesheet referenced by the {@link #userAgentStylesheetProperty() userAgentStylesheet} property. > *

> * Note: this property must only be modified on the JavaFX application thread. > */ > public static ObjectProperty styleThemeProperty(); > public static StyleTheme getStyleTheme(); > public static void setStyleTheme(StyleTheme theme); > ... > } > > > `styleTheme` and `userAgentStylesheet` are correlated to preserve backwards compatibility: setting `userAgentStylesheet` to the magic values "CASPIAN" or "MODENA" will implicitly set `styleTheme` to a new instance of the `CaspianTheme` or `ModenaTheme` class. Aside from these magic values, `userAgentStylesheet` can be set independently from `styleTheme`. In the CSS cascade, `userAgentStylesheet` has a lower precedence than `styleTheme`. > > #### 2. PlatformPreferences > `javafx.application.PlatformPreferences` can be used to query UI-related information about the current platform to allow theme implementations to adapt to the operating system. The interface extends `Map` and adds several useful methods, as well as the option to register a listener for change notifications: > > /** > * Contains UI preferences of the current platform. > *

> * {@code PlatformPreferences} implements {@link Map} to expose platform preferences as key-value pairs. > * For convenience, {@link #getString}, {@link #getBoolean} and {@link #getColor} are provided as typed > * alternatives to the untyped {@link #get} method. > *

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Removed unused StylesheetList constructor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/511/files - new: https://git.openjdk.org/jfx/pull/511/files/173de615..1cd42253 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/511.diff Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511 PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Fri Nov 11 01:04:46 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 11 Nov 2022 01:04:46 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 23:04:41 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Update PlatformPreferences when dark mode is enabled > > modules/javafx.controls/src/main/java/javafx/scene/control/theme/StylesheetList.java line 52: > >> 50: values = new ArrayList<>(initialCapacity); >> 51: } >> 52: > > This looks unused and rather unnecessary. That's correct. ------------- PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Fri Nov 11 01:13:40 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 11 Nov 2022 01:13:40 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 23:31:36 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Update PlatformPreferences when dark mode is enabled > > modules/javafx.graphics/src/main/java/javafx/application/PlatformPreferences.java line 117: > >> 115: * @since 20 >> 116: */ >> 117: public interface PlatformPreferences extends Map { > > Are you sure it is a good idea to expose these as a `Map`? It seems to me that this isn't that good a practice any more to have classes implement or extend lists/maps/sets as they pull in a huge amount of API surface that is mostly useless or too general for the class's purpose. > > The addition of the listener management methods also has me wondering, as `ObservableMap` does something similar. All of the mutating methods are useless, since the implementation always returns a read-only map. However, the alternative would be to duplicate APIs to enumerate and inspect the contents of the `PlatformPreferences` map (applications might want to show a list of available preferences). I'm not sure that's preferable, mostly because `PlatformPreferences` _does_ represent a mapping of keys to values. It's true that listener management makes it look like an `ObservableMap`. The difference is that `ObservableMap` doesn't support batch change notifications, which the current implementation relies on to minimize the number of style theme resets. Of course, that could be solved in a different way. ------------- PR: https://git.openjdk.org/jfx/pull/511 From aghaisas at openjdk.org Fri Nov 11 10:20:58 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 11 Nov 2022 10:20:58 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly set and remove inputMethodRequests property in TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/903 From aghaisas at openjdk.org Fri Nov 11 11:26:35 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 11 Nov 2022 11:26:35 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: <50-PNzlMNo_7mR2kmZRGGYepRmGQ1W107YRLLHLDshY=.3a77651d-aa05-4ef1-b7f8-83f26439f2c6@github.com> References: <50-PNzlMNo_7mR2kmZRGGYepRmGQ1W107YRLLHLDshY=.3a77651d-aa05-4ef1-b7f8-83f26439f2c6@github.com> Message-ID: <5l7gVq28lhr4N9DnQfLvY-GBHz9eqS-vz7g12Mfkk9s=.7ae9cde0-4b56-43b7-beec-b3745212f752@github.com> On Thu, 10 Nov 2022 20:36:58 GMT, Andy Goryachev wrote: > > So this really is not a bug in the CSS parser after all? > > Not in the CssParser, but in the code that resolves the actual values at runtime (CssStyleHelper). May not be a bug per se, but rather a side effect of some specific order of initialization. Keep in mind that it gets resolved, eventually. I agree. ------------- PR: https://git.openjdk.org/jfx/pull/947 From aghaisas at openjdk.org Fri Nov 11 11:31:38 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 11 Nov 2022 11:31:38 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 21:04:49 GMT, Michael Strau? wrote: > > Because Modena is the default stylesheet. > > Then the underlying problem should probably be filed as a new JBS issue, especially since the exception doesn't communicate the cause of the problem to application developers who run into the same issue. Since, there is no visual indication of the underlying problem (if any), it is hard to file a reproducible issue once the exception is fixed. On the other hand, we do not wish to keep this exception from occurring if it can be fixed with a simple initialization. ------------- PR: https://git.openjdk.org/jfx/pull/947 From kcr at openjdk.org Sat Nov 12 15:09:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 15:09:30 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 12:01:53 GMT, Ajit Ghaisas wrote: > Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. > Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. > > Fix: > - Increased the sleep time to 500ms between `System.gc()` calls. > - Reduced the number of SwingNodes by half as an additional step towards making the test lighter. > > Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed. I left a comment inline recommending to revert one part of your change. I verified that the test always fails on my Mac without your fix, and passes with your fix (I ran it in a loop 20 times with the number of swing nodes reverted back to 10). So this simple fix is fine, and as you note, brings this test in line with other tests that manually check for leaks. I still think we could make _all_ of our memory leak tests more robust by using JMemoryBuddy. Can you file a follow-up bug to do that? tests/system/src/test/java/test/javafx/embed/swing/SwingNodeDnDMemoryLeakTest.java line 52: > 50: public class SwingNodeDnDMemoryLeakTest { > 51: > 52: final static int TOTAL_SWINGNODE = 5; I don't think this change is necessary. The test will take no more time with 10 nodes than it will with 5, since the GC loop with the sleep is not dependent on the number of nodes. ------------- PR: https://git.openjdk.org/jfx/pull/946 From kcr at openjdk.org Sat Nov 12 15:11:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 15:11:28 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 11:29:27 GMT, Ajit Ghaisas wrote: > > Then the underlying problem should probably be filed as a new JBS issue, especially since the exception doesn't communicate the cause of the problem to application developers who run into the same issue. I agree. > Since, there is no visual indication of the underlying problem (if any), it is hard to file a reproducible issue once the exception is fixed. On the other hand, we do not wish to keep this exception from occurring if it can be fixed with a simple initialization. Since we aren't fixing anything in the code, but rather working around the problem with a change to `modena.css`, it should still be possible to reproduce this in a test that uses a custom stylesheet. ------------- PR: https://git.openjdk.org/jfx/pull/947 From kcr at openjdk.org Sat Nov 12 15:34:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 15:34:34 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems [v2] In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Thu, 10 Nov 2022 14:56:17 GMT, Lukasz Kostyra wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8296589: PixelBufferDrawTest fails on some systems > > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass > (0.01 delta is tighter than other tests which use 0.07). > lukostyra force-pushed the JDK-8296589-PixelBufferDrawTest-tolerance branch from 46665a4 to 082cd74 @lukostyra Please don't force push to your branch once the PR has been published as `rfr`. See item 3 of [the pull request section in CONTRIBUTING.md](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#submitting-your-changes-via-a-pull-request). ------------- PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Sat Nov 12 15:39:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 15:39:12 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems [v2] In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Thu, 10 Nov 2022 14:56:17 GMT, Lukasz Kostyra wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8296589: PixelBufferDrawTest fails on some systems > > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass > (0.01 delta is tighter than other tests which use 0.07). Updated fix looks fine. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Sat Nov 12 15:55:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 15:55:37 GMT Subject: RFR: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly set and remove inputMethodRequests property in TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/903 From kcr at openjdk.org Sat Nov 12 16:10:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 12 Nov 2022 16:10:37 GMT Subject: RFR: 8296621: Stage steals focus on scene change In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 00:53:19 GMT, Thiago Milczarek Sayao wrote: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. I agree that changing from one scene to another should not cause a new request focus call. My only concern is to ensure that this will not cause any regressions for the initial setting of a scene. A safer change might be to qualify the existing call to `requestFocus` with a check of the previous scene, and only call it if `oldScene == null`. Also, is it possible to add an automated unit test? If not, then a manual test would be in order. ------------- PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Sat Nov 12 17:16:00 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 12 Nov 2022 17:16:00 GMT Subject: RFR: 8296621: Stage steals focus on scene change In-Reply-To: References: Message-ID: <54dmnceDH08tGLP9Up1NM1Fe9UWRsKGHDMglAf2AoHI=.eb40e1d4-9a55-45a0-b418-92cdd4b80fb4@github.com> On Wed, 9 Nov 2022 00:53:19 GMT, Thiago Milczarek Sayao wrote: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > I agree that changing from one scene to another should not cause a new request focus call. My only concern is to ensure that this will not cause any regressions for the initial setting of a scene. A safer change might be to qualify the existing call to `requestFocus` with a check of the previous scene, and only call it if `oldScene == null`. > > /reviewers 2 The reason I found this is that `requestFocus()` in glass native side was being called before the window was visible. I'm not sure about windows or macos, but requesting focus on a unmapped window doesn't work (on Linux) and it seems logical to me. Considering that the usual scenario is to `setScene()` and then `show()`. ------------- PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Sat Nov 12 17:16:02 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 12 Nov 2022 17:16:02 GMT Subject: RFR: 8296621: Stage steals focus on scene change In-Reply-To: References: Message-ID: <3acXNs07SCtQUKirTwYNNSaTQBiDR-3kgUxpGhCD2UE=.7e6dca75-5c48-4b4b-83c4-2ad204c0d3d7@github.com> On Sat, 12 Nov 2022 16:06:39 GMT, Kevin Rushforth wrote: > Also, is it possible to add an automated unit test? If not, then a manual test would be in order. I think it's possible to add an automated test. Will try. ------------- PR: https://git.openjdk.org/jfx/pull/940 From jhendrikx at openjdk.org Sat Nov 12 20:38:49 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 12 Nov 2022 20:38:49 GMT Subject: RFR: 8221708 Update Eclipse project files [v3] In-Reply-To: References: Message-ID: > See https://bugs.openjdk.org/browse/JDK-8221708 John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary add-exports attribute from Eclipse files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/930/files - new: https://git.openjdk.org/jfx/pull/930/files/c27beb6a..82491a4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=01-02 Stats: 86 lines in 21 files changed: 0 ins; 86 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/930.diff Fetch: git fetch https://git.openjdk.org/jfx pull/930/head:pull/930 PR: https://git.openjdk.org/jfx/pull/930 From tsayao at openjdk.org Sun Nov 13 01:02:36 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 13 Nov 2022 01:02:36 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/c3252bd0..113e472a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=00-01 Stats: 93 lines in 1 file changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From nlisker at openjdk.org Sun Nov 13 01:47:44 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 13 Nov 2022 01:47:44 GMT Subject: RFR: 8221708 Update Eclipse project files [v3] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 20:38:49 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary add-exports attribute from Eclipse files tests/manual/controls/.classpath line 10: > 8: > 9: > 10: The wrong attribute was removed. The module one should stay, the exports one should be removed. tests/manual/desktop/.classpath line 23: > 21: > 22: > 23: Missing the `excluding=".classpath|.project|.settings"` entry? ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 13 01:47:44 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 13 Nov 2022 01:47:44 GMT Subject: RFR: 8221708 Update Eclipse project files [v3] In-Reply-To: References: Message-ID: <7t-TuSG0e1YPQ14k0A9cAHwwGAf78zyrfcek3Q0VQ_Y=.87e120aa-28c0-49b2-b8bd-06ef97dcad68@github.com> On Sun, 13 Nov 2022 01:43:30 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary add-exports attribute from Eclipse files > > tests/manual/desktop/.classpath line 23: > >> 21: >> 22: >> 23: > > Missing the `excluding=".classpath|.project|.settings"` entry? Never mind, it has a source folder. ------------- PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 13 02:27:55 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 13 Nov 2022 02:27:55 GMT Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: References: Message-ID: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> > See https://bugs.openjdk.org/browse/JDK-8221708 John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix controls classpath ------------- Changes: - all: https://git.openjdk.org/jfx/pull/930/files - new: https://git.openjdk.org/jfx/pull/930/files/82491a4c..c5cc34eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=930&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/930.diff Fetch: git fetch https://git.openjdk.org/jfx pull/930/head:pull/930 PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 13 02:27:56 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 13 Nov 2022 02:27:56 GMT Subject: RFR: 8221708 Update Eclipse project files [v3] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:41:45 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary add-exports attribute from Eclipse files > > tests/manual/controls/.classpath line 10: > >> 8: >> 9: >> 10: > > The wrong attribute was removed. The module one should stay, the exports one should be removed. A bit overeager there, sorry I missed it. I've added it back. ------------- PR: https://git.openjdk.org/jfx/pull/930 From nlisker at openjdk.org Sun Nov 13 03:10:47 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 13 Nov 2022 03:10:47 GMT Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix controls classpath Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/930 From jhendrikx at openjdk.org Sun Nov 13 21:13:03 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 13 Nov 2022 21:13:03 GMT Subject: Integrated: 8221708 Update Eclipse project files In-Reply-To: References: Message-ID: <4yr6c1uyd9OZvwHtQY14Uc5QaJtKJaj9ezrZcnH_hgE=.f34c50a8-9311-45a0-8f71-bda77f68705f@github.com> On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote: > See https://bugs.openjdk.org/browse/JDK-8221708 This pull request has now been integrated. Changeset: 7dc284df Author: John Hendrikx Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/7dc284dfe33fa8b8a83289de21dc9f7747ac099f Stats: 1649 lines in 123 files changed: 1377 ins; 246 del; 26 mod 8221708: Update Eclipse project files Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/930 From duke at openjdk.org Mon Nov 14 06:18:36 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Mon, 14 Nov 2022 06:18:36 GMT Subject: RFR: 8296589: PixelBufferDrawTest fails on some systems [v2] In-Reply-To: References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: <5nxSQVHe4PK-26hszh_lHmRVQv9bBc1rOG6gCswMM-A=.538f4193-c279-4530-9075-613ad67a96d4@github.com> On Thu, 10 Nov 2022 14:56:17 GMT, Lukasz Kostyra wrote: >> Issue happening on some hardware due to slightly different pixel values being returned. >> >> Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). > > Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8296589: PixelBufferDrawTest fails on some systems > > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass > (0.01 delta is tighter than other tests which use 0.07). > > lukostyra force-pushed the JDK-8296589-PixelBufferDrawTest-tolerance branch from [46665a4](https://github.com/openjdk/jfx/commit/46665a4c47257cf350475007e56d67d073df8741) to [082cd74](https://github.com/openjdk/jfx/commit/082cd74054b683dd20a6b428bc2d4aeeeff476f4) > > @lukostyra Please don't force push to your branch once the PR has been published as `rfr`. See item 3 of [the pull request section in CONTRIBUTING.md](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#submitting-your-changes-via-a-pull-request). Sorry about that! I'll make sure to not do it in the future. ------------- PR: https://git.openjdk.org/jfx/pull/944 From aghaisas at openjdk.org Mon Nov 14 07:01:42 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 07:01:42 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 12:01:53 GMT, Ajit Ghaisas wrote: > Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. > Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. > > Fix: > - Increased the sleep time to 500ms between `System.gc()` calls. > - Reduced the number of SwingNodes by half as an additional step towards making the test lighter. > > Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed. > I verified that the test always fails on my Mac without your fix, and passes with your fix (I ran it in a loop 20 times with the number of swing nodes reverted back to 10). So this simple fix is fine, and as you note, brings this test in line with other tests that manually check for leaks. I still think we could make all of our memory leak tests more robust by using JMemoryBuddy. Can you file a follow-up bug to do that? Filed [JDK-8296919](https://bugs.openjdk.org/browse/JDK-8296919) for this. ------------- PR: https://git.openjdk.org/jfx/pull/946 From aghaisas at openjdk.org Mon Nov 14 07:01:43 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 07:01:43 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 14:48:09 GMT, Kevin Rushforth wrote: >> Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. >> Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. >> >> Fix: >> - Increased the sleep time to 500ms between `System.gc()` calls. >> - Reduced the number of SwingNodes by half as an additional step towards making the test lighter. >> >> Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed. > > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeDnDMemoryLeakTest.java line 52: > >> 50: public class SwingNodeDnDMemoryLeakTest { >> 51: >> 52: final static int TOTAL_SWINGNODE = 5; > > I don't think this change is necessary. The test will take no more time with 10 nodes than it will with 5, since the GC loop with the sleep is not dependent on the number of nodes. OK. I will revert this change. ------------- PR: https://git.openjdk.org/jfx/pull/946 From aghaisas at openjdk.org Mon Nov 14 07:04:36 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 07:04:36 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes [v2] In-Reply-To: References: Message-ID: > Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. > Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. > > Fix: > - Increased the sleep time to 500ms between `System.gc()` calls. > - Reduced the number of SwingNodes by half as an additional step towards making the test lighter. > > Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with above changes and no failure was observed. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Revert total swingnode count to 10 in test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/946/files - new: https://git.openjdk.org/jfx/pull/946/files/14309ed7..0b98be18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=946&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=946&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/946.diff Fetch: git fetch https://git.openjdk.org/jfx pull/946/head:pull/946 PR: https://git.openjdk.org/jfx/pull/946 From aghaisas at openjdk.org Mon Nov 14 11:21:30 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 11:21:30 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> Message-ID: <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> On Fri, 4 Nov 2022 20:30:53 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > 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 24 additional commits since the last revision: > > - 8294809: review comments > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: whitespace > - 8294809: no public api > - 8294809: map change listener > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: generics > - 8294809: is alive > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8294809: removed weak listeners support > - ... and 14 more: https://git.openjdk.org/jfx/compare/fa19443d...470f42c1 modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 70: > 68: * > 69: */ > 70: public class ListenerHelper implements IDisconnectable { This class is mixing two things- 1. Managing listeners in a generic way - by providing ability to add & removeAll (via disconnect()) 2. Trying to cater to *Skin specific requirement Ideally, (2) above should be done separately. I mean, the class ListenerHelper should not use `SkinBase`. What do you think? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 87: > 85: > 86: public static ListenerHelper get(SkinBase skin) { > 87: return accessor.apply(skin); `accessor` can be `null` and needs to be checked. modules/javafx.controls/src/test/java/test/javafx/scene/control/TestListenerHelper.java line 94: > 92: > 93: @Test > 94: public void testChangeListener_MultipleProperties() { Should we address a hypothetical use case where the `ListenerHelper` has added a ChangeListener for 2 properties as done in this test case and wants to remove only ChangeListener for p1? currently `h.disconnet()` removes ChangeListener of both the properties. ------------- PR: https://git.openjdk.org/jfx/pull/908 From aghaisas at openjdk.org Mon Nov 14 12:00:00 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 12:00:00 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: <8p-iED9EmGxiZ2ZzUOXy-df9KJ1kuc1xikU_UDSmDt4=.c42b9a24-89d9-4d8b-bb4a-8830907a8fef@github.com> On Thu, 10 Nov 2022 20:11:55 GMT, Andy Goryachev wrote: >> A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. >> >> Solution: initialize the derived color to transparent earlier to suppress the exception. >> >> This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8291853: review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/947 From thiago.sayao at gmail.com Mon Nov 14 12:54:34 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 14 Nov 2022 09:54:34 -0300 Subject: Plans for gtk glass backend Message-ID: Hi, I have some plans to work on gtk glass backend, not necessarily in this order: 1) Unify WindowContextBase and WindowContextTop - those were separated for applet support that were removed 2) Remove gtk2 Support 3) Add gesture support 4) Rework AlwaysOnTop, exploring _NET_WM_STATE_ABOVE 5) Fix DND: JDK-8273379, JDK-8280383 Some depend on [1]. I don't promise I will finish all of them, but it's the intention. Comments are welcome. [1] https://github.com/openjdk/jfx/pull/915 - 8260528: Clean glass-gtk sizing and positioning code -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Nov 14 14:02:17 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Mon, 14 Nov 2022 14:02:17 GMT Subject: Integrated: 8296589: PixelBufferDrawTest fails on some systems In-Reply-To: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> References: <_chQtxo82wavfWOKtlyy292nBsBgjnikp1OKH2zU3V4=.6b40043d-02be-46f5-b6d4-72cf07d4577d@github.com> Message-ID: On Wed, 9 Nov 2022 18:00:31 GMT, Lukasz Kostyra wrote: > Issue happening on some hardware due to slightly different pixel values being returned. > > Increased tolerance of asserts in compareColor function to allow these tests to pass (0.01 delta is still tighter than other similar tests which use 0.07). This pull request has now been integrated. Changeset: 0ee116d3 Author: Lukasz Kostyra Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0ee116d3ff7d9b91df1424b2cebd4b771adb0c89 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8296589: PixelBufferDrawTest fails on some systems Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/944 From kcr at openjdk.org Mon Nov 14 14:03:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 14 Nov 2022 14:03:03 GMT Subject: RFR: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes [v2] In-Reply-To: References: Message-ID: <1uzcf8e1czwiF9n-dHlMGhuRLv6VbWVpNPF4XXNpjPo=.1172f956-f0e9-4238-89d1-21f3e5141ab8@github.com> On Mon, 14 Nov 2022 07:04:36 GMT, Ajit Ghaisas wrote: >> Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. >> Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. >> >> Fix: >> - Increased the sleep time to 500ms between `System.gc()` calls. >> >> Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with this change and no failure was observed. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Revert total swingnode count to 10 in test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/946 From john.hendrikx at gmail.com Mon Nov 14 14:25:16 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 14 Nov 2022 15:25:16 +0100 Subject: Plans for gtk glass backend In-Reply-To: References: Message-ID: <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> I have an issue related to child stages not being allowed to be as large as their parent stage under Linux.? It's somewhere fairly deep in the system, and I was wondering if that would be near these things you are planning to do.? I wouldn't know myself how to fix it, but can help where I can: https://bugs.openjdk.org/browse/JDK-8248435 If not, that's fine :) --John On 14/11/2022 13:54, Thiago Milczarek Say?o wrote: > Hi, > > I have some plans to work on gtk glass backend, not necessarily?in > this order: > > 1) Unify WindowContextBase and WindowContextTop - those were separated > for applet support that were removed > 2) Remove gtk2 Support > 3) Add gesture support > 4) Rework AlwaysOnTop, exploring?_NET_WM_STATE_ABOVE > 5) Fix DND: JDK-8273379,?JDK-8280383 > > Some depend on [1]. > > I don't promise I will finish all of them, but it's the intention. > > Comments are welcome. > > [1] https://github.com/openjdk/jfx/pull/915 -?8260528: Clean glass-gtk > sizing and positioning code > > -- Thiago. From john.hendrikx at gmail.com Mon Nov 14 14:52:58 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 14 Nov 2022 15:52:58 +0100 Subject: Discussion: Naming API method Message-ID: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> Hi, I'm working on https://github.com/openjdk/jfx/pull/830 where I asked for some opinions on the naming of a new method I'd like to introduce in ObservableValue. I wrote a (perhaps too large) comment about the possible names and rationales: https://github.com/openjdk/jfx/pull/830#issuecomment-1304846220 I'd like to ask what others think what would be a good name for this new method (Observable#when in the PR) in order to move the PR forward, as I think it offers a very compelling feature to JavaFX (moving from weak reference to deterministic behavior when it comes to listener management).? My opinion has always been that using weak listeners for listener management is a crutch that relies far too much on the internal workings of the JVM and Garbage Collector which offer no guarantees as to the timely clean up of these references and the listeners related to them. Leading contenders are (but not limited to these, if you have a better name): 1) conditionOn 2) updateWhen 3) when 4) whenever Usage in code is nearly always going to be something like these constructs: ????? // keeps text property in sync with longLivedProperty when label is shown: label.textProperty().bind(longLivedProperty.**when**(label::isShownProperty)); ????? // keeps text property in sync with longLivedProperty when container is shown: label.textProperty().bind(longLivedProperty.**when**(container::isShownProperty)); It can also be used to make a listener only actively listen when a condition is met (the listener is added/removed immediately when the condition changes, facilitating GC): ????? // listen to changes of longLivedProperty when container is shown: ????? longLivedProperty.when(container::isShownProperty) ??????????? .addListener((obs, old, current) -> { ... change listener ... }); Or it can be used to disable updates temporarily (or permanently): ??????? BooleanProperty allowUpdates = new SimpleBooleanProperty(true) ??????? // keeps text property in sync when updates are allowed: ??????? name.textProperty().bind(model.title.when(allowUpdates)); detail.textProperty().bind(model.subtitle.when(allowUpdates)); asyncImageProperty.imageHandleProperty().bind(model.imageHandle.when(allowUpdates)); This last example can be useful in Skin#dispose, but has uses outside of skins as well, for example when you want to prevent updates until things have settled down. Thanks for reading! --John From A.Anafinow at tms-bonn.de Mon Nov 14 15:19:58 2022 From: A.Anafinow at tms-bonn.de (Anafinow, Andrej) Date: Mon, 14 Nov 2022 15:19:58 +0000 Subject: AW: Plans for gtk glass backend In-Reply-To: <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> References: , <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> Message-ID: <7a9b5d50c7094727905c53aaa844d6d8@tms-bonn.de> https://mail.openjdk.org/pipermail/openjfx-dev/2022-March/033802.html ________________________________ Von: openjfx-dev im Auftrag von John Hendrikx Gesendet: Montag, 14. November 2022 15:25:16 An: openjfx-dev at openjdk.org Betreff: Re: Plans for gtk glass backend I have an issue related to child stages not being allowed to be as large as their parent stage under Linux. It's somewhere fairly deep in the system, and I was wondering if that would be near these things you are planning to do. I wouldn't know myself how to fix it, but can help where I can: https://bugs.openjdk.org/browse/JDK-8248435 If not, that's fine :) --John On 14/11/2022 13:54, Thiago Milczarek Say?o wrote: > Hi, > > I have some plans to work on gtk glass backend, not necessarily in > this order: > > 1) Unify WindowContextBase and WindowContextTop - those were separated > for applet support that were removed > 2) Remove gtk2 Support > 3) Add gesture support > 4) Rework AlwaysOnTop, exploring _NET_WM_STATE_ABOVE > 5) Fix DND: JDK-8273379, JDK-8280383 > > Some depend on [1]. > > I don't promise I will finish all of them, but it's the intention. > > Comments are welcome. > > [1] https://github.com/openjdk/jfx/pull/915 - 8260528: Clean glass-gtk > sizing and positioning code > > -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Mon Nov 14 15:26:19 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 14 Nov 2022 15:26:19 GMT Subject: Integrated: 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 12:01:53 GMT, Ajit Ghaisas wrote: > Root cause: The test unreliability comes from the 250ms sleep between `System.gc()` calls. > Other system tests such as `TabPaneHeaderLeakTest`, `AccordionTitlePaneLeakTest` and `ShapeViewOrderLeakTest` etc sleep for 500ms between `System.gc()` calls. > > Fix: > - Increased the sleep time to 500ms between `System.gc()` calls. > > Testing: This test used to fail on my macBook all the time if ran as part of a full system test run. I executed full test runs 5 times with this change and no failure was observed. This pull request has now been integrated. Changeset: 59569502 Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/595695020cf46737a9790fb5638252d3e4a6fdad Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8285503: SwingNodeDnDMemoryLeakTest::testSwingNodeMemoryLeak fails sometimes Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/946 From kevin.rushforth at oracle.com Mon Nov 14 17:40:02 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 14 Nov 2022 09:40:02 -0800 Subject: Discussion: Naming API method In-Reply-To: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> References: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> Message-ID: <97cc19ef-675a-571e-783c-c076e9409120@oracle.com> I also think this will be a useful feature to get into JavaFX. As for the name of the method, the only one of them I don't like is "conditionOn". That name doesn't suggest (to me anyway) what its purpose is. I think any of the ones with "when" in the name would work. I have a slight preference for "updateWhen", but could be talked into one of the others. -- Kevin On 11/14/2022 6:52 AM, John Hendrikx wrote: > Hi, > > I'm working on https://github.com/openjdk/jfx/pull/830 where I asked > for some opinions on the naming of a new method I'd like to introduce > in ObservableValue. > > I wrote a (perhaps too large) comment about the possible names and > rationales: > https://github.com/openjdk/jfx/pull/830#issuecomment-1304846220 > > I'd like to ask what others think what would be a good name for this > new method (Observable#when in the PR) in order to move the PR > forward, as I think it offers a very compelling feature to JavaFX > (moving from weak reference to deterministic behavior when it comes to > listener management).? My opinion has always been that using weak > listeners for listener management is a crutch that relies far too much > on the internal workings of the JVM and Garbage Collector which offer > no guarantees as to the timely clean up of these references and the > listeners related to them. > > Leading contenders are (but not limited to these, if you have a better > name): > > 1) conditionOn > > 2) updateWhen > > 3) when > > 4) whenever > > Usage in code is nearly always going to be something like these > constructs: > > ????? // keeps text property in sync with longLivedProperty when label > is shown: > label.textProperty().bind(longLivedProperty.**when**(label::isShownProperty)); > > > ????? // keeps text property in sync with longLivedProperty when > container is shown: > label.textProperty().bind(longLivedProperty.**when**(container::isShownProperty)); > > > It can also be used to make a listener only actively listen when a > condition is met (the listener is added/removed immediately when the > condition changes, facilitating GC): > > ????? // listen to changes of longLivedProperty when container is shown: > ????? longLivedProperty.when(container::isShownProperty) > ??????????? .addListener((obs, old, current) -> { ... change listener > ... }); > > Or it can be used to disable updates temporarily (or permanently): > > ??????? BooleanProperty allowUpdates = new SimpleBooleanProperty(true) > > ??????? // keeps text property in sync when updates are allowed: > ??????? name.textProperty().bind(model.title.when(allowUpdates)); > detail.textProperty().bind(model.subtitle.when(allowUpdates)); > asyncImageProperty.imageHandleProperty().bind(model.imageHandle.when(allowUpdates)); > > > This last example can be useful in Skin#dispose, but has uses outside > of skins as well, for example when you want to prevent updates until > things have settled down. > > Thanks for reading! > > --John > > From andy.goryachev at oracle.com Mon Nov 14 17:47:30 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 14 Nov 2022 17:47:30 +0000 Subject: Discussion: Naming API method In-Reply-To: <97cc19ef-675a-571e-783c-c076e9409120@oracle.com> References: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> <97cc19ef-675a-571e-783c-c076e9409120@oracle.com> Message-ID: I'd pick "whenever" or "onCondition". "updateWhen" sounds like an update, which I think it is not. "when" seems too vague. Disclaimer: English is not my native language. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Monday, 2022/11/14 at 09:40 To: openjfx-dev at openjdk.org Subject: Re: Discussion: Naming API method I also think this will be a useful feature to get into JavaFX. As for the name of the method, the only one of them I don't like is "conditionOn". That name doesn't suggest (to me anyway) what its purpose is. I think any of the ones with "when" in the name would work. I have a slight preference for "updateWhen", but could be talked into one of the others. -- Kevin On 11/14/2022 6:52 AM, John Hendrikx wrote: > Hi, > > I'm working on https://github.com/openjdk/jfx/pull/830 where I asked > for some opinions on the naming of a new method I'd like to introduce > in ObservableValue. > > I wrote a (perhaps too large) comment about the possible names and > rationales: > https://github.com/openjdk/jfx/pull/830#issuecomment-1304846220 > > I'd like to ask what others think what would be a good name for this > new method (Observable#when in the PR) in order to move the PR > forward, as I think it offers a very compelling feature to JavaFX > (moving from weak reference to deterministic behavior when it comes to > listener management). My opinion has always been that using weak > listeners for listener management is a crutch that relies far too much > on the internal workings of the JVM and Garbage Collector which offer > no guarantees as to the timely clean up of these references and the > listeners related to them. > > Leading contenders are (but not limited to these, if you have a better > name): > > 1) conditionOn > > 2) updateWhen > > 3) when > > 4) whenever > > Usage in code is nearly always going to be something like these > constructs: > > // keeps text property in sync with longLivedProperty when label > is shown: > label.textProperty().bind(longLivedProperty.**when**(label::isShownProperty)); > > > // keeps text property in sync with longLivedProperty when > container is shown: > label.textProperty().bind(longLivedProperty.**when**(container::isShownProperty)); > > > It can also be used to make a listener only actively listen when a > condition is met (the listener is added/removed immediately when the > condition changes, facilitating GC): > > // listen to changes of longLivedProperty when container is shown: > longLivedProperty.when(container::isShownProperty) > .addListener((obs, old, current) -> { ... change listener > ... }); > > Or it can be used to disable updates temporarily (or permanently): > > BooleanProperty allowUpdates = new SimpleBooleanProperty(true) > > // keeps text property in sync when updates are allowed: > name.textProperty().bind(model.title.when(allowUpdates)); > detail.textProperty().bind(model.subtitle.when(allowUpdates)); > asyncImageProperty.imageHandleProperty().bind(model.imageHandle.when(allowUpdates)); > > > This last example can be useful in Skin#dispose, but has uses outside > of skins as well, for example when you want to prevent updates until > things have settled down. > > Thanks for reading! > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Nov 14 18:22:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 14 Nov 2022 18:22:39 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 20:11:55 GMT, Andy Goryachev wrote: >> A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. >> >> Solution: initialize the derived color to transparent earlier to suppress the exception. >> >> This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8291853: review comments Let's do file a follow-up bug. ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Mon Nov 14 18:25:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 18:25:39 GMT Subject: Integrated: 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 19:36:46 GMT, Andy Goryachev wrote: > Using new Skin.install() method to properly set and remove inputMethodRequests property in TextInputControl. > > This avoids memory leaks resulting from skin change, as well as honors user-set properties when installing an uninstalling. > > This PR depends on [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) Skin.install(). This pull request has now been integrated. Changeset: a13630fb Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/a13630fba8854b84516a089ff67e4c0c4c01ff79 Stats: 203 lines in 2 files changed: 118 ins; 40 del; 45 mod 8268877: TextInputControlSkin: incorrect inputMethod event handler after switching skin Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.org/jfx/pull/903 From angorya at openjdk.org Mon Nov 14 18:25:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 18:25:46 GMT Subject: Integrated: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:52:50 GMT, Andy Goryachev wrote: > A race condition exists where a derived color depends on another derived color which has not been yet defined or processed. The only side effect of this condition is a ClassCastException - the color eventually gets resolved. > > Solution: initialize the derived color to transparent earlier to suppress the exception. > > This was also a test bug https://bugs.openjdk.org/browse/JDK-8198604 This pull request has now been integrated. Changeset: 7ec0852c Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7ec0852cca60a4093db0f68cf91da1291a9cf978 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Mon Nov 14 19:35:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 19:35:53 GMT Subject: RFR: 8291853: [CSS] ClassCastException in CssStyleHelper calculateValue [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 18:20:26 GMT, Kevin Rushforth wrote: > Let's do file a follow-up bug. [JDK-8296825](https://bugs.openjdk.org/browse/JDK-8296825) ------------- PR: https://git.openjdk.org/jfx/pull/947 From angorya at openjdk.org Mon Nov 14 20:18:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 20:18:30 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 10:20:59 GMT, Ajit Ghaisas 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 24 additional commits since the last revision: >> >> - 8294809: review comments >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: whitespace >> - 8294809: no public api >> - 8294809: map change listener >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: generics >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8294809: removed weak listeners support >> - ... and 14 more: https://git.openjdk.org/jfx/compare/a53372a1...470f42c1 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TestListenerHelper.java line 94: > >> 92: >> 93: @Test >> 94: public void testChangeListener_MultipleProperties() { > > Should we address a hypothetical use case where the `ListenerHelper` has added a ChangeListener for 2 properties as done in this test case and wants to remove only ChangeListener for p1? > currently `h.disconnet()` removes ChangeListener of both the properties. If this is a requirement, then multi-property method `addChangeListener(Runnable, ObservableValue ...)` should not be used. Instead, use a normal `addChangeListener(ObservableValue, *)` and its return `IDisconnectable` to remove the listener. An example use case for multi-property method is listening for both width and height properties to update a shape or recalculate an area. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Mon Nov 14 20:23:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 20:23:09 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v10] In-Reply-To: References: Message-ID: <-VdfOaxo31bCdehyZGWWfL8-EWUl3GJj_rJ_pCc2frQ=.5ebf2074-7156-48a4-b4f8-e565afe243d1@github.com> > Introduction > > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). > > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > Proposal > > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: > > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. > - keeps track of the listeners and the corresponding ObservableValues > - provides a single disconnect() method to remove all the listeners in one go. > - optionally, it should be possible to add a lambda (Runnable) to a group of properties > - optionally, there should be a boolean flag to fire the lambda immediately > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method > > Make it Public Later > > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. > > Where It Will Be Useful > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. > > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft > > https://github.com/openjdk/jfx/pull/914 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 26 additional commits since the last revision: - 8294809: review comments - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - 8294809: review comments - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - 8294809: whitespace - 8294809: no public api - 8294809: map change listener - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - 8294809: generics - 8294809: is alive - ... and 16 more: https://git.openjdk.org/jfx/compare/a47e8f3e...2a295c24 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/908/files - new: https://git.openjdk.org/jfx/pull/908/files/470f42c1..2a295c24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=08-09 Stats: 1962 lines in 134 files changed: 1588 ins; 292 del; 82 mod Patch: https://git.openjdk.org/jfx/pull/908.diff Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908 PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Mon Nov 14 20:23:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 20:23:11 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 09:08:11 GMT, Ajit Ghaisas 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 24 additional commits since the last revision: >> >> - 8294809: review comments >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: whitespace >> - 8294809: no public api >> - 8294809: map change listener >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: generics >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8294809: removed weak listeners support >> - ... and 14 more: https://git.openjdk.org/jfx/compare/02f51b53...470f42c1 > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 87: > >> 85: >> 86: public static ListenerHelper get(SkinBase skin) { >> 87: return accessor.apply(skin); > > `accessor` can be `null` and needs to be checked. I don't think this is the case. When this method is called, SkinBase class must be already loaded and resolved, that means it's static { } block, which sets the accessor, has been executed. But just in case, I should move the static block in SkinBase, so we don't have any surprises. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Mon Nov 14 20:29:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 14 Nov 2022 20:29:12 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 10:32:47 GMT, Ajit Ghaisas 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 24 additional commits since the last revision: >> >> - 8294809: review comments >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: whitespace >> - 8294809: no public api >> - 8294809: map change listener >> - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper >> - 8294809: generics >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8294809: removed weak listeners support >> - ... and 14 more: https://git.openjdk.org/jfx/compare/8cec4ed6...470f42c1 > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 70: > >> 68: * >> 69: */ >> 70: public class ListenerHelper implements IDisconnectable { > > This class is mixing two things- > 1. Managing listeners in a generic way - by providing ability to add & removeAll (via disconnect()) > 2. Trying to cater to *Skin specific requirement > > Ideally, (2) above should be done separately. I mean, the class ListenerHelper should not use `SkinBase`. > What do you think? you are correct: the original intent for this class was to make it a general purpose facility to help with listeners, something that might be useful at the application level (and it used `ListenerHelper.get(Node)`). Since that would require CSR and a public discussion, we decided to hide it as an implementation detail in skins (to unblock skin memory leak fixes). Once we go through all the necessary discussions and everyone agrees, we could introduce it as a public API in the javafx.base module. ------------- PR: https://git.openjdk.org/jfx/pull/908 From kcr at openjdk.org Mon Nov 14 21:16:04 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 14 Nov 2022 21:16:04 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 20:19:09 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 87: >> >>> 85: >>> 86: public static ListenerHelper get(SkinBase skin) { >>> 87: return accessor.apply(skin); >> >> `accessor` can be `null` and needs to be checked. > > I don't think this is the case. > When this method is called, SkinBase class must be already loaded and resolved, that means it's static { } block, which sets the accessor, has been executed. But just in case, I should move the static block in SkinBase, so we don't have any surprises. Right, there is no way the accessor can be null, since it is initialized at class load time in the static initializer, We do this in many other places (e.g., Node.java). ------------- PR: https://git.openjdk.org/jfx/pull/908 From kcr at openjdk.org Mon Nov 14 21:31:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 14 Nov 2022 21:31:19 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 20:26:54 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ListenerHelper.java line 70: >> >>> 68: * >>> 69: */ >>> 70: public class ListenerHelper implements IDisconnectable { >> >> This class is mixing two things- >> 1. Managing listeners in a generic way - by providing ability to add & removeAll (via disconnect()) >> 2. Trying to cater to *Skin specific requirement >> >> Ideally, (2) above should be done separately. I mean, the class ListenerHelper should not use `SkinBase`. >> What do you think? > > you are correct: the original intent for this class was to make it a general purpose facility to help with listeners, something that might be useful at the application level (and it used `ListenerHelper.get(Node)`). Since that would require CSR and a public discussion, we decided to hide it as an implementation detail in skins (to unblock skin memory leak fixes). > > Once we go through all the necessary discussions and everyone agrees, we could introduce it as a public API in the javafx.base module. Exactly. In its current form, `ListenerHelper` is a utility helper class for Skins, and should be reviewed with that in mind. As discussed in previous comments, there are several things that will need to change when/if this is proposed as a more general utility. We can defer that discussion, since this is entirely an internal helper class for now. As a next step, after this is integrated and before any discussion of making this a public utility, it can be used as a replacement for `LambdaMultiplePropertyChangeListenerHandler` -- see [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076). ------------- PR: https://git.openjdk.org/jfx/pull/908 From thiago.sayao at gmail.com Tue Nov 15 00:14:01 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 14 Nov 2022 21:14:01 -0300 Subject: Plans for gtk glass backend In-Reply-To: <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> References: <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> Message-ID: I took a look at it, and It seems "by design". Child stages can be larger, it just can't cover the desktop bar. If you run in a kiosk style setup you can probably hide the bar. It makes sense to me from a security perspective. -- Thiago. Em seg., 14 de nov. de 2022 ?s 11:25, John Hendrikx escreveu: > I have an issue related to child stages not being allowed to be as large > as their parent stage under Linux. It's somewhere fairly deep in the > system, and I was wondering if that would be near these things you are > planning to do. I wouldn't know myself how to fix it, but can help > where I can: > > https://bugs.openjdk.org/browse/JDK-8248435 > > If not, that's fine :) > > --John > > On 14/11/2022 13:54, Thiago Milczarek Say?o wrote: > > Hi, > > > > I have some plans to work on gtk glass backend, not necessarily in > > this order: > > > > 1) Unify WindowContextBase and WindowContextTop - those were separated > > for applet support that were removed > > 2) Remove gtk2 Support > > 3) Add gesture support > > 4) Rework AlwaysOnTop, exploring _NET_WM_STATE_ABOVE > > 5) Fix DND: JDK-8273379, JDK-8280383 > > > > Some depend on [1]. > > > > I don't promise I will finish all of them, but it's the intention. > > > > Comments are welcome. > > > > [1] https://github.com/openjdk/jfx/pull/915 - 8260528: Clean glass-gtk > > sizing and positioning code > > > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Nov 15 00:37:52 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 15 Nov 2022 02:37:52 +0200 Subject: Plans for gtk glass backend In-Reply-To: References: <2a75d010-8ac4-d88a-50ee-49375e8efdd6@gmail.com> Message-ID: Is https://bugs.openjdk.org/browse/JDK-8275033 related? On Tue, Nov 15, 2022 at 2:14 AM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > I took a look at it, and It seems "by design". > Child stages can be larger, it just can't cover the desktop bar. > If you run in a kiosk style setup you can probably hide the bar. > > It makes sense to me from a security perspective. > > -- Thiago. > > Em seg., 14 de nov. de 2022 ?s 11:25, John Hendrikx < > john.hendrikx at gmail.com> escreveu: > >> I have an issue related to child stages not being allowed to be as large >> as their parent stage under Linux. It's somewhere fairly deep in the >> system, and I was wondering if that would be near these things you are >> planning to do. I wouldn't know myself how to fix it, but can help >> where I can: >> >> https://bugs.openjdk.org/browse/JDK-8248435 >> >> If not, that's fine :) >> >> --John >> >> On 14/11/2022 13:54, Thiago Milczarek Say?o wrote: >> > Hi, >> > >> > I have some plans to work on gtk glass backend, not necessarily in >> > this order: >> > >> > 1) Unify WindowContextBase and WindowContextTop - those were separated >> > for applet support that were removed >> > 2) Remove gtk2 Support >> > 3) Add gesture support >> > 4) Rework AlwaysOnTop, exploring _NET_WM_STATE_ABOVE >> > 5) Fix DND: JDK-8273379, JDK-8280383 >> > >> > Some depend on [1]. >> > >> > I don't promise I will finish all of them, but it's the intention. >> > >> > Comments are welcome. >> > >> > [1] https://github.com/openjdk/jfx/pull/915 - 8260528: Clean glass-gtk >> > sizing and positioning code >> > >> > -- Thiago. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Tue Nov 15 02:09:10 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 15 Nov 2022 02:09:10 GMT Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix controls classpath I updated https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse. ------------- PR: https://git.openjdk.org/jfx/pull/930 From aghaisas at openjdk.org Tue Nov 15 06:40:19 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 15 Nov 2022 06:40:19 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Mon, 14 Nov 2022 21:26:52 GMT, Kevin Rushforth wrote: >> you are correct: the original intent for this class was to make it a general purpose facility to help with listeners, something that might be useful at the application level (and it used `ListenerHelper.get(Node)`). Since that would require CSR and a public discussion, we decided to hide it as an implementation detail in skins (to unblock skin memory leak fixes). >> >> Once we go through all the necessary discussions and everyone agrees, we could introduce it as a public API in the javafx.base module. > > Exactly. In its current form, `ListenerHelper` is a utility helper class for Skins, and should be reviewed with that in mind. As discussed in previous comments, there are several things that will need to change when/if this is proposed as a more general utility. We can defer that discussion, since this is entirely an internal helper class for now. > > As a next step, after this is integrated and before any discussion of making this a public utility, it can be used as a replacement for `LambdaMultiplePropertyChangeListenerHandler` -- see [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076). Although it is an internal (non-public) utility class, once introduced, it will be tempting to use it from non-Skin code as well. If the current scope is limited to provide "a utility helper class for Skins" then how about doing one of two things- 1) Mention the current intention and possible future modifications as a block comment above the `ListenerHelper` class 2) Keep only common methods in`ListenerHelper` class and move `Skin` specific code to a class derived from `ListenerHelper`. Skins should start using this derived class. >> I don't think this is the case. >> When this method is called, SkinBase class must be already loaded and resolved, that means it's static { } block, which sets the accessor, has been executed. But just in case, I should move the static block in SkinBase, so we don't have any surprises. > > Right, there is no way the accessor can be null, since it is initialized at class load time in the static initializer, We do this in many other places (e.g., Node.java). The `accessor` cannot be null **only if** it is used from *Skins. In the current form, as we provide a no-argument public constructor, it is possible to create an object of `ListenerHelper` without calling setAccessor. Many unit tests added as part of this PR create such `ListenerHelper` objects. ------------- PR: https://git.openjdk.org/jfx/pull/908 From jhendrikx at openjdk.org Tue Nov 15 09:03:11 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 15 Nov 2022 09:03:11 GMT Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: <-UIDjNbrAxtFMlYz5HksM5HkoT_q4ReqgaAMhlhcLaM=.c1529b49-040f-44cd-a462-7080c55c3714@github.com> On Tue, 15 Nov 2022 02:05:33 GMT, Nir Lisker wrote: > I updated https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse. Looks good, nicely explained :) ------------- PR: https://git.openjdk.org/jfx/pull/930 From kevin.rushforth at oracle.com Tue Nov 15 12:48:07 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Nov 2022 04:48:07 -0800 Subject: Discussion: Naming API method In-Reply-To: References: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> <97cc19ef-675a-571e-783c-c076e9409120@oracle.com> Message-ID: While rereading the proposed docs for the new method, the following stood out to me: "The returned ObservableValue only observes this value when condition holds true." So I agree that "updateWhen" isn't really accurate, but I don't care for "onCondition" either. I think "whenever" would be OK, but what about "observesWhen" (or maybe "observedWhen") as a name? -- Kevin On 11/14/2022 9:47 AM, Andy Goryachev wrote: > > I'd pick "whenever" or "onCondition". > > "updateWhen" sounds like an update, which I think it is not.? "when" > seems too vague. > > Disclaimer: English is not my native language. > > -andy > > *From: *openjfx-dev on behalf of Kevin > Rushforth > *Date: *Monday, 2022/11/14 at 09:40 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Discussion: Naming API method > > I also think this will be a useful feature to get into JavaFX. > > As for the name of the method, the only one of them I don't like is > "conditionOn". That name doesn't suggest (to me anyway) what its purpose > is. I think any of the ones with "when" in the name would work. I have a > slight preference for "updateWhen", but could be talked into one of the > others. > > -- Kevin > > > On 11/14/2022 6:52 AM, John Hendrikx wrote: > > Hi, > > > > I'm working on https://github.com/openjdk/jfx/pull/830 where I asked > > for some opinions on the naming of a new method I'd like to introduce > > in ObservableValue. > > > > I wrote a (perhaps too large) comment about the possible names and > > rationales: > > https://github.com/openjdk/jfx/pull/830#issuecomment-1304846220 > > > > I'd like to ask what others think what would be a good name for this > > new method (Observable#when in the PR) in order to move the PR > > forward, as I think it offers a very compelling feature to JavaFX > > (moving from weak reference to deterministic behavior when it comes to > > listener management).? My opinion has always been that using weak > > listeners for listener management is a crutch that relies far too much > > on the internal workings of the JVM and Garbage Collector which offer > > no guarantees as to the timely clean up of these references and the > > listeners related to them. > > > > Leading contenders are (but not limited to these, if you have a better > > name): > > > > 1) conditionOn > > > > 2) updateWhen > > > > 3) when > > > > 4) whenever > > > > Usage in code is nearly always going to be something like these > > constructs: > > > > ????? // keeps text property in sync with longLivedProperty when label > > is shown: > > > label.textProperty().bind(longLivedProperty.**when**(label::isShownProperty)); > > > > > > > ????? // keeps text property in sync with longLivedProperty when > > container is shown: > > > label.textProperty().bind(longLivedProperty.**when**(container::isShownProperty)); > > > > > > It can also be used to make a listener only actively listen when a > > condition is met (the listener is added/removed immediately when the > > condition changes, facilitating GC): > > > > ????? // listen to changes of longLivedProperty when container is shown: > > longLivedProperty.when(container::isShownProperty) > > ??????????? .addListener((obs, old, current) -> { ... change listener > > ... }); > > > > Or it can be used to disable updates temporarily (or permanently): > > > > ??????? BooleanProperty allowUpdates = new SimpleBooleanProperty(true) > > > > ??????? // keeps text property in sync when updates are allowed: > > name.textProperty().bind(model.title.when(allowUpdates)); > > detail.textProperty().bind(model.subtitle.when(allowUpdates)); > > > asyncImageProperty.imageHandleProperty().bind(model.imageHandle.when(allowUpdates)); > > > > > > This last example can be useful in Skin#dispose, but has uses outside > > of skins as well, for example when you want to prevent updates until > > things have settled down. > > > > Thanks for reading! > > > > --John > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Nov 15 12:56:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 15 Nov 2022 12:56:06 GMT Subject: RFR: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed In-Reply-To: References: Message-ID: <5jfSj4MbG5wI4X25O4Op9wPM-t-aMONcLZ9sMRm902I=.37384f34-9bb6-423d-ab49-f734fb4502a5@github.com> On Wed, 9 Nov 2022 10:08:28 GMT, pandaapo wrote: > Fixes [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) Now that [JDK-8285503](https://bugs.openjdk.org/browse/JDK-8285503) has been fixed, [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) has been closed as "not an issue". I am therefore closing this PR. ------------- PR: https://git.openjdk.org/jfx/pull/942 From kcr at openjdk.org Tue Nov 15 12:56:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 15 Nov 2022 12:56:06 GMT Subject: Withdrawn: 8296618: Skip failing test SwingNodeDnDMemoryLeakTest until JDK-8285503 is fixed In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:08:28 GMT, pandaapo wrote: > Fixes [JDK-8296618](https://bugs.openjdk.org/browse/JDK-8296618) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/942 From kcr at openjdk.org Tue Nov 15 14:25:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 15 Nov 2022 14:25:56 GMT Subject: RFR: 8297042: gradle -PBUILD_SDK_FOR_TEST=false fails with gradle 7.6 Message-ID: This PR fixes our `build.gradle` script so it can work with gradle 7.6. When doing a test build with gradle 7.6 RC3: $ gradle sdk $ gradle --info -PBUILD_SDK_FOR_TEST=false test We get the following error: FAILURE: Build failed with an exception. * Where: Build file 'C:\Users\kcr\javafx\jfx-kcr\jfx\rt\build.gradle' line: 615 * What went wrong: A problem occurred evaluating root project 'rt'. > No signature of method: org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.useFilter() is applicable for argument types: (build_32ube911nql8mvr8torfp363j$_run_closure1) values: [build_32ube911nql8mvr8torfp363j$_run_closure1 at 1679a7fe] As noted in JBS, setting the gradle `-PBUILD_SDK_FOR_TEST=false` flag can be used when running tests to avoid a complete build of the sdk. The fix is to remove the use of `gradle.taskGraph.useFilter`, which is not public API, but is an implementation detail that happened to "work" up until recently, but stopped working some time between gradle 7.3 and gradle 7.6. I say "work" in quotes, because there is effectively no difference in what gets run because of the dependency on the shims. The following two GHA test runs show the problem when running with gradle 7.6 RC3 and the fix: [test-build-gradle-7.6](https://github.com/kevinrushforth/jfx/actions/runs/3470969280) : test build run using gradle 7.6 RC3 without the fix from this PR; it fails as expected [test-build-gradle-7.6+8297042](https://github.com/kevinrushforth/jfx/actions/runs/3470983142) : test build run using gradle 7.6 RC3 without the fix from this PR; it passes on all platforms Additionally, the GHA test run for _this_ PR shows that it works fine with gradle 7.3. ------------- Commit messages: - 8297042: gradle -PBUILD_SDK_FOR_TEST=false fails with gradle 7.6 Changes: https://git.openjdk.org/jfx/pull/949/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297042 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/949.diff Fetch: git fetch https://git.openjdk.org/jfx pull/949/head:pull/949 PR: https://git.openjdk.org/jfx/pull/949 From andy.goryachev at oracle.com Tue Nov 15 16:54:48 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 15 Nov 2022 16:54:48 +0000 Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: Nir, thank you so much! A few minor corrections might be needed. in Import the Eclipse Projects: - the screenshots are outdated, using much older version of Eclipse, the UI has been changed a bit. The latest Eclipse won't work with java19 without a separate plugin, but i am sure they will fix it soon. - there is an option to 'ignore projects already in the workspace' and I think it must be turned on (I was getting a warning). - we probably should mention that the gradle build should be run after initial checkout, including sdk and apps. This will load and build the dependencies (lucene). Perhaps we should also add a section dedicated to configuring error levels, as the default configuration turns off important warnings and enables too many unimportant ones. Thank you again -andy From: openjfx-dev on behalf of Nir Lisker Date: Monday, 2022/11/14 at 18:09 To: openjfx-dev at openjdk.org Subject: Re: RFR: 8221708 Update Eclipse project files [v4] On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix controls classpath I updated https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse. ------------- PR: https://git.openjdk.org/jfx/pull/930 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Nov 15 17:44:06 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 15 Nov 2022 19:44:06 +0200 Subject: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: > > - the screenshots are outdated, using much older version of Eclipse, the > UI has been changed a bit. The latest Eclipse won't work with java19 > without a separate plugin, but i am sure they will fix it soon. > Yes, I will need to delete all the projects and re-import in order to create the new screenshot. The separate plugin support is explained under "Configure Eclipse to use the latest JDK". Each Eclipse release requires a plugin for the simultaneously released Java version, It is "fixed" in the next version, but then you need another plugin for the new release. - there is an option to 'ignore projects already in the workspace' and I > think it must be turned on (I was getting a warning). > If you are importing for the first time, no project will already be in the workspace, so it doesn't matter. If you are re-importing it's up to you if you want to ignore them or not, I would say. - we probably should mention that the gradle build should be run after > initial checkout, including *sdk* and *apps*. This will load and build > the dependencies (lucene). > That is explained in the main page - https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX, or at least should be, as it isn't an Eclipse-specific step. There is a mention of this in the Using Eclipse section. On Tue, Nov 15, 2022 at 6:54 PM Andy Goryachev wrote: > Nir, thank you so much! > > > > A few minor corrections might be needed. > > > > in Import the Eclipse Projects: > > - the screenshots are outdated, using much older version of Eclipse, the > UI has been changed a bit. The latest Eclipse won't work with java19 > without a separate plugin, but i am sure they will fix it soon. > > - there is an option to 'ignore projects already in the workspace' and I > think it must be turned on (I was getting a warning). > > - we probably should mention that the gradle build should be run after > initial checkout, including *sdk* and *apps*. This will load and build > the dependencies (lucene). > > > > Perhaps we should also add a section dedicated to configuring error > levels, as the default configuration turns off important warnings and > enables too many unimportant ones. > > > > Thank you again > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Nir > Lisker > *Date: *Monday, 2022/11/14 at 18:09 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: RFR: 8221708 Update Eclipse project files [v4] > > On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx > wrote: > > >> See https://bugs.openjdk.org/browse/JDK-8221708 > > > > John Hendrikx has updated the pull request incrementally with one > additional commit since the last revision: > > > > Fix controls classpath > > I updated > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse > . > > ------------- > > PR: https://git.openjdk.org/jfx/pull/930 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Nov 15 18:20:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 15 Nov 2022 18:20:14 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Tue, 15 Nov 2022 06:17:21 GMT, Ajit Ghaisas wrote: >> Right, there is no way the accessor can be null, since it is initialized at class load time in the static initializer, We do this in many other places (e.g., Node.java). > > The `accessor` cannot be null **only if** it is used from *Skins. > In the current form, as we provide a no-argument public constructor, it is possible to create an object of `ListenerHelper` without calling setAccessor. Many unit tests added as part of this PR create such `ListenerHelper` objects. The `accessor` is used **only** if used from *Skins, meaning to get it from a Skin, one needs to invoke `get(SkinBase)` method, and it's magically not a null there! It is perfectly fine to create an instance of ListenerHelper using the constructor. The `accessor` will be null, of course, but it's ok because it will never be used until one calls `get(SkinBase)` ... and see above. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Tue Nov 15 18:27:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 15 Nov 2022 18:27:12 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: On Tue, 15 Nov 2022 06:35:05 GMT, Ajit Ghaisas wrote: >> Exactly. In its current form, `ListenerHelper` is a utility helper class for Skins, and should be reviewed with that in mind. As discussed in previous comments, there are several things that will need to change when/if this is proposed as a more general utility. We can defer that discussion, since this is entirely an internal helper class for now. >> >> As a next step, after this is integrated and before any discussion of making this a public utility, it can be used as a replacement for `LambdaMultiplePropertyChangeListenerHandler` -- see [JDK-8296076](https://bugs.openjdk.org/browse/JDK-8296076). > > Although it is an internal (non-public) utility class, once introduced, it will be tempting to use it from non-Skin code as well. > If the current scope is limited to provide "a utility helper class for Skins" then how about doing one of two things- > 1) Mention the current intention and possible future modifications as a block comment above the `ListenerHelper` class > 2) Keep only common methods in`ListenerHelper` class and move `Skin` specific code to a class derived from `ListenerHelper`. Skins should start using this derived class. added comment for #1 option. ------------- PR: https://git.openjdk.org/jfx/pull/908 From angorya at openjdk.org Tue Nov 15 18:30:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 15 Nov 2022 18:30:33 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v11] In-Reply-To: References: Message-ID: > Introduction > > There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). > > This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance > https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java > > Proposal > > It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: > > - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. > - keeps track of the listeners and the corresponding ObservableValues > - provides a single disconnect() method to remove all the listeners in one go. > - optionally, it should be possible to add a lambda (Runnable) to a group of properties > - optionally, there should be a boolean flag to fire the lambda immediately > - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method > > Make it Public Later > > Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. > > Where It Will Be Useful > > [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" > and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. > > https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft > > https://github.com/openjdk/jfx/pull/914 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294809: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/908/files - new: https://git.openjdk.org/jfx/pull/908/files/2a295c24..8cef69c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=908&range=09-10 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/908.diff Fetch: git fetch https://git.openjdk.org/jfx pull/908/head:pull/908 PR: https://git.openjdk.org/jfx/pull/908 From michaelstrau2 at gmail.com Tue Nov 15 18:38:50 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 15 Nov 2022 19:38:50 +0100 Subject: Discussion: Naming API method In-Reply-To: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> References: <137fd6a4-8a7f-7234-47c6-16e04758fa3a@gmail.com> Message-ID: The new operation returns a new ObservableValue that is only meaningfully "exists" when the condition holds. If the condition doesn't hold, the effect is as if the operation wasn't invoked at all, i.e. it doesn't meaningfully exist. With this in mind, here's another option: label.textProperty().bind(longLivedProperty.withScope(container::isShownProperty)); On Mon, Nov 14, 2022 at 3:53 PM John Hendrikx wrote: > > Hi, > > I'm working on https://github.com/openjdk/jfx/pull/830 where I asked for > some opinions on the naming of a new method I'd like to introduce in > ObservableValue. > > I wrote a (perhaps too large) comment about the possible names and > rationales: https://github.com/openjdk/jfx/pull/830#issuecomment-1304846220 > > I'd like to ask what others think what would be a good name for this new > method (Observable#when in the PR) in order to move the PR forward, as I > think it offers a very compelling feature to JavaFX (moving from weak > reference to deterministic behavior when it comes to listener > management). My opinion has always been that using weak listeners for > listener management is a crutch that relies far too much on the internal > workings of the JVM and Garbage Collector which offer no guarantees as > to the timely clean up of these references and the listeners related to > them. > > Leading contenders are (but not limited to these, if you have a better > name): > > 1) conditionOn > > 2) updateWhen > > 3) when > > 4) whenever > > Usage in code is nearly always going to be something like these constructs: > > // keeps text property in sync with longLivedProperty when label > is shown: > label.textProperty().bind(longLivedProperty.**when**(label::isShownProperty)); > > // keeps text property in sync with longLivedProperty when > container is shown: > label.textProperty().bind(longLivedProperty.**when**(container::isShownProperty)); > > > It can also be used to make a listener only actively listen when a > condition is met (the listener is added/removed immediately when the > condition changes, facilitating GC): > > // listen to changes of longLivedProperty when container is shown: > longLivedProperty.when(container::isShownProperty) > .addListener((obs, old, current) -> { ... change listener > ... }); > > Or it can be used to disable updates temporarily (or permanently): > > BooleanProperty allowUpdates = new SimpleBooleanProperty(true) > > // keeps text property in sync when updates are allowed: > name.textProperty().bind(model.title.when(allowUpdates)); > detail.textProperty().bind(model.subtitle.when(allowUpdates)); > asyncImageProperty.imageHandleProperty().bind(model.imageHandle.when(allowUpdates)); > > This last example can be useful in Skin#dispose, but has uses outside of > skins as well, for example when you want to prevent updates until things > have settled down. > > Thanks for reading! > > --John > > From kcr at openjdk.org Tue Nov 15 23:06:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 15 Nov 2022 23:06:28 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test This will need to be carefully tested on all platforms, since `WindowStage::requestFocus` will no longer ever be called when a Stage is first created and shown. If it isn't doing anything useful (which seems the case on Linux), then in practice, this might not matter, but that's where the testing comes in. ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Wed Nov 16 00:05:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 00:05:06 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests Message-ID: 1. Introduced the following utility methods: - Util.launch - Util.shutdown - Util.waitForLatch 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. 3. Replaced local waitForLatch copies with Util.waitForLatch ------------- Commit messages: - 8206430: wait for latch - 8206430: exit test - 8206430: wait for latch - 8206430: t..w - 8206430: r..s - 8206430: h..p - 8206430: util.shutdown - 8206430: c..f - 8206430: util.launch Changes: https://git.openjdk.org/jfx/pull/950/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8206430 Stats: 2255 lines in 91 files changed: 603 ins; 1094 del; 558 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 00:15:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 00:15:33 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: References: Message-ID: <8ThN61nMISbEV-05IeBEfDsfsbLUTYqyxsWBaFeiw7s=.bc2db128-4d30-4d35-9178-e582d57c5ff9@github.com> On Tue, 15 Nov 2022 18:00:59 GMT, Andy Goryachev wrote: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch This is a large enough change that it really could use two reviewers. ------------- PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 01:10:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 01:10:29 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:00:59 GMT, Andy Goryachev wrote: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch I left a couple quick comments on the new utility methods in `test.util.Util`. Have you run a full test (including robot) on all three platforms? > Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. I am not aware of any out of order calls. Perhaps you are referring to the following pattern: Platform.runLater(() -> stage.hide()); Platform.exit(); That is actually valid, since `Platform.exit()` can be called on any thread. The FX runtime doesn't exit until all pending runnables are run. Doing the exit on the FX application thread is fine, too. tests/system/src/test/java/test/util/Util.java line 317: > 315: * @param args - command line arguments > 316: */ > 317: public static void launch ( This looks like a useful utility. I think it would be helpful to either remove the timeout parameter entirely, or else have a variant of this that doesn't take the timeout value, and use a default timeout value. Most tests use 10 or 15 seconds so standardizing on 15 seems reasonable. Also, many of the tests use `Platform.startup` since they don't need to launch an application. Have you looked at providing a similar utility method for those cases? tests/system/src/test/java/test/util/Util.java line 338: > 336: public static void shutdown(Stage... stages) { > 337: // why isn't runAndWait() exposed as a public API? > 338: PlatformImpl.runAndWait(() -> { Not providing a public `runAndWait` was a deliberate choice. In any case, tests or utilities that need to wait should use the `runAndWait` method in this Util class in preference to `PlatformImpl`. For one thing it will throw exceptions back to the caller where as the `PlatformImpl` method will not. I think `Platform.runLater` should be sufficient here, but as long as the tests are still stable when using `runAndWait`, I don't have a strong objection. ------------- PR: https://git.openjdk.org/jfx/pull/950 From jvos at openjdk.org Wed Nov 16 08:22:50 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 16 Nov 2022 08:22:50 GMT Subject: [jfx17u] RFR: 8290348: TreeTableView jumping to top Message-ID: Clean backport of 8290348: TreeTableView jumping to top Reviewed-by: aghaisas, kcr ------------- Commit messages: - 8290348: TreeTableView jumping to top Changes: https://git.openjdk.org/jfx17u/pull/89/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=89&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290348 Stats: 81 lines in 2 files changed: 46 ins; 11 del; 24 mod Patch: https://git.openjdk.org/jfx17u/pull/89.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/89/head:pull/89 PR: https://git.openjdk.org/jfx17u/pull/89 From aghaisas at openjdk.org Wed Nov 16 08:30:48 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 16 Nov 2022 08:30:48 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: References: Message-ID: <8FXt7jCUTjf15HTMpzuXOxvbsLao1jWw5wgvX19zXeI=.c922571e-a7bd-46c4-b865-633b13ef77f6@github.com> On Tue, 15 Nov 2022 18:00:59 GMT, Andy Goryachev wrote: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch Overall this looks good. Thanks for addressing this. This is resulting in two test failures when run as a FULL system test run on my macBook with macOS 11.7.1. - test.javafx.scene.web.ColorChooserTest.testColorChooser() - test.robot.javafx.scene.ComboBoxTest.testComboBoxSceneChange1() ------------- PR: https://git.openjdk.org/jfx/pull/950 From arapte at openjdk.org Wed Nov 16 09:42:19 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 16 Nov 2022 09:42:19 GMT Subject: RFR: 8296330: Tests: Add layout container snapping tests [v6] In-Reply-To: References: Message-ID: <6gOOn85LEeV0-kRGhlKsBjM1rAERwzdyx4EoXVE1OhA=.73f66ddd-8a98-423c-afea-4474adfebcec@github.com> On Thu, 10 Nov 2022 16:46:53 GMT, Marius Hanl wrote: >> While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. >> >> The goal of this PR is to add snapping tests for all layout container. >> After that we can create issues for all broken layout container, fix them and comment in the corresponding line. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8296330: Added JDK-8296609 Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/936 From arapte at openjdk.org Wed Nov 16 09:42:11 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 16 Nov 2022 09:42:11 GMT Subject: RFR: 8297042: gradle -PBUILD_SDK_FOR_TEST=false fails with gradle 7.6 In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 14:21:12 GMT, Kevin Rushforth wrote: > This PR fixes our `build.gradle` script so it can work with gradle 7.6. > > When doing a test build with gradle 7.6 RC3: > > > $ gradle sdk > $ gradle --info -PBUILD_SDK_FOR_TEST=false test > > > We get the following error: > > > FAILURE: Build failed with an exception. > > * Where: > Build file 'C:\Users\kcr\javafx\jfx-kcr\jfx\rt\build.gradle' line: 615 > > * What went wrong: > A problem occurred evaluating root project 'rt'. >> No signature of method: org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.useFilter() is applicable for argument types: (build_32ube911nql8mvr8torfp363j$_run_closure1) values: [build_32ube911nql8mvr8torfp363j$_run_closure1 at 1679a7fe] > > > As noted in JBS, setting the gradle `-PBUILD_SDK_FOR_TEST=false` flag can be used when running tests to avoid a complete build of the sdk. > > The fix is to remove the use of `gradle.taskGraph.useFilter`, which is not public API, but is an implementation detail that happened to "work" up until recently, but stopped working some time between gradle 7.3 and gradle 7.6. I say "work" in quotes, because there is effectively no difference in what gets run because of the dependency on the shims. > > The following two GHA test runs show the problem when running with gradle 7.6 RC3 and the fix: > > [test-build-gradle-7.6](https://github.com/kevinrushforth/jfx/actions/runs/3470969280) : test build run using gradle 7.6 RC3 without the fix from this PR; it fails as expected > [test-build-gradle-7.6+8297042](https://github.com/kevinrushforth/jfx/actions/runs/3470983142) : test build run using gradle 7.6 RC3 without the fix from this PR; it passes on all platforms > > Additionally, the GHA test run for _this_ PR shows that it works fine with gradle 7.3. Verified on macOS Monterey with gradle 7.3 and 7.6. Behavior looks unchanged with both. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/949 From aghaisas at openjdk.org Wed Nov 16 09:51:07 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 16 Nov 2022 09:51:07 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v11] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:30:33 GMT, Andy Goryachev wrote: >> Introduction >> >> There is a number of places where various listeners (strong as well as weak) are added, to be later disconnected in one go. For example, Skin implementations use dispose() method to clean up the listeners installed in the corresponding Control (sometimes using LambdaMultiplePropertyChangeListenerHandler class). >> >> This pattern is also used by app developers, but there is no public utility class to do that, so every one must invent their own, see for instance >> https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/FxDisconnector.java >> >> Proposal >> >> It might be beneficial to create a class (ListenerHelper, feel free to suggest a better name) which: >> >> - provides convenient methods like addChangeListener, addInvalidationListener, addWeakChangeListener, etc. >> - keeps track of the listeners and the corresponding ObservableValues >> - provides a single disconnect() method to remove all the listeners in one go. >> - optionally, it should be possible to add a lambda (Runnable) to a group of properties >> - optionally, there should be a boolean flag to fire the lambda immediately >> - strongly suggest implementing an IDisconnectable functional interface with a single disconnect() method >> >> Make it Public Later >> >> Initially, I think we could place the new class in package com.sun.javafx.scene.control; to be made publicly accessible later. >> >> Where It Will Be Useful >> >> [JDK-8294589](https://bugs.openjdk.org/browse/JDK-8294589) "MenuBarSkin: memory leak when changing skin" >> and other skins, as a replacement for LambdaMultiplePropertyChangeListenerHandler. >> >> https://github.com/openjdk/jfx/pull/908#:~:text=19%20hours%20ago-,8295175%3A%20SplitPaneSkinSkin%3A%20memory%20leak%20when%20changing%20skin%20%23911,-Draft >> >> https://github.com/openjdk/jfx/pull/914 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8294809: review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/908 From aghaisas at openjdk.org Wed Nov 16 09:51:07 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 16 Nov 2022 09:51:07 GMT Subject: RFR: 8294809: ListenerHelper for managing and disconnecting listeners [v9] In-Reply-To: References: <35YAlUwLKKw2-W9C7vly3S_S2qyaX_aJWmr-6Bs8Cy4=.c4bc33ca-3f75-4c84-9543-ebe7e0ea7ae8@github.com> <7vOXTx9cPXjSpGr0Bi7bHXL-khVDLQLRHXUHCoiA7Ak=.dde962e4-03be-43e0-9a15-0010c359ad63@github.com> Message-ID: <28bVDAnv1NOjlaRgcWURyFASDgzq_lnbFDZtqSOrD9Y=.3fd46e30-f3d7-4ccf-9ac2-91378ac91261@github.com> On Tue, 15 Nov 2022 18:16:20 GMT, Andy Goryachev wrote: >> The `accessor` cannot be null **only if** it is used from *Skins. >> In the current form, as we provide a no-argument public constructor, it is possible to create an object of `ListenerHelper` without calling setAccessor. Many unit tests added as part of this PR create such `ListenerHelper` objects. > > The `accessor` is used **only** if used from *Skins, meaning to get it from a Skin, one needs to invoke `get(SkinBase)` method, and it's magically not a null there! > > It is perfectly fine to create an instance of ListenerHelper using the constructor. The `accessor` will be null, of course, but it's ok because it will never be used until one calls `get(SkinBase)` ... and see above. That is my whole point. We have two paths - one for Skin classes and other for generic usage. Approving the PR as you have added a comment regarding `ListenerHelper` class's current scope being limited to Skins. We may need to revisit the suggestion of having a derived class in future. ------------- PR: https://git.openjdk.org/jfx/pull/908 From aghaisas at openjdk.org Wed Nov 16 11:14:55 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 16 Nov 2022 11:14:55 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: <8yqwuupBm11y9X1T-Uf5dLcnMeKYpAh5cqKbMMku-qQ=.14aaa48e-2045-4815-a23b-fbd3ff087dd2@github.com> On Sat, 2 Jul 2022 05:23:22 GMT, Michael Strau? wrote: >> good catch :) >> >> No review, just a couple of comments: >> >> - other subclasses of MultipleSelectionModelBase might have similar issues >> - the fix gets rid of the error (good!) but might fire incorrect changes (see below) >> - there are quite a lot of open issues related to change notification, some might profit from a fix of this >> - tests, tests, tests .. :) >> >> selectIndices might involve disjoint intervals in the change (even for addition which is unusual in the "normal" implementations of observableLists) >> >> // initial selection, starting from empty >> selectionModel.selectIndices(0, /*1, IMPORTANT: remove some index */ 2, 3); >> System.out.println(change); >> // expected and actual change >> { [0, 2, 3] added at 0 } >> >> // add selection of disjoint indices (assuming a longer items list) >> selectionModel.selectIndices(1, 5, 7); >> System.out.println(change); >> // actual >> { [1, 2, 3] added at 1 } >> // expected >> { [1] added at 1, [5, 7] added at 4 } > > I don't understand how the original code, as well as the proposed solution, can work at all. Let's take @kleopatra's example: > > selectionModel.selectIndices(0, 2, 3); > // ---> expected: { [0, 2, 3] added at 0 } > selectionModel.selectIndices(1, 5, 7); > // ---> expected: { [1] added at 1, [5, 7] added at 4 } > > In order to find the two sub-ranges `[1]` and `[5, 7]`, we need to compare the _newly added_ indices to the _entire_ list of selected indices. Without doing that, we can't just "know" that there are two contiguous sub-ranges in `[1, 5, 7]`. > > However, the algorithm that supposedly tries to do that, doesn't even look at the current list of selected indices (except for a single `indexOf` call, which doesn't do the trick): > > int pos = 0; > int start = 0; > int end = 0; > > // starting from pos, we keep going until the value is > // not the next value > int startValue = sortedNewIndices.get(pos++); > start = indexOf(startValue); > end = start + 1; > int endValue = startValue; > while (pos < size) { > int previousEndValue = endValue; > endValue = sortedNewIndices.get(pos++); > ++end; > if (previousEndValue != (endValue - 1)) { > _nextAdd(start, end); > start = end; > continue; > } > > // special case for when we get to the point where the loop is about to end > // and we have uncommitted changes to fire. > if (pos == size) { > _nextAdd(start, end); > } > } > > I think this algorithm mistakenly finds contiguous ranges within the list of _newly added_ indices, which is not what we want. > > Here is an algorithm that works: > > int startIndex = indexOf(sortedNewIndices.get(0)); > int endIndex = startIndex + 1; > > for (int i = 1; i < sortedNewIndices.size(); ++i) { > int currentValue = get(endIndex); > int currentNewValue = sortedNewIndices.get(i); > if (currentValue != currentNewValue) { > _nextAdd(startIndex, endIndex); > while (get(endIndex) != currentNewValue) ++endIndex; > startIndex = endIndex++; > } else { > ++endIndex; > } > > if (i == sortedNewIndices.size() - 1) { > _nextAdd(startIndex, endIndex); > } > } > > > Unfortunately, even with the working algorithm, the list change notifications are still not correct in all cases due to another (probably unrelated) bug in `SelectedIndicesList.get(int)`: If I remove the optimization that is implemented in that method, and replace it with a simple lookup, the notifications are always correct in my tests: > > @Override public Integer get(int index) { > for (int lastGetIndex = 0, lastGetValue = bitset.nextSetBit(0); > lastGetValue >= 0 || lastGetIndex == index; > lastGetIndex++, lastGetValue = bitset.nextSetBit(lastGetValue + 1)) { > if (lastGetIndex == index) { > return lastGetValue; > } > } > return -1; > } > > > Test 1: > > selectionModel.selectIndices(0, 2, 3); > // ---> { [0, 2, 3] added at 0 } > selectionModel.selectIndices(1, 5, 7); > // ---> { [1] added at 1, [5, 7] added at 4 } > > Test 2: > > selectionModel.selectIndices(1, 3, 4); > // ---> { [1, 3, 4] added at 0 } > selectionModel.selectIndices(0, 5, 7); > // ---> { [0] added at 0, [5, 7] added at 4 } > selectionModel.selectIndices(6, 8, 9); > // ---> { [6] added at 5, [8, 9] added at 7 } @mstr2, can you please review as well? ------------- PR: https://git.openjdk.org/jfx/pull/353 From aghaisas at openjdk.org Wed Nov 16 11:14:53 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 16 Nov 2022 11:14:53 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v5] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Thu, 14 Jul 2022 08:05:25 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK_8256397 > Fixed more issues with the multiple selection model change events, and verified them with more unit-tests. The fix looks good. I have identified minor spacing issues. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 721: > 719: size = -1; > 720: bitset.set(index); > 721: if(index <= lastGetValue) reset(); There should be a space between `if` and `(` modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 744: > 742: if (isSet) { > 743: bitset.set(index, end, isSet); > 744: if(index <= lastGetValue) reset(); There should be a space between `if` and `(` modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 751: > 749: // TODO handle remove > 750: bitset.set(index, end, isSet); > 751: if(index <= lastGetValue) reset(); There should be a space between `if` and `(` modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 827: > 825: size = -1; > 826: bitset.clear(index); > 827: if(index <= lastGetValue) reset(); There should be a space between `if` and `(` ------------- PR: https://git.openjdk.org/jfx/pull/353 From tsayao at openjdk.org Wed Nov 16 12:35:11 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 16 Nov 2022 12:35:11 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test One thing to do is to check if a window is focused when shown on mac and windows (I checked Linux). If it doesn't work a lot of Robot tests will fail - so if tests passes is a good indicator that it's ok. ------------- PR: https://git.openjdk.org/jfx/pull/940 From jvos at openjdk.org Wed Nov 16 12:55:19 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 16 Nov 2022 12:55:19 GMT Subject: [jfx17u] Integrated: 8290348: TreeTableView jumping to top In-Reply-To: References: Message-ID: <3VntPyeiMNFRT9mvNt4tUciSHtiqBfmWFxjJf66zqvU=.e2a340a5-d1d5-4660-9ec6-94d7769b13f1@github.com> On Wed, 16 Nov 2022 08:13:46 GMT, Johan Vos wrote: > Clean backport of 8290348: TreeTableView jumping to top > Reviewed-by: aghaisas, kcr This pull request has now been integrated. Changeset: 73220f43 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/73220f430a94750fedb63ebc26f722d2fc2d5aab Stats: 81 lines in 2 files changed: 46 ins; 11 del; 24 mod 8290348: TreeTableView jumping to top Backport-of: 6da05c2c7ed8f3911a43f51cbce2a5988a011c7d ------------- PR: https://git.openjdk.org/jfx17u/pull/89 From kcr at openjdk.org Wed Nov 16 13:06:44 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 13:06:44 GMT Subject: Integrated: 8297042: gradle -PBUILD_SDK_FOR_TEST=false fails with gradle 7.6 In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 14:21:12 GMT, Kevin Rushforth wrote: > This PR fixes our `build.gradle` script so it can work with gradle 7.6. > > When doing a test build with gradle 7.6 RC3: > > > $ gradle sdk > $ gradle --info -PBUILD_SDK_FOR_TEST=false test > > > We get the following error: > > > FAILURE: Build failed with an exception. > > * Where: > Build file 'C:\Users\kcr\javafx\jfx-kcr\jfx\rt\build.gradle' line: 615 > > * What went wrong: > A problem occurred evaluating root project 'rt'. >> No signature of method: org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.useFilter() is applicable for argument types: (build_32ube911nql8mvr8torfp363j$_run_closure1) values: [build_32ube911nql8mvr8torfp363j$_run_closure1 at 1679a7fe] > > > As noted in JBS, setting the gradle `-PBUILD_SDK_FOR_TEST=false` flag can be used when running tests to avoid a complete build of the sdk. > > The fix is to remove the use of `gradle.taskGraph.useFilter`, which is not public API, but is an implementation detail that happened to "work" up until recently, but stopped working some time between gradle 7.3 and gradle 7.6. I say "work" in quotes, because there is effectively no difference in what gets run because of the dependency on the shims. > > The following two GHA test runs show the problem when running with gradle 7.6 RC3 and the fix: > > [test-build-gradle-7.6](https://github.com/kevinrushforth/jfx/actions/runs/3470969280) : test build run using gradle 7.6 RC3 without the fix from this PR; it fails as expected > [test-build-gradle-7.6+8297042](https://github.com/kevinrushforth/jfx/actions/runs/3470983142) : test build run using gradle 7.6 RC3 without the fix from this PR; it passes on all platforms > > Additionally, the GHA test run for _this_ PR shows that it works fine with gradle 7.3. This pull request has now been integrated. Changeset: 6cc9c4d1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/6cc9c4d1b9a46432f1568a54d7dcdf51e224559b Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8297042: gradle -PBUILD_SDK_FOR_TEST=false fails with gradle 7.6 Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/949 From armin.schrenk at skymatic.de Wed Nov 16 14:29:12 2022 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Wed, 16 Nov 2022 15:29:12 +0100 Subject: Signing shared libraries and questions about loading Message-ID: Hello, for our application, a customer reported that the shared libraries (in this case DLLs) used by JFX are unsigned and thus were blocked from loading, which blocks the app from starting. The culprit for blocking is a new security feature for Windows 11, Smart App Control (https://support.microsoft.com/en-gb/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003). Since this feature seems to be a future part of Windows, i suggest to sign the shared libs before the maven release. In our case, the archive javafx-graphics-*-win.jar contains the DLLs. Apart from this feature request, we want to fix the issue on our side. To do that, I investigated into the sharedLib loading of JFX. SharedLib Loading is in JFX is done with the NativeLibLoader (https://github.com/openjdk/jfx/blob/19+11/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java). It does the following to load the native lib: 1. Load the DLLs from a certain path (see below) 2. On Failure, load the DLLs from a resource (aka the jar) by extracting them to a cache directory and load them from there 3. On Failure, do other stuff not of interest Our app is modular (or as much as possible), thus, the DLLs were always loaded from the resource. But this extract-and-cache approach is unsatisfying from our point of view. The app uses a custom JRE via jlink and is packaged with jpackage, and we would like to place the sharedLibs at build time somewhere in the app directory. So I had to figure out the where to place the DLLs, or more specifically, what path is checked in Step 1 of shared libLoading. Reading the inline comment starting at line 117, it should be the same dir as the jar is placed. Unfortunately, this is not the case and i had to dig more through the code to find out. Our app has the following structure: |- JarsAndMods ??? | - Mods ??? ??? | - modul1.jar ??? ??? | - modul2.jar ??? ??? | - ... ??? ??? | - javafx-graphics-XXX-win.jar ??? ??? | - ... ??? | - nonModular1.jar ??? | - nonModular2.jar ??? | - ... |- executable According to the comment, the path to place all DLLs should be /JarsAndMods/Mods. But verbose logging showed and later proofed by the code, it has to be /JarsAndMods/bin. My questions are: Why does JFX require only for Windows the `../bin` directory? Additionally, this inline comment has a FIXME that Step 1 of SharedLibLoading should be removed in the future. Is there already an ETA? And lastly, I would love to see some Documentation for this. I can write it and create the PR, but where should it be placed? Best wishes, Armin From kevin.rushforth at oracle.com Wed Nov 16 14:39:42 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Nov 2022 06:39:42 -0800 Subject: Signing shared libraries and questions about loading In-Reply-To: References: Message-ID: Leaving aside the question of signed libraries, if you are using jpackage / jlink to create a custom Java runtime with the JavaFX modules, then you should use the JMODs bundles and not the artifacts from Maven central. The maven modules are a handy convenience for developers, but not recommend for creating packaged applications. -- Kevin On 11/16/2022 6:29 AM, Armin Schrenk wrote: > Hello, > > for our application, a customer reported that the shared libraries (in > this case DLLs) used by JFX are unsigned and thus were blocked from > loading, which blocks the app from starting. The culprit for blocking > is a new security feature for Windows 11, Smart App Control > (https://support.microsoft.com/en-gb/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003). > Since this feature seems to be a future part of Windows, i suggest to > sign the shared libs before the maven release. In our case, the > archive javafx-graphics-*-win.jar contains the DLLs. > > Apart from this feature request, we want to fix the issue on our side. > To do that, I investigated into the sharedLib loading of JFX. > > SharedLib Loading is in JFX is done with the NativeLibLoader > (https://github.com/openjdk/jfx/blob/19+11/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java). > It does the following to load the native lib: > > 1. Load the DLLs from a certain path (see below) > 2. On Failure, load the DLLs from a resource (aka the jar) by > extracting them to a cache directory and load them from there > 3. On Failure, do other stuff not of interest > > Our app is modular (or as much as possible), thus, the DLLs were > always loaded from the resource. But this extract-and-cache approach > is unsatisfying from our point of view. The app uses a custom JRE via > jlink and is packaged with jpackage, and we would like to place the > sharedLibs at build time somewhere in the app directory. > > So I had to figure out the where to place the DLLs, or more > specifically, what path is checked in Step 1 of shared libLoading. > Reading the inline comment starting at line 117, it should be the same > dir as the jar is placed. Unfortunately, this is not the case and i > had to dig more through the code to find out. > > Our app has the following structure: > |- JarsAndMods > ??? | - Mods > ??? ??? | - modul1.jar > ??? ??? | - modul2.jar > ??? ??? | - ... > ??? ??? | - javafx-graphics-XXX-win.jar > ??? ??? | - ... > ??? | - nonModular1.jar > ??? | - nonModular2.jar > ??? | - ... > |- executable > > According to the comment, the path to place all DLLs should be > /JarsAndMods/Mods. > But verbose logging showed and later proofed by the code, it has to be > /JarsAndMods/bin. > > My questions are: > > Why does JFX require only for Windows the `../bin` directory? > > Additionally, this inline comment has a FIXME that Step 1 of > SharedLibLoading should be removed in the future. Is there already an > ETA? > > And lastly, I would love to see some Documentation for this. I can > write it and create the PR, but where should it be placed? > > > Best wishes, > > Armin > From angorya at openjdk.org Wed Nov 16 17:22:28 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 17:22:28 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 00:21:53 GMT, Kevin Rushforth wrote: >> 1. Introduced the following utility methods: >> - Util.launch >> - Util.shutdown >> - Util.waitForLatch >> 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. >> 3. Replaced local waitForLatch copies with Util.waitForLatch > > tests/system/src/test/java/test/util/Util.java line 338: > >> 336: public static void shutdown(Stage... stages) { >> 337: // why isn't runAndWait() exposed as a public API? >> 338: PlatformImpl.runAndWait(() -> { > > Not providing a public `runAndWait` was a deliberate choice. In any case, tests or utilities that need to wait should use the `runAndWait` method in this Util class in preference to `PlatformImpl`. For one thing it will throw exceptions back to the caller where as the `PlatformImpl` method will not. > > I think `Platform.runLater` should be sufficient here, but as long as the tests are still stable when using `runAndWait`, I don't have a strong objection. Will change the code to use Util.runAndWait, I think we should let the test code run its course in @AfterClass than to risk the test framework killing the process unexpectedly. Thank you for clarification, @kevinrushforth ! ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 17:26:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 17:26:31 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: <8FXt7jCUTjf15HTMpzuXOxvbsLao1jWw5wgvX19zXeI=.c922571e-a7bd-46c4-b865-633b13ef77f6@github.com> References: <8FXt7jCUTjf15HTMpzuXOxvbsLao1jWw5wgvX19zXeI=.c922571e-a7bd-46c4-b865-633b13ef77f6@github.com> Message-ID: <1poXqndpb9kuTAWgH58mqsmLxTdg20ec7WSLZyRUZbU=.ebd3d132-ef94-4795-8888-9e4d2dcf2a72@github.com> On Wed, 16 Nov 2022 08:27:17 GMT, Ajit Ghaisas wrote: > This is resulting in two test failures when run as a FULL system test run on my macBook with macOS 11.7.1. > > * test.javafx.scene.web.ColorChooserTest.testColorChooser() > * test.robot.javafx.scene.ComboBoxTest.testComboBoxSceneChange1() This is weird, I'll definitely take a look. On my Mac M1 I do get occasional failure in [StraightLineTest](https://github.com/openjdk/jfx/pull/classes/test.javafx.scene.web.StraightLineTest.html). [testLine](https://github.com/openjdk/jfx/pull/classes/test.javafx.scene.web.StraightLineTest.html#testLine) when running with no debug output. I am running the full test with this command - am I missing anything? ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 17:41:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 17:41:10 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v2] In-Reply-To: References: Message-ID: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch 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 11 additional commits since the last revision: - 8206430: run and wait - Merge remote-tracking branch 'origin/master' into 8206430.init.fx - 8206430: wait for latch - 8206430: exit test - 8206430: wait for latch - 8206430: t..w - 8206430: r..s - 8206430: h..p - 8206430: util.shutdown - 8206430: c..f - ... and 1 more: https://git.openjdk.org/jfx/compare/4f924f96...dbddbfad ------------- Changes: - all: https://git.openjdk.org/jfx/pull/950/files - new: https://git.openjdk.org/jfx/pull/950/files/51023c47..dbddbfad Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=00-01 Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 17:54:17 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 17:54:17 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v3] In-Reply-To: References: Message-ID: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8206430: default timeout 15 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/950/files - new: https://git.openjdk.org/jfx/pull/950/files/dbddbfad..57228341 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=01-02 Stats: 109 lines in 86 files changed: 19 ins; 2 del; 88 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 17:54:18 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 17:54:18 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 00:20:19 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8206430: default timeout 15 > > tests/system/src/test/java/test/util/Util.java line 317: > >> 315: * @param args - command line arguments >> 316: */ >> 317: public static void launch ( > > This looks like a useful utility. I think it would be helpful to either remove the timeout parameter entirely, or else have a variant of this that doesn't take the timeout value, and use a default timeout value. Most tests use 10 or 15 seconds so standardizing on 15 seems reasonable. > > Also, many of the tests use `Platform.startup` since they don't need to launch an application. Have you looked at providing a similar utility method for those cases? 1. added a method with 15 second default. There are only 4 remaining that use custom timeout, the first two use 5, the other two 50: test.javafx.embed.swing.JFXPanelTest.doSetupOnce() test.javafx.embed.swing.SwingFXUtilsTest.doSetupOnce() test.javafx.embed.swing.SwingNodeMemoryLeakTest.setupOnce() test.javafx.embed.swing.SwingNodeScaleTest.setupOnce() ------------- PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 18:00:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 18:00:37 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: <1poXqndpb9kuTAWgH58mqsmLxTdg20ec7WSLZyRUZbU=.ebd3d132-ef94-4795-8888-9e4d2dcf2a72@github.com> References: <8FXt7jCUTjf15HTMpzuXOxvbsLao1jWw5wgvX19zXeI=.c922571e-a7bd-46c4-b865-633b13ef77f6@github.com> <1poXqndpb9kuTAWgH58mqsmLxTdg20ec7WSLZyRUZbU=.ebd3d132-ef94-4795-8888-9e4d2dcf2a72@github.com> Message-ID: <-BbsLkIBATHisDO13Pd-RqhnwaWbCbOdmYoWxthmutU=.f2af1872-7c92-4982-9791-d25e48e06c35@github.com> On Wed, 16 Nov 2022 17:24:29 GMT, Andy Goryachev wrote: > This is resulting in two test failures when run as a FULL system test run on my macBook with macOS 11.7.1. > > * test.javafx.scene.web.ColorChooserTest.testColorChooser() > * test.robot.javafx.scene.ComboBoxTest.testComboBoxSceneChange1() These tests PASS for me (MacBook Pro x64 running macOS 12.5.1). @aghaisas how are they failing? ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 18:10:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 18:10:19 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:49:22 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/util/Util.java line 317: >> >>> 315: * @param args - command line arguments >>> 316: */ >>> 317: public static void launch ( >> >> This looks like a useful utility. I think it would be helpful to either remove the timeout parameter entirely, or else have a variant of this that doesn't take the timeout value, and use a default timeout value. Most tests use 10 or 15 seconds so standardizing on 15 seems reasonable. >> >> Also, many of the tests use `Platform.startup` since they don't need to launch an application. Have you looked at providing a similar utility method for those cases? > > 1. added a method with 15 second default. There are only 4 remaining that use custom timeout, the first two use 5, the other two 50: > test.javafx.embed.swing.JFXPanelTest.doSetupOnce() > test.javafx.embed.swing.SwingFXUtilsTest.doSetupOnce() > test.javafx.embed.swing.SwingNodeMemoryLeakTest.setupOnce() > test.javafx.embed.swing.SwingNodeScaleTest.setupOnce() 2. will add Util.startup(CountDownLatch, Runnable) for some of the tests ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 18:29:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 18:29:49 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v4] In-Reply-To: References: Message-ID: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8206430: util startup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/950/files - new: https://git.openjdk.org/jfx/pull/950/files/57228341..7560c0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=02-03 Stats: 233 lines in 11 files changed: 82 ins; 88 del; 63 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 18:47:57 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 18:47:57 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v3] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:54:17 GMT, Andy Goryachev wrote: >> 1. Introduced the following utility methods: >> - Util.launch >> - Util.shutdown >> - Util.waitForLatch >> 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. >> 3. Replaced local waitForLatch copies with Util.waitForLatch > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8206430: default timeout 15 tests/system/src/test/java/test/renderlock/RenderLockCommon.java line 124: > 122: @AfterClass > 123: public static void doTeardownOnce() { > 124: Util.shutdown(); This change causes the test to fail on Linux due to a latent test bug (specific to this test). The test is skipped on Linux using `assumeTrue` in an `@BeforeClass` method. This causes all test methods to be skipped, but the `@AfterClass` method is still run unconditionally. The `Util.shutdown` method calls `Platform.runLater` which will throw an exception if the FX runtime was never started. This causes JUnit to fail with a "DefaultMultiCauseException". I recommend either moving the `assumeTrue` to the `@Test` method in the `RenderLock1Test` class (there is only one) or else qualifying the call to `Util.shutdown` with `if (myApp != null)` so we don't call it if the platform wasn't launched. ------------- PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 18:47:58 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 18:47:58 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:06:21 GMT, Andy Goryachev wrote: >> 1. added a method with 15 second default. There are only 4 remaining that use custom timeout, the first two use 5, the other two 50: >> test.javafx.embed.swing.JFXPanelTest.doSetupOnce() >> test.javafx.embed.swing.SwingFXUtilsTest.doSetupOnce() >> test.javafx.embed.swing.SwingNodeMemoryLeakTest.setupOnce() >> test.javafx.embed.swing.SwingNodeScaleTest.setupOnce() > > 2. will add Util.startup(CountDownLatch, Runnable) for some of the tests > There are only 4 remaining that use custom timeout, the first two use 5, the other two 50 The ones using 5 seconds are mistakes (so they can use the variant without the explicit timeout). Not sure whether the ones that use 50 need to, but it seems safest to leave them alone. ------------- PR: https://git.openjdk.org/jfx/pull/950 From jvos at openjdk.org Wed Nov 16 19:08:57 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 16 Nov 2022 19:08:57 GMT Subject: [jfx17u] RFR: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors Message-ID: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors Reviewed-by: kcr, angorya ------------- Commit messages: - 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors Changes: https://git.openjdk.org/jfx17u/pull/90/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=90&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8222210 Stats: 54 lines in 2 files changed: 49 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/90.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/90/head:pull/90 PR: https://git.openjdk.org/jfx17u/pull/90 From angorya at openjdk.org Wed Nov 16 19:55:28 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 19:55:28 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v5] In-Reply-To: References: Message-ID: <0jxasQacN8X81BrYbBHQRSEJw7PJ9OIf3vq2zVxZkZc=.2d6d8c36-cf82-430f-899e-5072e2dcb6f6@github.com> > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8206430: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/950/files - new: https://git.openjdk.org/jfx/pull/950/files/7560c0f0..3fe70c20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=03-04 Stats: 12 lines in 4 files changed: 3 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From kcr at openjdk.org Wed Nov 16 20:04:16 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 20:04:16 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:29:49 GMT, Andy Goryachev wrote: >> 1. Introduced the following utility methods: >> - Util.launch >> - Util.shutdown >> - Util.waitForLatch >> 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. >> 3. Replaced local waitForLatch copies with Util.waitForLatch > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8206430: util startup tests/system/src/test/java/test/javafx/scene/lighting3D/DirectionalLightTest.java line 67: > 65: public static void exit() { > 66: Util.shutdown(); > 67: } This causes the test to fail. The superclass already does a shutdown, so the subclass must not. tests/system/src/test/java/test/util/Util.java line 362: > 360: try { > 361: String msg = "Timeout waiting for FX runtime to start"; > 362: Assert.assertTrue(msg, startupLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); I recommend to standardize on 15 seconds like you did for launch (the ones you replaced were mostly a mix of 10 or 15 seconds). Maybe you could create a STARTUP_TIMEOUT constant field? ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 20:04:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 20:04:16 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v4] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:50:34 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8206430: util startup > > tests/system/src/test/java/test/javafx/scene/lighting3D/DirectionalLightTest.java line 67: > >> 65: public static void exit() { >> 66: Util.shutdown(); >> 67: } > > This causes the test to fail. The superclass already does a shutdown, so the subclass must not. yes, just noticed that, thank you. fixed in the latest commit. > tests/system/src/test/java/test/util/Util.java line 362: > >> 360: try { >> 361: String msg = "Timeout waiting for FX runtime to start"; >> 362: Assert.assertTrue(msg, startupLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); > > I recommend to standardize on 15 seconds like you did for launch (the ones you replaced were mostly a mix of 10 or 15 seconds). Maybe you could create a STARTUP_TIMEOUT constant field? good idea, thanks! ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Wed Nov 16 20:12:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 16 Nov 2022 20:12:26 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v6] In-Reply-To: References: Message-ID: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8206430: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/950/files - new: https://git.openjdk.org/jfx/pull/950/files/3fe70c20..4fd492e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=950&range=04-05 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/950.diff Fetch: git fetch https://git.openjdk.org/jfx pull/950/head:pull/950 PR: https://git.openjdk.org/jfx/pull/950 From jvos at openjdk.org Wed Nov 16 21:03:03 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 16 Nov 2022 21:03:03 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 191: > 189: setBoundsImpl(ptr, x, y, xSet, ySet, w, h, cw, ch); > 190: > 191: if ((w <= 0) && (cw > 0) || (h <= 0) && (ch > 0)) { Why is this block removed? ------------- PR: https://git.openjdk.org/jfx/pull/915 From jvos at openjdk.org Wed Nov 16 21:19:16 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 16 Nov 2022 21:19:16 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code I'll do more testing and a detailed review, but first tests look good. ------------- PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Wed Nov 16 23:13:21 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 16 Nov 2022 23:13:21 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <7EDmBqRsqXTnl9yhrkNclXx98b7AZKuDK2XJjd2uYq8=.3330bc8c-537d-4d43-9079-78f0c81c9f0a@github.com> On Wed, 16 Nov 2022 20:59:32 GMT, Johan Vos wrote: >> Thiago Milczarek Sayao 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 contains one new commit since the last revision: >> >> 8260528: Clean glass-gtk sizing and positioning code > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 191: > >> 189: setBoundsImpl(ptr, x, y, xSet, ySet, w, h, cw, ch); >> 190: >> 191: if ((w <= 0) && (cw > 0) || (h <= 0) && (ch > 0)) { > > Why is this block removed? Size adjusting accounting frame extents is done in `WindowContextTop::update_frame_extents()` ------------- PR: https://git.openjdk.org/jfx/pull/915 From angorya at openjdk.org Thu Nov 17 00:19:52 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 17 Nov 2022 00:19:52 GMT Subject: RFR: 8297166: [TestBug] Fix some ignored unit test from TableViewTest Message-ID: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> Re-enabled some ignored tests. ------------- Commit messages: - 8297166: table view Changes: https://git.openjdk.org/jfx/pull/952/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297166 Stats: 24 lines in 1 file changed: 8 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/952.diff Fetch: git fetch https://git.openjdk.org/jfx pull/952/head:pull/952 PR: https://git.openjdk.org/jfx/pull/952 From aghaisas at openjdk.org Thu Nov 17 06:57:30 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 17 Nov 2022 06:57:30 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: <1poXqndpb9kuTAWgH58mqsmLxTdg20ec7WSLZyRUZbU=.ebd3d132-ef94-4795-8888-9e4d2dcf2a72@github.com> References: <8FXt7jCUTjf15HTMpzuXOxvbsLao1jWw5wgvX19zXeI=.c922571e-a7bd-46c4-b865-633b13ef77f6@github.com> <1poXqndpb9kuTAWgH58mqsmLxTdg20ec7WSLZyRUZbU=.ebd3d132-ef94-4795-8888-9e4d2dcf2a72@github.com> Message-ID: On Wed, 16 Nov 2022 17:24:29 GMT, Andy Goryachev wrote: > I am running the full test with this command - am I missing anything? `/bin/sh gradlew -PSTUB_RUNTIME=../caches/modular-sdk -PFULL_TEST=true -PUSE_ROBOT=true cleanTest test --no-daemon 2>&1 | tee ~/`date +"test-%Y-%m%d-%H%M%S"`.log` I use this command to run a full test run - ` gradle --continue --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test` > These tests PASS for me (MacBook Pro x64 running macOS 12.5.1). @aghaisas how are they failing? The two failures that I had reported were failing with "picked color being incorrect" and "ComboBox popup being not displayed due to timeout" Today, I have had successful run of all tests run thrice with the latest patch. It looks like the failures that I have seen yesterday were inconsistent. ------------- PR: https://git.openjdk.org/jfx/pull/950 From jvos at openjdk.org Thu Nov 17 09:48:56 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 09:48:56 GMT Subject: [jfx17u] Integrated: 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:58:22 GMT, Johan Vos wrote: > 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors > > Reviewed-by: kcr, angorya This pull request has now been integrated. Changeset: 19b42623 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/19b42623ef7752391e7ad5f8015dcc19810b5995 Stats: 54 lines in 2 files changed: 49 ins; 0 del; 5 mod 8222210: JFXPanel popups open at wrong coordinates when using multiple hidpi monitors Backport-of: f4e27e9d37439716455838671d2f06b8aca1d236 ------------- PR: https://git.openjdk.org/jfx17u/pull/90 From aghaisas at openjdk.org Thu Nov 17 11:43:08 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 17 Nov 2022 11:43:08 GMT Subject: RFR: 8297166: [TestBug] Fix some ignored unit test from TableViewTest In-Reply-To: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> References: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> Message-ID: On Wed, 16 Nov 2022 23:34:02 GMT, Andy Goryachev wrote: > Re-enabled some ignored tests. Marked as reviewed by aghaisas (Reviewer). modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 868: > 866: } > 867: > 868: /** We can remove this comment. If needed, we can get this information from looking at file revision history. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 2054: > 2052: } > 2053: > 2054: /** We can remove this comment. If needed, we can get this information from looking at file revision history. ------------- PR: https://git.openjdk.org/jfx/pull/952 From duke at openjdk.org Thu Nov 17 11:55:06 2022 From: duke at openjdk.org (Karthik P K) Date: Thu, 17 Nov 2022 11:55:06 GMT Subject: RFR: 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems Message-ID: Two RobotTest methods are marked as unstable on HiDPI Windows systems. ------------- Commit messages: - Rephrase comment of skipping test - Add BugID of the test failure bug - Mark tests as unstable for HiDPI on Windows Changes: https://git.openjdk.org/jfx/pull/951/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=951&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296556 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/951.diff Fetch: git fetch https://git.openjdk.org/jfx pull/951/head:pull/951 PR: https://git.openjdk.org/jfx/pull/951 From kcr at openjdk.org Thu Nov 17 11:55:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 17 Nov 2022 11:55:08 GMT Subject: RFR: 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 09:04:28 GMT, Karthik P K wrote: > Two RobotTest methods are marked as unstable on HiDPI Windows systems. The fix looks fine to me. Please add the bug ID (the bug tracking the failing test, not this bug) as requested. @arapte can be reviewer for this. tests/system/src/test/java/test/robot/javafx/scene/RobotTest.java line 682: > 680: if (PlatformUtil.isWindows() && Screen.getPrimary().getOutputScaleX() > 1) { > 681: //Mark test as unstable for HiDPI scale greater than 100% > 682: Assume.assumeTrue(Boolean.getBoolean("unstable.test")); Please add the BugID of the test failure bug. See [SwingNodeMemoryLeakTest.java#L88](https://github.com/openjdk/jfx/blob/fb6788a30160425a436a530a9cb511f633fb642b/tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java#L88) for example. tests/system/src/test/java/test/robot/javafx/scene/RobotTest.java line 738: > 736: if (PlatformUtil.isWindows() && Screen.getPrimary().getOutputScaleX() > 1) { > 737: //Mark test as unstable for HiDPI scale greater than 100% > 738: Assume.assumeTrue(Boolean.getBoolean("unstable.test")); Please add the BugID of the test failure bug. ------------- PR: https://git.openjdk.org/jfx/pull/951 From arapte at openjdk.org Thu Nov 17 11:55:09 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 17 Nov 2022 11:55:09 GMT Subject: RFR: 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 09:04:28 GMT, Karthik P K wrote: > Two RobotTest methods are marked as unstable on HiDPI Windows systems. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/951 From duke at openjdk.org Thu Nov 17 12:46:57 2022 From: duke at openjdk.org (Karthik P K) Date: Thu, 17 Nov 2022 12:46:57 GMT Subject: RFR: 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 13:57:29 GMT, Kevin Rushforth wrote: >> Two RobotTest methods are marked as unstable on HiDPI Windows systems. > > The fix looks fine to me. Please add the bug ID (the bug tracking the failing test, not this bug) as requested. > > @arapte can be reviewer for this. @kevinrushforth / @arapte can you please /sponsor this PR? ------------- PR: https://git.openjdk.org/jfx/pull/951 From duke at openjdk.org Thu Nov 17 13:08:40 2022 From: duke at openjdk.org (Karthik P K) Date: Thu, 17 Nov 2022 13:08:40 GMT Subject: Integrated: 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 09:04:28 GMT, Karthik P K wrote: > Two RobotTest methods are marked as unstable on HiDPI Windows systems. This pull request has now been integrated. Changeset: 74af45d6 Author: Karthik P K Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/74af45d69828bf5bd8cea5b7fbf8e8c6cac4f689 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8296556: Mark two RobotTest methods as unstable on HiDPI Windows systems Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/951 From jvos at openjdk.org Thu Nov 17 14:26:29 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 14:26:29 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: <7EDmBqRsqXTnl9yhrkNclXx98b7AZKuDK2XJjd2uYq8=.3330bc8c-537d-4d43-9079-78f0c81c9f0a@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> <7EDmBqRsqXTnl9yhrkNclXx98b7AZKuDK2XJjd2uYq8=.3330bc8c-537d-4d43-9079-78f0c81c9f0a@github.com> Message-ID: On Wed, 16 Nov 2022 23:09:47 GMT, Thiago Milczarek Sayao wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 191: >> >>> 189: setBoundsImpl(ptr, x, y, xSet, ySet, w, h, cw, ch); >>> 190: >>> 191: if ((w <= 0) && (cw > 0) || (h <= 0) && (ch > 0)) { >> >> Why is this block removed? > > Size adjusting accounting frame extents is done in `WindowContextTop::update_frame_extents()` I mainly wanted to make sure we were not missing a `notifyResize` event (which was executed in the removed block), but I see this is now done via `WindowContextTop::set_bounds` which is fine. ------------- PR: https://git.openjdk.org/jfx/pull/915 From aghaisas at openjdk.org Thu Nov 17 14:30:35 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 17 Nov 2022 14:30:35 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:12:26 GMT, Andy Goryachev wrote: >> 1. Introduced the following utility methods: >> - Util.launch >> - Util.shutdown >> - Util.waitForLatch >> 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. >> 3. Replaced local waitForLatch copies with Util.waitForLatch > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8206430: review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/950 From jvos at openjdk.org Thu Nov 17 14:35:55 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 14:35:55 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1269: > 1267: } > 1268: > 1269: void WindowContextTop::to_front() { Do you use `raise` and `lower` here because the sibiling parameter is always `NULL` ? ------------- PR: https://git.openjdk.org/jfx/pull/915 From jvos at openjdk.org Thu Nov 17 15:46:28 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 15:46:28 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 713: > 711: > 712: static int geometry_get_window_width(const WindowGeometry *windowGeometry) { > 713: return (windowGeometry->final_width.type != BOUNDSTYPE_WINDOW) minor: wouldn't it be more readable (here and below) if the test was reversed? ( `(windowGeometry->final_width.type != BOUNDSTYPE_WINDOW`) ------------- PR: https://git.openjdk.org/jfx/pull/915 From jvos at openjdk.org Thu Nov 17 15:52:00 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 15:52:00 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 891: > 889: > 890: if (get_frame_extents_property(&top, &left, &bottom, &right)) { > 891: if ((top + right + bottom + left) != 0) { Are we 100% sure the extents can never be negative values? ------------- PR: https://git.openjdk.org/jfx/pull/915 From jvos at openjdk.org Thu Nov 17 16:04:34 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 17 Nov 2022 16:04:34 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Mon, 7 Nov 2022 01:21:06 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao 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 contains one new commit since the last revision: > > 8260528: Clean glass-gtk sizing and positioning code modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1047: > 1045: > 1046: if (moved) { > 1047: geometry_set_window_x(&geometry, x); this will set `windowGeometry->refx` where 2 lines below you set `windowGeometry.current_x`. Unless there is gravity involved, both refer to the same value, one being `int` and the other being `float` though. Is there another conceptual difference, or why do we have 2 values here? ------------- PR: https://git.openjdk.org/jfx/pull/915 From angorya at openjdk.org Thu Nov 17 16:43:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 17 Nov 2022 16:43:36 GMT Subject: RFR: 8297166: [TestBug] Fix some ignored unit test from TableViewTest In-Reply-To: References: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> Message-ID: On Thu, 17 Nov 2022 11:39:54 GMT, Ajit Ghaisas wrote: >> Re-enabled some ignored tests. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 868: > >> 866: } >> 867: >> 868: /** > > We can remove this comment. If needed, we can get this information from looking at file revision history. I thought a bit of history won't hurt in case this test starts failing on some platform. Will avoid adding similar comments in the future. Thanks! ------------- PR: https://git.openjdk.org/jfx/pull/952 From kcr at openjdk.org Thu Nov 17 16:48:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 17 Nov 2022 16:48:28 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:12:26 GMT, Andy Goryachev wrote: >> 1. Introduced the following utility methods: >> - Util.launch >> - Util.shutdown >> - Util.waitForLatch >> 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. >> 3. Replaced local waitForLatch copies with Util.waitForLatch > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8206430: review comments Looks good. Tested on all three platforms. I left a minor doc comment (which I don't suggest you do anything about, since we don't generate docs for tests), as a note for future reference. tests/system/src/test/java/test/util/Util.java line 313: > 311: * @param startupLatch - a latch used to communicate successful start of the application > 312: * @param applicationClass - application to launch > 313: * @param args - command line arguments Since we don't generate javadocs for our tests, this doesn't matter, but for future refence, there should not be any punctuation (i.e., no `-`) after the name of the parameter. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Thu Nov 17 16:53:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 17 Nov 2022 16:53:36 GMT Subject: RFR: 8206430: Use consistent pattern for startup in FX system tests [v6] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:13:44 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8206430: review comments > > tests/system/src/test/java/test/util/Util.java line 313: > >> 311: * @param startupLatch - a latch used to communicate successful start of the application >> 312: * @param applicationClass - application to launch >> 313: * @param args - command line arguments > > Since we don't generate javadocs for our tests, this doesn't matter, but for future refence, there should not be any punctuation (i.e., no `-`) after the name of the parameter. Got it, thanks. ------------- PR: https://git.openjdk.org/jfx/pull/950 From angorya at openjdk.org Thu Nov 17 18:08:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 17 Nov 2022 18:08:12 GMT Subject: Integrated: 8206430: Use consistent pattern for startup in FX system tests In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:00:59 GMT, Andy Goryachev wrote: > 1. Introduced the following utility methods: > - Util.launch > - Util.shutdown > - Util.waitForLatch > 2. Fixed the out-of order calls to Stage.hide() and Platform.exit() in many tests' shutdowns. > 3. Replaced local waitForLatch copies with Util.waitForLatch This pull request has now been integrated. Changeset: 1ec06a80 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1ec06a80d13c8a33a1e998baa9942fbfc5035432 Stats: 2506 lines in 101 files changed: 702 ins; 1182 del; 622 mod 8206430: Use consistent pattern for startup in FX system tests Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/950 From mhanl at openjdk.org Thu Nov 17 18:12:28 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 17 Nov 2022 18:12:28 GMT Subject: Integrated: 8296330: Tests: Add layout container snapping tests In-Reply-To: References: Message-ID: <3sA6wfOGB_lTFn887P4chJmjO11rm7jb42TnPT0nm9U=.d8265b7b-98e6-42e7-bcfe-e4a0051720d0@github.com> On Thu, 3 Nov 2022 21:15:08 GMT, Marius Hanl wrote: > While checking https://bugs.openjdk.org/browse/JDK-8295078 I found much more layout container which do not snap their children correctly. > > The goal of this PR is to add snapping tests for all layout container. > After that we can create issues for all broken layout container, fix them and comment in the corresponding line. This pull request has now been integrated. Changeset: 626227dc Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/626227dc1029a0d984f2ed89a4397954bd71d676 Stats: 179 lines in 1 file changed: 179 ins; 0 del; 0 mod 8296330: Tests: Add layout container snapping tests Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/936 From kevin.rushforth at oracle.com Thu Nov 17 18:17:26 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Nov 2022 10:17:26 -0800 Subject: Result: New OpenJFX Committer: Andy Goryachev Message-ID: Voting for Andy Goryachev [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#angorya [2] https://mail.openjdk.org/pipermail/openjfx-dev/2022-November/036454.html From andy.goryachev at oracle.com Thu Nov 17 19:46:14 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 17 Nov 2022 19:46:14 +0000 Subject: [External] : Re: RFR: 8221708 Update Eclipse project files [v4] In-Reply-To: References: <4N9HInjkw3K4Iv9vNyoS-82woSbbUwSb75NGYoE5Mcg=.dd08917e-1d25-4752-90f6-53c9cb400c3f@github.com> Message-ID: >> - we probably should mention that the gradle build should be run after initial checkout, including sdk and apps. This will load and build the dependencies (lucene). > That is explained in the main page - https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX, or at least should be, as it isn't an Eclipse-specific step. There is a mention of this in the Using Eclipse section. I'd suggest to mention the need to rebuild using command line in the section Import the Eclipse Projects, since Eclipse will complain about missing dependencies. Perhaps provide the gradle command and a link to the "building.." page. Cheers, -andy From: Nir Lisker Date: Tuesday, 2022/11/15 at 09:44 To: Andy Goryachev Cc: Nir Lisker , openjfx-dev at openjdk.org Subject: [External] : Re: RFR: 8221708 Update Eclipse project files [v4] - the screenshots are outdated, using much older version of Eclipse, the UI has been changed a bit. The latest Eclipse won't work with java19 without a separate plugin, but i am sure they will fix it soon. Yes, I will need to delete all the projects and re-import in order to create the new screenshot. The separate plugin support is explained under "Configure Eclipse to use the latest JDK". Each Eclipse release requires a plugin for the simultaneously released Java version, It is "fixed" in the next version, but then you need another plugin for the new release. - there is an option to 'ignore projects already in the workspace' and I think it must be turned on (I was getting a warning). If you are importing for the first time, no project will already be in the workspace, so it doesn't matter. If you are re-importing it's up to you if you want to ignore them or not, I would say. - we probably should mention that the gradle build should be run after initial checkout, including sdk and apps. This will load and build the dependencies (lucene). That is explained in the main page - https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX, or at least should be, as it isn't an Eclipse-specific step. There is a mention of this in the Using Eclipse section. On Tue, Nov 15, 2022 at 6:54 PM Andy Goryachev > wrote: Nir, thank you so much! A few minor corrections might be needed. in Import the Eclipse Projects: - the screenshots are outdated, using much older version of Eclipse, the UI has been changed a bit. The latest Eclipse won't work with java19 without a separate plugin, but i am sure they will fix it soon. - there is an option to 'ignore projects already in the workspace' and I think it must be turned on (I was getting a warning). - we probably should mention that the gradle build should be run after initial checkout, including sdk and apps. This will load and build the dependencies (lucene). Perhaps we should also add a section dedicated to configuring error levels, as the default configuration turns off important warnings and enables too many unimportant ones. Thank you again -andy From: openjfx-dev > on behalf of Nir Lisker > Date: Monday, 2022/11/14 at 18:09 To: openjfx-dev at openjdk.org > Subject: Re: RFR: 8221708 Update Eclipse project files [v4] On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx > wrote: >> See https://bugs.openjdk.org/browse/JDK-8221708 > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix controls classpath I updated https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse. ------------- PR: https://git.openjdk.org/jfx/pull/930 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Nov 17 20:18:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 17 Nov 2022 20:18:01 GMT Subject: Integrated: 8297166: [TestBug] Fix some ignored unit test from TableViewTest In-Reply-To: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> References: <9ypRe-RBh6vE7KhwaIwRDGPnpjmfjcMQXMfUlHLnCnA=.c99ed129-6255-4d89-afde-d6b5f43f1aa9@github.com> Message-ID: On Wed, 16 Nov 2022 23:34:02 GMT, Andy Goryachev wrote: > Re-enabled some ignored tests. This pull request has now been integrated. Changeset: e3e0dfdb Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e3e0dfdb1b945844691c79e512dbae285027ff6c Stats: 24 lines in 1 file changed: 8 ins; 0 del; 16 mod 8297166: [TestBug] Fix some ignored unit test from TableViewTest Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/952 From nlisker at gmail.com Thu Nov 17 23:10:11 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 Nov 2022 01:10:11 +0200 Subject: CheckBoxTreeItem behavior Message-ID: Hi, I have been working on fixing some issues with the behavior of CheckBoxTreeItem. I stumbled across this situation: When a parent is de/selected, all of its children are set to the same state. However, a CheckBoxTreeItem can be set to indeterminate programmatically (the control itself does not allow indeterminate). Should all children also be set to an indeterminate state? If so, this will put the tree at an "invalid" state where leaf nodes can be indeterminate as well. OTOH, if not, then we are again at an invalid state if all children have the same state, but the parent doesn't. - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Nov 18 00:54:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 00:54:05 GMT Subject: RFR: 8297213: Robot capture tests should move mouse to corner of screen Message-ID: Added Util.parkCursor(Robot) method to move the cursor to lower left corner (while avoiding dock, tray, or active corners). ------------- Commit messages: - 8297213: park cursor Changes: https://git.openjdk.org/jfx/pull/955/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=955&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297213 Stats: 71 lines in 7 files changed: 49 ins; 16 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/955.diff Fetch: git fetch https://git.openjdk.org/jfx pull/955/head:pull/955 PR: https://git.openjdk.org/jfx/pull/955 From mstrauss at openjdk.org Fri Nov 18 03:23:30 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 18 Nov 2022 03:23:30 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v5] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Thu, 14 Jul 2022 08:05:25 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK_8256397 > Fixed more issues with the multiple selection model change events, and verified them with more unit-tests. Looks good to me. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1470: > 1468: } > 1469: > 1470: public ListView creatListViewWithMultipleSelection() { There's a typo in "creatList..." ------------- PR: https://git.openjdk.org/jfx/pull/353 From john.hendrikx at gmail.com Fri Nov 18 09:12:33 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 18 Nov 2022 10:12:33 +0100 Subject: CheckBoxTreeItem behavior In-Reply-To: References: Message-ID: On 18/11/2022 00:10, Nir Lisker wrote: > Hi, > > I have been working on fixing some issues with the behavior > of?CheckBoxTreeItem. I stumbled across?this situation: > > When a parent is de/selected, all of its children are set to the same > state. However, a CheckBoxTreeItem can be set to indeterminate > programmatically?(the control itself does not allow indeterminate). > Should all children also be set to an indeterminate state? If so, this > will put the tree at an "invalid" state where leaf nodes can be > indeterminate as well. OTOH, if not, then we are again at an invalid > state if all children have the same state, but the parent doesn't. I think the indeterminate state is best left up completely to the owner of the control. You may need information that is not part of the tree to actually determine if something is indeterminate or not.? A tree may be filtered, or a tree may represent only "nodes" while "leaves" are displayed in a 2nd control as a list.? This means that in theory, parent nodes could be indeterminate even if all its children are in the same state (checked/unchecked) due to filtering, and leaf nodes could be indeterminate if they represent a directory while the file selection is displayed in a separate control.? In Backup software, a directory may be partially selected if it has a filter associated with it (like *.java) even if that directory is empty or has only Java files currently... Some UI's will even allow you to click on an indeterminate parent node to check it (checking all children), click again to uncheck it (unchecked all children), and click a 3rd time to put it back to an indeterminate state (restoring all children to the state they had before the first click). --John From tsayao at openjdk.org Fri Nov 18 11:44:15 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 18 Nov 2022 11:44:15 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <9-BUmH6edCrGDa-WOIvdX30ahV6TcChPm4gQRe1Oeh0=.ceba4844-54ed-446e-a7e6-c1ad059618eb@github.com> On Thu, 17 Nov 2022 15:42:29 GMT, Johan Vos wrote: >> Thiago Milczarek Sayao 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 contains one new commit since the last revision: >> >> 8260528: Clean glass-gtk sizing and positioning code > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 713: > >> 711: >> 712: static int geometry_get_window_width(const WindowGeometry *windowGeometry) { >> 713: return (windowGeometry->final_width.type != BOUNDSTYPE_WINDOW) > > minor: wouldn't it be more readable (here and below) if the test was reversed? ( `(windowGeometry->final_width.type != BOUNDSTYPE_WINDOW`) Those functions already existed. Do you prefer to keep as it was or to invert the `if`? > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 891: > >> 889: >> 890: if (get_frame_extents_property(&top, &left, &bottom, &right)) { >> 891: if ((top + right + bottom + left) != 0) { > > Are we 100% sure the extents can never be negative values? I'm 99.99% sure :) > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1047: > >> 1045: >> 1046: if (moved) { >> 1047: geometry_set_window_x(&geometry, x); > > this will set `windowGeometry->refx` where 2 lines below you set `windowGeometry.current_x`. Unless there is gravity involved, both refer to the same value, one being `int` and the other being `float` though. Is there another conceptual difference, or why do we have 2 values here? I think you're right, I added `current_x/y` to check if a window moved, but `ref_x/ref_y` might contain the same value (different type). > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1269: > >> 1267: } >> 1268: >> 1269: void WindowContextTop::to_front() { > > Do you use `raise` and `lower` here because the sibiling parameter is always `NULL` ? Yes. But also `gdk_window_raise` and `gdk_window_lower` seems to better match the `toFront()` and `toBack()` description. See: https://tronche.com/gui/x/xlib/window/XRestackWindows.html https://tronche.com/gui/x/xlib/window/XRaiseWindow.html gdk functions calls those Xlib functions internally. ------------- PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Fri Nov 18 13:12:07 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 18 Nov 2022 13:12:07 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Wed, 16 Nov 2022 21:16:37 GMT, Johan Vos wrote: >> Thiago Milczarek Sayao 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 contains one new commit since the last revision: >> >> 8260528: Clean glass-gtk sizing and positioning code > > I'll do more testing and a detailed review, but first tests look good. @johanvos I replied the review comments but grouped them and It didn't trigger an email. ------------- PR: https://git.openjdk.org/jfx/pull/915 From duke at openjdk.org Fri Nov 18 14:43:25 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Fri, 18 Nov 2022 14:43:25 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest Message-ID: The change moves Locale setting in the test to @BeforeClass and @AfterClass calls. @BeforeClass method call stores current default VM locale and applies Locale.US, while @AfterClass method restores old VM locale after all tests are completed. I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. ------------- Commit messages: - 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest Changes: https://git.openjdk.org/jfx/pull/954/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8265828 Stats: 16 lines in 1 file changed: 13 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/954.diff Fetch: git fetch https://git.openjdk.org/jfx pull/954/head:pull/954 PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 15:49:21 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 15:49:21 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:59:09 GMT, Lukasz Kostyra wrote: > The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. > > I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. Looks good. modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 96: > 94: } > 95: > 96: @BeforeClass public static void setupBeforeAll() { Minor: we usually put annotations on a separate line, although some files (like this one) put the `@Test` annotation on the same line, splitting them is preferred. I'll approve it as-is, and reapprove if you decide to change (I'll leave it up to you). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/954 From mhanl at openjdk.org Fri Nov 18 16:04:29 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 18 Nov 2022 16:04:29 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:59:09 GMT, Lukasz Kostyra wrote: > The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. > > I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: > 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); > 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); > 60: private static Locale oldLocale; Isn't the creation of the DateTimeFormatter using the default locale? If so, this should probably be done after the locale is set. ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 16:17:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 16:17:29 GMT Subject: RFR: 8297213: Robot capture tests should move mouse to corner of screen In-Reply-To: References: Message-ID: <41sOiZaIaWwiDlzJNoVViMoOAaMok7G0uVBkecJzbSI=.552bf7ee-83cd-4ef9-8ed6-963625e45eca@github.com> On Fri, 18 Nov 2022 00:48:11 GMT, Andy Goryachev wrote: > Added Util.parkCursor(Robot) method to move the cursor to lower left corner (while avoiding dock, tray, or active corners). Looks good with one inline comment about a redundant call to `parkCursor`. tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 50: > 48: @Before > 49: public void before() { > 50: Util.parkCursor(getRobot()); This is redundant, since `RegionBackgroundImageUITest` extends from `VisuaTestBase`, which already calls `parkCursor`. You can remove the `before` method. ------------- PR: https://git.openjdk.org/jfx/pull/955 From kcr at openjdk.org Fri Nov 18 16:21:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 16:21:31 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: <_st3WVr-__QLK70AGAqKCXUNV8_cTG1wXTIkgpbS-_o=.bd2579b7-c8b4-4a9f-b20c-79af208a5168@github.com> On Fri, 18 Nov 2022 16:00:33 GMT, Marius Hanl wrote: >> The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. >> >> I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. > > modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: > >> 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); >> 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); >> 60: private static Locale oldLocale; > > Isn't the creation of the DateTimeFormatter using the default locale? If so, this should probably be done after the locale is set. This is a good point. Moving the initialization of those two fields to the `setupBeforeAll` method seems safest. ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 16:41:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 16:41:29 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:59:09 GMT, Lukasz Kostyra wrote: > The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. > > I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. Pending response to comment raised by Marius. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/954 From angorya at openjdk.org Fri Nov 18 16:44:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 16:44:06 GMT Subject: RFR: 8297213: Robot capture tests should move mouse to corner of screen [v2] In-Reply-To: References: Message-ID: > Added Util.parkCursor(Robot) method to move the cursor to lower left corner (while avoiding dock, tray, or active corners). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8297213: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/955/files - new: https://git.openjdk.org/jfx/pull/955/files/55a022c5..0e525b2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=955&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=955&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/955.diff Fetch: git fetch https://git.openjdk.org/jfx pull/955/head:pull/955 PR: https://git.openjdk.org/jfx/pull/955 From angorya at openjdk.org Fri Nov 18 16:44:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 16:44:09 GMT Subject: RFR: 8297213: Robot capture tests should move mouse to corner of screen [v2] In-Reply-To: <41sOiZaIaWwiDlzJNoVViMoOAaMok7G0uVBkecJzbSI=.552bf7ee-83cd-4ef9-8ed6-963625e45eca@github.com> References: <41sOiZaIaWwiDlzJNoVViMoOAaMok7G0uVBkecJzbSI=.552bf7ee-83cd-4ef9-8ed6-963625e45eca@github.com> Message-ID: On Fri, 18 Nov 2022 14:37:34 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8297213: review comments > > tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 50: > >> 48: @Before >> 49: public void before() { >> 50: Util.parkCursor(getRobot()); > > This is redundant, since `RegionBackgroundImageUITest` extends from `VisuaTestBase`, which already calls `parkCursor`. You can remove the `before` method. missed that, thanks! ------------- PR: https://git.openjdk.org/jfx/pull/955 From angorya at openjdk.org Fri Nov 18 16:54:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 16:54:16 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:59:09 GMT, Lukasz Kostyra wrote: > The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. > > I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: > 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); > 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); > 60: private static Locale oldLocale; I wonder how many other tests we have that depend on specific Locale? Perhaps we need to apply the same treatment to: - LocalDateStringConverterTest - LocalTimeStringConverterTest ------------- PR: https://git.openjdk.org/jfx/pull/954 From duke at openjdk.org Fri Nov 18 16:54:19 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Fri, 18 Nov 2022 16:54:19 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 15:45:46 GMT, Kevin Rushforth wrote: >> The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. >> >> I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. > > modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 96: > >> 94: } >> 95: >> 96: @BeforeClass public static void setupBeforeAll() { > > Minor: we usually put annotations on a separate line, although some files (like this one) put the `@Test` annotation on the same line, splitting them is preferred. I'll approve it as-is, and reapprove if you decide to change (I'll leave it up to you). Since I have to make some changes to this PR, I will update this as well. ------------- PR: https://git.openjdk.org/jfx/pull/954 From duke at openjdk.org Fri Nov 18 17:02:42 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Fri, 18 Nov 2022 17:02:42 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: <_st3WVr-__QLK70AGAqKCXUNV8_cTG1wXTIkgpbS-_o=.bd2579b7-c8b4-4a9f-b20c-79af208a5168@github.com> References: <_st3WVr-__QLK70AGAqKCXUNV8_cTG1wXTIkgpbS-_o=.bd2579b7-c8b4-4a9f-b20c-79af208a5168@github.com> Message-ID: On Fri, 18 Nov 2022 16:17:55 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: >> >>> 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); >>> 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); >>> 60: private static Locale oldLocale; >> >> Isn't the creation of the DateTimeFormatter using the default locale? If so, this should probably be done after the locale is set. > > This is a good point. Moving the initialization of those two fields to the `setupBeforeAll` method seems safest. That is a fair point. I'll have to change the code a bit, as `implementations()` method is called before a `@BeforeClass`-tagged method (which is probably why originally `Locale.setDefault()` was called there) and `aFormatter`/`aParser` are already used there, expected to be initialized. ------------- PR: https://git.openjdk.org/jfx/pull/954 From duke at openjdk.org Fri Nov 18 17:02:42 2022 From: duke at openjdk.org (Lukasz Kostyra) Date: Fri, 18 Nov 2022 17:02:42 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 16:50:21 GMT, Andy Goryachev wrote: >> The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. >> >> I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. > > modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: > >> 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); >> 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); >> 60: private static Locale oldLocale; > > I wonder how many other tests we have that depend on specific Locale? Perhaps we need to apply the same treatment to: > - LocalDateStringConverterTest > - LocalTimeStringConverterTest I could also change those, as they use `DateTimeFormatter` as well which uses `Locale` underneath as discussed above. @kevinrushforth what do you think? ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 17:04:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 17:04:30 GMT Subject: RFR: 8297213: Robot capture tests should move mouse to corner of screen [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 16:44:06 GMT, Andy Goryachev wrote: >> Added Util.parkCursor(Robot) method to move the cursor to lower left corner (while avoiding dock, tray, or active corners). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8297213: review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/955 From mhanl at openjdk.org Fri Nov 18 17:12:27 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 18 Nov 2022 17:12:27 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: <_st3WVr-__QLK70AGAqKCXUNV8_cTG1wXTIkgpbS-_o=.bd2579b7-c8b4-4a9f-b20c-79af208a5168@github.com> Message-ID: On Fri, 18 Nov 2022 17:00:08 GMT, Lukasz Kostyra wrote: >> This is a good point. Moving the initialization of those two fields to the `setupBeforeAll` method seems safest. > > That is a fair point. > > I'll have to change the code a bit, as `implementations()` method is called before a `@BeforeClass`-tagged method (which is probably why originally `Locale.setDefault()` was called there) and `aFormatter`/`aParser` are already used there, expected to be initialized. Maybe JUnit5 can help you here. You can check out my recently merged PR for an example for the usage of the parameterized api introduced in JUnit5. https://github.com/openjdk/jfx/pull/936 ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 17:23:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 17:23:09 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 16:59:09 GMT, Lukasz Kostyra wrote: > The change moves Locale setting in the test to `@BeforeClass` and `@AfterClass` calls. `@BeforeClass` method call stores current default VM locale and applies Locale.US, while `@AfterClass` method restores old VM locale after all tests are completed. > > I tested it both on Mac and Windows, in both cases Locale is changed, restored properly and tests pass. see inline comments ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 17:23:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 17:23:11 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: <_st3WVr-__QLK70AGAqKCXUNV8_cTG1wXTIkgpbS-_o=.bd2579b7-c8b4-4a9f-b20c-79af208a5168@github.com> Message-ID: On Fri, 18 Nov 2022 17:10:04 GMT, Marius Hanl wrote: >> That is a fair point. >> >> I'll have to change the code a bit, as `implementations()` method is called before a `@BeforeClass`-tagged method (which is probably why originally `Locale.setDefault()` was called there) and `aFormatter`/`aParser` are already used there, expected to be initialized. > > Maybe JUnit5 can help you here. > You can check out my recently merged PR for an example for the usage of the parameterized api introduced in JUnit5. > https://github.com/openjdk/jfx/pull/936 I guess they fixed this rather irritating "feature" in JUnit5. Another, possibly less-intrusive, approach would be to initialize all of the static fields in a `static { ... }` block (with a comment as to why you can't use an `@BeforeClass` method. ------------- PR: https://git.openjdk.org/jfx/pull/954 From kcr at openjdk.org Fri Nov 18 17:23:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 18 Nov 2022 17:23:13 GMT Subject: RFR: 8265828: [TestBug] Save and restore the default Locale in javafx.base unit test LocalDateTimeStringConverterTest In-Reply-To: References: Message-ID: <2VU-DqOhL1vZuyvWAmKs591QNd6KQ6cc9XlcPVU6u5U=.418b0ee0-60ea-4395-be4d-b57ccf80c3d9@github.com> On Fri, 18 Nov 2022 17:00:42 GMT, Lukasz Kostyra wrote: >> modules/javafx.base/src/test/java/test/javafx/util/converter/LocalDateTimeStringConverterTest.java line 60: >> >>> 58: private static final DateTimeFormatter aFormatter = DateTimeFormatter.ofPattern("dd MM yyyy HH mm ss"); >>> 59: private static final DateTimeFormatter aParser = DateTimeFormatter.ofPattern("yyyy MM dd hh mm ss a"); >>> 60: private static Locale oldLocale; >> >> I wonder how many other tests we have that depend on specific Locale? Perhaps we need to apply the same treatment to: >> - LocalDateStringConverterTest >> - LocalTimeStringConverterTest > > I could also change those, as they use `DateTimeFormatter` as well which uses `Locale` underneath as discussed above. @kevinrushforth what do you think? Yes, it seems reasonable to include those tests as well, since those tests have the same problem. ------------- PR: https://git.openjdk.org/jfx/pull/954 From angorya at openjdk.org Fri Nov 18 17:27:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 17:27:25 GMT Subject: Integrated: 8297213: Robot capture tests should move mouse to corner of screen In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 00:48:11 GMT, Andy Goryachev wrote: > Added Util.parkCursor(Robot) method to move the cursor to lower left corner (while avoiding dock, tray, or active corners). This pull request has now been integrated. Changeset: 086dac0b Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/086dac0b12233f31db33bb9fc43d821724710f70 Stats: 76 lines in 7 files changed: 48 ins; 23 del; 5 mod 8297213: Robot capture tests should move mouse to corner of screen Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/955 From nlisker at gmail.com Fri Nov 18 17:28:38 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 18 Nov 2022 19:28:38 +0200 Subject: CheckBoxTreeItem behavior In-Reply-To: References: Message-ID: I think that even if a node is set to indeterminate programmatically, its parents should be updated at the very least (unless it's set to be independent). Not updating the children seems reasonable. On Fri, Nov 18, 2022 at 11:12 AM John Hendrikx wrote: > > On 18/11/2022 00:10, Nir Lisker wrote: > > Hi, > > > > I have been working on fixing some issues with the behavior > > of CheckBoxTreeItem. I stumbled across this situation: > > > > When a parent is de/selected, all of its children are set to the same > > state. However, a CheckBoxTreeItem can be set to indeterminate > > programmatically (the control itself does not allow indeterminate). > > Should all children also be set to an indeterminate state? If so, this > > will put the tree at an "invalid" state where leaf nodes can be > > indeterminate as well. OTOH, if not, then we are again at an invalid > > state if all children have the same state, but the parent doesn't. > > I think the indeterminate state is best left up completely to the owner > of the control. You may need information that is not part of the tree to > actually determine if something is indeterminate or not. A tree may be > filtered, or a tree may represent only "nodes" while "leaves" are > displayed in a 2nd control as a list. This means that in theory, parent > nodes could be indeterminate even if all its children are in the same > state (checked/unchecked) due to filtering, and leaf nodes could be > indeterminate if they represent a directory while the file selection is > displayed in a separate control. In Backup software, a directory may be > partially selected if it has a filter associated with it (like *.java) > even if that directory is empty or has only Java files currently... > > Some UI's will even allow you to click on an indeterminate parent node > to check it (checking all children), click again to uncheck it > (unchecked all children), and click a 3rd time to put it back to an > indeterminate state (restoring all children to the state they had before > the first click). > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Nov 18 18:21:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 18 Nov 2022 18:21:34 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v5] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Thu, 14 Jul 2022 08:05:25 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK_8256397 > Fixed more issues with the multiple selection model change events, and verified them with more unit-tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1456: > 1454: testSelectedIndicesChangeEventsFactory(0, new int[]{2,3}, 1, new int[]{5,7}, > 1455: new int[][]{new int[]{1}, new int[]{5,7}}); > 1456: Do we have a test that tries to select indexes outside of the model? modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1467: > 1465: > 1466: testSelectedIndicesChangeEventsFactory(2, new int[]{3, 6,7}, 0, new int[]{1,4,5,8,9}, > 1467: new int[][]{new int[]{0,1},new int[]{4,5},new int[]{8,9}}); I wonder if this test covers all the possible code paths in the implementation. To illustrate just a subset of scenarios that should be tested, let's consider these scenarios (initial selection on the top line, change on the bottom line): index 0 flipped, index 1 unchanged: -I- ||- index 1 unchanged -|- -|- index 1 unchanged, index 2 flipped -|- -|| index 0 and 2 flipped |-- --| etc. Perhaps it is possible to design a test that user random number generator to generate initial state and the changes, apply these to both MultipleSelectionModelBase and let's say a BitSet, and then compare the results - doing this 10,000 times (a sort of fuzzing test). A model with 10 items might be sufficient. modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 1478: > 1476: listView.getItems().add("item-4"); > 1477: listView.getItems().add("item-5"); > 1478: listView.getItems().add("item-6"); minor: .getItems().addAll( "1", "2", .. ); ------------- PR: https://git.openjdk.org/jfx/pull/353 From powers.anirvan at gmail.com Fri Nov 18 18:23:19 2022 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Fri, 18 Nov 2022 23:53:19 +0530 Subject: JavaFX snapshots in Maven Message-ID: Hi, I am trying to run tests with the officially released WebKit and Media shared libraries using the -PSTUB_RUNTIME_OPENJFX option [1]. But it is failing in Gradle dependency verification with below error as checksums are missing from verification metadata. A problem occurred evaluating root project 'jfx'. > Dependency verification failed for configuration ':openjfxStubs' 5 artifacts failed verification: - javafx-20-ea+7.pom (org.openjfx:javafx:20-ea+7) from repository MavenRepo - javafx-media-20-ea+7-win.jar (org.openjfx:javafx-media:20-ea+7) from repository MavenRepo - javafx-media-20-ea+7.pom (org.openjfx:javafx-media:20-ea+7) from repository MavenRepo - javafx-web-20-ea+7-win.jar (org.openjfx:javafx-web:20-ea+7) from repository MavenRepo - javafx-web-20-ea+7.pom (org.openjfx:javafx-web:20-ea+7) from repository MavenRepo If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at https://docs.gradle.org/7.3/userguide/dependency_verification.html#sec:troubleshooting-verification One way of resolving this issue would be to use SNAPSHOT dependencies. Gradle does not verify them as their checksums would always change [2]. Also developers will no longer need to manually check and specify the latest version for the -PSTUB_RUNTIME_OPENJFX option (after changes are made in the build file to always refer to the SNAPSHOT version when this option is specified). But currently in Maven only EA builds of JavaFX are provided. SNAPSHOT builds are not provided. There had been a discussion in the past to not provide SNAPSHOT builds due to some Gradle issue [3]. But since it has been more than 4 years since then, maybe the situation has changed. Is providing SNAPSHOT builds a possibility now ? This will be convenient for developers especially for those who are not actively working on the sources of WebKit and Media libraries. [1] : https://github.com/openjdk/jfx/blob/master/WEBKIT-MEDIA-STUBS.md#officially-released-libraries [2] : https://docs.gradle.org/7.3/userguide/dependency_verification.html#sub:verification-metadata [3] : https://mail.openjdk.org/pipermail/openjfx-dev/2018-July/022107.html -- Anirvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Fri Nov 18 20:12:25 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 18 Nov 2022 21:12:25 +0100 Subject: CheckBoxTreeItem behavior In-Reply-To: References: Message-ID: <6956b76b-eb83-a56e-e593-08c2514dd5b4@gmail.com> Yeah, I didn't consider the other direction, that makes sense. --John On 18/11/2022 18:28, Nir Lisker wrote: > I think that even if a node is set to indeterminate programmatically, > its parents should be updated at the very least (unless it's set to be > independent). Not updating the children seems reasonable. > > On Fri, Nov 18, 2022 at 11:12 AM John Hendrikx > wrote: > > > On 18/11/2022 00:10, Nir Lisker wrote: > > Hi, > > > > I have been working on fixing some issues with the behavior > > of?CheckBoxTreeItem. I stumbled across?this situation: > > > > When a parent is de/selected, all of its children are set to the > same > > state. However, a CheckBoxTreeItem can be set to indeterminate > > programmatically?(the control itself does not allow indeterminate). > > Should all children also be set to an indeterminate state? If > so, this > > will put the tree at an "invalid" state where leaf nodes can be > > indeterminate as well. OTOH, if not, then we are again at an > invalid > > state if all children have the same state, but the parent doesn't. > > I think the indeterminate state is best left up completely to the > owner > of the control. You may need information that is not part of the > tree to > actually determine if something is indeterminate or not.? A tree > may be > filtered, or a tree may represent only "nodes" while "leaves" are > displayed in a 2nd control as a list.? This means that in theory, > parent > nodes could be indeterminate even if all its children are in the same > state (checked/unchecked) due to filtering, and leaf nodes could be > indeterminate if they represent a directory while the file > selection is > displayed in a separate control.? In Backup software, a directory > may be > partially selected if it has a filter associated with it (like > *.java) > even if that directory is empty or has only Java files currently... > > Some UI's will even allow you to click on an indeterminate parent > node > to check it (checking all children), click again to uncheck it > (unchecked all children), and click a 3rd time to put it back to an > indeterminate state (restoring all children to the state they had > before > the first click). > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Sat Nov 19 07:28:27 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 19 Nov 2022 09:28:27 +0200 Subject: CheckBoxTreeItem behavior - independent property Message-ID: Hi, Another issue I stumbled across is the usage of the Independent property on CheckBoxTreeItem. The docs read: A BooleanProperty used to represent the independent state of this > CheckBoxTreeItem. The independent state is used to represent whether > changes to a single CheckBoxTreeItem should influence the state of its > parent and children. By default, the independent property is false, which means that when a > CheckBoxTreeItem has state changes to the selected or indeterminate > properties, the state of related CheckBoxTreeItems will possibly be > changed. If the independent property is set to true, the state of related > CheckBoxTreeItems will never change. It makes it clear that changes to this checkbox don't influence its children/parents, and in terms of usage, it means that clicking on the checkbox doesn't change the state of its parents/children. However: 1. Does it also include stopping the propagation of selection updates through it? If an independent item has a child and a parent, and the parent is selected, does the item stop its child from being selected? I think that the answer is yes, but I want to make sure the independent property wasn't just meant for direct clicks or direct changes to its own properties alone. 2. Do the parents/children affect this item? The docs only mention one direction: item -> parents/children, it doesn't mention parents/children -> item. As it stands currently, the item seems to be affected by other selections. I find it odd because this doesn't make the item really independent, and I can't think of a use case for this one-sided independent behavior. In any case, I think that the documentation should clarify these points, so I would like to know what the behavior should be. - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Sat Nov 19 18:09:06 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 19 Nov 2022 18:09:06 GMT Subject: RFR: 8297130: ComboBox popup doesn't close after selecting value that was added with 'runLater' Message-ID: This PR fixes a bug where multi-level focus is not correctly preserved. The original implementation incorrectly assumed that there can only be a single focused node in the scene graph, which is not the case when a branch of the scene graph is presented by a `PopupWindow`. More specifically, when a focused node was removed from the scene graph, the focus flags of all parents were incorrectly cleared. The correct implementation only clears the `focusWithin` flag of parents (but not `focused` or `focusVisible`), and stops when another focused node is encountered along the way. ------------- Commit messages: - Preserve multi-level focusWithin - Failing test Changes: https://git.openjdk.org/jfx/pull/956/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=956&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297130 Stats: 69 lines in 2 files changed: 57 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/956.diff Fetch: git fetch https://git.openjdk.org/jfx pull/956/head:pull/956 PR: https://git.openjdk.org/jfx/pull/956 From mstrauss at openjdk.org Sun Nov 20 00:14:26 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 20 Nov 2022 00:14:26 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 22:58:56 GMT, Kevin Rushforth wrote: > This will take a fair bit of discussion regarding how various applications might use such a feature, what the API should look like, etc. > I think there are basically three categories of how applications might use this feature: 1. Extend a built-in theme. 2. Create a new static theme. 3. Create a dynamic theme that responds to OS preferences. The proposed feature addresses all three categories, with the third option (a dynamic theme) being the most difficult to implement. It requires quite a bit of effort to create such a theme, and a good amount of that effort will be figuring out how OS-level preferences interact with themes (platform independence is a complicating factor). I've made it an explicit non-goal of this feature to provide an API for higher-level concepts like dark mode, high contrast, etc., since I think APIs for OS design trends should be left to third-party libraries instead. ------------- PR: https://git.openjdk.org/jfx/pull/511 From arapte at openjdk.org Sun Nov 20 07:48:02 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Sun, 20 Nov 2022 07:48:02 GMT Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used In-Reply-To: References: Message-ID: On Sun, 11 Sep 2022 12:13:47 GMT, Johan Vos wrote: > Don't set TabHeader to mouseTransparent, since it might get stuck in that state (e.g. in case an Alert is shown). > The TabPaneSkin deals with the dragging internally, and does not require the dragged node to be mouseTransparent. Apologies for the delay. Looks good to me. Tested on all three platforms. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/895 From jhendrikx at openjdk.org Mon Nov 21 12:54:40 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 12:54:40 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base Message-ID: - Remove unsupported/unnecessary SuppressWarning annotations - Remove reduntant type specifications (use diamond operator) - Remove unused or duplicate imports - Remove unnecessary casts (type is already correct type or can be autoboxed) - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) - Remove redundant super interfaces (interface that is already inherited) - Remove unused type parameters - Remove declared checked exceptions that are never thrown - Add missing `@Override` annotations ------------- Commit messages: - Fix easy warnings in base Changes: https://git.openjdk.org/jfx/pull/957/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297332 Stats: 1269 lines in 265 files changed: 32 ins; 169 del; 1068 mod Patch: https://git.openjdk.org/jfx/pull/957.diff Fetch: git fetch https://git.openjdk.org/jfx pull/957/head:pull/957 PR: https://git.openjdk.org/jfx/pull/957 From kcr at openjdk.org Mon Nov 21 15:21:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Nov 2022 15:21:35 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations Per our offline discussion, we don't need as careful of a review of these "remove warnings" changes. Since this is the first one, I'd like a second reviewer, mainly to validate the pattern you are using. It should still be a quick review if nothing odd is spotted. The main thing to be careful of is that we don't touch any public API signatures, since some of these sort of automated changes can have impact that we would need to consider. ------------- PR: https://git.openjdk.org/jfx/pull/957 From kcr at openjdk.org Mon Nov 21 15:29:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Nov 2022 15:29:00 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations One other quick comment: since you are removing some suppress warnings for "removal", I'd like to see the results of a build and test with `gradle -PLINT=removal` to ensure that there are no new warnings. ------------- PR: https://git.openjdk.org/jfx/pull/957 From nlisker at openjdk.org Mon Nov 21 15:43:33 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 21 Nov 2022 15:43:33 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations @andy-goryachev-oracle Please review this as well. ------------- PR: https://git.openjdk.org/jfx/pull/957 From armin.schrenk at skymatic.de Mon Nov 21 16:08:29 2022 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Mon, 21 Nov 2022 17:08:29 +0100 Subject: Signing shared libraries and questions about loading In-Reply-To: References: Message-ID: <3b058835-9cb8-7972-6d55-b798c7432fb3@skymatic.de> Oh, thanks, didn't knew that. I tried the JMOD files provided by Gloun company with a local build. Works! But how can this be integrated into an automatic/CI build? Using a more or less arbitrary url pointing to a third-party website downloading a zip file of unknown structure would result in a "ducktape build" and is not very resilient against any changes. Furthermore, some build systems (i.e., ubuntu-ppa) do not allow external downloads. Does automatic build examples exist which are jlinking JFX to a custom JRE? Best wishes, Armin Am 16/11/2022 um 15:39 schrieb Kevin Rushforth: > Leaving aside the question of signed libraries, if you are using > jpackage / jlink to create a custom Java runtime with the JavaFX > modules, then you should use the JMODs bundles and not the artifacts > from Maven central. The maven modules are a handy convenience for > developers, but not recommend for creating packaged applications. > > -- Kevin > > > > > On 11/16/2022 6:29 AM, Armin Schrenk wrote: >> Hello, >> >> for our application, a customer reported that the shared libraries >> (in this case DLLs) used by JFX are unsigned and thus were blocked >> from loading, which blocks the app from starting. The culprit for >> blocking is a new security feature for Windows 11, Smart App Control >> (https://support.microsoft.com/en-gb/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003). >> Since this feature seems to be a future part of Windows, i suggest to >> sign the shared libs before the maven release. In our case, the >> archive javafx-graphics-*-win.jar contains the DLLs. >> >> Apart from this feature request, we want to fix the issue on our >> side. To do that, I investigated into the sharedLib loading of JFX. >> >> SharedLib Loading is in JFX is done with the NativeLibLoader >> (https://github.com/openjdk/jfx/blob/19+11/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java). >> It does the following to load the native lib: >> >> 1. Load the DLLs from a certain path (see below) >> 2. On Failure, load the DLLs from a resource (aka the jar) by >> extracting them to a cache directory and load them from there >> 3. On Failure, do other stuff not of interest >> >> Our app is modular (or as much as possible), thus, the DLLs were >> always loaded from the resource. But this extract-and-cache approach >> is unsatisfying from our point of view. The app uses a custom JRE via >> jlink and is packaged with jpackage, and we would like to place the >> sharedLibs at build time somewhere in the app directory. >> >> So I had to figure out the where to place the DLLs, or more >> specifically, what path is checked in Step 1 of shared libLoading. >> Reading the inline comment starting at line 117, it should be the >> same dir as the jar is placed. Unfortunately, this is not the case >> and i had to dig more through the code to find out. >> >> Our app has the following structure: >> |- JarsAndMods >> ??? | - Mods >> ??? ??? | - modul1.jar >> ??? ??? | - modul2.jar >> ??? ??? | - ... >> ??? ??? | - javafx-graphics-XXX-win.jar >> ??? ??? | - ... >> ??? | - nonModular1.jar >> ??? | - nonModular2.jar >> ??? | - ... >> |- executable >> >> According to the comment, the path to place all DLLs should be >> /JarsAndMods/Mods. >> But verbose logging showed and later proofed by the code, it has to >> be /JarsAndMods/bin. >> >> My questions are: >> >> Why does JFX require only for Windows the `../bin` directory? >> >> Additionally, this inline comment has a FIXME that Step 1 of >> SharedLibLoading should be removed in the future. Is there already an >> ETA? >> >> And lastly, I would love to see some Documentation for this. I can >> write it and create the PR, but where should it be placed? >> >> >> Best wishes, >> >> Armin >> > From nlisker at openjdk.org Mon Nov 21 16:37:50 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 21 Nov 2022 16:37:50 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: <78oWN0-w8mNb7aYESCmSAFB_TcKPFaxFbeqvEo70228=.b75f05c2-7bc5-43c2-91e2-436e678a63b8@github.com> On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/957 From nlisker at openjdk.org Mon Nov 21 16:37:53 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 21 Nov 2022 16:37:53 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 15:19:24 GMT, Kevin Rushforth wrote: > The main thing to be careful of is that we don't touch any public API signatures, since some of these sort of automated changes can have impact that we would need to consider. This set of warnings doesn't change method signatures. The "raw types" warning fix will do that, so we will be careful there. ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 17:01:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 17:01:33 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: <4pNAXqWtUkEP5Go8gNIlp9NWcgoMz1yEwvWccDyixUU=.491e5eae-8be8-429c-8fe8-fe27127703c9@github.com> On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations One suggestion I'd like to make is to publish the Compiler Errors/Warnings configuration for Eclipse. I have a set of screenshots that produce a 0 err/warn count with the current master. Eclipse also seem to provide a way to export/import these configs, but for some reason export/import stopped working for me around a decade ago. I also noticed two things in general: 1. the default err/warn configuration enables meaningless warnings and disables those that point to the real problems (see [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379)) 2. in large code bases with multiple contributors, it makes little sense to enable warnings like usage of raw type or unused imports since they a) don't contribute to code quality and b) are getting re-introduced all the time by people who don't use Eclipse I am giving just two examples, but there are a few other warnings that I think should be disabled. It does not mean we should not attempt to clean up the code base, but at some point the benefit-to-cost ratio is just not that great. ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 17:07:28 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 17:07:28 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations This comment might be out of place, but since we started fixing raw type use may be you could take a look at it? I know it's in javafx.graphics, so not technically a part of this PR, but It's pretty weird. If I modify CssParser (any small change would do, even insert a space), Eclipse suddenly gives me a bunch of errors. The constructor ParsedValueImpl[],BackgroundPosition[]>(ParsedValueImpl[], LayeredBackgroundPositionConverter) is undefined CssParser.java line 2929 The constructor ParsedValueImpl[],BackgroundSize[]>(ParsedValueImpl[], LayeredBackgroundSizeConverter) is undefined CssParser.java line 3119 The constructor ParsedValueImpl[],BorderImageSlices[]>(ParsedValueImpl[], SliceSequenceConverter) is undefined CssParser.java line 3514 The constructor ParsedValueImpl[],BorderStrokeStyle[]>(ParsedValueImpl[], BorderStrokeStyleSequenceConverter) is undefined CssParser.java line 3172 The constructor ParsedValueImpl[],BorderWidths[]>(ParsedValueImpl[], BorderImageWidthsSequenceConverter) is undefined CssParser.java line 3558 The constructor ParsedValueImpl[],BorderStrokeStyle[]>[],BorderStrokeStyle[][]>(ParsedValueImpl[],BorderStrokeStyle[]>[], LayeredBorderStyleConverter) is undefined CssParser.java line 3187 If I then clean all the projects, the errors disappear. The only solution I found is to convert the offending lines to use raw types. Any ideas? ------------- PR: https://git.openjdk.org/jfx/pull/957 From hmeda at openjdk.org Mon Nov 21 17:08:09 2022 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 21 Nov 2022 17:08:09 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 Message-ID: Updated sqlite to v3.39.4 Verified build on windows, linux and mac. Sanity testing looks fine. ------------- Commit messages: - Update Sqlite to v3.39.4 Changes: https://git.openjdk.org/jfx/pull/953/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295755 Stats: 11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod Patch: https://git.openjdk.org/jfx/pull/953.diff Fetch: git fetch https://git.openjdk.org/jfx pull/953/head:pull/953 PR: https://git.openjdk.org/jfx/pull/953 From angorya at openjdk.org Mon Nov 21 19:14:58 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 19:14:58 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations Changes requested by angorya (Author). modules/javafx.base/src/main/java/javafx/beans/property/IntegerPropertyBase.java line 56: > 54: > 55: private int value; > 56: private ObservableIntegerValue observable = null;; is there an Eclipse warning for extra semicolon? modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyBooleanProperty.java line 168: > 166: } > 167: }; > 168: }; how did you find these - manually or searching for a "};" pattern? modules/javafx.base/src/main/java/javafx/util/converter/DateStringConverter.java line 130: > 128: > 129: /** {@inheritDoc} */ > 130: @SuppressWarnings("removal") puzzling - why was it marked with @SuppressWarnings("removal") ? modules/javafx.base/src/shims/java/javafx/event/EventTypeShim.java line 30: > 28: import java.util.List; > 29: > 30: public class EventTypeShim { this changes public API surface, does it not? modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 123: > 121: > 122: if (weakReference.get() == null && counter < steps / 3) { > 123: int percentageUsed = (steps - counter) / steps * 100; I suspect this will not produce a desired result. Perhaps it should be (int)(100.0 * (steps - counter) / steps); ------------- PR: https://git.openjdk.org/jfx/pull/957 From kcr at openjdk.org Mon Nov 21 19:30:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Nov 2022 19:30:31 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 17:35:08 GMT, Andy Goryachev wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > modules/javafx.base/src/shims/java/javafx/event/EventTypeShim.java line 30: > >> 28: import java.util.List; >> 29: >> 30: public class EventTypeShim { > > this changes public API surface, does it not? This is in the test shims, so not public API. ------------- PR: https://git.openjdk.org/jfx/pull/957 From kcr at openjdk.org Mon Nov 21 19:34:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 21 Nov 2022 19:34:26 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 19:11:16 GMT, Andy Goryachev wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 123: > >> 121: >> 122: if (weakReference.get() == null && counter < steps / 3) { >> 123: int percentageUsed = (steps - counter) / steps * 100; > > I suspect this will not produce a desired result. > Perhaps it should be > (int)(100.0 * (steps - counter) / steps); Removing the `(int)` cast is a behavior-neutral change. What you are pointing out does look a bug, but it is unrelated to this cleanup, so should be filed and fixed separately. ------------- PR: https://git.openjdk.org/jfx/pull/957 From jhendrikx at openjdk.org Mon Nov 21 19:56:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 19:56:24 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 17:20:43 GMT, Andy Goryachev wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > modules/javafx.base/src/main/java/javafx/beans/property/IntegerPropertyBase.java line 56: > >> 54: >> 55: private int value; >> 56: private ObservableIntegerValue observable = null;; > > is there an Eclipse warning for extra semicolon? Yes, `potential programming problems / empty statement`. It can sometimes point to a mistake where a semi colon is used just before a block. ------------- PR: https://git.openjdk.org/jfx/pull/957 From jhendrikx at openjdk.org Mon Nov 21 20:01:04 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 20:01:04 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 17:29:42 GMT, Andy Goryachev wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > modules/javafx.base/src/main/java/javafx/util/converter/DateStringConverter.java line 130: > >> 128: >> 129: /** {@inheritDoc} */ >> 130: @SuppressWarnings("removal") > > puzzling - why was it marked with @SuppressWarnings("removal") ? Probably the deprecation for removal warning was first blocked, then later fixed without removing the suppress warnings. There are currently no calls in that code that call anything deprecated, so I remove the suppress warnings. ------------- PR: https://git.openjdk.org/jfx/pull/957 From jhendrikx at openjdk.org Mon Nov 21 20:01:05 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 20:01:05 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 19:26:48 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/shims/java/javafx/event/EventTypeShim.java line 30: >> >>> 28: import java.util.List; >>> 29: >>> 30: public class EventTypeShim { >> >> this changes public API surface, does it not? > > This is in the test shims, so not public API. Shims are not public as far as I know. ------------- PR: https://git.openjdk.org/jfx/pull/957 From jhendrikx at openjdk.org Mon Nov 21 20:07:27 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 20:07:27 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 19:32:01 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 123: >> >>> 121: >>> 122: if (weakReference.get() == null && counter < steps / 3) { >>> 123: int percentageUsed = (steps - counter) / steps * 100; >> >> I suspect this will not produce a desired result. >> Perhaps it should be >> (int)(100.0 * (steps - counter) / steps); > > Removing the `(int)` cast is a behavior-neutral change. What you are pointing out does look a bug, but it is unrelated to this cleanup, so should be filed and fixed separately. Yeah, this looks like a bug, as `(steps - counter) / steps` which are all `int`s will likely always result in `0`. The cast removal here however does not alter the calculation, but does point to an error in the author's thought process. The result is however only used in the log message to inform of a problem, and so the logic is not otherwise affected. I can file a separate issue for this, unless we can agree to fix it as part of this clean-up. ------------- PR: https://git.openjdk.org/jfx/pull/957 From arapte at openjdk.org Mon Nov 21 20:12:20 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 21 Nov 2022 20:12:20 GMT Subject: [jfx17u] RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader Message-ID: Backport this a11y fix to jfx17u. This is not a clean backport. The source code changes apply cleanly but there was a conflict in test file. The test `DialogTest.java` file does not exist in jfx17u source. The file is now added but only with one test that was added as part of this fix to mainline, and other pre-existing tests are removed. Tested that fix works as expected on Windows and macOS ------------- Commit messages: - remove unused import - 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader Changes: https://git.openjdk.org/jfx17u/pull/91/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=91&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8087557 Stats: 89 lines in 6 files changed: 88 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/91.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/91/head:pull/91 PR: https://git.openjdk.org/jfx17u/pull/91 From angorya at openjdk.org Mon Nov 21 20:23:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 20:23:38 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 19:58:31 GMT, John Hendrikx wrote: >> This is in the test shims, so not public API. > > Shims are not public as far as I know. you are right. I just looked at the package "package javafx.event;" and said hmmm... ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 20:32:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 20:32:24 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations @hjohn I changed the title of the bug to make it clearer, please update this PR's title. ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 20:32:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 20:32:25 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 19:53:59 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/property/IntegerPropertyBase.java line 56: >> >>> 54: >>> 55: private int value; >>> 56: private ObservableIntegerValue observable = null;; >> >> is there an Eclipse warning for extra semicolon? > > Yes, `potential programming problems / empty statement`. It can sometimes point to a mistake where a semi colon is used just before a block. Cool. My eclipse finds other places which do look like a bug - see disposed:65 It is in the base - why isn't it this PR? ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 20:32:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 20:32:25 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 20:25:06 GMT, Andy Goryachev wrote: >> Yes, `potential programming problems / empty statement`. It can sometimes point to a mistake where a semi colon is used just before a block. > > Cool. My eclipse finds other places which do look like a bug - see disposed:65 > It is in the base - why isn't it this PR? full list Description Resource Location Empty control-flow statement DateCellBehavior.java line 95 Empty control-flow statement Disposer.java line 65 Empty control-flow statement Disposer.java line 66 Empty control-flow statement Disposer.java line 66 Empty control-flow statement Disposer.java line 72 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 267 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 268 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 380 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 494 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 673 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 678 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 686 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 800 Empty control-flow statement DualPivotQuicksort20191112Ext.java line 808 Empty control-flow statement KeyboardShortcutsHandler.java line 498 Empty control-flow statement PrismFontFactory.java line 1401 Unnecessary semicolon AbstractPrimaryTimerTest.java line 188 Unnecessary semicolon Activity.java line 31 Unnecessary semicolon AnimationMock.java line 41 Unnecessary semicolon Arc2D.java line 388 Unnecessary semicolon BaseMesh.java line 68 Unnecessary semicolon BindingsNumberCalculationsTest.java line 838 Unnecessary semicolon Bloom.java line 90 Unnecessary semicolon BoxBlur.java line 95 Unnecessary semicolon ButtonBaseTest.java line 182 Unnecessary semicolon CachingShapeRep.java line 234 Unnecessary semicolon CascadingStyle.java line 184 Unnecessary semicolon CellUtils.java line 155 Unnecessary semicolon CellUtils.java line 305 Unnecessary semicolon ChoiceBoxTreeCell.java line 340 Unnecessary semicolon Clipboard.java line 389 Unnecessary semicolon ClipboardContent.java line 212 Unnecessary semicolon ColorAdjust.java line 98 Unnecessary semicolon ColorInput.java line 83 Unnecessary semicolon ColorPalette.java line 445 Unnecessary semicolon ComboBoxTreeCell.java line 373 Unnecessary semicolon ContextMenuTest.java line 259 Unnecessary semicolon CssParser.java line 2493 Unnecessary semicolon CssParser.java line 3830 Unnecessary semicolon CssParser.java line 3834 Unnecessary semicolon D3DFrameStats.java line 54 Unnecessary semicolon DefaultCancelButtonTestBase.java line 304 Unnecessary semicolon DisplacementMap.java line 108 Unnecessary semicolon DisplacementMap.java line 243 Unnecessary semicolon DropShadow.java line 148 Unnecessary semicolon DummyTexture.java line 41 Unnecessary semicolon DumpRenderTree.java line 94 Unnecessary semicolon DumpRenderTree.java line 106 Unnecessary semicolon FXCanvas.java line 171 Unnecessary semicolon FXCanvas.java line 1254 Unnecessary semicolon FXDnDInteropN.java line 374 Unnecessary semicolon FireButtonBaseTest.java line 92 Unnecessary semicolon GaussianBlur.java line 83 Unnecessary semicolon Glow.java line 82 Unnecessary semicolon HyperlinkTest.java line 250 Unnecessary semicolon Image.java line 248 Unnecessary semicolon ImageInput.java line 81 Unnecessary semicolon ImageStorage.java line 115 Unnecessary semicolon InnerShadow.java line 128 Unnecessary semicolon IosImageLoaderFactory.java line 42 Unnecessary semicolon J2DPrinter.java line 865 Unnecessary semicolon J2DPrinterJob.java line 776 Unnecessary semicolon KeyCode.java line 1177 Unnecessary semicolon KeyCodeMap.java line 62 Unnecessary semicolon KeyFrameTest.java line 131 Unnecessary semicolon KeyFrameTest.java line 136 Unnecessary semicolon KeyFrameTest.java line 141 Unnecessary semicolon KeyFrameTest.java line 146 Unnecessary semicolon KeyFrameTest.java line 218 Unnecessary semicolon KeyFrameTest.java line 223 Unnecessary semicolon KeyFrameTest.java line 228 Unnecessary semicolon LeakTest.java line 187 Unnecessary semicolon LeakTest.java line 348 Unnecessary semicolon LeakTest.java line 474 Unnecessary semicolon LeakTest.java line 205 Unnecessary semicolon LeakTest.java line 210 Unnecessary semicolon LeakTest.java line 215 Unnecessary semicolon LightBaseTest.java line 89 Unnecessary semicolon Lighting.java line 77 Unnecessary semicolon Lighting.java line 164 Unnecessary semicolon LineChartTest.java line 55 Unnecessary semicolon LinearConvolveRenderState.java line 124 Unnecessary semicolon LinuxArch.java line 37 Unnecessary semicolon ListCellTest.java line 918 Unnecessary semicolon ListView.java line 526 Unnecessary semicolon ListViewTest.java line 775 Unnecessary semicolon ListViewTest.java line 815 Unnecessary semicolon MacAccessible.java line 1122 Unnecessary semicolon MacTouchInputSupport.java line 63 Unnecessary semicolon MediaException.java line 89 Unnecessary semicolon MediaException.java line 201 Unnecessary semicolon MediaPlayer.java line 267 Unnecessary semicolon MediaView.java line 475 Unnecessary semicolon MediaView.java line 744 Unnecessary semicolon MediaView.java line 800 Unnecessary semicolon MenuItemTest.java line 351 Unnecessary semicolon MenuItemTest.java line 541 Unnecessary semicolon MenuTest.java line 598 Unnecessary semicolon MotionBlur.java line 87 Unnecessary semicolon NodeEffectInput.java line 48 Unnecessary semicolon PaintTypeTest.java line 74 Unnecessary semicolon ParsedValueTest.java line 64 Unnecessary semicolon PerspectiveTransform.java line 136 Unnecessary semicolon PhongMaterial.java line 35 Unnecessary semicolon PlayerStateEvent.java line 37 Unnecessary semicolon PopupWindow.java line 692 Unnecessary semicolon PredefinedMeshManager.java line 234 Unnecessary semicolon Printer.java line 215 Unnecessary semicolon PrinterJob.java line 473 Unnecessary semicolon PrismTextLayout.java line 983 Unnecessary semicolon PrismTrace.java line 56 Unnecessary semicolon PseudoClassTest.java line 783 Unnecessary semicolon PseudoClassTest.java line 808 Unnecessary semicolon PseudoClassTest.java line 833 Unnecessary semicolon PseudoClassTest.java line 861 Unnecessary semicolon PseudoClassTest.java line 909 Unnecessary semicolon PseudoClassTest.java line 930 Unnecessary semicolon PseudoClassTest.java line 945 Unnecessary semicolon PseudoClassTest.java line 966 Unnecessary semicolon PseudoClassTest.java line 981 Unnecessary semicolon PseudoClassTest.java line 1002 Unnecessary semicolon PseudoClassTest.java line 1045 Unnecessary semicolon PseudoClassTest.java line 1050 Unnecessary semicolon PseudoClassTest.java line 1099 Unnecessary semicolon PseudoClassTest.java line 1104 Unnecessary semicolon PseudoClassTest.java line 1141 Unnecessary semicolon PseudoClassTest.java line 1199 Unnecessary semicolon PseudoClassTest.java line 1221 Unnecessary semicolon PseudoClassTest.java line 1242 Unnecessary semicolon PseudoClassTest.java line 1246 Unnecessary semicolon PseudoClassTest.java line 1265 Unnecessary semicolon Reflection.java line 95 Unnecessary semicolon Region.java line 978 Unnecessary semicolon Region.java line 1426 Unnecessary semicolon RegionTest.java line 1224 Unnecessary semicolon RenderThemeImpl.java line 84 Unnecessary semicolon RenderThemeImpl.java line 445 Unnecessary semicolon RenderThemeImpl.java line 463 Unnecessary semicolon RenderThemeImpl.java line 477 Unnecessary semicolon RenderThemeImpl.java line 491 Unnecessary semicolon RenderThemeImpl.java line 504 Unnecessary semicolon RenderThemeImpl.java line 522 Unnecessary semicolon RenderThemeImpl.java line 542 Unnecessary semicolon RenderThemeImpl.java line 592 Unnecessary semicolon Scene.java line 2018 Unnecessary semicolon SepiaTone.java line 83 Unnecessary semicolon Shadow.java line 92 Unnecessary semicolon SplitPane.java line 260 Unnecessary semicolon StyleManagerTest.java line 1007 Unnecessary semicolon StyleManagerTest.java line 1017 Unnecessary semicolon SubScene.java line 143 Unnecessary semicolon SwingNodeHelper.java line 117 Unnecessary semicolon TableColumnHeaderTest.java line 291 Unnecessary semicolon TableHeaderRow.java line 264 Unnecessary semicolon TableViewTest.java line 1535 Unnecessary semicolon TableViewTest.java line 1587 Unnecessary semicolon TableViewTest.java line 1743 Unnecessary semicolon TableViewTest.java line 1785 Unnecessary semicolon TextArea.java line 432 Unnecessary semicolon TextAreaSkin.java line 496 Unnecessary semicolon TextBehaviorShim.java line 46 Unnecessary semicolon TextInputControlBehavior.java line 642 Unnecessary semicolon TextInputControlSkin.java line 125 Unnecessary semicolon TextInputControlSkin.java line 145 Unnecessary semicolon TextInputControlSkin.java line 740 Unnecessary semicolon TextInputControlSkin.java line 745 Unnecessary semicolon TextInputControlSkin.java line 750 Unnecessary semicolon TextInputControlSkin.java line 838 Unnecessary semicolon ToolBar.java line 152 Unnecessary semicolon Tooltip.java line 218 Unnecessary semicolon TreeCellTest.java line 1001 Unnecessary semicolon TreeTableColumnHeaderTest.java line 120 Unnecessary semicolon TreeTableViewTest.java line 2522 Unnecessary semicolon TreeTableViewTest.java line 2575 Unnecessary semicolon TreeTableViewTest.java line 2718 Unnecessary semicolon TreeTableViewTest.java line 2757 Unnecessary semicolon TreeViewTest.java line 1121 Unnecessary semicolon TreeViewTest.java line 1160 Unnecessary semicolon URLTypeTest.java line 96 Unnecessary semicolon VirtualizedControlTestUtils.java line 95 Unnecessary semicolon WCPasteboard.java line 41 Unnecessary semicolon WCPluginWidget.java line 52 Unnecessary semicolon WinHTMLCodec.java line 169 Unnecessary semicolon WinHTMLCodec.java line 170 Unnecessary semicolon WinHTMLCodec.java line 384 Unnecessary semicolon XYChart.java line 1329 ------------- PR: https://git.openjdk.org/jfx/pull/957 From angorya at openjdk.org Mon Nov 21 20:32:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 21 Nov 2022 20:32:25 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: References: <5WrXQHajzOYjcW1QBeUNOr1Pu_0c6Uhvr88i5sTXiCk=.648ed567-a5bd-4dcb-90f6-bbec3678f050@github.com> Message-ID: On Mon, 21 Nov 2022 20:26:54 GMT, Andy Goryachev wrote: >> Cool. My eclipse finds other places which do look like a bug - see disposed:65 >> It is in the base - why isn't it this PR? > > full list > > > Description Resource Location > Empty control-flow statement DateCellBehavior.java line 95 > Empty control-flow statement Disposer.java line 65 > Empty control-flow statement Disposer.java line 66 > Empty control-flow statement Disposer.java line 66 > Empty control-flow statement Disposer.java line 72 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 267 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 268 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 380 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 494 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 673 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 678 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 686 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 800 > Empty control-flow statement DualPivotQuicksort20191112Ext.java line 808 > Empty control-flow statement KeyboardShortcutsHandler.java line 498 > Empty control-flow statement PrismFontFactory.java line 1401 > Unnecessary semicolon AbstractPrimaryTimerTest.java line 188 > Unnecessary semicolon Activity.java line 31 > Unnecessary semicolon AnimationMock.java line 41 > Unnecessary semicolon Arc2D.java line 388 > Unnecessary semicolon BaseMesh.java line 68 > Unnecessary semicolon BindingsNumberCalculationsTest.java line 838 > Unnecessary semicolon Bloom.java line 90 > Unnecessary semicolon BoxBlur.java line 95 > Unnecessary semicolon ButtonBaseTest.java line 182 > Unnecessary semicolon CachingShapeRep.java line 234 > Unnecessary semicolon CascadingStyle.java line 184 > Unnecessary semicolon CellUtils.java line 155 > Unnecessary semicolon CellUtils.java line 305 > Unnecessary semicolon ChoiceBoxTreeCell.java line 340 > Unnecessary semicolon Clipboard.java line 389 > Unnecessary semicolon ClipboardContent.java line 212 > Unnecessary semicolon ColorAdjust.java line 98 > Unnecessary semicolon ColorInput.java line 83 > Unnecessary semicolon ColorPalette.java line 445 > Unnecessary semicolon ComboBoxTreeCell.java line 373 > Unnecessary semicolon ContextMenuTest.java line 259 > Unnecessary semicolon CssParser.java line 2493 > Unnecessary semicolon CssParser.java line 3830 > Unnecessary semicolon CssParser.java line 3834 > Unnecessary semicolon D3DFrameStats.java line 54 > Unnecessary semicolon DefaultCancelButtonTestBase.java line 304 > Unnecessary semicolon DisplacementMap.java line 108 > Unnecessary semicolon DisplacementMap.java line 243 > Unnecessary semicolon DropShadow.java line 148 > Unnecessary semicolon DummyTexture.java line 41 > Unnecessary semicolon DumpRenderTree.java line 94 > Unnecessary semicolon DumpRenderTree.java line 106 > Unnecessary semicolon FXCanvas.java line 171 > Unnecessary semicolon FXCanvas.java line 1254 > Unnecessary semicolon FXDnDInteropN.java line 374 > Unnecessary semicolon FireButtonBaseTest.java line 92 > Unnecessary semicolon GaussianBlur.java line 83 > Unnecessary semicolon Glow.java line 82 > Unnecessary semicolon HyperlinkTest.java line 250 > Unnecessary semicolon Image.java line 248 > Unnecessary semicolon ImageInput.java line 81 > Unnecessary semicolon ImageStorage.java line 115 > Unnecessary semicolon InnerShadow.java line 128 > Unnecessary semicolon IosImageLoaderFactory.java line 42 > Unnecessary semicolon J2DPrinter.java line 865 > Unnecessary semicolon J2DPrinterJob.java line 776 > Unnecessary semicolon KeyCode.java line 1177 > Unnecessary semicolon KeyCodeMap.java line 62 > Unnecessary semicolon KeyFrameTest.java line 131 > Unnecessary semicolon KeyFrameTest.java line 136 > Unnecessary semicolon KeyFrameTest.java line 141 > Unnecessary semicolon KeyFrameTest.java line 146 > Unnecessary semicolon KeyFrameTest.java line 218 > Unnecessary semicolon KeyFrameTest.java line 223 > Unnecessary semicolon KeyFrameTest.java line 228 > Unnecessary semicolon LeakTest.java line 187 > Unnecessary semicolon LeakTest.java line 348 > Unnecessary semicolon LeakTest.java line 474 > Unnecessary semicolon LeakTest.java line 205 > Unnecessary semicolon LeakTest.java line 210 > Unnecessary semicolon LeakTest.java line 215 > Unnecessary semicolon LightBaseTest.java line 89 > Unnecessary semicolon Lighting.java line 77 > Unnecessary semicolon Lighting.java line 164 > Unnecessary semicolon LineChartTest.java line 55 > Unnecessary semicolon LinearConvolveRenderState.java line 124 > Unnecessary semicolon LinuxArch.java line 37 > Unnecessary semicolon ListCellTest.java line 918 > Unnecessary semicolon ListView.java line 526 > Unnecessary semicolon ListViewTest.java line 775 > Unnecessary semicolon ListViewTest.java line 815 > Unnecessary semicolon MacAccessible.java line 1122 > Unnecessary semicolon MacTouchInputSupport.java line 63 > Unnecessary semicolon MediaException.java line 89 > Unnecessary semicolon MediaException.java line 201 > Unnecessary semicolon MediaPlayer.java line 267 > Unnecessary semicolon MediaView.java line 475 > Unnecessary semicolon MediaView.java line 744 > Unnecessary semicolon MediaView.java line 800 > Unnecessary semicolon MenuItemTest.java line 351 > Unnecessary semicolon MenuItemTest.java line 541 > Unnecessary semicolon MenuTest.java line 598 > Unnecessary semicolon MotionBlur.java line 87 > Unnecessary semicolon NodeEffectInput.java line 48 > Unnecessary semicolon PaintTypeTest.java line 74 > Unnecessary semicolon ParsedValueTest.java line 64 > Unnecessary semicolon PerspectiveTransform.java line 136 > Unnecessary semicolon PhongMaterial.java line 35 > Unnecessary semicolon PlayerStateEvent.java line 37 > Unnecessary semicolon PopupWindow.java line 692 > Unnecessary semicolon PredefinedMeshManager.java line 234 > Unnecessary semicolon Printer.java line 215 > Unnecessary semicolon PrinterJob.java line 473 > Unnecessary semicolon PrismTextLayout.java line 983 > Unnecessary semicolon PrismTrace.java line 56 > Unnecessary semicolon PseudoClassTest.java line 783 > Unnecessary semicolon PseudoClassTest.java line 808 > Unnecessary semicolon PseudoClassTest.java line 833 > Unnecessary semicolon PseudoClassTest.java line 861 > Unnecessary semicolon PseudoClassTest.java line 909 > Unnecessary semicolon PseudoClassTest.java line 930 > Unnecessary semicolon PseudoClassTest.java line 945 > Unnecessary semicolon PseudoClassTest.java line 966 > Unnecessary semicolon PseudoClassTest.java line 981 > Unnecessary semicolon PseudoClassTest.java line 1002 > Unnecessary semicolon PseudoClassTest.java line 1045 > Unnecessary semicolon PseudoClassTest.java line 1050 > Unnecessary semicolon PseudoClassTest.java line 1099 > Unnecessary semicolon PseudoClassTest.java line 1104 > Unnecessary semicolon PseudoClassTest.java line 1141 > Unnecessary semicolon PseudoClassTest.java line 1199 > Unnecessary semicolon PseudoClassTest.java line 1221 > Unnecessary semicolon PseudoClassTest.java line 1242 > Unnecessary semicolon PseudoClassTest.java line 1246 > Unnecessary semicolon PseudoClassTest.java line 1265 > Unnecessary semicolon Reflection.java line 95 > Unnecessary semicolon Region.java line 978 > Unnecessary semicolon Region.java line 1426 > Unnecessary semicolon RegionTest.java line 1224 > Unnecessary semicolon RenderThemeImpl.java line 84 > Unnecessary semicolon RenderThemeImpl.java line 445 > Unnecessary semicolon RenderThemeImpl.java line 463 > Unnecessary semicolon RenderThemeImpl.java line 477 > Unnecessary semicolon RenderThemeImpl.java line 491 > Unnecessary semicolon RenderThemeImpl.java line 504 > Unnecessary semicolon RenderThemeImpl.java line 522 > Unnecessary semicolon RenderThemeImpl.java line 542 > Unnecessary semicolon RenderThemeImpl.java line 592 > Unnecessary semicolon Scene.java line 2018 > Unnecessary semicolon SepiaTone.java line 83 > Unnecessary semicolon Shadow.java line 92 > Unnecessary semicolon SplitPane.java line 260 > Unnecessary semicolon StyleManagerTest.java line 1007 > Unnecessary semicolon StyleManagerTest.java line 1017 > Unnecessary semicolon SubScene.java line 143 > Unnecessary semicolon SwingNodeHelper.java line 117 > Unnecessary semicolon TableColumnHeaderTest.java line 291 > Unnecessary semicolon TableHeaderRow.java line 264 > Unnecessary semicolon TableViewTest.java line 1535 > Unnecessary semicolon TableViewTest.java line 1587 > Unnecessary semicolon TableViewTest.java line 1743 > Unnecessary semicolon TableViewTest.java line 1785 > Unnecessary semicolon TextArea.java line 432 > Unnecessary semicolon TextAreaSkin.java line 496 > Unnecessary semicolon TextBehaviorShim.java line 46 > Unnecessary semicolon TextInputControlBehavior.java line 642 > Unnecessary semicolon TextInputControlSkin.java line 125 > Unnecessary semicolon TextInputControlSkin.java line 145 > Unnecessary semicolon TextInputControlSkin.java line 740 > Unnecessary semicolon TextInputControlSkin.java line 745 > Unnecessary semicolon TextInputControlSkin.java line 750 > Unnecessary semicolon TextInputControlSkin.java line 838 > Unnecessary semicolon ToolBar.java line 152 > Unnecessary semicolon Tooltip.java line 218 > Unnecessary semicolon TreeCellTest.java line 1001 > Unnecessary semicolon TreeTableColumnHeaderTest.java line 120 > Unnecessary semicolon TreeTableViewTest.java line 2522 > Unnecessary semicolon TreeTableViewTest.java line 2575 > Unnecessary semicolon TreeTableViewTest.java line 2718 > Unnecessary semicolon TreeTableViewTest.java line 2757 > Unnecessary semicolon TreeViewTest.java line 1121 > Unnecessary semicolon TreeViewTest.java line 1160 > Unnecessary semicolon URLTypeTest.java line 96 > Unnecessary semicolon VirtualizedControlTestUtils.java line 95 > Unnecessary semicolon WCPasteboard.java line 41 > Unnecessary semicolon WCPluginWidget.java line 52 > Unnecessary semicolon WinHTMLCodec.java line 169 > Unnecessary semicolon WinHTMLCodec.java line 170 > Unnecessary semicolon WinHTMLCodec.java line 384 > Unnecessary semicolon XYChart.java line 1329 many of those ^^ appear to be bugs. ------------- PR: https://git.openjdk.org/jfx/pull/957 From jhendrikx at openjdk.org Mon Nov 21 20:38:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 21 Nov 2022 20:38:24 GMT Subject: RFR: JDK-8297332: Remove easy warnings in base In-Reply-To: <4pNAXqWtUkEP5Go8gNIlp9NWcgoMz1yEwvWccDyixUU=.491e5eae-8be8-429c-8fe8-fe27127703c9@github.com> References: <4pNAXqWtUkEP5Go8gNIlp9NWcgoMz1yEwvWccDyixUU=.491e5eae-8be8-429c-8fe8-fe27127703c9@github.com> Message-ID: On Mon, 21 Nov 2022 16:57:30 GMT, Andy Goryachev wrote: > One suggestion I'd like to make is to publish the Compiler Errors/Warnings configuration for Eclipse. I have a set of screenshots that produce a 0 err/warn count with the current master. Eclipse also seem to provide a way to export/import these configs, but for some reason export/import stopped working for me around a decade ago. > > I also noticed two things in general: > > 1. the default err/warn configuration enables meaningless warnings and disables those that point to the real problems (see [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379)) The default configuration of Eclipse is a very conservative starting point, and shouldn't really be used for anything serious about code quality. Also, many of the warnings are not unique to Eclipse (it's just that Eclipse users notice them far easier thanks to a global problem view). The raw type warnings, unchecked casts and many others are part of `javac` as well. > 2. in large code bases with multiple contributors, it makes little sense to enable warnings like usage of raw type or unused imports since they a) don't contribute to code quality and b) are getting re-introduced all the time by people who don't use Eclipse I disagree, raw types warnings are of great value. Raw types were used in the pre Java 1.5 days, and `ClassCastException`s were a big problem then. After Java got generics, many of these can now be checked by the compiler and will result in compile errors. List list = new ArrayList(); list.add(2); String s = (String)list.get(0); The above code will have 0 warnings apart from raw type usage. It is also obviously wrong and will result in a runtime exception. This wouldn't compile if the list was typed. Unused imports are less of a problem I agree, but some hygiene there can help. For example, importing things just because Javadoc refers to it can point to problems in documentation where higher level concepts are referred to from a lower level abstraction. In projects I usually work on, we tend to have a fixed import order to avoid diffs on imports. Any diffs on imports then more clearly show you're adding/removing new dependencies -- depending on the code involved this can already be insightful to see if the code isn't doing too much or doing things it shouldn't be doing (ie. importing `java.sql.Date` instead of `java.util.Date` -- something you won't notice when only looking at the code). However, the best way to handle keeping a code base clean with many contributors is to make it part of the build process; the first step to achieve this is to clean the code base. Once the code is nearly warning free, the build can enfo