From psadhukhan at openjdk.org Fri Sep 1 03:27:59 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 1 Sep 2023 03:27:59 GMT Subject: RFR: 8315317: Add test for JDK-8262518 Message-ID: Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak ------------- Commit messages: - jckeck fix - 8315317: Add test for JDK-8262518 Changes: https://git.openjdk.org/jfx/pull/1228/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315317 Stats: 137 lines in 1 file changed: 137 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1228.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1228/head:pull/1228 PR: https://git.openjdk.org/jfx/pull/1228 From jvos at openjdk.org Fri Sep 1 09:12:14 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 09:12:14 GMT Subject: [jfx17u] RFR: 8310681: Update WebKit to 616.1 Message-ID: almost clean backport (apart from remove/add FontCustomPlatformData.h) of 8310681: Update WebKit to 616.1 Reviewed-by: kcr, sykora ------------- Commit messages: - 8310681: Update WebKit to 616.1 Changes: https://git.openjdk.org/jfx17u/pull/134/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310681 Stats: 156 lines in 2 files changed: 98 ins; 58 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/134.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/134/head:pull/134 PR: https://git.openjdk.org/jfx17u/pull/134 From bae at openjdk.org Fri Sep 1 09:34:49 2023 From: bae at openjdk.org (Andrew Brygin) Date: Fri, 1 Sep 2023 09:34:49 GMT Subject: Integrated: 8311097: Synchron XMLHttpRequest not receiving data In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 14:32:37 GMT, Andrew Brygin wrote: > This issue is a regression from 7e48413eb0 8285881: Update WebKit to 614.1. For synchronous requests, we have an additional buffer to collect data, and the appending data into this buffer is doing in a wrong way: we use Vector::append(U&& u), which adds only the first data element. Instead, we should use Vector::append(const U* u, size_t size) in order to add all obtained data. > > I have added the test for this issue to LoadTest.java This pull request has now been integrated. Changeset: 82f27748 Author: Andrew Brygin Committer: Dmitry Cherepanov URL: https://git.openjdk.org/jfx/commit/82f2774895b41ce81215012556483b1519495d5d Stats: 52 lines in 4 files changed: 50 ins; 1 del; 1 mod 8311097: Synchron XMLHttpRequest not receiving data Reviewed-by: jbhaskar, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1227 From jvos at openjdk.org Fri Sep 1 09:37:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 09:37:48 GMT Subject: [jfx17u] Withdrawn: 8310681: Update WebKit to 616.1 In-Reply-To: References: Message-ID: <71tWU0Wj4vuh7f1uirhg8zcEUbEFLxtBaiK1dxgC1Lc=.80397e60-f64b-49b4-9b59-6a12da2526ca@github.com> On Fri, 1 Sep 2023 09:05:27 GMT, Johan Vos wrote: > almost clean backport (apart from remove/add FontCustomPlatformData.h) of 8310681: Update WebKit to 616.1 > Reviewed-by: kcr, sykora This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx17u/pull/134 From jvos at openjdk.org Fri Sep 1 09:41:12 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 09:41:12 GMT Subject: [jfx17u] RFR: 8308307: Update to gcc 12.2.0 on Linux Message-ID: clean backport of 8308307: Update to gcc 12.2.0 on Linux Reviewed-by: arapte, sykora ------------- Commit messages: - 8308307: Update to gcc 12.2.0 on Linux Changes: https://git.openjdk.org/jfx17u/pull/135/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=135&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308307 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx17u/pull/135.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/135/head:pull/135 PR: https://git.openjdk.org/jfx17u/pull/135 From kpk at openjdk.org Fri Sep 1 09:45:46 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 1 Sep 2023 09:45:46 GMT Subject: RFR: 8296266: TextArea: Navigation breaks with RTL text In-Reply-To: References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com> Message-ID: On Thu, 31 Aug 2023 19:04:12 GMT, Andy Goryachev wrote: > This statement is not exactly correct. Cmd+right navigates to a (visible) line end, in this case it's in the middle of the text string (index=8). So if you place the cursor after the colon (index=7) and press right arrow, you'll get the split caret in exact the same configuration as cmd+right. Thanks for the details. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1220#issuecomment-1702472168 From jvos at openjdk.org Fri Sep 1 10:05:59 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 10:05:59 GMT Subject: [jfx17u] RFR: 8304665: Change to Xcode12.4+1.1 devkit Message-ID: clean backport of 8304665: Change to Xcode12.4+1.1 devkit Reviewed-by: jvos, arapte ------------- Commit messages: - 8304665: Change to Xcode12.4+1.1 devkit Changes: https://git.openjdk.org/jfx17u/pull/136/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304665 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx17u/pull/136.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/136/head:pull/136 PR: https://git.openjdk.org/jfx17u/pull/136 From jvos at openjdk.org Fri Sep 1 10:38:43 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 10:38:43 GMT Subject: [jfx17u] Integrated: 8304665: Change to Xcode12.4+1.1 devkit In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 09:58:20 GMT, Johan Vos wrote: > clean backport of 8304665: Change to Xcode12.4+1.1 devkit > Reviewed-by: jvos, arapte This pull request has now been integrated. Changeset: 5b4d13e1 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/5b4d13e10988ad00276b1a5c46282caf88eac9b4 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8304665: Change to Xcode12.4+1.1 devkit Backport-of: d875c876512260b47e93c49270e7dcc589a7c8b2 ------------- PR: https://git.openjdk.org/jfx17u/pull/136 From aghaisas at openjdk.org Fri Sep 1 10:41:43 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 1 Sep 2023 10:41:43 GMT Subject: RFR: 8283675: Line not removed from LineChart when series cleared In-Reply-To: References: Message-ID: <8GM-wTU_UviCJE8zA5XuuJ9wW7hMkbdf7ZjBD2Vb5OE=.a9a593d8-9c46-449f-a6ef-c6eec79d2549@github.com> On Fri, 18 Aug 2023 07:25:28 GMT, Karthik P K wrote: > The issue is present in AreaChart along with the LineChart. Issue is fixed in both the charts as part of this PR. > The line elements in case of Line chart and both line element and fill element in the case of Area charts were not cleared in `makePaths()` method in AreaChart.java. Hence the line and fill area were not getting cleared when series was cleared. > > Made changes in code to clear line element and fill element as required in the `makePaths()` method. > > Added tests to validate the changes in both LineChart and AreaChart. The fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1214#pullrequestreview-1606704659 From jvos at openjdk.org Fri Sep 1 11:18:49 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 11:18:49 GMT Subject: [jfx17u] Integrated: 8308307: Update to gcc 12.2.0 on Linux In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 09:35:04 GMT, Johan Vos wrote: > clean backport of 8308307: Update to gcc 12.2.0 on Linux > Reviewed-by: arapte, sykora This pull request has now been integrated. Changeset: 25bc4a0e Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/25bc4a0ee934d405155f2a31e5a7b62a34b3c715 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8308307: Update to gcc 12.2.0 on Linux Backport-of: 5bbb95b1443ca9e2dbf1d1536e5f76071d37f1c4 ------------- PR: https://git.openjdk.org/jfx17u/pull/135 From bae at openjdk.org Fri Sep 1 11:56:07 2023 From: bae at openjdk.org (Andrew Brygin) Date: Fri, 1 Sep 2023 11:56:07 GMT Subject: [jfx21u] RFR: 8311097: Synchron XMLHttpRequest not receiving data Message-ID: Clean backport of the fix for 8311097 from openjfx/master to jfx21u. Local runs of :web:test reveal no issues. ------------- Commit messages: - 8311097: Synchron XMLHttpRequest not receiving data Changes: https://git.openjdk.org/jfx21u/pull/12/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=12&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311097 Stats: 52 lines in 4 files changed: 50 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/12.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/12/head:pull/12 PR: https://git.openjdk.org/jfx21u/pull/12 From jvos at openjdk.org Fri Sep 1 11:59:05 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 11:59:05 GMT Subject: [jfx17u] RFR: 8315527: Change JavaFX release version to 17.0.9 in jfx17u Message-ID: Increase version to 17.0.9 ------------- Commit messages: - Increase version to 17.0.9 Changes: https://git.openjdk.org/jfx17u/pull/137/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315527 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/137.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/137/head:pull/137 PR: https://git.openjdk.org/jfx17u/pull/137 From bae at openjdk.org Fri Sep 1 11:59:45 2023 From: bae at openjdk.org (Andrew Brygin) Date: Fri, 1 Sep 2023 11:59:45 GMT Subject: [jfx21u] Integrated: 8311097: Synchron XMLHttpRequest not receiving data In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 11:47:09 GMT, Andrew Brygin wrote: > Clean backport of the fix for 8311097 from openjfx/master to jfx21u. Local runs of :web:test reveal no issues. This pull request has now been integrated. Changeset: b2850a09 Author: Andrew Brygin Committer: Dmitry Cherepanov URL: https://git.openjdk.org/jfx21u/commit/b2850a0967fe4c3a538769ce7c9970cab4c55f8e Stats: 52 lines in 4 files changed: 50 ins; 1 del; 1 mod 8311097: Synchron XMLHttpRequest not receiving data Backport-of: 82f2774895b41ce81215012556483b1519495d5d ------------- PR: https://git.openjdk.org/jfx21u/pull/12 From jpereda at openjdk.org Fri Sep 1 12:12:49 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 1 Sep 2023 12:12:49 GMT Subject: [jfx17u] RFR: 8315527: Change JavaFX release version to 17.0.9 in jfx17u In-Reply-To: References: Message-ID: <851nYqIGqxt2RuJfsowf-FDIQxpucvEulrh3o709XSI=.28a09dff-9781-4eae-822b-72001ab10c13@github.com> On Fri, 1 Sep 2023 11:53:22 GMT, Johan Vos wrote: > Increase version to 17.0.9 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/137#pullrequestreview-1606826170 From jvos at openjdk.org Fri Sep 1 12:16:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 12:16:45 GMT Subject: [jfx17u] Integrated: 8315527: Change JavaFX release version to 17.0.9 in jfx17u In-Reply-To: References: Message-ID: <5rmloz3vWWioHDn9aIhBfJ6vXLo-vl-D-TAh1OqjiFo=.bbbcbcc7-6b3e-4903-aacc-278d45505282@github.com> On Fri, 1 Sep 2023 11:53:22 GMT, Johan Vos wrote: > Increase version to 17.0.9 This pull request has now been integrated. Changeset: c02cb49c Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/c02cb49c6afc64763ad73cca6da351d9ad05178e Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8315527: Change JavaFX release version to 17.0.9 in jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/137 From jvos at openjdk.org Fri Sep 1 12:48:57 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 12:48:57 GMT Subject: [jfx17u] RFR: 8308306: Update to Xcode 14.3 on macOS Message-ID: 8308306: Update to Xcode 14.3 on macOS Reviewed-by: arapte, sykora ------------- Commit messages: - 8308306: Update to Xcode 14.3 on macOS Changes: https://git.openjdk.org/jfx17u/pull/138/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308306 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx17u/pull/138.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/138/head:pull/138 PR: https://git.openjdk.org/jfx17u/pull/138 From jvos at openjdk.org Fri Sep 1 13:03:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 13:03:47 GMT Subject: [jfx17u] Integrated: 8308306: Update to Xcode 14.3 on macOS In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 12:43:35 GMT, Johan Vos wrote: > 8308306: Update to Xcode 14.3 on macOS > Reviewed-by: arapte, sykora This pull request has now been integrated. Changeset: 45b7fc3e Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/45b7fc3ea503f2478010f34ef3240fe9c232ecce Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod 8308306: Update to Xcode 14.3 on macOS Backport-of: 2833a53ad1b40675c8eb6c3f19631bd0d3df5198 ------------- PR: https://git.openjdk.org/jfx17u/pull/138 From jvos at openjdk.org Fri Sep 1 13:09:19 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 13:09:19 GMT Subject: [jfx17u] RFR: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows Message-ID: Clean backport of 2 issues: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows 8303748: WebKit build fails with Visual Studio 2022 17.5.0 Reviewed-by: arapte, sykora ------------- Commit messages: - 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows Changes: https://git.openjdk.org/jfx17u/pull/139/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308308 Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx17u/pull/139.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/139/head:pull/139 PR: https://git.openjdk.org/jfx17u/pull/139 From jvos at openjdk.org Fri Sep 1 13:28:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 13:28:47 GMT Subject: [jfx17u] Integrated: 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows In-Reply-To: References: Message-ID: <2oiZGHiJBoh6LGb5DWLBZo1scnge3r2wR7oOu5Kvdak=.809732a9-08aa-463e-aeac-160c4866d96e@github.com> On Fri, 1 Sep 2023 13:03:03 GMT, Johan Vos wrote: > Clean backport of 2 issues: > 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows > 8303748: WebKit build fails with Visual Studio 2022 17.5.0 > > > Reviewed-by: arapte, sykora This pull request has now been integrated. Changeset: 5b25b799 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/5b25b79906c2aa2221a2a2b914033025dea37075 Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod 8308308: Update to Visual Studio 2022 version 17.5.0 on Windows 8303748: WebKit build fails with Visual Studio 2022 17.5.0 Backport-of: 8fc1a256a90fa02bbf775317de3158c81e7b950d ------------- PR: https://git.openjdk.org/jfx17u/pull/139 From jvos at openjdk.org Fri Sep 1 14:02:30 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 14:02:30 GMT Subject: [jfx17u] RFR: 8310681: Update WebKit to 616.1 Message-ID: <1hwBr9epWyxapgGP9lXRwZMi1Z3eLZpn1KxB3zAcvNM=.e990879a-6d8b-458a-9487-858f77efd644@github.com> Almost clean backport for 8310681: Update WebKit to 616.1 Reviewed-by: kcr, sykora The only manual change was changing the (c) year in the removed graphics/java/FontCustomPlatformData.h fil ------------- Commit messages: - 8310681: Update WebKit to 616.1 Changes: https://git.openjdk.org/jfx17u/pull/140/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=140&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310681 Stats: 381300 lines in 5888 files changed: 214309 ins; 124154 del; 42837 mod Patch: https://git.openjdk.org/jfx17u/pull/140.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/140/head:pull/140 PR: https://git.openjdk.org/jfx17u/pull/140 From angorya at openjdk.org Fri Sep 1 14:37:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Sep 2023 14:37:49 GMT Subject: RFR: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 03:16:11 GMT, Prasanta Sadhukhan wrote: > Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 94: > 92: //Lets throw in a little sleep so we can read the output > 93: try { > 94: Thread.sleep(100); I would suggest to use random delay here (random.nextInt(100)). But make sure to set a random seed at the beginning and print it so it can be reproduced. Although in this test, the outcome depends on many things that the test has no control over. What do you think? tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 108: > 106: ref.get() != null).count(); > 107: // Sometimes panel count can shoot upto more than 3 once or twice > 108: // due to gc not being guranteed so this check prevents false failure guaranteed tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 116: > 114: System.out.println("iteration " + count + " Panels in memory: " > 115: + panelCount + " fail " + fail); > 116: assertFalse(fail > 2); I actually seen the number to shoot up to 38 (albeit with Thread.sleep(1)). I wonder if there is a better way to detect failure? May be the fact that the 'panelCount` is ever increasing is the sign of failure, whereas if at least one time it's dropping we have succeeded. Or perhaps look at the count when the test complete and fail if panelCount < (attempts / 2) or something ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313115716 PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313099511 PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313112869 From kcr at openjdk.org Fri Sep 1 14:41:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Sep 2023 14:41:49 GMT Subject: RFR: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:33:52 GMT, Andy Goryachev wrote: >> Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak > > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 94: > >> 92: //Lets throw in a little sleep so we can read the output >> 93: try { >> 94: Thread.sleep(100); > > I would suggest to use random delay here (random.nextInt(100)). > But make sure to set a random seed at the beginning and print it so it can be reproduced. Although in this test, the outcome depends on many things that the test has no control over. > What do you think? No, let's not. While there may be some rare cases where randomness adds something useful to the test, automated tests should be predictable. > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 116: > >> 114: System.out.println("iteration " + count + " Panels in memory: " >> 115: + panelCount + " fail " + fail); >> 116: assertFalse(fail > 2); > > I actually seen the number to shoot up to 38 (albeit with Thread.sleep(1)). I wonder if there is a better way to detect failure? May be the fact that the 'panelCount` is ever increasing is the sign of failure, whereas if at least one time it's dropping we have succeeded. > Or perhaps look at the count when the test complete and fail if panelCount < (attempts / 2) or something I recommend using `JMemoryBuddy`, which is what we use for all of our newer memory leak tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313120071 PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313120559 From jvos at openjdk.org Fri Sep 1 14:43:55 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 14:43:55 GMT Subject: [jfx17u] Integrated: 8310681: Update WebKit to 616.1 In-Reply-To: <1hwBr9epWyxapgGP9lXRwZMi1Z3eLZpn1KxB3zAcvNM=.e990879a-6d8b-458a-9487-858f77efd644@github.com> References: <1hwBr9epWyxapgGP9lXRwZMi1Z3eLZpn1KxB3zAcvNM=.e990879a-6d8b-458a-9487-858f77efd644@github.com> Message-ID: <_K494YQWxEGhdE7GPw3Jppj0PmdjRt4QN5oslBnKmp0=.f0513659-3bef-47f5-a331-0c8c8b5343d7@github.com> On Fri, 1 Sep 2023 13:39:57 GMT, Johan Vos wrote: > Almost clean backport for > 8310681: Update WebKit to 616.1 > Reviewed-by: kcr, sykora > > The only manual change was changing the (c) year in the removed graphics/java/FontCustomPlatformData.h fil This pull request has now been integrated. Changeset: 0e81ee16 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/0e81ee16627fc3b6f16179db2e957d02a77f8e67 Stats: 381300 lines in 5888 files changed: 214309 ins; 124154 del; 42837 mod 8310681: Update WebKit to 616.1 Backport-of: 2dc699a8661fb23040c9f8e3905713229e615816 ------------- PR: https://git.openjdk.org/jfx17u/pull/140 From angorya at openjdk.org Fri Sep 1 14:47:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Sep 2023 14:47:46 GMT Subject: RFR: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:37:53 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 94: >> >>> 92: //Lets throw in a little sleep so we can read the output >>> 93: try { >>> 94: Thread.sleep(100); >> >> I would suggest to use random delay here (random.nextInt(100)). >> But make sure to set a random seed at the beginning and print it so it can be reproduced. Although in this test, the outcome depends on many things that the test has no control over. >> What do you think? > > No, let's not. While there may be some rare cases where randomness adds something useful to the test, automated tests should be predictable. they become predictable when the seed is known. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313132281 From kcr at openjdk.org Fri Sep 1 15:01:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Sep 2023 15:01:49 GMT Subject: RFR: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:45:05 GMT, Andy Goryachev wrote: >> No, let's not. While there may be some rare cases where randomness adds something useful to the test, automated tests should be predictable. > > they become predictable when the seed is known. Yes, but then you would need to modify the test to rerun it with the same seed as the time it failed. If we had a utility that made this easy, then maybe, but I'd still be skeptical. I am not convinced that whatever benefit we might get is worth the effort or the unpredictability. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313149894 From angorya at openjdk.org Fri Sep 1 15:11:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Sep 2023 15:11:49 GMT Subject: RFR: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:58:56 GMT, Kevin Rushforth wrote: >> they become predictable when the seed is known. > > Yes, but then you would need to modify the test to rerun it with the same seed as the time it failed. If we had a utility that made this easy, then maybe, but I'd still be skeptical. I am not convinced that whatever benefit we might get is worth the effort or the unpredictability. the main benefit is that every new run effectively extends the test coverage. however, in this particular case, the test won't be reproducible because it depends on many other factors like the platform load. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1313162332 From kcr at openjdk.org Fri Sep 1 16:50:43 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Sep 2023 16:50:43 GMT Subject: RFR: 8314064: Enable building JavaFX on native Windows AArch64 (ARM64) [v2] In-Reply-To: References: Message-ID: On Sat, 12 Aug 2023 16:21:07 GMT, Martin Fox wrote: >> This PR enables building for 64-bit ARM on Windows ARM machines. Tested on a Windows 11 ARM virtual machine running under Parallels on an Apple Silicon Mac. The ARM version of JDK 17 was provided by Microsoft. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge remote-tracking branch 'upstream/master' into winarmbuild > - Can now build for ARM64 on Windows ARM machine Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1208#pullrequestreview-1607324433 From jvos at openjdk.org Fri Sep 1 17:40:12 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 17:40:12 GMT Subject: [jfx17u] RFR: 8313177: Web Workers timeout with Webkit 616.1 Message-ID: 8313177: Web Workers timeout with Webkit 616.1 Reviewed-by: kcr, hmeda ------------- Commit messages: - 8313177: Web Workers timeout with Webkit 616.1 Changes: https://git.openjdk.org/jfx17u/pull/141/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313177 Stats: 117 lines in 4 files changed: 110 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/141.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/141/head:pull/141 PR: https://git.openjdk.org/jfx17u/pull/141 From jvos at openjdk.org Fri Sep 1 18:03:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 18:03:45 GMT Subject: [jfx17u] Integrated: 8313177: Web Workers timeout with Webkit 616.1 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 17:32:24 GMT, Johan Vos wrote: > 8313177: Web Workers timeout with Webkit 616.1 > Reviewed-by: kcr, hmeda This pull request has now been integrated. Changeset: c29ae729 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/c29ae729fa16d5710e272315d5e23488ec00c624 Stats: 117 lines in 4 files changed: 110 ins; 7 del; 0 mod 8313177: Web Workers timeout with Webkit 616.1 Backport-of: 5f5e54feb2e816dcb351a28862c798117c3f81e8 ------------- PR: https://git.openjdk.org/jfx17u/pull/141 From jvos at openjdk.org Fri Sep 1 18:27:00 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 18:27:00 GMT Subject: [jfx17u] RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes Message-ID: <_EVO8zRzrFTI7hjvUAeSh0dMdU90OrILIyvtlNkWaf8=.8dbe1180-5bb8-4434-965b-dafa2b033dfb@github.com> 8313711: Cherry-pick WebKit 616.1 stabilization fixes Reviewed-by: kcr, sykora ------------- Commit messages: - 8313711: Cherry-pick WebKit 616.1 stabilization fixes Changes: https://git.openjdk.org/jfx17u/pull/142/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313711 Stats: 637 lines in 88 files changed: 320 ins; 150 del; 167 mod Patch: https://git.openjdk.org/jfx17u/pull/142.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/142/head:pull/142 PR: https://git.openjdk.org/jfx17u/pull/142 From jvos at openjdk.org Fri Sep 1 18:46:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 18:46:47 GMT Subject: [jfx17u] Integrated: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: <_EVO8zRzrFTI7hjvUAeSh0dMdU90OrILIyvtlNkWaf8=.8dbe1180-5bb8-4434-965b-dafa2b033dfb@github.com> References: <_EVO8zRzrFTI7hjvUAeSh0dMdU90OrILIyvtlNkWaf8=.8dbe1180-5bb8-4434-965b-dafa2b033dfb@github.com> Message-ID: On Fri, 1 Sep 2023 18:22:22 GMT, Johan Vos wrote: > 8313711: Cherry-pick WebKit 616.1 stabilization fixes > Reviewed-by: kcr, sykora This pull request has now been integrated. Changeset: d80fb3a5 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/d80fb3a52c8d26f90ddadbea704bed305e83694b Stats: 637 lines in 88 files changed: 320 ins; 150 del; 167 mod 8313711: Cherry-pick WebKit 616.1 stabilization fixes Backport-of: af8950e7ebfa1f0705cc9ef5ab50ce25571c00d4 ------------- PR: https://git.openjdk.org/jfx17u/pull/142 From jvos at openjdk.org Fri Sep 1 18:52:59 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 18:52:59 GMT Subject: [jfx17u] RFR: 8314212: Crash when loading cnn.com in WebView Message-ID: <399wHKCJ-1sHHmUlINGjRIX-DQ2uNTJ0_-id0i7GWIo=.642ac104-7d8d-449a-a2cf-89ad97bfb5ad@github.com> Clean backport of 8314212: Crash when loading cnn.com in WebView Reviewed-by: kcr, hmeda ------------- Commit messages: - 8314212: Crash when loading cnn.com in WebView Changes: https://git.openjdk.org/jfx17u/pull/143/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314212 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/143.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/143/head:pull/143 PR: https://git.openjdk.org/jfx17u/pull/143 From jvos at openjdk.org Fri Sep 1 19:13:44 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 19:13:44 GMT Subject: [jfx17u] Integrated: 8314212: Crash when loading cnn.com in WebView In-Reply-To: <399wHKCJ-1sHHmUlINGjRIX-DQ2uNTJ0_-id0i7GWIo=.642ac104-7d8d-449a-a2cf-89ad97bfb5ad@github.com> References: <399wHKCJ-1sHHmUlINGjRIX-DQ2uNTJ0_-id0i7GWIo=.642ac104-7d8d-449a-a2cf-89ad97bfb5ad@github.com> Message-ID: <-68bEjAt8bps4ppLnnbmcdLO6203KSBAwUerQKfMuPY=.4071fcb3-1a03-4369-bd80-8eded119cbde@github.com> On Fri, 1 Sep 2023 18:47:28 GMT, Johan Vos wrote: > Clean backport of > 8314212: Crash when loading cnn.com in WebView > Reviewed-by: kcr, hmeda This pull request has now been integrated. Changeset: b3df5374 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/b3df53746f55a78f536748ff162a23eb371e7804 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod 8314212: Crash when loading cnn.com in WebView Backport-of: ddd1f79685383f592a4651811a9a9070569a7832 ------------- PR: https://git.openjdk.org/jfx17u/pull/143 From jvos at openjdk.org Fri Sep 1 19:59:06 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Sep 2023 19:59:06 GMT Subject: [jfx17u] RFR: 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element Message-ID: Clean backport of 8313181: Enabling modern media controls on webkit 616.1 does not load?button images on HTML5 video Element Reviewed-by: kcr, hmeda ------------- Commit messages: - 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element Changes: https://git.openjdk.org/jfx17u/pull/144/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=144&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313181 Stats: 279 lines in 12 files changed: 273 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/144.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/144/head:pull/144 PR: https://git.openjdk.org/jfx17u/pull/144 From duke at openjdk.org Fri Sep 1 20:11:44 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 1 Sep 2023 20:11:44 GMT Subject: Integrated: 8314064: Enable building JavaFX on native Windows AArch64 (ARM64) In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 16:16:44 GMT, Martin Fox wrote: > This PR enables building for 64-bit ARM on Windows ARM machines. Tested on a Windows 11 ARM virtual machine running under Parallels on an Apple Silicon Mac. The ARM version of JDK 17 was provided by Microsoft. This pull request has now been integrated. Changeset: 84aad81a Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/84aad81ad3ac00ca1600b715a5482c90b5a12e55 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8314064: Enable building JavaFX on native Windows AArch64 (ARM64) Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1208 From shurailine at openjdk.org Sat Sep 2 00:31:26 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Sat, 2 Sep 2023 00:31:26 GMT Subject: [jfx-tests] RFR: JDK-8315409: Fix jfx-tests so they work with latest jfx build [v2] In-Reply-To: References: Message-ID: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> > JDK-8315409: Fix jfx-tests so they work with latest jfx build Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: Addressing copyright issues. ------------- Changes: - all: https://git.openjdk.org/jfx-tests/pull/1/files - new: https://git.openjdk.org/jfx-tests/pull/1/files/feebfc83..808056a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=1&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=1&range=00-01 Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx-tests/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx-tests/pull/1 From jvos at openjdk.org Sat Sep 2 08:46:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Sat, 2 Sep 2023 08:46:47 GMT Subject: [jfx17u] Integrated: 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 19:51:51 GMT, Johan Vos wrote: > Clean backport of 8313181: Enabling modern media controls on webkit 616.1 does not load?button images on HTML5 video Element > > Reviewed-by: kcr, hmeda This pull request has now been integrated. Changeset: 12f416d0 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/12f416d02b02e7ea3d9b8d921d1552cd5c125327 Stats: 279 lines in 12 files changed: 273 ins; 1 del; 5 mod 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element Backport-of: 5d741761e751aa047f265d9d816be535a1818aee ------------- PR: https://git.openjdk.org/jfx17u/pull/144 From jvos at openjdk.org Sat Sep 2 08:58:36 2023 From: jvos at openjdk.org (Johan Vos) Date: Sat, 2 Sep 2023 08:58:36 GMT Subject: [jfx17u] RFR: 8306329: Update ICU4C to 73.1 Message-ID: Clean backport of 8306329: Update ICU4C to 73.1 Reviewed-by: kcr, jvos ------------- Commit messages: - 8306329: Update ICU4C to 73.1 Changes: https://git.openjdk.org/jfx17u/pull/145/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306329 Stats: 35622 lines in 738 files changed: 9131 ins; 2562 del; 23929 mod Patch: https://git.openjdk.org/jfx17u/pull/145.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/145/head:pull/145 PR: https://git.openjdk.org/jfx17u/pull/145 From jvos at openjdk.org Sat Sep 2 11:56:52 2023 From: jvos at openjdk.org (Johan Vos) Date: Sat, 2 Sep 2023 11:56:52 GMT Subject: [jfx17u] Integrated: 8306329: Update ICU4C to 73.1 In-Reply-To: References: Message-ID: On Sat, 2 Sep 2023 08:51:35 GMT, Johan Vos wrote: > Clean backport of > 8306329: Update ICU4C to 73.1 > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: cba058f0 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/cba058f057aba54028809c4dcf56a3453fd7780e Stats: 35622 lines in 738 files changed: 9131 ins; 2562 del; 23929 mod 8306329: Update ICU4C to 73.1 Backport-of: 2f5dcfd3d06282a5552bf9db676541686600a9b9 ------------- PR: https://git.openjdk.org/jfx17u/pull/145 From jpereda at openjdk.org Sat Sep 2 12:53:09 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 2 Sep 2023 12:53:09 GMT Subject: [jfx17u] RFR: 8311097: Synchron XMLHttpRequest not receiving data Message-ID: <8PKoDZ9dKKrkVVN9pL4pG4w4J1_7YOewMD8K6rDi91w=.5fc80762-1bac-41de-9a8e-0f9941423417@github.com> Clean backport of 8311097: Synchron XMLHttpRequest not receiving data Reviewed-by: jbhaskar, kcr ------------- Commit messages: - 8311097: Synchron XMLHttpRequest not receiving data Changes: https://git.openjdk.org/jfx17u/pull/146/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311097 Stats: 52 lines in 4 files changed: 50 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/146.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/146/head:pull/146 PR: https://git.openjdk.org/jfx17u/pull/146 From mhanl at openjdk.org Sat Sep 2 13:01:56 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 2 Sep 2023 13:01:56 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) Message-ID: This PR adds a test that verifies the `SkinBase.layoutChildren(..)` method with different scales. While not explicitly documented, this method will receive the snapped and correctly calculated x, y, width and height values, so that children of the Control can be layouted correctly without requiring to do many more calculations regarding padding. ------------- Commit messages: - JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) Changes: https://git.openjdk.org/jfx/pull/1229/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315569 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1229.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1229/head:pull/1229 PR: https://git.openjdk.org/jfx/pull/1229 From mhanl at openjdk.org Sat Sep 2 13:09:14 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 2 Sep 2023 13:09:14 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: References: Message-ID: > This PR adds a test that verifies the `SkinBase.layoutChildren(..)` method with different scales. > While not explicitly documented, this method will receive the snapped and correctly calculated x, y, width and height values, so that children of the Control can be layouted correctly without requiring to do many more calculations regarding padding. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8315569: Set a min size ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1229/files - new: https://git.openjdk.org/jfx/pull/1229/files/880a2981..8ae26188 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1229&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1229&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1229.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1229/head:pull/1229 PR: https://git.openjdk.org/jfx/pull/1229 From jpereda at openjdk.org Sat Sep 2 14:49:42 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sat, 2 Sep 2023 14:49:42 GMT Subject: [jfx17u] Integrated: 8311097: Synchron XMLHttpRequest not receiving data In-Reply-To: <8PKoDZ9dKKrkVVN9pL4pG4w4J1_7YOewMD8K6rDi91w=.5fc80762-1bac-41de-9a8e-0f9941423417@github.com> References: <8PKoDZ9dKKrkVVN9pL4pG4w4J1_7YOewMD8K6rDi91w=.5fc80762-1bac-41de-9a8e-0f9941423417@github.com> Message-ID: On Sat, 2 Sep 2023 12:47:18 GMT, Jose Pereda wrote: > Clean backport of 8311097: Synchron XMLHttpRequest not receiving data > Reviewed-by: jbhaskar, kcr This pull request has now been integrated. Changeset: 7e1a7122 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/7e1a71228befdb010bffd56565586e74c180bc2f Stats: 52 lines in 4 files changed: 50 ins; 1 del; 1 mod 8311097: Synchron XMLHttpRequest not receiving data Backport-of: 82f2774895b41ce81215012556483b1519495d5d ------------- PR: https://git.openjdk.org/jfx17u/pull/146 From michaelstrau2 at gmail.com Sat Sep 2 22:09:13 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 3 Sep 2023 00:09:13 +0200 Subject: JavaFX object traits Message-ID: There's a proposal to add a common interface that identifies JavaFX objects that can hold an Observable property map: https://github.com/openjdk/jfx/pull/1215 The reason for this is obvious: allow JavaFX objects that can hold properties to be consumed by code without depending on brittle `instanceof` checks. The problem is real, but I think we can do much better than that. Why have a common interface at all? Well, of course it allows consumers to treat different objects in a uniform way. But there's more to it: the interface specifies the _meaning_ of the method; it guarantees that `Foo::getProperties` and `Bar::getProperties` are, in fact, not only methods with the same name, but the same semantics. `getProperties` and `hasProperties` is one example of such commonality between dissimilar classes like `Node` and `MenuItem`. But I've come across other examples in my own projects. For example, I'd like to consume JavaFX objects that have the `visible` and `disable` properties. Other applications will have different use cases, but since we don't know all possible use cases, it's hard to come up with a set of useful combinations of properties and methods. However, I think we can use the Java type system to allow applications to compose types that fit their unique use case. We begin by identifying common properties, and create trait interfaces that describe those properties: public final class javafx.scene.Trait { public interface Visible { BooleanProperty visibleProperty() default boolean isVisible()... default void setVisible(boolean value)... } public interface Disable { BooleanProperty disableProperty() default boolean isDisable()... default void setDisable(boolean value)... } public interface Properties { ObservableMap getProperties() default boolean hasProperties()... } ... } These interfaces can now be implemented by all relevant JavaFX classes. This includes `Node`, `MenuItem`, and `Tab`, but applications are free to implement these trait interfaces themselves. Applications can now consume objects that implement any combination of traits, which gives applications the much-needed flexibility to use shared code for all kinds of JavaFX objects: void doSomething(T node) { node.getProperties().put("foo", "bar"); node.setVisible(true); } void doAnotherThing(T node) { node.setText("hello"); node.setGraphic(myGraphic); } What do you think? From tsayao at openjdk.org Sun Sep 3 15:36:47 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 15:36:47 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: <1556Jy6lZMKlwsTbPAQWZzXmo3IUYovqqW3XRgFdTt0=.f1c5ffaf-df2e-4e8c-9fd6-b9e82fe6e586@github.com> On Sun, 9 Jul 2023 17:43:05 GMT, Thiago Milczarek Sayao wrote: > The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. > > Te fix replaces the usage of the function for already known extents value calculation. Can someone sponsor this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1173#issuecomment-1704335769 From tsayao at openjdk.org Sun Sep 3 18:12:51 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 18:12:51 GMT Subject: RFR: 8308644: [Linux] Missing mappings for dead keys + Alt Gr [v5] In-Reply-To: References: Message-ID: <1XqBNSHdLpBfeQlFDM0GOsV260QAAfg1StZSPqGao0s=.0a79f33e-6ff8-45a9-96e6-7ccf820e71f6@github.com> On Thu, 22 Jun 2023 11:45:30 GMT, Thiago Milczarek Sayao wrote: >> This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some systems. > > Thiago Milczarek Sayao 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 16 additional commits since the last revision: > > - Minimize changes > - Merge branch 'master' into gdk_to_glass_key_map > - Forgot test code > - Back to hash > - Revert key lock change because it has different behaviour > - Revert modifier change + Remove F13 -> F24 > - Remove print statement > - Use GDK instead of X calls (to ease in a future wayland implementation) > - Avoid sending unknown key event > - GDK_META_MASK is not ALT > - ... and 6 more: https://git.openjdk.org/jfx/compare/d342c77f...aad021a6 It's a simple addition, with no hurries, just commenting to keep it on the list. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1143#issuecomment-1704366359 From jpereda at openjdk.org Sun Sep 3 18:52:11 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 3 Sep 2023 18:52:11 GMT Subject: [jfx17u] RFR: 8307960: Create Table Column PopupMenu lazily Message-ID: <2rtLVmzdD2Hw6MDCBpuvt3eFPobkKLtwYPcuJfClHUc=.38a2ba8f-7494-4790-8f41-c791e483cb32@github.com> Almost clean backport of 8307960: Create Table Column PopupMenu lazily Reviewed-by: angorya There was a conflict from JDK-8297414: Remove easy warnings in javafx.controls, that was easily fixed. ------------- Commit messages: - 8307960: Create Table Column PopupMenu lazily Changes: https://git.openjdk.org/jfx17u/pull/147/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307960 Stats: 449 lines in 4 files changed: 440 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/147.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/147/head:pull/147 PR: https://git.openjdk.org/jfx17u/pull/147 From jvos at openjdk.org Sun Sep 3 19:10:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 3 Sep 2023 19:10:45 GMT Subject: [jfx17u] RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: <2rtLVmzdD2Hw6MDCBpuvt3eFPobkKLtwYPcuJfClHUc=.38a2ba8f-7494-4790-8f41-c791e483cb32@github.com> References: <2rtLVmzdD2Hw6MDCBpuvt3eFPobkKLtwYPcuJfClHUc=.38a2ba8f-7494-4790-8f41-c791e483cb32@github.com> Message-ID: On Sun, 3 Sep 2023 18:46:48 GMT, Jose Pereda wrote: > Almost clean backport of 8307960: Create Table Column PopupMenu lazily > Reviewed-by: angorya > > There was a conflict from JDK-8297414: Remove easy warnings in javafx.controls, that was easily fixed. There was only a very minor change compared to the original commit, looks good. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx17u/pull/147#pullrequestreview-1608566936 From jpereda at openjdk.org Sun Sep 3 19:53:46 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 3 Sep 2023 19:53:46 GMT Subject: [jfx17u] Integrated: 8307960: Create Table Column PopupMenu lazily In-Reply-To: <2rtLVmzdD2Hw6MDCBpuvt3eFPobkKLtwYPcuJfClHUc=.38a2ba8f-7494-4790-8f41-c791e483cb32@github.com> References: <2rtLVmzdD2Hw6MDCBpuvt3eFPobkKLtwYPcuJfClHUc=.38a2ba8f-7494-4790-8f41-c791e483cb32@github.com> Message-ID: <8dZ0cxsYbqEZUREpG0fkZycQyNb4N2CCLddzLY466HI=.dc20357e-a02c-4c3b-8737-5e3f894713e5@github.com> On Sun, 3 Sep 2023 18:46:48 GMT, Jose Pereda wrote: > Almost clean backport of 8307960: Create Table Column PopupMenu lazily > Reviewed-by: angorya > > There was a conflict from JDK-8297414: Remove easy warnings in javafx.controls, that was easily fixed. This pull request has now been integrated. Changeset: 56761977 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/56761977df240900c6fabcd25fab4edb7adba4c1 Stats: 449 lines in 4 files changed: 440 ins; 6 del; 3 mod 8307960: Create Table Column PopupMenu lazily Reviewed-by: jvos Backport-of: 8aff5252339a7a45bd03b2656387c2651c0f70f7 ------------- PR: https://git.openjdk.org/jfx17u/pull/147 From tsayao at openjdk.org Sun Sep 3 22:08:13 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor Message-ID: This replaces obsolete XIM and uses gtk api for IME. Gtk uses [ibus](https://github.com/ibus/ibus) Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. ------------- Commit messages: - Don't highlight for dead keys - Don't move the caret on preedit - Add function to return relative location of the caret (it's how it's handled on Linux). - Merge branch 'master' into new_ime - Merge branch 'master' into new_ime - Weird API - JavaFX does not currently supports surrouding - Remove dup event - Progress - Fix key typing - ... and 61 more: https://git.openjdk.org/jfx/compare/84aad81a...5d6bd04d Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305418 Stats: 525 lines in 16 files changed: 135 ins; 277 del; 113 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From duke at openjdk.org Sun Sep 3 22:08:13 2023 From: duke at openjdk.org (Glavo) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. I am a native speaker of Chinese. I tested it using the ibus pinyin input method on Ubuntu. I found some problems: * Input method candidate window sometimes appear in the wrong location: ![image](https://user-images.githubusercontent.com/20694662/229506031-ee5d6061-8405-4e81-8602-efb51d6d14ee.png) * When the focus moves away from a text field, the console will continuously output an assertion error log: (java:3296): Gtk-CRITICAL **: 20:18:35.210: gtk_im_context_set_cursor_location: assertion 'GTK_IS_IM_CONTEXT (context)' failed It appears to be in the correct position, but another issue still exists. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1494222748 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1497697683 From tsayao at openjdk.org Sun Sep 3 22:08:13 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 12:20:10 GMT, Glavo wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > I am a native speaker of Chinese. I tested it using the ibus pinyin input method on Ubuntu. I found some problems: > > * Input method candidate window sometimes appear in the wrong location: > > ![image](https://user-images.githubusercontent.com/20694662/229506031-ee5d6061-8405-4e81-8602-efb51d6d14ee.png) > > * When the focus moves away from a text field, the console will continuously output an assertion error log: > > > (java:3296): Gtk-CRITICAL **: 20:18:35.210: gtk_im_context_set_cursor_location: assertion 'GTK_IS_IM_CONTEXT (context)' failed @Glavo the selection window should appear in the right location now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1496735428 From tsayao at openjdk.org Sun Sep 3 22:08:13 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. Thank you for the feedback. Will look into it. I'm sure I am missing details of other languages. @kevinrushforth Is there anyone at Oracle that could provide guidance on language variations so I can make this right? Yeah, I know many things are probably no working. The plan is to get feedback and keep fixing until it's all good. I only speak/read latin-based languages so I have never needed IME. The process is now reporting KEY_PRESS events even if filtered by IME. @beldenfox You seem to have a lot of expertise on the topic. Should dead keys be reported as KEY_PRESS with the corresponding character? I asked around on Gtk IRC and `gdk_keyval_to_unicode` won't work for dead keys. We need a custom map including dead keys as seen on [gdkkeyuni.c](https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/gdkkeyuni.c) Dead keys should work now, but not sure I covered them all. Yesterday I was reading some of the Mac code for handling IME to understand it better. I started to get the idea. @beldenfox Your test app is very handy. This is the current state: [Screencast from 03-09-2023 15:47:01.webm](https://github.com/openjdk/jfx/assets/30704286/db30803a-0c8b-450d-95a1-81bf80a4b2ff) I did put a lot of work on it. Now I need feedback from users if everything is working as expected. I'm unsure if I missed a detail from a specific language/culture. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1494229776 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1496737066 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1498124303 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1546904623 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1546999336 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1547013377 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1549412139 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1704374033 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1704417064 From duke at openjdk.org Sun Sep 3 22:08:13 2023 From: duke at openjdk.org (Martin Fox) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. I see that this PR changes the behavior of dead keys. You may be aware of this but I thought I would write this up for others to review. In the past when the user pressed a dead key they got no feedback until they pressed the next key at which point the final character would appear. With this PR when the user presses a dead key they get a preview of the diacritic which looks the same as previewing text from an IME. This is a change from the old JavaFX behavior but not necessarily a bug. In fact it matches the new behavior of Ubuntu. I'm not sure when they made the switch but in Ubuntu 18 there was no diacritic preview and in Ubuntu 22 there is. It also matches the way the Mac works. At the API level this changes the event stream. In the past the dead key only generated an incorrectly encoded RELEASED KeyEvent. The fully composed character was then delivered as the commit string in an InputMethodEvent. With this PR the (sort of bogus) RELEASED KeyEvent goes away and is replaced by an InputMethodEvent that delivers the preview diacritic in the compose string. One minor detail: after entering a dead key the cursor moves to a point before the preview diacritic instead of after it. That looks like a bug and doesn't match the way other parts of Ubuntu behave. modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 58: > 56: > 57: // This function exists because gdk_keyval_to_unicode won't translate dead keys > 58: guint32 glass_gdk_keyval_to_unicode(guint keyval) { I don't think this routine is needed. You only need Unicode text for a TYPED KeyEvent and dead keys don't generate those. `notifyKey` will just ignore any text you pass in for PRESSED or RELEASED events. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1522286678 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1193908201 From tsayao at openjdk.org Sun Sep 3 22:08:13 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 22:08:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 19:13:14 GMT, Martin Fox wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > I see that this PR changes the behavior of dead keys. You may be aware of this but I thought I would write this up for others to review. > > In the past when the user pressed a dead key they got no feedback until they pressed the next key at which point the final character would appear. With this PR when the user presses a dead key they get a preview of the diacritic which looks the same as previewing text from an IME. > > This is a change from the old JavaFX behavior but not necessarily a bug. In fact it matches the new behavior of Ubuntu. I'm not sure when they made the switch but in Ubuntu 18 there was no diacritic preview and in Ubuntu 22 there is. It also matches the way the Mac works. > > At the API level this changes the event stream. In the past the dead key only generated an incorrectly encoded RELEASED KeyEvent. The fully composed character was then delivered as the commit string in an InputMethodEvent. With this PR the (sort of bogus) RELEASED KeyEvent goes away and is replaced by an InputMethodEvent that delivers the preview diacritic in the compose string. > > One minor detail: after entering a dead key the cursor moves to a point before the preview diacritic instead of after it. That looks like a bug and doesn't match the way other parts of Ubuntu behave. @beldenfox Thanks for taking your time to look at this. I have fixed the preview diacritic caret position. @beldenfox I'm getting the bogus KEY_RELEASED event you mentioned. It's weird because tbe dead key produces a KEY_RELEASED but not a KEY_PRESS. Edit: bool WindowContextBase::im_filter_keypress(GdkEventKey *event) { return gtk_im_context_filter_keypress(im_ctx.ctx, event); } This is why. I will check, but I think dead keys should either produce both KEY_PRESS and KEY_RELEASED or none. I have attached a simple test app on [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418) On Windows (using the test app mentioned) I get when typing ?: Pressed: ? Pressed: e Released: e I think it should have a Released event with ?, shouldn't it? Also Windows does not deliver the `InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` event. > modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 58: > >> 56: >> 57: // This function exists because gdk_keyval_to_unicode won't translate dead keys >> 58: guint32 glass_gdk_keyval_to_unicode(guint keyval) { > > I don't think this routine is needed. You only need Unicode text for a TYPED KeyEvent and dead keys don't generate those. `notifyKey` will just ignore any text you pass in for PRESSED or RELEASED events. I was doing some experimentation. But your're right, removed it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1537228963 PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1537240046 PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1194958983 From duke at openjdk.org Sun Sep 3 22:08:14 2023 From: duke at openjdk.org (Martin Fox) Date: Sun, 3 Sep 2023 22:08:14 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sat, 6 May 2023 23:11:21 GMT, Thiago Milczarek Sayao wrote: >> I see that this PR changes the behavior of dead keys. You may be aware of this but I thought I would write this up for others to review. >> >> In the past when the user pressed a dead key they got no feedback until they pressed the next key at which point the final character would appear. With this PR when the user presses a dead key they get a preview of the diacritic which looks the same as previewing text from an IME. >> >> This is a change from the old JavaFX behavior but not necessarily a bug. In fact it matches the new behavior of Ubuntu. I'm not sure when they made the switch but in Ubuntu 18 there was no diacritic preview and in Ubuntu 22 there is. It also matches the way the Mac works. >> >> At the API level this changes the event stream. In the past the dead key only generated an incorrectly encoded RELEASED KeyEvent. The fully composed character was then delivered as the commit string in an InputMethodEvent. With this PR the (sort of bogus) RELEASED KeyEvent goes away and is replaced by an InputMethodEvent that delivers the preview diacritic in the compose string. >> >> One minor detail: after entering a dead key the cursor moves to a point before the preview diacritic instead of after it. That looks like a bug and doesn't match the way other parts of Ubuntu behave. > > @beldenfox I'm getting the bogus KEY_RELEASED event you mentioned. It's weird because tbe dead key produces a KEY_RELEASED but not a KEY_PRESS. > > Edit: > > bool WindowContextBase::im_filter_keypress(GdkEventKey *event) { > return gtk_im_context_filter_keypress(im_ctx.ctx, event); > } > > > > This is why. I will check, but I think dead keys should either produce both KEY_PRESS and KEY_RELEASED or none. > > I have attached a simple test app on [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418) > > On Windows (using the test app mentioned) I get when typing ?: > > Pressed: ? > Pressed: e > Released: e > > > > I think it should have a Released event with ?, shouldn't it? > > Also Windows does not deliver the `InputMethodEvent.INPUT_METHOD_TEXT_CHANGED` event. @tsayao The bogus RELEASED event happens on every platform after an InputMethodEvent that commits. I suppose the key press event is swallowed by the IM context which then commits the text and exits the compose state. Then the release event arrives and is processed as a standard KeyEvent. On Windows dead keys are handled entirely using KeyEvents, no InputMethodEvents involved. The final character is delivered as the text in a TYPED KeyEvent. Your new code is handling dead keys just fine, the event sequence matches the way the Mac works and is compatible with the way the previous Linux code worked. But with this PR I'm not seeing any KeyEvents as I type regular text. If you're typing, say, Spanish most characters (other than dead keys) should generate PRESSED and TYPED KeyEvents. Your code delivers every character in an InputMethodEvent commit event. This needs to be fixed, the system relies on PRESSED events to trigger accelerators. I did a little Googling and I think this is just the way the Gtk IM works; all text is delivered in a commit signal. I think you need to track whether the IM is in pre-edit mode or not to distinguish which commits should turn into KeyEvents and which should remain as InputMethodEvents. There are signals for tracking pre-edit mode but I haven't tested them out. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1537593602 From duke at openjdk.org Sun Sep 3 22:08:14 2023 From: duke at openjdk.org (Martin Fox) Date: Sun, 3 Sep 2023 22:08:14 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 14 May 2023 22:17:30 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > Dead keys should work now, but not sure I covered them all. @tsayao You should expand your test app to show TYPED KeyEvents or use the KeyEventViewer app I just attached to the original bug report. Then run it against an unmodified JFX build on Linux and see what events go by. If you have a Mac that's even better, the sequence of events between Mac and Linux should be very similar. As I said in my earlier note you already had dead keys working just fine. Just treat them like any other IM event. And they don't generate PRESSED KeyEvents on Linux, that only happens on Windows. It's the non-dead letter keys that are the problem. If you fire up one of the test apps and immediately press the X key you should see this sequence of events on all platforms: 1. PRESSED KeyEvent with KeyCode.X 2. TYPED KeyEvent with the text "x". 3. RELEASED KeyEvent with KeyCode.X Your code is generating this sequence: 1. InputMethodEvent with commit text "x" 2. PRESSED KeyEvent with KeyCode.X 3. RELEASED KeyEvent with KeyCode.X Each of these characters is coming in as a `commit` signal without a `preedit-changed` signal before it. These commits shouldn't be sent to `jViewNotifyInputMethod`. You need to detect this case and a) ignore the commit and b) return `false` from `filterIME` so the event is handled by `process_key` instead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1547040959 From duke at openjdk.org Sun Sep 3 22:08:14 2023 From: duke at openjdk.org (leewyatt) Date: Sun, 3 Sep 2023 22:08:14 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. Thank you, this PR is extremely, extremely useful. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1652041588 From tsayao at openjdk.org Sun Sep 3 22:08:14 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 3 Sep 2023 22:08:14 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Mon, 15 May 2023 00:15:05 GMT, Martin Fox wrote: >> Dead keys should work now, but not sure I covered them all. > > @tsayao You should expand your test app to show TYPED KeyEvents or use the KeyEventViewer app I just attached to the original bug report. Then run it against an unmodified JFX build on Linux and see what events go by. If you have a Mac that's even better, the sequence of events between Mac and Linux should be very similar. > > As I said in my earlier note you already had dead keys working just fine. Just treat them like any other IM event. And they don't generate PRESSED KeyEvents on Linux, that only happens on Windows. > > It's the non-dead letter keys that are the problem. If you fire up one of the test apps and immediately press the X key you should see this sequence of events on all platforms: > > 1. PRESSED KeyEvent with KeyCode.X > 2. TYPED KeyEvent with the text "x". > 3. RELEASED KeyEvent with KeyCode.X > > Your code is generating this sequence: > > 1. InputMethodEvent with commit text "x" > 2. PRESSED KeyEvent with KeyCode.X > 3. RELEASED KeyEvent with KeyCode.X > > Each of these characters is coming in as a `commit` signal without a `preedit-changed` signal before it. These commits shouldn't be sent to `jViewNotifyInputMethod`. You need to detect this case and a) ignore the commit and b) return `false` from `filterIME` so the event is handled by `process_key` instead. @beldenfox I've made some progress. I've copied the Mac method from `MacView.java` for now, still need to figure it out how to deal with `IME_ATTR_*` and probably the selection/surrounding functionality. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1556308604 From kpk at openjdk.org Mon Sep 4 04:45:49 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Sep 2023 04:45:49 GMT Subject: Integrated: 8283675: Line not removed from LineChart when series cleared In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 07:25:28 GMT, Karthik P K wrote: > The issue is present in AreaChart along with the LineChart. Issue is fixed in both the charts as part of this PR. > The line elements in case of Line chart and both line element and fill element in the case of Area charts were not cleared in `makePaths()` method in AreaChart.java. Hence the line and fill area were not getting cleared when series was cleared. > > Made changes in code to clear line element and fill element as required in the `makePaths()` method. > > Added tests to validate the changes in both LineChart and AreaChart. This pull request has now been integrated. Changeset: e8491ba4 Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/e8491ba47c2926547ee484e7fda767132aff2edd Stats: 46 lines in 3 files changed: 39 ins; 6 del; 1 mod 8283675: Line not removed from LineChart when series cleared Reviewed-by: angorya, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1214 From psadhukhan at openjdk.org Mon Sep 4 06:34:18 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 4 Sep 2023 06:34:18 GMT Subject: RFR: 8315317: Add test for JDK-8262518 [v2] In-Reply-To: References: Message-ID: <-2dACKZsXPuT8vm2Zcu5_qkjXsYzv88ZugV0wgCPBTs=.f394ffe7-aea7-4036-a465-2d786b96940d@github.com> > Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Better failure detection ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1228/files - new: https://git.openjdk.org/jfx/pull/1228/files/ac0205a0..bf7623a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1228&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1228&range=00-01 Stats: 14 lines in 1 file changed: 3 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1228.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1228/head:pull/1228 PR: https://git.openjdk.org/jfx/pull/1228 From psadhukhan at openjdk.org Mon Sep 4 06:35:45 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 4 Sep 2023 06:35:45 GMT Subject: RFR: 8315317: Add test for JDK-8262518 [v2] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:38:16 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 116: >> >>> 114: System.out.println("iteration " + count + " Panels in memory: " >>> 115: + panelCount + " fail " + fail); >>> 116: assertFalse(fail > 2); >> >> I actually seen the number to shoot up to 38 (albeit with Thread.sleep(1)). I wonder if there is a better way to detect failure? May be the fact that the 'panelCount` is ever increasing is the sign of failure, whereas if at least one time it's dropping we have succeeded. >> Or perhaps look at the count when the test complete and fail if panelCount < (attempts / 2) or something > > I recommend using `JMemoryBuddy`, which is what we use for all of our newer memory leak tests. I am not sure I understand the nuances of JMemoryBuddy. I tried using `JMemoryBuddy.assertCollectable` but it fails with Exception in thread "Thread-7" java.lang.AssertionError: Content of WeakReference was not collected. content: javax.swing.JPanel[,0,0,0x0,layout=java.awt.FlowLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=] at test.util.memory.JMemoryBuddy.assertCollectable(JMemoryBuddy.java:91) maybe because the test doesn't cause SwingNode content count to 0. But I have modified the test to have better way of detecting failure as suggested and check for total count at end which normally increases without fix..I hope that should be good enough to ensure it fails without the fix and pass with it.. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1314491398 From jvos at openjdk.org Mon Sep 4 08:48:51 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Sep 2023 08:48:51 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 17:43:05 GMT, Thiago Milczarek Sayao wrote: > The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. > > Te fix replaces the usage of the function for already known extents value calculation. I am very careful when generic glass code is changed, but with the explanation added, I don't see a potential case for regression, so +1 from me. We should encourage developers to use 22-ea builds to make sure there is indeed no regression. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1173#pullrequestreview-1609059785 From jpereda at openjdk.org Mon Sep 4 09:17:17 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 4 Sep 2023 09:17:17 GMT Subject: [jfx17u] RFR: 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy Message-ID: Almost clean backport of 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy Reviewed-by: kcr, aghaisas It had some minor conflicts from JDK-8089280 (TableViewSkinBase: copyright year, and TableViewTest, TreeTableViewTest: wrong insertion point of new test), that were easily solved. ------------- Commit messages: - 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy Changes: https://git.openjdk.org/jfx17u/pull/148/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8089280 Stats: 182 lines in 7 files changed: 122 ins; 44 del; 16 mod Patch: https://git.openjdk.org/jfx17u/pull/148.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/148/head:pull/148 PR: https://git.openjdk.org/jfx17u/pull/148 From jvos at openjdk.org Mon Sep 4 09:43:17 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Sep 2023 09:43:17 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 543: > 541: int b = other.bits != null ? other.bits.length : 0; > 542: > 543: if (a != b) return false; I understand the following loop will return false in case a != b as well, but for performance reasons, wouldn't it be best to keep this test (as it immediately fails in case a != b)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1314695648 From jvos at openjdk.org Mon Sep 4 09:48:18 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Sep 2023 09:48:18 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 549: > 547: > 548: for (int i = 0; i < max; i++) { > 549: long m0 = i >= a ? 0 : this.bits[i]; Are we guaranteed that it is an invariant of this Class that there will never be an entry in `bits` that is `0`? From the code, it looks like that is the case (at least when inspecting add and remove), but it's not enforced I believe (e.g. subclasses may violate this rule). This remark is irrelevant if we consider 2 BitSets to be equal if their length is not equal, but the entries that are only in 1 of the sets are always 0. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1314701415 From aghaisas at openjdk.org Mon Sep 4 09:50:46 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 4 Sep 2023 09:50:46 GMT Subject: [jfx-tests] RFR: JDK-8315409: Fix jfx-tests so they work with latest jfx build [v2] In-Reply-To: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> References: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> Message-ID: On Sat, 2 Sep 2023 00:31:26 GMT, Alexandre Iline wrote: >> JDK-8315409: Fix jfx-tests so they work with latest jfx build > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Addressing copyright issues. I verified that the following tests can be run now with the latest jfx build. Tests that run with the latest jfx build (some test failures are observed fixing which is out of scope of this PR) : - 3DTests - ControlsTests - FxmlTests - SceneGraphTests Tests that do not compile yet (I believe, this is future work) : - WebNodeManualTests - ControlsLeakTests - FXCssTests - WebNodeAutomated - appBundlerTestsJDK9 ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/1#issuecomment-1704957371 From kpk at openjdk.org Mon Sep 4 10:52:07 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Sep 2023 10:52:07 GMT Subject: RFR: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests Message-ID: Made changes to use Util::waitForIdle instead of Toolkit::firePulse in system tests. The test will wait for default value of 10 pulses to complete in the scene before executing the subsequent statements. ------------- Commit messages: - Use Util::waitForIdle instead of Toolkit::firePulse Changes: https://git.openjdk.org/jfx/pull/1230/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308608 Stats: 7 lines in 2 files changed: 2 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1230.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1230/head:pull/1230 PR: https://git.openjdk.org/jfx/pull/1230 From kpk at openjdk.org Mon Sep 4 13:22:13 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Sep 2023 13:22:13 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared Message-ID: Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. ------------- Commit messages: - Add test to check if line and area removed on clearing series Changes: https://git.openjdk.org/jfx/pull/1231/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1231&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314779 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1231.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1231/head:pull/1231 PR: https://git.openjdk.org/jfx/pull/1231 From jvos at openjdk.org Mon Sep 4 19:24:12 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Sep 2023 19:24:12 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: <34oTC7j7ml8nlX8kNLrX1ldCNalO_tt-RdsXYzADdAM=.da3c9e4a-01b8-495c-862b-e84d9316854c@github.com> Message-ID: On Wed, 16 Aug 2023 14:16:23 GMT, John Hendrikx wrote: >> Thanks for that test, actually it could be used as part of a test in PseudoClassTest, to verify that the old implementation failed and the new one worked? >> >> And this brings up another issue: the constructor `PseudoClassState(List)` is not used anywhere, is it? Should it be removed then (unless it is added to such test)? > > Alright, I'll add the test. > > As for the other issue: there are quite a few other issues **near** the code I've changed, but in order for a PR to remain focused, and not burdened with changes that don't contribute to the intended change (making it smaller and easier to review), it's best to address these in another PR that focuses specifically on such problems (unused constructors, unused fields, unused methods, etc). > > In this specific case, the constructor was not changed or added by me, it's part of private API and it's not causing problems. Changing it would distract from the goal of the PR, and so is IMHO out of scope. I agree this is out of scope. Once this PR is merged, there are many things that can be done to cleanup the code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1315170858 From mstrauss at openjdk.org Tue Sep 5 00:55:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 00:55:44 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Removed application preferences implementation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/f8a9c8af..40e2f286 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=03-04 Stats: 455 lines in 8 files changed: 10 ins; 440 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Tue Sep 5 01:10:04 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 01:10:04 GMT Subject: RFR: 8301302: Platform preferences API [v4] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <1wpQh3sviOLynWRd_lEAZ27iManns5ojKnDagHWua4A=.d2660433-6ad2-48fa-9999-ec63f08e514a@github.com> Message-ID: <2C8nDzGDyN_oke69A80JP33xd85Xq53q-u5ngkvHphE=.eb64b7d7-38fa-4d35-ba5d-3f2e73f9b972@github.com> On Thu, 24 Aug 2023 21:32:18 GMT, Andy Goryachev wrote: > It looks like the discussion in the mailing list resolved some of the questions the group posed, perhaps we could move forward. > > Would it be possible to extract read-only platform preferences into a separate PR in order to integrate that part first? Sure! I've removed the Application Preferences API. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1705811405 From duke at openjdk.org Tue Sep 5 01:28:49 2023 From: duke at openjdk.org (duke) Date: Tue, 5 Sep 2023 01:28:49 GMT Subject: Withdrawn: 8311216: DataURI can lose information in some charset environments In-Reply-To: References: Message-ID: <6pDEItr1Y1tXTrlFNL39HSqiYXlhe3JkbvpGTFdXQOY=.10051c02-7f7d-4cdb-ad24-51a7975eea50@github.com> On Sat, 1 Jul 2023 22:24:09 GMT, Michael Strau? wrote: > DataURI uses the following implementation to decode the percent-encoded payload of a "data" URI: > > > ... > String data = uri.substring(dataSeparator + 1); > Charset charset = Charset.defaultCharset(); > ... > URLDecoder.decode(data.replace("+", "%2B"), charset).getBytes(charset) > > > This approach only works if the charset that is passed into `URLDecoder.decode` and `String.getBytes` doesn't lose information when converting between `String` and `byte[]` representations, as might happen in a US-ASCII environment. > > This PR solves the problem by not using `URLDecoder`, but instead simply decoding percent-encoded escape sequences as specified by RFC 3986, page 11. > > **Note to reviewers**: the failing test can only be observed when the JVM uses a default charset that can't represent the payload, which can be enforced by specifying the `-Dfile.encoding=US-ASCII` VM option. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1165 From jvos at openjdk.org Tue Sep 5 07:20:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 07:20:45 GMT Subject: RFR: 8313321 : Set minimum python version in WebKit cmake scripts [v2] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 16:17:29 GMT, Hima Bindu Meda wrote: >> Minimum version of python ,to run webkit build , on linux is set to 3.6 and for other platforms, minimum version of python is set to 3.8. >> >> Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > change minimum version for mac to 3.6 I think that should be ok for now, and I don't want to make the PR more complex as this is a good step, but I believe we need more strict checks: * also check the maximum version for python * check versions of perl,ruby Unfortunately, building webkit is extremely brittle and requiring exact versions is decreasing the chances on failures at build or runtime. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1205#issuecomment-1706072588 From jvos at openjdk.org Tue Sep 5 08:10:50 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 08:10:50 GMT Subject: [jfx17u] RFR: 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 09:10:18 GMT, Jose Pereda wrote: > Almost clean backport of 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy > > Reviewed-by: kcr, aghaisas > > It had some minor conflicts from JDK-8089280 (TableViewSkinBase: copyright year, and TableViewTest, TreeTableViewTest: wrong insertion point of new test), that were easily solved. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/148#pullrequestreview-1610473012 From jpereda at openjdk.org Tue Sep 5 08:25:52 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 08:25:52 GMT Subject: [jfx17u] Integrated: 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy In-Reply-To: References: Message-ID: <14x-Z4w08AVPmxCnra-TnDKzblfPAzuSGN9JZBqDfRQ=.ead970e5-0373-425c-befa-02c2fd8f1ffb@github.com> On Mon, 4 Sep 2023 09:10:18 GMT, Jose Pereda wrote: > Almost clean backport of 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy > > Reviewed-by: kcr, aghaisas > > It had some minor conflicts from JDK-8089280 (TableViewSkinBase: copyright year, and TableViewTest, TreeTableViewTest: wrong insertion point of new test), that were easily solved. This pull request has now been integrated. Changeset: f652155d Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/f652155df9eb9a87dfeefce55410805e1fe411c3 Stats: 182 lines in 7 files changed: 122 ins; 44 del; 16 mod 8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy Reviewed-by: jvos Backport-of: 5e4552db7389d93829e6ecfc61936ccad75c56c2 ------------- PR: https://git.openjdk.org/jfx17u/pull/148 From jpereda at openjdk.org Tue Sep 5 09:28:08 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 09:28:08 GMT Subject: [jfx17u] RFR: 8298728: Cells in VirtualFlow jump after resizing Message-ID: Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing Reviewed-by: aghaisas, angorya There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: - setSkin(new SkinStub(this)); + setSkin(new SkinStub<>(this)); ------------- Commit messages: - 8298728: Cells in VirtualFlow jump after resizing Changes: https://git.openjdk.org/jfx17u/pull/149/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298728 Stats: 130 lines in 4 files changed: 111 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jfx17u/pull/149.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/149/head:pull/149 PR: https://git.openjdk.org/jfx17u/pull/149 From jvos at openjdk.org Tue Sep 5 09:40:49 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 09:40:49 GMT Subject: [jfx17u] RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 09:22:58 GMT, Jose Pereda wrote: > Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing > Reviewed-by: aghaisas, angorya > > There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: > > - setSkin(new SkinStub(this)); > + setSkin(new SkinStub<>(this)); Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/149#pullrequestreview-1610650476 From aghaisas at openjdk.org Tue Sep 5 09:58:44 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 5 Sep 2023 09:58:44 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 13:15:47 GMT, Karthik P K wrote: > Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. > This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. New test addition looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1231#pullrequestreview-1610682711 From jhendrikx at openjdk.org Tue Sep 5 13:14:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 5 Sep 2023 13:14:49 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 13:09:46 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 549: >> >>> 547: >>> 548: for (int i = 0; i < max; i++) { >>> 549: long m0 = i >= a ? 0 : this.bits[i]; >> >> Are we guaranteed that it is an invariant of this Class that there will never be an entry in `bits` that is `0`? From the code, it looks like that is the case (at least when inspecting add and remove), but it's not enforced I believe (e.g. subclasses may violate this rule). >> This remark is irrelevant if we consider 2 BitSets to be equal if their length is not equal, but the entries that are only in 1 of the sets are always 0. > >> Are we guaranteed that it is an invariant of this Class that there will never be an entry in bits that is 0? > > Unfortunately not, the `remove` code does not shrink the array (it only shrinks when all bits were cleared, not when only the bits were cleared in higher `long` locations). Note that this is rare anyway, these sets were rarely mutated (if ever), which is also the reason why this caching change was easy to do. This is also why it never broke in practice. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1315876660 From jhendrikx at openjdk.org Tue Sep 5 13:14:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 5 Sep 2023 13:14:48 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 09:40:14 GMT, Johan Vos wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 543: > >> 541: int b = other.bits != null ? other.bits.length : 0; >> 542: >> 543: if (a != b) return false; > > I understand the following loop will return false in case a != b as well, but for performance reasons, wouldn't it be best to keep this test (as it immediately fails in case a != b)? The problem is that `BitSet` isn't diligent enough about how it manages its arrays. If all bits get cleared in the highest `long`, it would need to shrink the array (potentially by more than one `long` if the next highest `long` is also `0`), but of course it doesn't. The only thing it does is to reset to an empty array when **all** bits were cleared. So `a != b` does not guarantee they're not equal. If `a` has length 1 and `b` has length 2 but its `bits[1]` is `0`, they're still equal (assuming `bits[0]` is equal for both). The whole class is poorly engineered unfortunately -- note that almost all comments about this change are pointing out problems in `BitSet`, not about the actual caching. I think it would best to remove `BitSet`. The need for it is minimal once the caching goes in; saving space when you have a million copies of these is useful, but no longer relevant when they're now a million references to the same (immutable) copy. > Are we guaranteed that it is an invariant of this Class that there will never be an entry in bits that is 0? Unfortunately not, the `remove` code does not shrink the array (it only shrinks when all bits were cleared, not when only the bits were cleared in higher `long` locations). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1315873108 PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1315875492 From jgneff at openjdk.org Tue Sep 5 15:50:50 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 5 Sep 2023 15:50:50 GMT Subject: RFR: 8313321 : Set minimum python version in WebKit cmake scripts [v2] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 16:17:29 GMT, Hima Bindu Meda wrote: >> Minimum version of python ,to run webkit build , on linux is set to 3.6 and for other platforms, minimum version of python is set to 3.8. >> >> Verified build on all platforms. No issue seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > change minimum version for mac to 3.6 Just a note that I was unable to build WebKit on Windows using the latest Python version 3.9 that comes with and up-to-date Cygwin installation due to the following issue: * [Windows-style path is not recognized under cygwin](https://github.com/python/cpython/issues/90907) I also couldn't find an easy way to "pin" the version number to keep Cygwin from upgrading it, so I had to revert the version manually each time I ran the Cygwin update tool. See my message on the mailing list for details: * [Cygwin Python 3.9 breaks Windows WebKit build](https://mail.openjdk.org/pipermail/openjfx-dev/2023-January/037822.html) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1205#issuecomment-1706877360 From jpereda at openjdk.org Tue Sep 5 17:10:17 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 17:10:17 GMT Subject: [jfx17u] RFR: 8251481: TableCell accessing row: NPE on auto-sizing Message-ID: Clean backport of 8251481: TableCell accessing row: NPE on auto-sizing Reviewed-by: fastegal ------------- Commit messages: - 8251481: TableCell accessing row: NPE on auto-sizing Changes: https://git.openjdk.org/jfx17u/pull/150/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251481 Stats: 50 lines in 3 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/150.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/150/head:pull/150 PR: https://git.openjdk.org/jfx17u/pull/150 From jvos at openjdk.org Tue Sep 5 18:02:03 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 18:02:03 GMT Subject: [jfx17u] RFR: 8251481: TableCell accessing row: NPE on auto-sizing Message-ID: 8251481: TableCell accessing row: NPE on auto-sizing Reviewed-by: fastegal ------------- Commit messages: - 8251481: TableCell accessing row: NPE on auto-sizing Changes: https://git.openjdk.org/jfx17u/pull/151/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251481 Stats: 50 lines in 3 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/151.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/151/head:pull/151 PR: https://git.openjdk.org/jfx17u/pull/151 From jpereda at openjdk.org Tue Sep 5 18:12:51 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 18:12:51 GMT Subject: [jfx17u] RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: <4mtfQp9qM4wm4NqQ-Ia8j23XiVpEKgSma1GnU4YjwlU=.be5e63a8-9e6a-4d4d-b0bf-13d480650141@github.com> On Tue, 5 Sep 2023 09:22:58 GMT, Jose Pereda wrote: > Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing > Reviewed-by: aghaisas, angorya > > There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: > > - setSkin(new SkinStub(this)); > + setSkin(new SkinStub<>(this)); Tests are failing ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/149#issuecomment-1707079001 From jpereda at openjdk.org Tue Sep 5 18:12:51 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 18:12:51 GMT Subject: [jfx17u] Withdrawn: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: <6Inl65GbZiQDsEqYvRe3Q0UwgWCFqGc_EQdGPXKF2ik=.0335f2bb-d9f6-4d68-ba53-117867ba0e7c@github.com> On Tue, 5 Sep 2023 09:22:58 GMT, Jose Pereda wrote: > Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing > Reviewed-by: aghaisas, angorya > > There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: > > - setSkin(new SkinStub(this)); > + setSkin(new SkinStub<>(this)); This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx17u/pull/149 From angorya at openjdk.org Tue Sep 5 18:49:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 18:49:20 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 13:07:55 GMT, John Hendrikx wrote: > I think it would best to remove `BitSet` does it mean there'll be a followup PR? or should it be done as a part of this one? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1316269856 From angorya at openjdk.org Tue Sep 5 18:50:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 18:50:48 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 13:15:47 GMT, Karthik P K wrote: > Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. > This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. modules/javafx.controls/src/test/java/test/javafx/scene/chart/StackedAreaChartTest.java line 414: > 412: } > 413: > 414: @Test minor: I would suggest adding a comment explaining what the test does. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1231#discussion_r1316272301 From jvos at openjdk.org Tue Sep 5 18:51:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 18:51:45 GMT Subject: [jfx17u] RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 17:02:40 GMT, Jose Pereda wrote: > Clean backport of 8251481: TableCell accessing row: NPE on auto-sizing > Reviewed-by: fastegal Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/150#pullrequestreview-1611725107 From jpereda at openjdk.org Tue Sep 5 18:55:45 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 18:55:45 GMT Subject: [jfx17u] Integrated: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: <7RYW_d--xiQt9jsfzeaVG8v4HM0X2ghXQ8hAPEcb-qk=.7f099f43-1261-4f58-b04a-3e4904e4c90f@github.com> On Tue, 5 Sep 2023 17:02:40 GMT, Jose Pereda wrote: > Clean backport of 8251481: TableCell accessing row: NPE on auto-sizing > Reviewed-by: fastegal This pull request has now been integrated. Changeset: 2e56cc0e Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/2e56cc0e7badf019c4fa99e5329bea2ee4216443 Stats: 50 lines in 3 files changed: 49 ins; 0 del; 1 mod 8251481: TableCell accessing row: NPE on auto-sizing Reviewed-by: jvos Backport-of: 59cd8ec2d6a221a19ac4eb3a26f65535766410cc ------------- PR: https://git.openjdk.org/jfx17u/pull/150 From jvos at openjdk.org Tue Sep 5 18:55:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 18:55:47 GMT Subject: [jfx17u] RFR: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 17:55:23 GMT, Johan Vos wrote: > 8251481: TableCell accessing row: NPE on auto-sizing > Reviewed-by: fastegal duplicate PR to investigate why it wasn't a clean BP. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/151#issuecomment-1707154738 From jvos at openjdk.org Tue Sep 5 18:55:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 18:55:48 GMT Subject: [jfx17u] Withdrawn: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 17:55:23 GMT, Johan Vos wrote: > 8251481: TableCell accessing row: NPE on auto-sizing > Reviewed-by: fastegal This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx17u/pull/151 From jpereda at openjdk.org Tue Sep 5 19:05:09 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 19:05:09 GMT Subject: [jfx17u] RFR: 8251483: TableCell: NPE on modifying item's list Message-ID: <0HblJSQoiIUErhAGpjwNcOdRBOLAOPIw8HmyP6erii8=.a953cc17-28ba-4467-8251-aa558110c4cc@github.com> Clean backport of 8251483: TableCell: NPE on modifying item's list Reviewed-by: aghaisas, mstrauss ------------- Commit messages: - 8251483: TableCell: NPE on modifying item's list Changes: https://git.openjdk.org/jfx17u/pull/152/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251483 Stats: 76 lines in 3 files changed: 67 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx17u/pull/152.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/152/head:pull/152 PR: https://git.openjdk.org/jfx17u/pull/152 From jvos at openjdk.org Tue Sep 5 19:25:18 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Sep 2023 19:25:18 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: <0ll0k9vshvgEpiWasM8xm_nPhQwD2XQkBX4sW64ICYw=.580385a1-d55f-4510-a07f-fd0cede9df27@github.com> On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 The caching means a huge performance improvement in real-world applications. This looks like one of the most relevant performance enhancements we can achieve. I tried hard but could not spot regression. I'd love to see this PR merged and used in ea-releases so that we get hopefully feedback from real-world libraries and applications soon. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1611779656 From angorya at openjdk.org Tue Sep 5 20:02:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 20:02:14 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 00:55:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Removed application preferences implementation modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 762: > 760: */ > 761: public Map getPlatformPreferences() { > 762: return Map.of(); Should javadoc explicitly proclaim that the map is immutable? modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1081: > 1079: public static void updatePreferences(Map preferences) { > 1080: if (isFxApplicationThread()) { > 1081: checkHighContrastThemeChanged(preferences); is this needed in this preferences-only PR? modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1093: > 1091: > 1092: // This method will be removed when StyleThemes are added. > 1093: private static void checkHighContrastThemeChanged(Map preferences) { is this needed? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/ChangedValue.java line 47: > 45: * @return a mapping of keys to changed values > 46: */ > 47: public static Map getEffectiveChanges(Map old, Map current) { this class does not handle addition of keys in `current` - should we explain this fact in this method and/or the class javadoc? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 112: > 110: } > 111: > 112: throw new IllegalArgumentException( should this behavior be documented? there is no mention of an exception in case of type mismatch in the base class. also, do we want to have some kind of trivial conversion implemented such as int -> long -> double ? or not? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 118: > 116: } > 117: > 118: fireValueChangedEvent(); It looks like this will fire `colorProperty.fireValueChangedEvent();` for all colors in `allColors`, even when none has changed. edit: I see what you did here. Contrary to it's name, `fireValueChangeEvent` does not always fire. Perhaps we could rename the method to fireValueChangeEventIfChanged/Maybe or some such? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 197: > 195: > 196: private void updateEffectiveValue() { > 197: // Choose the first non-null value in this order: overrideValue, platformValue, defaultValue. are null default values allowed? modules/javafx.graphics/src/main/java/javafx/application/Application.java line 35: > 33: import javafx.css.Stylesheet; > 34: import javafx.scene.Scene; > 35: import javafx.scene.paint.Color; strictly speaking, this file should be unchanged. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 448: > 446: * by JavaFX when the operating system reports that a platform preference has changed. > 447: * > 448: * @return the {@code Preferences} instance minor: make it a link or add a line with a link to the comment itself saying something like `Please refer to { @ link Preferences } javadoc for a list of expected preferences.` modules/javafx.graphics/src/test/java/test/com/sun/javafx/application/preferences/PlatformPreferencesTest.java line 41: > 39: > 40: import static org.junit.jupiter.api.Assertions.*; > 41: import static test.javafx.collections.MockMapObserver.Tuple.tup; this generates 9 errors in eclipse, starting with Description Resource Type The type test.javafx.collections.MockMapObserver.Tuple.tup is not accessible PlatformPreferencesTest.java Java Problem the following change to graphics/.classpath should fix it (inc. complete file): tests/manual/events/PlatformPreferencesTest.java line 113: > 111: return "{\r\n\t" + entries + "\r\n}\r\n"; > 112: } > 113: extra newline? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316296127 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316302729 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316302948 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316305695 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316310131 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316313168 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316320186 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316322553 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316325117 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316336107 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316337291 From jpereda at openjdk.org Tue Sep 5 20:09:53 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 20:09:53 GMT Subject: [jfx17u] Integrated: 8251483: TableCell: NPE on modifying item's list In-Reply-To: <0HblJSQoiIUErhAGpjwNcOdRBOLAOPIw8HmyP6erii8=.a953cc17-28ba-4467-8251-aa558110c4cc@github.com> References: <0HblJSQoiIUErhAGpjwNcOdRBOLAOPIw8HmyP6erii8=.a953cc17-28ba-4467-8251-aa558110c4cc@github.com> Message-ID: On Tue, 5 Sep 2023 18:59:56 GMT, Jose Pereda wrote: > Clean backport of 8251483: TableCell: NPE on modifying item's list > Reviewed-by: aghaisas, mstrauss This pull request has now been integrated. Changeset: 0985af97 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/0985af975fa93ff3c829b78af25c35d30bd192f4 Stats: 76 lines in 3 files changed: 67 ins; 0 del; 9 mod 8251483: TableCell: NPE on modifying item's list Backport-of: 222b2b11ee58717eb355eac86ad39fffea256d00 ------------- PR: https://git.openjdk.org/jfx17u/pull/152 From jpereda at openjdk.org Tue Sep 5 20:19:02 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 20:19:02 GMT Subject: [jfx17u] RFR: 8289751: Multiple unit test failures after JDK-8251483 Message-ID: Clean backport of 8289751: Multiple unit test failures after JDK-8251483 Reviewed-by: kcr ------------- Commit messages: - 8289751: Multiple unit test failures after JDK-8251483 Changes: https://git.openjdk.org/jfx17u/pull/153/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289751 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/153.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/153/head:pull/153 PR: https://git.openjdk.org/jfx17u/pull/153 From angorya at openjdk.org Tue Sep 5 20:23:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 20:23:43 GMT Subject: RFR: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 10:47:02 GMT, Karthik P K wrote: > Made changes to use Util::waitForIdle instead of Toolkit::firePulse in system tests. The test will wait for default value of 10 pulses to complete in the scene before executing the subsequent statements. tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 101: > 99: }); > 100: > 101: Util.waitForIdle(scene); is this the right place for waitForIdle? should it be on L98? since there are multiple key presses involved? and also, do we still need to .sleep() on L103? tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 104: > 102: robot.keyType(KeyCode.ENTER); > 103: }); > 104: Util.waitForIdle(scene); once we have waitForIdle, do we still need to wait() ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1230#discussion_r1316365449 PR Review Comment: https://git.openjdk.org/jfx/pull/1230#discussion_r1316366508 From kcr at openjdk.org Tue Sep 5 20:37:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Sep 2023 20:37:04 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 00:55:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Removed application preferences implementation A couple minor comments. on the API docs. I'll do a more thorough review later. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 466: > 464: * so applications should not assume that a particular preference is always available. > 465: *

> 466: * The following list contains all preferences that are potentially available on the specified platforms: Is it possible that a preference might be stored that isn't in the below list? Or is it guaranteed that the _only_ possible preferences that will ever be stored are those documented here? If the former, I recommend removing the word "all". If the latter, then it is OK as is, if we are comfortable specifying this. ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1611865735 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316367820 From kcr at openjdk.org Tue Sep 5 20:37:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Sep 2023 20:37:07 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 19:41:33 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/javafx/application/Application.java line 35: > >> 33: import javafx.css.Stylesheet; >> 34: import javafx.scene.Scene; >> 35: import javafx.scene.paint.Color; > > strictly speaking, this file should be unchanged. Agreed. Now that the user preferences API has been split into a follow-on enhancement, which was a very good idea, there is no reason to change this file. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 448: > >> 446: * by JavaFX when the operating system reports that a platform preference has changed. >> 447: * >> 448: * @return the {@code Preferences} instance > > minor: make it a link or add a line with a link to the comment itself saying something like > `Please refer to { @ link Preferences } javadoc for a list of expected preferences.` I think there is no need to make this a link, since the return type of the method already provides the link. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316363536 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316365683 From jpereda at openjdk.org Tue Sep 5 20:47:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 20:47:48 GMT Subject: [jfx17u] Integrated: 8289751: Multiple unit test failures after JDK-8251483 In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:12:36 GMT, Jose Pereda wrote: > Clean backport of 8289751: Multiple unit test failures after JDK-8251483 > Reviewed-by: kcr This pull request has now been integrated. Changeset: 289ac761 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/289ac761451aa08be72b74e11d695a0c56a434e6 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8289751: Multiple unit test failures after JDK-8251483 Backport-of: b9f39076bbd4065da61f0c4610d6823a48c6eb46 ------------- PR: https://git.openjdk.org/jfx17u/pull/153 From angorya at openjdk.org Tue Sep 5 20:49:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 20:49:11 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 20:19:11 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 448: >> >>> 446: * by JavaFX when the operating system reports that a platform preference has changed. >>> 447: * >>> 448: * @return the {@code Preferences} instance >> >> minor: make it a link or add a line with a link to the comment itself saying something like >> `Please refer to { @ link Preferences } javadoc for a list of expected preferences.` > > I think there is no need to make this a link, since the return type of the method already provides the link. not in Eclipse. {@code} shows up in monospace font, while {@link} provides the link: Screenshot 2023-09-05 at 13 45 41 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316388067 From kcr at openjdk.org Tue Sep 5 21:10:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Sep 2023 21:10:07 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 20:44:19 GMT, Andy Goryachev wrote: >> I think there is no need to make this a link, since the return type of the method already provides the link. > > not in Eclipse. {@code} shows up in monospace font, while {@link} provides the link: > > Screenshot 2023-09-05 at 13 45 41 Yes, I know that `{@code}` shows up in monospace font, while `{@link}` provides the link. It does that in the javadoc-generated API docs, too. What I meant by my comment is that since the method in question returns a `Preferences` object, it already generates a link to that class when listing the signature the method. Our usual practice is to not include a link to a class that is returned by a method or passed in as a parameter to a method, since it is a redundant link. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316406896 From angorya at openjdk.org Tue Sep 5 21:15:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 21:15:02 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 21:06:38 GMT, Kevin Rushforth wrote: >> not in Eclipse. {@code} shows up in monospace font, while {@link} provides the link: >> >> Screenshot 2023-09-05 at 13 45 41 > > Yes, I know that `{@code}` shows up in monospace font, while `{@link}` provides the link. It does that in the javadoc-generated API docs, too. > > What I meant by my comment is that since the method in question returns a `Preferences` object, it already generates a link to that class when listing the signature the method. Our usual practice is to not include a link to a class that is returned by a method or passed in as a parameter to a method, since it is a redundant link. All I actually want is a link to the platform keys, not to the Properties class per se. Perhaps something similar to what String.format() does. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316411060 From kcr at openjdk.org Tue Sep 5 21:34:03 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Sep 2023 21:34:03 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 21:12:09 GMT, Andy Goryachev wrote: >> Yes, I know that `{@code}` shows up in monospace font, while `{@link}` provides the link. It does that in the javadoc-generated API docs, too. >> >> What I meant by my comment is that since the method in question returns a `Preferences` object, it already generates a link to that class when listing the signature the method. Our usual practice is to not include a link to a class that is returned by a method or passed in as a parameter to a method, since it is a redundant link. > > All I actually want is a link to the platform keys, not to the Properties class per se. > Perhaps something similar to what String.format() does. Hmm, maybe. In that case, the description seems the best place for that sort of link, rather than the `@return`. Although, since that list is a predominant part of the class docs of Preferences, the link in the method signature that already goes to Preferences class ought to cover that, I would think. I wouldn't mind either way. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316430567 From angorya at openjdk.org Tue Sep 5 21:41:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 21:41:04 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 21:31:23 GMT, Kevin Rushforth wrote: >> All I actually want is a link to the platform keys, not to the Properties class per se. >> Perhaps something similar to what String.format() does. > > Hmm, maybe. In that case, the description seems the best place for that sort of link, rather than the `@return`. Although, since that list is a predominant part of the class docs of Preferences, the link in the method signature that already goes to Preferences class ought to cover that, I would think. I wouldn't mind either way. It's just a suggestion, really, saves a click. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316433857 From angorya at openjdk.org Tue Sep 5 21:41:07 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 21:41:07 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 00:55:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Removed application preferences implementation modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 468: > 466: * The following list contains all preferences that are potentially available on the specified platforms: > 467: * > 468: * we might want to add an anchor somewhere here, to be able to create a link in Platform.getPreferences(), similar to what String.format() -> Formatter#syntax does:

Format String Syntax

------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316436962 From kcr at openjdk.org Tue Sep 5 22:47:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Sep 2023 22:47:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: <70haO014JfOGU23AB6EQzTuoIS0Ql9zIu9FJs71T9X8=.b5e7fcbb-ac70-4030-8eda-d0f0b8da7f43@github.com> On Tue, 5 Sep 2023 18:45:50 GMT, Andy Goryachev wrote: > > I think it would best to remove BitSet > > does it mean there'll be a followup PR? Filing a follow-up cleanup bug seems reasonable, but not urgent, especially now that BitSet is immutable . The problems pointed out are (largely, if not wholly) theoretical, but it does continue to be a maintenance burden. > or should it be done as a part of this one? Definitely not. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1316491035 From mstrauss at openjdk.org Tue Sep 5 22:54:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 22:54:05 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> On Tue, 5 Sep 2023 19:11:20 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 762: > >> 760: */ >> 761: public Map getPlatformPreferences() { >> 762: return Map.of(); > > Should javadoc explicitly proclaim that the map is immutable? No. This map is only used by `QuantumToolkit` to initialize the preferences. The implementation should not keep this map around, and an immutability guarantee might be seen as an invitation to do so. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316494811 From mstrauss at openjdk.org Tue Sep 5 22:59:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 22:59:05 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 19:18:04 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1081: > >> 1079: public static void updatePreferences(Map preferences) { >> 1080: if (isFxApplicationThread()) { >> 1081: checkHighContrastThemeChanged(preferences); > > is this needed in this preferences-only PR? Yes. This PR replaces the special-purpose implementation to retrieve the theme name of the Windows platform with a general-purpse implementation to retrieve all kinds of preferences. We need to retain the theme name handling, otherwise high-contrast support for the Caspian and Modena themes doesn't work. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1093: > >> 1091: >> 1092: // This method will be removed when StyleThemes are added. >> 1093: private static void checkHighContrastThemeChanged(Map preferences) { > > is this needed? Yes, see above. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316496781 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316496877 From mstrauss at openjdk.org Tue Sep 5 23:04:06 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:04:06 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <7NAcM5MBUf7XjVlDCyQy_0XQIs2rJDfep0q-rD1zTyk=.f764a95c-acd0-41b6-8f49-3dd6728d0126@github.com> On Tue, 5 Sep 2023 19:21:39 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/ChangedValue.java line 47: > >> 45: * @return a mapping of keys to changed values >> 46: */ >> 47: public static Map getEffectiveChanges(Map old, Map current) { > > this class does not handle addition of keys in `current` - should we explain this fact in this method and/or the class javadoc? It doesn't handle _removals_ of keys in `current`, which is explained in the method documentation: "Returns a map that contains the _new or changed_ mappings of _current_ compared to _old_. A value has changed if _Objects#equals_ or _Arrays#equals_ returns _false_ when invoked with the old and new value." If you think this is not clear enough, I can try to improve the wording. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316499514 From mstrauss at openjdk.org Tue Sep 5 23:10:05 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:10:05 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 19:26:50 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 112: > >> 110: } >> 111: >> 112: throw new IllegalArgumentException( > > should this behavior be documented? > there is no mention of an exception in case of type mismatch in the base class. > > also, do we want to have some kind of trivial conversion implemented such as int -> long -> double ? > or not? It is documented in the `Platform.Preferences` interface, which is implemented by this class: /** * Returns the value to which the specified key is mapped. * * @param the type of the value * @param key the key * @param type the type of the value * @throws NullPointerException if {@code key} is null * @throws IllegalArgumentException if the key is not mapped to a {@code type} instance * @return the value to which the key is mapped, or {@code Optional.empty()} * if no mapping exists for the specified key */ Optional getValue(String key, Class type); I'm a bit hesitant regarding an automatic conversion. What would be the use case for this? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316502374 From angorya at openjdk.org Tue Sep 5 23:26:47 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 23:26:47 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> Message-ID: <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> On Tue, 5 Sep 2023 22:51:28 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 762: >> >>> 760: */ >>> 761: public Map getPlatformPreferences() { >>> 762: return Map.of(); >> >> Should javadoc explicitly proclaim that the map is immutable? > > No. This map is only used by `QuantumToolkit` to initialize the preferences. The implementation should not keep this map around, and an immutability guarantee might be seen as an invitation to do so. would it make sense to add this explanation to javadoc, even though it's not a public API? >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/ChangedValue.java line 47: >> >>> 45: * @return a mapping of keys to changed values >>> 46: */ >>> 47: public static Map getEffectiveChanges(Map old, Map current) { >> >> this class does not handle addition of keys in `current` - should we explain this fact in this method and/or the class javadoc? > > It doesn't handle _removals_ of keys in `current`, which is explained in the method documentation: > > "Returns a map that contains the _new or changed_ mappings of _current_ compared to _old_. > A value has changed if _Objects#equals_ or _Arrays#equals_ returns _false_ when invoked with the old and new value." > > If you think this is not clear enough, I can try to improve the wording. is it actually possible to have keys removed at runtime? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316507700 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316509976 From mstrauss at openjdk.org Tue Sep 5 23:26:50 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:26:50 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 19:30:30 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 118: > >> 116: } >> 117: >> 118: fireValueChangedEvent(); > > It looks like this will fire `colorProperty.fireValueChangedEvent();` for all colors in `allColors`, even when none has changed. > edit: I see what you did here. Contrary to it's name, `fireValueChangeEvent` does not always fire. Perhaps we could rename the method to fireValueChangeEventIfChanged/Maybe or some such? I've renamed it to `fireValueChangedIfNecessary`. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 197: > >> 195: >> 196: private void updateEffectiveValue() { >> 197: // Choose the first non-null value in this order: overrideValue, platformValue, defaultValue. > > are null default values allowed? I can't think of a good reason why we would have preferences with a `null` default value. The small set of convenience properties is meant as a baseline that all JavaFX developers can rely on. > tests/manual/events/PlatformPreferencesTest.java line 113: > >> 111: return "{\r\n\t" + entries + "\r\n}\r\n"; >> 112: } >> 113: > > extra newline? Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316504358 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316505649 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316506587 From mstrauss at openjdk.org Tue Sep 5 23:26:52 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:26:52 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 20:16:45 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Application.java line 35: >> >>> 33: import javafx.css.Stylesheet; >>> 34: import javafx.scene.Scene; >>> 35: import javafx.scene.paint.Color; >> >> strictly speaking, this file should be unchanged. > > Agreed. Now that the user preferences API has been split into a follow-on enhancement, which was a very good idea, there is no reason to change this file. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316505922 From mstrauss at openjdk.org Tue Sep 5 23:26:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:26:44 GMT Subject: RFR: 8301302: Platform preferences API [v6] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Revert Application changes - Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/40e2f286..4b9f75d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=04-05 Stats: 10 lines in 4 files changed: 1 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Tue Sep 5 23:34:02 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:34:02 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> Message-ID: On Tue, 5 Sep 2023 23:21:18 GMT, Andy Goryachev wrote: >> It doesn't handle _removals_ of keys in `current`, which is explained in the method documentation: >> >> "Returns a map that contains the _new or changed_ mappings of _current_ compared to _old_. >> A value has changed if _Objects#equals_ or _Arrays#equals_ returns _false_ when invoked with the old and new value." >> >> If you think this is not clear enough, I can try to improve the wording. > > is it actually possible to have keys removed at runtime? The set of preferences that is reported by a platform is hard-coded in the native platform implementation, and depends on the operating system version. It might indeed be the case that an OS upgrade/downgrade could result in a different set of reported properties, but can this happen while a JavaFX applications remains running? In any case, even if that were to happen, the current behavior is that a preference that was once reported will not be removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316515253 From angorya at openjdk.org Tue Sep 5 23:34:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 23:34:06 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 23:07:03 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 112: >> >>> 110: } >>> 111: >>> 112: throw new IllegalArgumentException( >> >> should this behavior be documented? >> there is no mention of an exception in case of type mismatch in the base class. >> >> also, do we want to have some kind of trivial conversion implemented such as int -> long -> double ? >> or not? > > It is documented in the `Platform.Preferences` interface, which is implemented by this class: > > > /** > * Returns the value to which the specified key is mapped. > * > * @param the type of the value > * @param key the key > * @param type the type of the value > * @throws NullPointerException if {@code key} is null > * @throws IllegalArgumentException if the key is not mapped to a {@code type} instance > * @return the value to which the key is mapped, or {@code Optional.empty()} > * if no mapping exists for the specified key > */ > Optional getValue(String key, Class type); > > > I'm a bit hesitant regarding an automatic conversion. What would be the use case for this? one [possible] use case is when different versions of the native platform have different types (int32/int64 ?). or, if the property value is String with the semantics of an integer. Of course, the app dev can always request an Object and parse that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316515202 From mstrauss at openjdk.org Tue Sep 5 23:34:07 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:34:07 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 20:21:54 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 466: > >> 464: * so applications should not assume that a particular preference is always available. >> 465: *

>> 466: * The following list contains all preferences that are potentially available on the specified platforms: > > Is it possible that a preference might be stored that isn't in the below list? Or is it guaranteed that the _only_ possible preferences that will ever be stored are those documented here? If the former, I recommend removing the word "all". If the latter, then it is OK as is, if we are comfortable specifying this. I think we should indeed document _all_ possible preferences for the platform toolkit implementations we control. Of course, this means that we need to keep this list in sync with the actual implementation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316516566 From angorya at openjdk.org Tue Sep 5 23:38:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 23:38:01 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 23:30:39 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 466: >> >>> 464: * so applications should not assume that a particular preference is always available. >>> 465: *

>>> 466: * The following list contains all preferences that are potentially available on the specified platforms: >> >> Is it possible that a preference might be stored that isn't in the below list? Or is it guaranteed that the _only_ possible preferences that will ever be stored are those documented here? If the former, I recommend removing the word "all". If the latter, then it is OK as is, if we are comfortable specifying this. > > I think we should indeed document _all_ possible preferences for the platform toolkit implementations we control. Of course, this means that we need to keep this list in sync with the actual implementation. +1 we could put the doc (in markdown format) in the doc-files/platform directory (or create any other subdirectory, see JDK-8309749) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316518504 From jpereda at openjdk.org Tue Sep 5 23:41:57 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Sep 2023 23:41:57 GMT Subject: [jfx17u] RFR: 8298728: Cells in VirtualFlow jump after resizing Message-ID: Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing Reviewed-by: aghaisas, angorya There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: - setSkin(new SkinStub(this)); + setSkin(new SkinStub<>(this)); ------------- Commit messages: - 8298728: Cells in VirtualFlow jump after resizing Changes: https://git.openjdk.org/jfx17u/pull/154/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298728 Stats: 130 lines in 4 files changed: 111 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jfx17u/pull/154.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/154/head:pull/154 PR: https://git.openjdk.org/jfx17u/pull/154 From mstrauss at openjdk.org Tue Sep 5 23:50:52 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:50:52 GMT Subject: RFR: 8301302: Platform preferences API [v7] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added javadoc link to list of platform preferences ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/4b9f75d4..27022f31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Tue Sep 5 23:50:55 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 5 Sep 2023 23:50:55 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 21:37:38 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 468: > >> 466: * The following list contains all preferences that are potentially available on the specified platforms: >> 467: * >> 468: *

> > we might want to add an anchor somewhere here, to be able to create a link in Platform.getPreferences(), similar to what String.format() -> Formatter#syntax does: > > >

Format String Syntax

I've added a `@see` tag to the `Platform.getPreferences()` method, which links to the table in the class documentation of `Platform.Preferences`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316523643 From angorya at openjdk.org Tue Sep 5 23:51:18 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Sep 2023 23:51:18 GMT Subject: RFR: 8301302: Platform preferences API [v6] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 23:26:44 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - Revert Application changes > - Addressed review comments I'll do another round of testing on windows and macos and continue this review tomorrow. I feel we are very close. Thank you for your hard work! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1707450525 From mstrauss at openjdk.org Wed Sep 6 00:06:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 00:06:44 GMT Subject: RFR: 8301302: Platform preferences API [v8] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: improve javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/27022f31..02d6a2f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=06-07 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Sep 6 00:06:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 00:06:45 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> Message-ID: On Tue, 5 Sep 2023 23:18:22 GMT, Andy Goryachev wrote: >> No. This map is only used by `QuantumToolkit` to initialize the preferences. The implementation should not keep this map around, and an immutability guarantee might be seen as an invitation to do so. > > would it make sense to add this explanation to javadoc, even though it's not a public API? I've added the following sentence: Callers should assume that the returned map is immutable, while implementations should either return an immutable map, or give up ownership of the returned map. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316535413 From mstrauss at openjdk.org Wed Sep 6 00:14:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 00:14:45 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Update Eclipse .classpath file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/02d6a2f0..4172fa61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Sep 6 00:14:46 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 00:14:46 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 5 Sep 2023 23:27:44 GMT, Andy Goryachev wrote: >> It is documented in the `Platform.Preferences` interface, which is implemented by this class: >> >> >> /** >> * Returns the value to which the specified key is mapped. >> * >> * @param the type of the value >> * @param key the key >> * @param type the type of the value >> * @throws NullPointerException if {@code key} is null >> * @throws IllegalArgumentException if the key is not mapped to a {@code type} instance >> * @return the value to which the key is mapped, or {@code Optional.empty()} >> * if no mapping exists for the specified key >> */ >> Optional getValue(String key, Class type); >> >> >> I'm a bit hesitant regarding an automatic conversion. What would be the use case for this? > > one [possible] use case is when different versions of the native platform have different types (int32/int64 ?). > or, if the property value is String with the semantics of an integer. > > Of course, the app dev can always request an Object and parse that. If we add this, we'd also need to decide whether we only want to support lossless conversions, or if lossy conversions are acceptable as well. Since this will add a considerable amount of complexity to this PR, I suggest we don't to it at this time. If there's a need, we can always add it later. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316537786 From mstrauss at openjdk.org Wed Sep 6 00:14:49 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 00:14:49 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <3q0LubyBITqpGjvzKJbKyRhxG40PQ7cl-AsSl-8Lr38=.a8130593-5b0e-4443-be01-bdf30c3ca256@github.com> On Tue, 5 Sep 2023 19:56:56 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed application preferences implementation > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/application/preferences/PlatformPreferencesTest.java line 41: > >> 39: >> 40: import static org.junit.jupiter.api.Assertions.*; >> 41: import static test.javafx.collections.MockMapObserver.Tuple.tup; > > this generates 9 errors in eclipse, starting with > > Description Resource Type > The type test.javafx.collections.MockMapObserver.Tuple.tup is not accessible PlatformPreferencesTest.java Java Problem > > the following change to graphics/.classpath should fix it (inc. complete file): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've updated the `.classpath` file as shown. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1316539556 From kpk at openjdk.org Wed Sep 6 05:21:03 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Sep 2023 05:21:03 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared [v2] In-Reply-To: References: Message-ID: > Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. > This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1231/files - new: https://git.openjdk.org/jfx/pull/1231/files/19864916..ccb895ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1231&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1231&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1231.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1231/head:pull/1231 PR: https://git.openjdk.org/jfx/pull/1231 From kpk at openjdk.org Wed Sep 6 05:58:22 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Sep 2023 05:58:22 GMT Subject: RFR: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests [v2] In-Reply-To: References: Message-ID: > Made changes to use Util::waitForIdle instead of Toolkit::firePulse in system tests. The test will wait for default value of 10 pulses to complete in the scene before executing the subsequent statements. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1230/files - new: https://git.openjdk.org/jfx/pull/1230/files/5f8045c0..73d9fcb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1230&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1230&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1230.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1230/head:pull/1230 PR: https://git.openjdk.org/jfx/pull/1230 From kpk at openjdk.org Wed Sep 6 06:04:49 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Sep 2023 06:04:49 GMT Subject: RFR: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:18:52 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 101: > >> 99: }); >> 100: >> 101: Util.waitForIdle(scene); > > is this the right place for waitForIdle? should it be on L98? since there are multiple key presses involved? > > and also, do we still need to .sleep() on L103? Ideally yes it should be on L98. Since we can not call `waitForIdle` from Application thread I added at L101. But if we have to achieve the purpose of using `waitForIdle` in the test then it should be added after each key press. So updated the code to do so. I had kept the sleep as it is thinking if it might be required in slower systems. Since we are waiting for 10 pulses with `waitForIdle` it might not be needed. Hence removed it. Since we are using `Util.runAndWait` there is no need for the `scrollLatch` hence removed it. > tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 104: > >> 102: robot.keyType(KeyCode.ENTER); >> 103: }); >> 104: Util.waitForIdle(scene); > > once we have waitForIdle, do we still need to wait() ? Same as above comment, I had kept the sleep as it is thinking if it might be required in slower systems. Since we are waiting for 10 pulses with `waitForIdle` it might not be needed. Hence removed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1230#discussion_r1316774380 PR Review Comment: https://git.openjdk.org/jfx/pull/1230#discussion_r1316774759 From jvos at openjdk.org Wed Sep 6 06:30:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Sep 2023 06:30:45 GMT Subject: [jfx17u] RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:36:25 GMT, Jose Pereda wrote: > Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing > Reviewed-by: aghaisas, angorya > > There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: > > > - setSkin(new SkinStub(this)); > + setSkin(new SkinStub<>(this)); Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/154#pullrequestreview-1612573125 From aghaisas at openjdk.org Wed Sep 6 06:34:45 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 6 Sep 2023 06:34:45 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 05:21:03 GMT, Karthik P K wrote: >> Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. >> This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by aghaisas (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1231#pullrequestreview-1612577672 From jpereda at openjdk.org Wed Sep 6 07:39:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 07:39:48 GMT Subject: [jfx17u] Integrated: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:36:25 GMT, Jose Pereda wrote: > Almost clean backport of 8298728: Cells in VirtualFlow jump after resizing > Reviewed-by: aghaisas, angorya > > There was a small conflict in VirtualFlowTest::CellStub, due to JDK-8297414: > > > - setSkin(new SkinStub(this)); > + setSkin(new SkinStub<>(this)); This pull request has now been integrated. Changeset: acf8acc8 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/acf8acc88dbf2d2c11d0321fe345b4bc8e180841 Stats: 130 lines in 4 files changed: 111 ins; 2 del; 17 mod 8298728: Cells in VirtualFlow jump after resizing Reviewed-by: jvos Backport-of: ca29cc6122010e4b94778cc658efd4fdddc8af67 ------------- PR: https://git.openjdk.org/jfx17u/pull/154 From jpereda at openjdk.org Wed Sep 6 07:51:59 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 07:51:59 GMT Subject: [jfx17u] RFR: 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Message-ID: <263FEx62k2a3EmpfdeWzFFitAwmh4uDEm5wOU7a5Yv4=.4c76a21b-ef42-45a2-93e9-877e7d9dfd8a@github.com> Clean backport of 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Reviewed-by: angorya, jvos ------------- Commit messages: - 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Changes: https://git.openjdk.org/jfx17u/pull/155/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303680 Stats: 43 lines in 2 files changed: 42 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/155.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/155/head:pull/155 PR: https://git.openjdk.org/jfx17u/pull/155 From jpereda at openjdk.org Wed Sep 6 08:15:47 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 08:15:47 GMT Subject: [jfx17u] RFR: 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession In-Reply-To: <263FEx62k2a3EmpfdeWzFFitAwmh4uDEm5wOU7a5Yv4=.4c76a21b-ef42-45a2-93e9-877e7d9dfd8a@github.com> References: <263FEx62k2a3EmpfdeWzFFitAwmh4uDEm5wOU7a5Yv4=.4c76a21b-ef42-45a2-93e9-877e7d9dfd8a@github.com> Message-ID: On Wed, 6 Sep 2023 07:45:58 GMT, Jose Pereda wrote: > Clean backport of 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession > > Reviewed-by: angorya, jvos Errors are due to branch not being up to date. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/155#issuecomment-1707876939 From jpereda at openjdk.org Wed Sep 6 08:15:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 08:15:48 GMT Subject: [jfx17u] Withdrawn: 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession In-Reply-To: <263FEx62k2a3EmpfdeWzFFitAwmh4uDEm5wOU7a5Yv4=.4c76a21b-ef42-45a2-93e9-877e7d9dfd8a@github.com> References: <263FEx62k2a3EmpfdeWzFFitAwmh4uDEm5wOU7a5Yv4=.4c76a21b-ef42-45a2-93e9-877e7d9dfd8a@github.com> Message-ID: <-QH7qihoI5_cwfrkv8sW_q4gc3NFWB-gvCn7oDiBbKk=.487e4cd9-02d9-4862-85f9-69a3c7a6e2a9@github.com> On Wed, 6 Sep 2023 07:45:58 GMT, Jose Pereda wrote: > Clean backport of 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession > > Reviewed-by: angorya, jvos This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx17u/pull/155 From jpereda at openjdk.org Wed Sep 6 08:23:07 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 08:23:07 GMT Subject: [jfx17u] RFR: 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Message-ID: Clean backport of 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Reviewed-by: angorya, jvos ------------- Commit messages: - 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Changes: https://git.openjdk.org/jfx17u/pull/156/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303680 Stats: 43 lines in 2 files changed: 42 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/156.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/156/head:pull/156 PR: https://git.openjdk.org/jfx17u/pull/156 From jpereda at openjdk.org Wed Sep 6 08:34:45 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 08:34:45 GMT Subject: [jfx17u] Integrated: 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:16:46 GMT, Jose Pereda wrote: > Clean backport of 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession > Reviewed-by: angorya, jvos This pull request has now been integrated. Changeset: 877ee019 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/877ee019db89fda3cd3f4f2364e6a2ecfd8200bb Stats: 43 lines in 2 files changed: 42 ins; 1 del; 0 mod 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession Backport-of: 6be8703ca9e6dccdda8b75b63efbcea5c6728d6f ------------- PR: https://git.openjdk.org/jfx17u/pull/156 From jpereda at openjdk.org Wed Sep 6 08:55:12 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 08:55:12 GMT Subject: [jfx17u] RFR: 8306447: Adding an element to a long existing list may cause the first visible element to jump Message-ID: Clean backport of 8306447: Adding an element to a long existing list may cause the first visible element to jump Reviewed-by: angorya, kcr ------------- Commit messages: - 8306447: Adding an element to a long existing list may cause the first visible element to jump Changes: https://git.openjdk.org/jfx17u/pull/157/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306447 Stats: 62 lines in 2 files changed: 56 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/157.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/157/head:pull/157 PR: https://git.openjdk.org/jfx17u/pull/157 From lkostyra at openjdk.org Wed Sep 6 09:01:18 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 6 Sep 2023 09:01:18 GMT Subject: RFR: 8315728: [testbug] SystemMenuBarTest prints "FAILED IS: false" Message-ID: Printed line was right above the assertion testing the printed `failed` value. Failing assertion will print the value of `failed` regardless, so the printed line was redundant. ------------- Commit messages: - 8315728: [testbug] SystemMenuBarTest prints "FAILED IS: false" Changes: https://git.openjdk.org/jfx/pull/1233/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315728 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1233.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1233/head:pull/1233 PR: https://git.openjdk.org/jfx/pull/1233 From jpereda at openjdk.org Wed Sep 6 09:16:51 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 09:16:51 GMT Subject: [jfx17u] Integrated: 8306447: Adding an element to a long existing list may cause the first visible element to jump In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:49:50 GMT, Jose Pereda wrote: > Clean backport of 8306447: Adding an element to a long existing list may cause the first visible element to jump > Reviewed-by: angorya, kcr This pull request has now been integrated. Changeset: a90a028f Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/a90a028f619712cebb14c8f66ac98f3d10ea3e1c Stats: 62 lines in 2 files changed: 56 ins; 1 del; 5 mod 8306447: Adding an element to a long existing list may cause the first visible element to jump Backport-of: 1a0f6c7f5e131d0a40073ccfe21bb6dd0d6b2da3 ------------- PR: https://git.openjdk.org/jfx17u/pull/157 From jpereda at openjdk.org Wed Sep 6 09:49:13 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 09:49:13 GMT Subject: [jfx17u] RFR: 8293836: Rendering performance degradation at bottom of TableView with many rows Message-ID: Clean backport of 8293836: Rendering performance degradation at bottom of TableView with many rows Reviewed-by: angorya, kcr ------------- Commit messages: - 8293836: Rendering performance degradation at bottom of TableView with many rows Changes: https://git.openjdk.org/jfx17u/pull/158/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293836 Stats: 13 lines in 1 file changed: 5 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/158.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/158/head:pull/158 PR: https://git.openjdk.org/jfx17u/pull/158 From jpereda at openjdk.org Wed Sep 6 10:01:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 10:01:48 GMT Subject: [jfx17u] Integrated: 8293836: Rendering performance degradation at bottom of TableView with many rows In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 09:41:35 GMT, Jose Pereda wrote: > Clean backport of 8293836: Rendering performance degradation at bottom of TableView with many rows > > Reviewed-by: angorya, kcr This pull request has now been integrated. Changeset: 514dfaec Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/514dfaeca4b6e5154556474df3519b0256547973 Stats: 13 lines in 1 file changed: 5 ins; 6 del; 2 mod 8293836: Rendering performance degradation at bottom of TableView with many rows Backport-of: 10f41b7d1f2f53ebe2bfdb61de495bbb7290d32d ------------- PR: https://git.openjdk.org/jfx17u/pull/158 From jpereda at openjdk.org Wed Sep 6 10:26:58 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 10:26:58 GMT Subject: [jfx17u] RFR: 8309470: Potential performance improvements in VirtualFlow Message-ID: Clean backport of 8309470: Potential performance improvements in VirtualFlow Reviewed-by: kpk, angorya ------------- Commit messages: - 8309470: Potential performance improvements in VirtualFlow Changes: https://git.openjdk.org/jfx17u/pull/159/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309470 Stats: 217 lines in 2 files changed: 191 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jfx17u/pull/159.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/159/head:pull/159 PR: https://git.openjdk.org/jfx17u/pull/159 From jvos at openjdk.org Wed Sep 6 10:39:47 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Sep 2023 10:39:47 GMT Subject: [jfx17u] RFR: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: <5TSfVPoOO7wEFxjWFwKzLl6SUutxjNhNJ51FiIOR_Ds=.af7c8f8a-58c9-4222-8edb-15e3d5f10b87@github.com> On Wed, 6 Sep 2023 10:21:14 GMT, Jose Pereda wrote: > Clean backport of 8309470: Potential performance improvements in VirtualFlow > Reviewed-by: kpk, angorya Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/159#pullrequestreview-1613024999 From jpereda at openjdk.org Wed Sep 6 10:42:46 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 10:42:46 GMT Subject: [jfx17u] Integrated: 8309470: Potential performance improvements in VirtualFlow In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 10:21:14 GMT, Jose Pereda wrote: > Clean backport of 8309470: Potential performance improvements in VirtualFlow > Reviewed-by: kpk, angorya This pull request has now been integrated. Changeset: 4b1022f6 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/4b1022f637a935faced125bb810b0fcd0df43985 Stats: 217 lines in 2 files changed: 191 ins; 14 del; 12 mod 8309470: Potential performance improvements in VirtualFlow Reviewed-by: jvos Backport-of: 9ad0e908088373aaa7220fc98ef5625d8f9ff6a4 ------------- PR: https://git.openjdk.org/jfx17u/pull/159 From aghaisas at openjdk.org Wed Sep 6 10:42:48 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 6 Sep 2023 10:42:48 GMT Subject: [jfx-tests] RFR: JDK-8315409: Fix jfx-tests so they work with latest jfx build [v2] In-Reply-To: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> References: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> Message-ID: On Sat, 2 Sep 2023 00:31:26 GMT, Alexandre Iline wrote: >> JDK-8315409: Fix jfx-tests so they work with latest jfx build > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Addressing copyright issues. Approving this PR as it will serve as the foundation of future fixes. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx-tests/pull/1#pullrequestreview-1613029537 From jpereda at openjdk.org Wed Sep 6 11:07:56 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 11:07:56 GMT Subject: [jfx17u] RFR: 8310638: Filtering a TableView with a large number of items freezes the UI Message-ID: <5N2udayiQGsjQuX8l1k39ve5khhvp-_4Zq8_Bye7bXg=.2d9acc12-b8fe-4a3c-b5cf-68d6d58cd108@github.com> Almost clean backport of 8310638: Filtering a TableView with a large number of items freezes the UI Reviewed-by: kcr, angorya There was a small conflict in VirtualFlowTest due to JDK-8297414: - list = new ArrayLinkedListShim(); + list = new ArrayLinkedListShim<>(); ------------- Commit messages: - 8310638: Filtering a TableView with a large number of items freezes the UI Changes: https://git.openjdk.org/jfx17u/pull/160/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310638 Stats: 49 lines in 3 files changed: 47 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/160.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/160/head:pull/160 PR: https://git.openjdk.org/jfx17u/pull/160 From jvos at openjdk.org Wed Sep 6 11:23:44 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Sep 2023 11:23:44 GMT Subject: [jfx17u] RFR: 8310638: Filtering a TableView with a large number of items freezes the UI In-Reply-To: <5N2udayiQGsjQuX8l1k39ve5khhvp-_4Zq8_Bye7bXg=.2d9acc12-b8fe-4a3c-b5cf-68d6d58cd108@github.com> References: <5N2udayiQGsjQuX8l1k39ve5khhvp-_4Zq8_Bye7bXg=.2d9acc12-b8fe-4a3c-b5cf-68d6d58cd108@github.com> Message-ID: On Wed, 6 Sep 2023 11:02:23 GMT, Jose Pereda wrote: > Almost clean backport of 8310638: Filtering a TableView with a large number of items freezes the UI > Reviewed-by: kcr, angorya > > There was a small conflict in VirtualFlowTest due to JDK-8297414: > > - list = new ArrayLinkedListShim(); > + list = new ArrayLinkedListShim<>(); Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/160#pullrequestreview-1613092427 From jpereda at openjdk.org Wed Sep 6 11:23:44 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 11:23:44 GMT Subject: [jfx17u] Integrated: 8310638: Filtering a TableView with a large number of items freezes the UI In-Reply-To: <5N2udayiQGsjQuX8l1k39ve5khhvp-_4Zq8_Bye7bXg=.2d9acc12-b8fe-4a3c-b5cf-68d6d58cd108@github.com> References: <5N2udayiQGsjQuX8l1k39ve5khhvp-_4Zq8_Bye7bXg=.2d9acc12-b8fe-4a3c-b5cf-68d6d58cd108@github.com> Message-ID: <5Nd3Lgytm_VzVQZ79JhwUHQD-BRvcSHNSxkkMPatQjA=.684eacba-9f5c-48f2-a65c-77df9ade3e5a@github.com> On Wed, 6 Sep 2023 11:02:23 GMT, Jose Pereda wrote: > Almost clean backport of 8310638: Filtering a TableView with a large number of items freezes the UI > Reviewed-by: kcr, angorya > > There was a small conflict in VirtualFlowTest due to JDK-8297414: > > - list = new ArrayLinkedListShim(); > + list = new ArrayLinkedListShim<>(); This pull request has now been integrated. Changeset: 817a42b4 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/817a42b4b172d77e1a9b0eda16bcf5424a30af6c Stats: 49 lines in 3 files changed: 47 ins; 0 del; 2 mod 8310638: Filtering a TableView with a large number of items freezes the UI Reviewed-by: jvos Backport-of: 8b1a446ca9519f468aa1cf6ee9876b6035dcac37 ------------- PR: https://git.openjdk.org/jfx17u/pull/160 From kcr at openjdk.org Wed Sep 6 12:12:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 12:12:47 GMT Subject: RFR: 8315728: [testbug] SystemMenuBarTest prints "FAILED IS: false" In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:54:51 GMT, Lukasz Kostyra wrote: > Printed line was right above the assertion testing the printed `failed` value. Failing assertion will print the value of `failed` regardless, so the printed line was redundant. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1233#pullrequestreview-1613180696 From lkostyra at openjdk.org Wed Sep 6 12:28:47 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 6 Sep 2023 12:28:47 GMT Subject: Integrated: 8315728: [testbug] SystemMenuBarTest prints "FAILED IS: false" In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:54:51 GMT, Lukasz Kostyra wrote: > Printed line was right above the assertion testing the printed `failed` value. Failing assertion will print the value of `failed` regardless, so the printed line was redundant. This pull request has now been integrated. Changeset: 668e4b91 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/668e4b9195ecbf586d548bf2307fffaec8e79b61 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8315728: [testbug] SystemMenuBarTest prints "FAILED IS: false" Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1233 From tsayao at openjdk.org Wed Sep 6 12:39:53 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 6 Sep 2023 12:39:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: <1CIghfNnSHS1CagNn4nBxInZsXSP3Jc4WdMXAkEHSbU=.1b4cf54d-7ba9-4a92-a355-43cfee0342ab@github.com> On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) I will check the failing tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1708271876 From jpereda at openjdk.org Wed Sep 6 13:56:15 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 13:56:15 GMT Subject: [jfx17u] RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 Message-ID: Almost clean backport of 8138842: TableViewSelectionModel.selectIndices does not select index 0 Reviewed-by: angorya, aghaisas There were conflicts with the insertion point of the two tests TableViewTest and TreeTableViewTest. In the case of TableViewTest: also two tests that already exist were added at the end (as this is how they are upstream), so the conflict was resolved by removing the two original tests, so the order of tests remains the same as upstream. ------------- Commit messages: - 8138842: TableViewSelectionModel.selectIndices does not select index 0 Changes: https://git.openjdk.org/jfx17u/pull/161/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=161&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8138842 Stats: 73 lines in 4 files changed: 49 ins; 13 del; 11 mod Patch: https://git.openjdk.org/jfx17u/pull/161.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/161/head:pull/161 PR: https://git.openjdk.org/jfx17u/pull/161 From jvos at openjdk.org Wed Sep 6 14:04:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Sep 2023 14:04:48 GMT Subject: [jfx17u] RFR: 8138842: TableViewSelectionModel.selectIndices does not select index 0 In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:49:30 GMT, Jose Pereda wrote: > Almost clean backport of 8138842: TableViewSelectionModel.selectIndices does not select index 0 > Reviewed-by: angorya, aghaisas > > There were conflicts with the insertion point of the two tests TableViewTest and TreeTableViewTest. > > In the case of TableViewTest: also two tests that already exist were added at the end (as this is how they are upstream), so the conflict was resolved by removing the two original tests, so the order of tests remains the same as upstream. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/161#pullrequestreview-1613424302 From jpereda at openjdk.org Wed Sep 6 14:09:47 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 14:09:47 GMT Subject: [jfx17u] Integrated: 8138842: TableViewSelectionModel.selectIndices does not select index 0 In-Reply-To: References: Message-ID: <2LCbT6DUELYjV3AX0-TLD4FKVVcPuHqAoLz0JT4yIdU=.5cbb0220-7ba9-44f2-956d-ff2658d9e7d8@github.com> On Wed, 6 Sep 2023 13:49:30 GMT, Jose Pereda wrote: > Almost clean backport of 8138842: TableViewSelectionModel.selectIndices does not select index 0 > Reviewed-by: angorya, aghaisas > > There were conflicts with the insertion point of the two tests TableViewTest and TreeTableViewTest. > > In the case of TableViewTest: also two tests that already exist were added at the end (as this is how they are upstream), so the conflict was resolved by removing the two original tests, so the order of tests remains the same as upstream. This pull request has now been integrated. Changeset: 9d33f058 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/9d33f0580d55d63e2baee9904a29623ffc52dde4 Stats: 73 lines in 4 files changed: 49 ins; 13 del; 11 mod 8138842: TableViewSelectionModel.selectIndices does not select index 0 Reviewed-by: jvos Backport-of: ef9f0664484f7a3c2a9ebfbd81e1d23ef65218ed ------------- PR: https://git.openjdk.org/jfx17u/pull/161 From dlemmermann at gmail.com Wed Sep 6 14:27:00 2023 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Wed, 6 Sep 2023 16:27:00 +0200 Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: <0ll0k9vshvgEpiWasM8xm_nPhQwD2XQkBX4sW64ICYw=.580385a1-d55f-4510-a07f-fd0cede9df27@github.com> References: <0ll0k9vshvgEpiWasM8xm_nPhQwD2XQkBX4sW64ICYw=.580385a1-d55f-4510-a07f-fd0cede9df27@github.com> Message-ID: <3F911162-B79D-4CBB-86A3-9DA752CCF1FE@gmail.com> More than happy to provide feedback regarding performance improvements in our applications due to this change. Dirk > Am 05.09.2023 um 21:25 schrieb Johan Vos : > > On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: > >>> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >>> >>> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >>> >>> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >>> >>> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >>> >>> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >>> >>> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >>> >>> Although the test case above was extreme, this change should have positive effects for most applications. >> >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > The caching means a huge performance improvement in real-world applications. This looks like one of the most relevant performance enhancements we can achieve. > I tried hard but could not spot regression. I'd love to see this PR merged and used in ea-releases so that we get hopefully feedback from real-world libraries and applications soon. > > ------------- > > Marked as reviewed by jvos (Reviewer). > > PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1611779656 From jpereda at openjdk.org Wed Sep 6 14:29:12 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 14:29:12 GMT Subject: [jfx17u] RFR: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Message-ID: Almost clean backport of 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Reviewed-by: angorya There was a conflict with the insertion point of the test in TreeTableViewTest, that was solved by swapping the order of tests to match up with upstream. ------------- Commit messages: - 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Changes: https://git.openjdk.org/jfx17u/pull/162/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311127 Stats: 163 lines in 3 files changed: 130 ins; 31 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/162.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/162/head:pull/162 PR: https://git.openjdk.org/jfx17u/pull/162 From angorya at openjdk.org Wed Sep 6 14:47:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 14:47:49 GMT Subject: RFR: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared [v2] In-Reply-To: References: Message-ID: <2R2FRdxeqT5Iqs1ZRuLKQ2PKHjVFXm0rsIHBx1MTt9o=.203458ab-27e8-44a2-abf0-ed7538368808@github.com> On Wed, 6 Sep 2023 05:21:03 GMT, Karthik P K wrote: >> Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. >> This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments looks good, thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1231#pullrequestreview-1613532675 From kpk at openjdk.org Wed Sep 6 15:05:01 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Sep 2023 15:05:01 GMT Subject: Integrated: 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 13:15:47 GMT, Karthik P K wrote: > Added test: `testChartLineAndAreaRemovedOnClearingSeries()` for `StackedAreaChart` to check if the line and fill elements gets removed from the series on clearing the series. This test is added similar to the tests added to `LineChart` and `AreaChart`. > This test is not required for `BarChart`, `BubbleChart` and `ScatterChart` as no node will added to the series in these charts. This pull request has now been integrated. Changeset: 3bfede8b Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/3bfede8b550455fab6259b37f3622ea3830a142c Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod 8314779: [testbug] Add test to all the XYCharts to check if chart components are removed when series is cleared Reviewed-by: aghaisas, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1231 From angorya at openjdk.org Wed Sep 6 15:12:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 15:12:19 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 00:05:58 GMT, Michael Strau? wrote: >> one [possible] use case is when different versions of the native platform have different types (int32/int64 ?). >> or, if the property value is String with the semantics of an integer. >> >> Of course, the app dev can always request an Object and parse that. > > If we add this, we'd also need to decide whether we only want to support lossless conversions, or if lossy conversions are acceptable as well. Since this will add a considerable amount of complexity to this PR, I suggest we don't to it at this time. If there's a need, we can always add it later. after some thought, I would say conversion is not needed - should that unlikely scenario happen, the app devs could use getValue(.., Object.class); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317442623 From angorya at openjdk.org Wed Sep 6 15:29:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 15:29:56 GMT Subject: RFR: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 05:58:22 GMT, Karthik P K wrote: >> Made changes to use Util::waitForIdle instead of Toolkit::firePulse in system tests. The test will wait for default value of 10 pulses to complete in the scene before executing the subsequent statements. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments looks good, thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1230#pullrequestreview-1613637038 From angorya at openjdk.org Wed Sep 6 15:32:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 15:32:24 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-XO11QPZiV-mkUHEoRQOU0xa9YDEKNy6sLrXCzWWQdg=.0d028485-4202-4558-816b-2e354ba5e99f@github.com> On Wed, 6 Sep 2023 00:14:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse .classpath file quick question: do we have @since tags in all the right places, right? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708612185 From mstrauss at openjdk.org Wed Sep 6 15:50:15 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 15:50:15 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <6temSfr_A7ddCxJd2-iy3eGdlUt2eODQ7NYiihdzKGk=.5c9fe7b6-b923-457f-a11f-4c558a1389eb@github.com> On Wed, 6 Sep 2023 00:14:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse .classpath file > quick question: do we have @SInCE tags in all the right places, right? There are only three new public APIs, all of which have the `since` tag: 1. `javafx.application.Appearance` 2. `javafx.application.Platform.getPreferences()` 3. `javafx.application.Platform.Preferences` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708643943 From jvos at openjdk.org Wed Sep 6 15:58:48 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Sep 2023 15:58:48 GMT Subject: [jfx17u] RFR: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:23:39 GMT, Jose Pereda wrote: > Almost clean backport of 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers > Reviewed-by: angorya > > There was a conflict with the insertion point of the test in TreeTableViewTest, that was solved by swapping the order of tests to match up with upstream. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/162#pullrequestreview-1613692713 From jpereda at openjdk.org Wed Sep 6 15:58:49 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 15:58:49 GMT Subject: [jfx17u] Integrated: 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:23:39 GMT, Jose Pereda wrote: > Almost clean backport of 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers > Reviewed-by: angorya > > There was a conflict with the insertion point of the test in TreeTableViewTest, that was solved by swapping the order of tests to match up with upstream. This pull request has now been integrated. Changeset: 21a08a84 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/21a08a8461f9e88cde8ecb882b1cba1eb6f55ec9 Stats: 163 lines in 3 files changed: 130 ins; 31 del; 2 mod 8311127: Regression: The fix for TableView and TreeTableView menu button affects all table column headers Reviewed-by: jvos Backport-of: 5aad0406e5ab18d9da56e8adb4c013b93be1ba3d ------------- PR: https://git.openjdk.org/jfx17u/pull/162 From jpereda at openjdk.org Wed Sep 6 16:10:00 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 16:10:00 GMT Subject: [jfx17u] RFR: 8311185: VirtualFlow jump when cellcount changes Message-ID: Clean backport of 8311185: VirtualFlow jump when cellcount changes Reviewed-by: angorya, kcr ------------- Commit messages: - 8311185: VirtualFlow jump when cellcount changes Changes: https://git.openjdk.org/jfx17u/pull/163/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311185 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/163.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/163/head:pull/163 PR: https://git.openjdk.org/jfx17u/pull/163 From jpereda at openjdk.org Wed Sep 6 16:23:46 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Sep 2023 16:23:46 GMT Subject: [jfx17u] Integrated: 8311185: VirtualFlow jump when cellcount changes In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:02:08 GMT, Jose Pereda wrote: > Clean backport of 8311185: VirtualFlow jump when cellcount changes > Reviewed-by: angorya, kcr This pull request has now been integrated. Changeset: 07955dd2 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/07955dd287d6e995174aa4860f168dd8a50571a5 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod 8311185: VirtualFlow jump when cellcount changes Backport-of: 0371b349c929a0f8e71d8f2a01b1e565bb885e6c ------------- PR: https://git.openjdk.org/jfx17u/pull/163 From kpk at openjdk.org Wed Sep 6 16:26:48 2023 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Sep 2023 16:26:48 GMT Subject: Integrated: 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 10:47:02 GMT, Karthik P K wrote: > Made changes to use Util::waitForIdle instead of Toolkit::firePulse in system tests. The test will wait for default value of 10 pulses to complete in the scene before executing the subsequent statements. This pull request has now been integrated. Changeset: 8fcd6e5e Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/8fcd6e5e55967810ec2acd3dcc9b47bae5c70350 Stats: 16 lines in 2 files changed: 0 ins; 11 del; 5 mod 8308608: [testbug] Use Util::waitForIdle instead of Toolkit::firePulse in system tests Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1230 From kcr at openjdk.org Wed Sep 6 16:26:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 16:26:50 GMT Subject: [jfx-tests] RFR: JDK-8315409: Fix jfx-tests so they work with latest jfx build [v2] In-Reply-To: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> References: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> Message-ID: On Sat, 2 Sep 2023 00:31:26 GMT, Alexandre Iline wrote: >> JDK-8315409: Fix jfx-tests so they work with latest jfx build > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Addressing copyright issues. There are still 122 more files that are missing a `,` after `2023`. I will file a follow-on issue so as not to delay getting this in. We can run our copyright year update script to fix the rest. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx-tests/pull/1#pullrequestreview-1613753647 From duke at openjdk.org Wed Sep 6 16:43:51 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 6 Sep 2023 16:43:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) I ran into similar failures when I added a method to a core class but did not add it to the Stub version of the same class. In my case I added a call to Stage.java but didn't add it to SubStage.java. I'll be away from my computer for about a week and will take a closer look at this when I get back. I did notice that when I press a dead key the caret ends up at the beginning of the preview string when it should be at the end. There's also an issue with the way keys on the numeric keypad are being encoded. The fix is minor (I think) and I'll send details when I get back. Beyond that I don't understand the IME machinery so here's hoping that someone who does can spare some cycles to review this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1708736380 From angorya at openjdk.org Wed Sep 6 17:11:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 17:11:10 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> Message-ID: On Wed, 6 Sep 2023 00:01:29 GMT, Michael Strau? wrote: >> would it make sense to add this explanation to javadoc, even though it's not a public API? > > I've added the following sentence: > > Callers should assume that the returned map is immutable, while implementations should > either return an immutable map, or give up ownership of the returned map. > > > What do you think? Thank you for clarification! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317595357 From shurailine at openjdk.org Wed Sep 6 17:12:51 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Wed, 6 Sep 2023 17:12:51 GMT Subject: [jfx-tests] Integrated: JDK-8315409: Fix jfx-tests so they work with latest jfx build In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 20:22:09 GMT, Alexandre Iline wrote: > JDK-8315409: Fix jfx-tests so they work with latest jfx build This pull request has now been integrated. Changeset: 9a7df0b5 Author: Alexandre Iline URL: https://git.openjdk.org/jfx-tests/commit/9a7df0b57cb8ce035b3221a24a20d62d049c7090 Stats: 27092 lines in 465 files changed: 1910 ins; 22848 del; 2334 mod 8315409: Fix jfx-tests so they work with latest jfx build Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx-tests/pull/1 From angorya at openjdk.org Wed Sep 6 17:25:15 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 17:25:15 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <_pNWZVvmqrOWu9kRN3KdpCFKfgmzo4D37gXH_5B5m6o=.f8009e0c-5b3d-4d87-84bd-ada459ab89cd@github.com> On Wed, 6 Sep 2023 00:14:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse .classpath file modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 472: > 470: * > 471: * > 472: * would it be possible to sort the keys alphabetically? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317608737 From angorya at openjdk.org Wed Sep 6 17:35:15 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 17:35:15 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> On Wed, 6 Sep 2023 00:14:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse .classpath file tests/manual/events/PlatformPreferencesTest.java line 85: > 83: textArea.setText("preferences = " + formatPrefs(cachedPreferences.entrySet().stream())); > 84: > 85: Platform.getPreferences().addListener( While testing on macOS 13.3.1a, a change in the Appearance settings page results in one valid change reported, followed by a number of empty changes. Is it possible to suppress empty changes? example: changed = { macOS.NSColor.alternatingContentBackgroundColors=[Ljavafx.scene.paint.Color;@58d04cb macOS.NSColor.controlBackgroundColor=0xffffffff macOS.NSColor.controlColor=0xffffffff macOS.NSColor.controlTextColor=0x000000d8 macOS.NSColor.disabledControlTextColor=0x0000003f macOS.NSColor.gridColor=0xe6e6e6ff macOS.NSColor.headerTextColor=0x000000d8 macOS.NSColor.highlightColor=0xffffffff macOS.NSColor.keyboardFocusIndicatorColor=0x4eab307f macOS.NSColor.labelColor=0x000000d8 macOS.NSColor.linkColor=0x0068daff macOS.NSColor.placeholderTextColor=0x0000003f macOS.NSColor.quaternaryLabelColor=0x00000019 macOS.NSColor.secondaryLabelColor=0x0000007f macOS.NSColor.selectedContentBackgroundColor=0x4da033ff macOS.NSColor.selectedControlColor=0xd0eac8ff macOS.NSColor.selectedControlTextColor=0x000000d8 macOS.NSColor.selectedTextBackgroundColor=0xd0eac8ff macOS.NSColor.selectedTextColor=0x000000ff macOS.NSColor.separatorColor=0x00000019 macOS.NSColor.systemBlueColor=0x007affff macOS.NSColor.systemBrownColor=0xa2845eff macOS.NSColor.systemGrayColor=0x8e8e93ff macOS.NSColor.systemGreenColor=0x28cd41ff macOS.NSColor.systemIndigoColor=0x5856d6ff macOS.NSColor.systemOrangeColor=0xff9500ff macOS.NSColor.systemPinkColor=0xff2d55ff macOS.NSColor.systemPurpleColor=0xaf52deff macOS.NSColor.systemRedColor=0xff3b30ff macOS.NSColor.systemTealColor=0x59adc4ff macOS.NSColor.systemYellowColor=0xffcc00ff macOS.NSColor.tertiaryLabelColor=0x00000042 macOS.NSColor.textBackgroundColor=0xffffffff macOS.NSColor.textColor=0x000000ff macOS.NSColor.underPageBackgroundColor=0x969696e5 macOS.NSColor.unemphasizedSelectedContentBackgroundColor=0xdcdcdcff macOS.NSColor.unemphasizedSelectedTextBackgroundColor=0xdcdcdcff macOS.NSColor.unemphasizedSelectedTextColor=0x000000ff macOS.NSColor.windowBackgroundColor=0xecececff macOS.NSColor.windowFrameTextColor=0x000000d8 } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } changed = { } tests/manual/events/PlatformPreferencesTest.java line 108: > 106: String entries = prefs > 107: .sorted(Map.Entry.comparingByKey()) > 108: .map(Object::toString) very, very minor: you could format arrays, to avoid [Ljavafx.scene.paint.Color;@2bacc543 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317617606 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317618960 From angorya at openjdk.org Wed Sep 6 17:48:18 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 17:48:18 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 00:14:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Update Eclipse .classpath file it's been a while, could you please merge in the master branch? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708830192 From kcr at openjdk.org Wed Sep 6 18:06:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 18:06:24 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <3yEdWA6rRyYGHKPjFhLN0pQQAjFMgjBWXBoC3qLE__I=.eb3d0e35-d007-4932-847b-4772dbafe893@github.com> On Tue, 5 Sep 2023 23:35:04 GMT, Andy Goryachev wrote: >> I think we should indeed document _all_ possible preferences for the platform toolkit implementations we control. Of course, this means that we need to keep this list in sync with the actual implementation. > > +1 > > we could put the doc (in markdown format) in the doc-files/platform directory (or create any other subdirectory, see JDK-8309749) I think Michael meant that the javadoc-generated API docs in this file need to be kept up to date. If we are going to say _all_, then yes it will. I don't see a need for any other doc related to this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317649740 From mstrauss at openjdk.org Wed Sep 6 18:14:02 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 18:14:02 GMT Subject: RFR: 8301302: Platform preferences API [v10] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? 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 18 additional commits since the last revision: - Merge branch 'master' into feature/platform-preferences - Format arrays in test application - Suppress empty change message in test application - Update Eclipse .classpath file - improve javadoc - Added javadoc link to list of platform preferences - Revert Application changes - Addressed review comments - Removed application preferences implementation - Added test - ... and 8 more: https://git.openjdk.org/jfx/compare/e6b6074c...2837e33c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/4172fa61..2837e33c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=08-09 Stats: 385585 lines in 6288 files changed: 217555 ins; 124574 del; 43456 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Sep 6 18:14:04 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 18:14:04 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> Message-ID: On Wed, 6 Sep 2023 17:31:06 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Eclipse .classpath file > > tests/manual/events/PlatformPreferencesTest.java line 85: > >> 83: textArea.setText("preferences = " + formatPrefs(cachedPreferences.entrySet().stream())); >> 84: >> 85: Platform.getPreferences().addListener( > > While testing on macOS 13.3.1a, a change in the Appearance settings page results in one valid change reported, followed by a number of empty changes. Is it possible to suppress empty changes? > > example: > > > changed = { > macOS.NSColor.alternatingContentBackgroundColors=[Ljavafx.scene.paint.Color;@58d04cb > macOS.NSColor.controlBackgroundColor=0xffffffff > macOS.NSColor.controlColor=0xffffffff > macOS.NSColor.controlTextColor=0x000000d8 > macOS.NSColor.disabledControlTextColor=0x0000003f > macOS.NSColor.gridColor=0xe6e6e6ff > macOS.NSColor.headerTextColor=0x000000d8 > macOS.NSColor.highlightColor=0xffffffff > macOS.NSColor.keyboardFocusIndicatorColor=0x4eab307f > macOS.NSColor.labelColor=0x000000d8 > macOS.NSColor.linkColor=0x0068daff > macOS.NSColor.placeholderTextColor=0x0000003f > macOS.NSColor.quaternaryLabelColor=0x00000019 > macOS.NSColor.secondaryLabelColor=0x0000007f > macOS.NSColor.selectedContentBackgroundColor=0x4da033ff > macOS.NSColor.selectedControlColor=0xd0eac8ff > macOS.NSColor.selectedControlTextColor=0x000000d8 > macOS.NSColor.selectedTextBackgroundColor=0xd0eac8ff > macOS.NSColor.selectedTextColor=0x000000ff > macOS.NSColor.separatorColor=0x00000019 > macOS.NSColor.systemBlueColor=0x007affff > macOS.NSColor.systemBrownColor=0xa2845eff > macOS.NSColor.systemGrayColor=0x8e8e93ff > macOS.NSColor.systemGreenColor=0x28cd41ff > macOS.NSColor.systemIndigoColor=0x5856d6ff > macOS.NSColor.systemOrangeColor=0xff9500ff > macOS.NSColor.systemPinkColor=0xff2d55ff > macOS.NSColor.systemPurpleColor=0xaf52deff > macOS.NSColor.systemRedColor=0xff3b30ff > macOS.NSColor.systemTealColor=0x59adc4ff > macOS.NSColor.systemYellowColor=0xffcc00ff > macOS.NSColor.tertiaryLabelColor=0x00000042 > macOS.NSColor.textBackgroundColor=0xffffffff > macOS.NSColor.textColor=0x000000ff > macOS.NSColor.underPageBackgroundColor=0x969696e5 > macOS.NSColor.unemphasizedSelectedContentBackgroundColor=0xdcdcdcff > macOS.NSColor.unemphasizedSelectedTextBackgroundColor=0xdcdcdcff > macOS.NSColor.unemphasizedSelectedTextColor=0x000000ff > macOS.NSColor.windowBackgroundColor=0xecececff > macOS.NSColor.windowFrameTextColor=0x000000d8 > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > } > changed = { > > }... Fixed. > tests/manual/events/PlatformPreferencesTest.java line 108: > >> 106: String entries = prefs >> 107: .sorted(Map.Entry.comparingByKey()) >> 108: .map(Object::toString) > > very, very minor: you could format arrays, to avoid [Ljavafx.scene.paint.Color;@2bacc543 Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317654428 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317654505 From kcr at openjdk.org Wed Sep 6 18:27:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 18:27:53 GMT Subject: [jfx-tests] RFR: JDK-8315409: Fix jfx-tests so they work with latest jfx build [v2] In-Reply-To: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> References: <-Hu92kM6Xc4xBWlqVNQRtZDtRjd3QR6n8qtanbBRujI=.0b52e49b-8aef-498b-be16-85f788242224@github.com> Message-ID: On Sat, 2 Sep 2023 00:31:26 GMT, Alexandre Iline wrote: >> JDK-8315409: Fix jfx-tests so they work with latest jfx build > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Addressing copyright issues. I just now ran our copyright script and submitted PR #2 to fix the copyright lines. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/1#issuecomment-1708883815 From angorya at openjdk.org Wed Sep 6 18:30:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 18:30:12 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> Message-ID: On Wed, 6 Sep 2023 18:07:31 GMT, Michael Strau? wrote: >> tests/manual/events/PlatformPreferencesTest.java line 85: >> >>> 83: textArea.setText("preferences = " + formatPrefs(cachedPreferences.entrySet().stream())); >>> 84: >>> 85: Platform.getPreferences().addListener( >> >> While testing on macOS 13.3.1a, a change in the Appearance settings page results in one valid change reported, followed by a number of empty changes. Is it possible to suppress empty changes? >> >> example: >> >> >> changed = { >> macOS.NSColor.alternatingContentBackgroundColors=[Ljavafx.scene.paint.Color;@58d04cb >> macOS.NSColor.controlBackgroundColor=0xffffffff >> macOS.NSColor.controlColor=0xffffffff >> macOS.NSColor.controlTextColor=0x000000d8 >> macOS.NSColor.disabledControlTextColor=0x0000003f >> macOS.NSColor.gridColor=0xe6e6e6ff >> macOS.NSColor.headerTextColor=0x000000d8 >> macOS.NSColor.highlightColor=0xffffffff >> macOS.NSColor.keyboardFocusIndicatorColor=0x4eab307f >> macOS.NSColor.labelColor=0x000000d8 >> macOS.NSColor.linkColor=0x0068daff >> macOS.NSColor.placeholderTextColor=0x0000003f >> macOS.NSColor.quaternaryLabelColor=0x00000019 >> macOS.NSColor.secondaryLabelColor=0x0000007f >> macOS.NSColor.selectedContentBackgroundColor=0x4da033ff >> macOS.NSColor.selectedControlColor=0xd0eac8ff >> macOS.NSColor.selectedControlTextColor=0x000000d8 >> macOS.NSColor.selectedTextBackgroundColor=0xd0eac8ff >> macOS.NSColor.selectedTextColor=0x000000ff >> macOS.NSColor.separatorColor=0x00000019 >> macOS.NSColor.systemBlueColor=0x007affff >> macOS.NSColor.systemBrownColor=0xa2845eff >> macOS.NSColor.systemGrayColor=0x8e8e93ff >> macOS.NSColor.systemGreenColor=0x28cd41ff >> macOS.NSColor.systemIndigoColor=0x5856d6ff >> macOS.NSColor.systemOrangeColor=0xff9500ff >> macOS.NSColor.systemPinkColor=0xff2d55ff >> macOS.NSColor.systemPurpleColor=0xaf52deff >> macOS.NSColor.systemRedColor=0xff3b30ff >> macOS.NSColor.systemTealColor=0x59adc4ff >> macOS.NSColor.systemYellowColor=0xffcc00ff >> macOS.NSColor.tertiaryLabelColor=0x00000042 >> macOS.NSColor.textBackgroundColor=0xffffffff >> macOS.NSColor.textColor=0x000000ff >> macOS.NSColor.underPageBackgroundColor=0x969696e5 >> macOS.NSColor.unemphasizedSelectedContentBackgroundColor=0xdcdcdcff >> macOS.NSColor.unemphasizedSelectedTextBackgroundColor=0xdcdcdcff >> macOS.NSColor.unemphasizedSelectedTextColor=0x000000ff >> macOS.NSColor.windowBackgroundColor=0xecececff >> macOS.NSColor.windowFrameTextColor=0x000000d8 >> } >> changed = { >> >> } >> changed = { >> >> } >> changed = { >> >> } >> chan... > > Fixed. sorry, that's not exactly what I meant. Platform preferences gets invalidated multiple times, but only the first time the value(s) are changed - all the other invalidations in the same batch have values unchanged. Is it possible to have only one invalidation per change? example: {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317672545 From kcr at openjdk.org Wed Sep 6 18:30:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 18:30:26 GMT Subject: [jfx-tests] RFR: 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 Message-ID: As mentioned in the JBS Description, I generated this PR by running the same copyright tool we use to update the jfx repo, with a slight modification to not filter out those files that already had "Copyright.*2023", since those are the ones that need to be fixed up for incorrect formatting. I manually reverted two files that had an embedded copyright line in a String. ------------- Commit messages: - 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 Changes: https://git.openjdk.org/jfx-tests/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=2&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315809 Stats: 139 lines in 139 files changed: 0 ins; 0 del; 139 mod Patch: https://git.openjdk.org/jfx-tests/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx-tests/pull/2 From kcr at openjdk.org Wed Sep 6 18:30:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 18:30:27 GMT Subject: [jfx-tests] RFR: 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 18:22:38 GMT, Kevin Rushforth wrote: > As mentioned in the JBS Description, I generated this PR by running the same copyright tool we use to update the jfx repo, with a slight modification to not filter out those files that already had "Copyright.*2023", since those are the ones that need to be fixed up for incorrect formatting. > > I manually reverted two files that had an embedded copyright line in a String. Reviewers: @arapte @shurymury ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/2#issuecomment-1708881863 From angorya at openjdk.org Wed Sep 6 19:04:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 19:04:13 GMT Subject: RFR: 8301302: Platform preferences API [v10] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 18:14:02 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? 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 18 additional commits since the last revision: > > - Merge branch 'master' into feature/platform-preferences > - Format arrays in test application > - Suppress empty change message in test application > - Update Eclipse .classpath file > - improve javadoc > - Added javadoc link to list of platform preferences > - Revert Application changes > - Addressed review comments > - Removed application preferences implementation > - Added test > - ... and 8 more: https://git.openjdk.org/jfx/compare/11651aea...2837e33c Another question, certainly out of scope for this PR. In Windows, we have display orientation and Scale settings. Changing those result in change updates sent via Screen.getScreens(), but Screen, while having DPI and scale fields, lacks orientation. Does it make sense to use this app Preferences API for screen orientation, or should we enhance Screen? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708930418 From mstrauss at openjdk.org Wed Sep 6 19:14:55 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 19:14:55 GMT Subject: RFR: 8301302: Platform preferences API [v11] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Fire only a single invalidation event ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/2837e33c..9cfded0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=09-10 Stats: 25 lines in 3 files changed: 12 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From angorya at openjdk.org Wed Sep 6 19:15:00 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 19:15:00 GMT Subject: RFR: 8301302: Platform preferences API [v10] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 18:14:02 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? 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 18 additional commits since the last revision: > > - Merge branch 'master' into feature/platform-preferences > - Format arrays in test application > - Suppress empty change message in test application > - Update Eclipse .classpath file > - improve javadoc > - Added javadoc link to list of platform preferences > - Revert Application changes > - Addressed review comments > - Removed application preferences implementation > - Added test > - ... and 8 more: https://git.openjdk.org/jfx/compare/df315e45...2837e33c One more question: are there currently any OS version specific differences in the Preferences keys? Like going from Win10 to Win11, or from macOS 12.* to 13.* ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708937760 From mstrauss at openjdk.org Wed Sep 6 19:15:02 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 19:15:02 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> Message-ID: On Wed, 6 Sep 2023 18:27:01 GMT, Andy Goryachev wrote: >> Fixed. > > sorry, that's not exactly what I meant. Platform preferences gets invalidated multiple times, but only the first time the value(s) are changed - all the other invalidations in the same batch have values unchanged. > Is it possible to have only one invalidation per change? > > example: > > {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} > {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} That's a good point. I've changed the implementation so that even when multiple preferences have changed, only a single invalidation notification is generated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317713132 From mstrauss at openjdk.org Wed Sep 6 19:16:25 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 19:16:25 GMT Subject: RFR: 8301302: Platform preferences API [v10] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 19:01:28 GMT, Andy Goryachev wrote: > Another question, certainly out of scope for this PR. In Windows, we have display orientation and Scale settings. Changing those result in change updates sent via Screen.getScreens(), but Screen, while having DPI and scale fields, lacks orientation. > > Does it make sense to use this app Preferences API for screen orientation, or should we enhance Screen? Since Preferences are not tied to a screen, I think this wouldn't be a good fit. We'd basically have to create a preference that contains mappings of screens to orientations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708947736 From mstrauss at openjdk.org Wed Sep 6 19:22:14 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 19:22:14 GMT Subject: RFR: 8301302: Platform preferences API [v10] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 19:07:19 GMT, Andy Goryachev wrote: > One more question: are there currently any OS version specific differences in the Preferences keys? Like going from Win10 to Win11, or from macOS 12.* to 13.* ? All of the `Windows.UIColor.*` mappings are available starting with Windows 10 build 10240. There are some `macOS.NSColor.*` mappings that are only available starting with macOS 10.14, but as far as I know JavaFX requires macOS 11.0, so there would be no difference in practice. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1708954773 From mstrauss at openjdk.org Wed Sep 6 19:28:51 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 19:28:51 GMT Subject: RFR: 8311895: CSS Transitions [v7] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 18:41:32 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). >> >> ### Example >> >> .button { >> -fx-background-color: dodgerblue; >> } >> >> .button:hover { >> -fx-background-color: red; >> -fx-scale-x: 1.1; >> -fx-scale-y: 1.1; >> >> transition: -fx-background-color 0.5s ease, >> -fx-scale-x 0.5s ease, >> -fx-scale-y 0.5s ease; >> } >> >> >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Added documentation Let?s keep this open. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-1708963197 From angorya at openjdk.org Wed Sep 6 19:36:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 19:36:13 GMT Subject: RFR: 8301302: Platform preferences API [v11] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 19:14:55 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Fire only a single invalidation event tests/manual/events/PlatformPreferencesTest.java line 46: > 44: import java.util.stream.Collectors; > 45: > 46: public class PlatformPreferencesTest extends Application { Could we rename this class? We already have PlatformPreferencesTest somewhere. PlatformPreferencesTestApp might be good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317738225 From angorya at openjdk.org Wed Sep 6 19:36:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 19:36:14 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <-Ouu7VyZeP9whapovhkJnfpwlYWcCpckDcyuk-NbgU4=.674f4bb6-a4f3-4efa-9606-ad863d5e6d54@github.com> Message-ID: On Wed, 6 Sep 2023 19:08:51 GMT, Michael Strau? wrote: >> sorry, that's not exactly what I meant. Platform preferences gets invalidated multiple times, but only the first time the value(s) are changed - all the other invalidations in the same batch have values unchanged. >> Is it possible to have only one invalidation per change? >> >> example: >> >> {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} >> {Windows.UIColor.Accent=0x498205ff, Windows.SPI.HighContrastOn=false, Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff, Windows.SysColor.COLOR_WINDOW=0xffffffff, Windows.UIColor.AccentLight1=0x61a907ff, Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff, Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff, Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff, Windows.SysColor.COLOR_BTNTEXT=0x000000ff, Windows.UIColor.Foreground=0xffffffff, Windows.UIColor.AccentDark1=0x3e7204ff, Windows.UIColor.Background=0x000000ff, Windows.UIColor.AccentLight3=0xc1f96cff, Windows.UIColor.AccentLight2=0x99f618ff, Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff, Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff, Windows.UIColor.AccentDark2=0x254b03ff, Windows.UIColor.AccentDark3=0x0d2801ff} > > That's a good point. I've changed the implementation so that even when multiple preferences have changed, only a single invalidation notification is generated. thank you, getting one event per change via OS Settings panel on win11 and macOS. @kevinrushforth please check this on Linux (I've added this on PlatformPreferencesTest:89 - System.out.println(Platform.getPreferences()); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317734061 From andy.goryachev at oracle.com Wed Sep 6 19:40:49 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 6 Sep 2023 19:40:49 +0000 Subject: JavaFX object traits In-Reply-To: References: Message-ID: I think this proposal makes a lot of sense. Having the trait interfaces inner classes of Trait clearly narrows down semantics. "Trait" might be too generic, maybe FxTrait or something like that? Just a thought. What other traits/properties should we include? Converting https://github.com/openjdk/jfx/pull/1215 to draft until this discussion comes to a resolution. -andy From: openjfx-dev on behalf of Michael Strau? Date: Saturday, September 2, 2023 at 15:09 To: openjfx-dev Subject: JavaFX object traits There's a proposal to add a common interface that identifies JavaFX objects that can hold an Observable property map: https://github.com/openjdk/jfx/pull/1215 The reason for this is obvious: allow JavaFX objects that can hold properties to be consumed by code without depending on brittle `instanceof` checks. The problem is real, but I think we can do much better than that. Why have a common interface at all? Well, of course it allows consumers to treat different objects in a uniform way. But there's more to it: the interface specifies the _meaning_ of the method; it guarantees that `Foo::getProperties` and `Bar::getProperties` are, in fact, not only methods with the same name, but the same semantics. `getProperties` and `hasProperties` is one example of such commonality between dissimilar classes like `Node` and `MenuItem`. But I've come across other examples in my own projects. For example, I'd like to consume JavaFX objects that have the `visible` and `disable` properties. Other applications will have different use cases, but since we don't know all possible use cases, it's hard to come up with a set of useful combinations of properties and methods. However, I think we can use the Java type system to allow applications to compose types that fit their unique use case. We begin by identifying common properties, and create trait interfaces that describe those properties: public final class javafx.scene.Trait { public interface Visible { BooleanProperty visibleProperty() default boolean isVisible()... default void setVisible(boolean value)... } public interface Disable { BooleanProperty disableProperty() default boolean isDisable()... default void setDisable(boolean value)... } public interface Properties { ObservableMap getProperties() default boolean hasProperties()... } ... } These interfaces can now be implemented by all relevant JavaFX classes. This includes `Node`, `MenuItem`, and `Tab`, but applications are free to implement these trait interfaces themselves. Applications can now consume objects that implement any combination of traits, which gives applications the much-needed flexibility to use shared code for all kinds of JavaFX objects: void doSomething(T node) { node.getProperties().put("foo", "bar"); node.setVisible(true); } void doAnotherThing(T node) { node.setText("hello"); node.setGraphic(myGraphic); } What do you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Sep 6 20:13:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 20:13:12 GMT Subject: RFR: 8301302: Platform preferences API [v11] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 19:14:55 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Fire only a single invalidation event looking good?? (with a minor change requested). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1614131903 From mstrauss at openjdk.org Wed Sep 6 20:41:25 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 20:41:25 GMT Subject: RFR: 8301302: Platform preferences API [v12] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes per review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/9cfded0b..c8fd0e70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=10-11 Stats: 6 lines in 2 files changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Sep 6 20:45:08 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 20:45:08 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: <_pNWZVvmqrOWu9kRN3KdpCFKfgmzo4D37gXH_5B5m6o=.f8009e0c-5b3d-4d87-84bd-ada459ab89cd@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <_pNWZVvmqrOWu9kRN3KdpCFKfgmzo4D37gXH_5B5m6o=.f8009e0c-5b3d-4d87-84bd-ada459ab89cd@github.com> Message-ID: <36uPjXMG7XcDp65vzpc_FtvC4xHmYedO11-0uA76ZHs=.131d752d-e95b-4af7-b472-e92edf3d41ea@github.com> On Wed, 6 Sep 2023 17:22:11 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Eclipse .classpath file > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 472: > >> 470: * >> 471: * >> 472: * > > would it be possible to sort the keys alphabetically? I don't think that's necessarily a good idea. I've reordered some of them, but others should be grouped. For example: it makes sense to keep the following keys together: * `macOS.NSColor.labelColor` * `macOS.NSColor.secondaryLabelColor` * `macOS.NSColor.tertiaryLabelColor` * `macOS.NSColor.quaternaryLabelColor` Another example: * `macOS.NSColor.textBackgroundColor` * `macOS.NSColor.selectedTextBackgroundColor` As it is, most of the keys appear in the same order as they appear in the respective platform's developer documentation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317811702 From mstrauss at openjdk.org Wed Sep 6 20:45:10 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 20:45:10 GMT Subject: RFR: 8301302: Platform preferences API [v11] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 19:34:05 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Fire only a single invalidation event > > tests/manual/events/PlatformPreferencesTest.java line 46: > >> 44: import java.util.stream.Collectors; >> 45: >> 46: public class PlatformPreferencesTest extends Application { > > Could we rename this class? We already have PlatformPreferencesTest somewhere. > PlatformPreferencesTestApp might be good. I've renamed it to `PlatformPreferencesChangedTest` to keep the naming convention of the surrounding files. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317812240 From angorya at openjdk.org Wed Sep 6 20:45:08 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 6 Sep 2023 20:45:08 GMT Subject: RFR: 8301302: Platform preferences API [v9] In-Reply-To: <36uPjXMG7XcDp65vzpc_FtvC4xHmYedO11-0uA76ZHs=.131d752d-e95b-4af7-b472-e92edf3d41ea@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <_pNWZVvmqrOWu9kRN3KdpCFKfgmzo4D37gXH_5B5m6o=.f8009e0c-5b3d-4d87-84bd-ada459ab89cd@github.com> <36uPjXMG7XcDp65vzpc_FtvC4xHmYedO11-0uA76ZHs=.131d752d-e95b-4af7-b472-e92edf3d41ea@github.com> Message-ID: On Wed, 6 Sep 2023 20:40:31 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 472: >> >>> 470: * >>> 471: * >>> 472: * >> >> would it be possible to sort the keys alphabetically? > > I don't think that's necessarily a good idea. I've reordered some of them, but others should be grouped. For example: it makes sense to keep the following keys together: > * `macOS.NSColor.labelColor` > * `macOS.NSColor.secondaryLabelColor` > * `macOS.NSColor.tertiaryLabelColor` > * `macOS.NSColor.quaternaryLabelColor` > > Another example: > * `macOS.NSColor.textBackgroundColor` > * `macOS.NSColor.selectedTextBackgroundColor` > > As it is, most of the keys appear in the same order as they appear in the respective platform's developer documentation. makes sense, thank you for clarification. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317813366 From mstrauss at openjdk.org Wed Sep 6 21:15:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 21:15:45 GMT Subject: RFR: 8301302: Platform preferences API [v13] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: change test class name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/c8fd0e70..1eaea48a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From kcr at openjdk.org Wed Sep 6 21:55:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 21:55:08 GMT Subject: RFR: 8301302: Platform preferences API [v13] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 21:15:45 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > change test class name I left a few comments on the API docs. I tested this on Ubuntu 16.04 Linux (yes, I know it's old). It doesn't pick up a change to the theme, but only reports the new value the next time I run the program. The serious issue is that it crashes on exit running any JavaFX program. It hangs trying to write the hs_err file, so all I have is this console error: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f0da9446b18, pid=10266, tid=10290 # # JRE version: Java(TM) SE Runtime Environment (19.0.2+7) (build 19.0.2+7-44) # Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0.2+7-44, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xc85b18] [error occurred during error reporting (printing problematic frame), id 0xb, SIGSEGV (0xb) at pc=0x00007f0da9ba8223] # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /localhome/kcr/javafx/tmp/core.10266) # # An error report file with more information is saved as: # /localhome/kcr/javafx/tmp/hs_err_pid10266.log modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 637: > 635: > 636: /** > 637: * Returns the {@link Integer} instance to which the specified key is mapped. I think you can use `@code` rather than `@link` since there is already a link generated to `Integer` in the method signature. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 648: > 646: > 647: /** > 648: * Returns the {@link Double} instance to which the specified key is mapped. Same comment here and below: I think you can use `@code` ------------- PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1614217820 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317854793 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317855515 From kcr at openjdk.org Wed Sep 6 21:55:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 21:55:12 GMT Subject: RFR: 8301302: Platform preferences API [v12] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 20:41:25 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 582: > 580: * > 581: * @return the platform appearance > 582: */ Please remove this javadoc block. Properties should only have docs on the xxxProperty method (or, for concrete classes, the private xxxx field), not on the setters and getters. This will allow javadoc to copy the information from the property, and generate cross-links. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 599: > 597: * > 598: * @return the background color > 599: */ Remove this javadoc block. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 616: > 614: * > 615: * @return the foreground color > 616: */ and this one modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 633: > 631: * > 632: * @return the accent color > 633: */ and this one ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317834094 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317834392 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317834594 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1317834690 From kcr at openjdk.org Wed Sep 6 22:49:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 22:49:45 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: References: Message-ID: <7mWAYVHXbNI3zHcklygYXf1hhCTDU8WrZBBPyuM1yr0=.b3a0bef7-3b36-4dda-a72a-255800afb9f5@github.com> On Sat, 2 Sep 2023 13:09:14 GMT, Marius Hanl wrote: >> This PR adds a test that verifies the `SkinBase.layoutChildren(..)` method with different scales. >> While not explicitly documented, this method will receive the snapped and correctly calculated x, y, width and height values, so that children of the Control can be layouted correctly without requiring to do many more calculations regarding padding. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8315569: Set a min size Reviewer: @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1229#issuecomment-1709224393 From mstrauss at openjdk.org Wed Sep 6 23:03:46 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 23:03:46 GMT Subject: RFR: 8301302: Platform preferences API [v14] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <2EfuA1AARxBetI-Z4MzQ3vv16m4qWmwxdHGwDgNW7ug=.d9923026-1903-41be-8b28-164c9b52ae99@github.com> > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Remove javadocs - Add signal handler for gtk-theme-name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/1eaea48a..aae55f99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=12-13 Stats: 58 lines in 4 files changed: 20 ins; 24 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Sep 6 23:04:14 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 6 Sep 2023 23:04:14 GMT Subject: RFR: 8301302: Platform preferences API [v13] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 6 Sep 2023 21:52:22 GMT, Kevin Rushforth wrote: > I left a few comments on the API docs. > > I tested this on Ubuntu 16.04 Linux (yes, I know it's old). It doesn't pick up a change to the theme, but only reports the new value the next time I run the program. > > The serious issue is that it crashes on exit running any JavaFX program. It hangs trying to write the hs_err file, so all I have is this console error: > ... I've changed the Javadoc comments. The crash is a bit strange, doesn't happen for me on Ubuntu 20.04. There are a few modifications on the native side in the latest commit, could you test again? If the crash persists, I need to install a Ubuntu 16.04 machine to see what's going on. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1709234625 From kcr at openjdk.org Wed Sep 6 23:38:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 23:38:48 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Sat, 29 Jul 2023 00:12:45 GMT, Andy Goryachev wrote: > Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). I have a couple comments on the javadoc and one inline comment on the test. Also, I recommend adding a basic functional test of the new methods (I know that the same could be said of the others), meaning a test with in-range values to make sure that it does a floor (or ceil) as expected. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1808: > 1806: * If this region's snapToPixel property is true, returns a value floored > 1807: * to the nearest pixel in the horizontal direction, else returns the > 1808: * same value, for any non-negative value. For negative values returns 0.0. I see this in the two new snap methods: > For negative values returns 0.0. Clamping to zero is not something any of the other snap methods do. It seems unexpected for a general purpose method such as this. If your use case really does require clamping to 0 (does it?), that should either be done by the caller, or it will need a name that implies clamping (e.g., has "clamp" or "positive" or similar in the name). So the first question to answer is whether this really needs to clamp to zero? Possibly worth noting is that this new method is similar to the existing private method `snapPortion`, but with a clamp to 0. I don't know if that might help inform the name (since it is non-public, it might not). modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1808: > 1806: * If this region's snapToPixel property is true, then the value is either floored (positive values) or > 1807: * ceiled (negative values) with a scale. When the absolute value of the given value > 1808: * multiplied by the current scale is less than 10^15, then this method guarantees that: 1. This doesn't match the descriptions of the other snap methods. All of them say "to the nearest pixel" without mentioning "the given scale" (which isn't accurate anyway, since the scale isn't "given" here). I recommend doing the same here. If we want to add something about the scale, then it should be done for all of the snap methods, and in a follow-on issue. If we do this, I would add it after the first sentence, and it would need to say that it is the "render" scale, explaining that the scale is used so that it will be rounded/floored/ceiled to the nearest screen pixel after taking scale into account. 2. None of the other snap methods specify the guarantee you are making in this method, so we shouldn't add it here. This is also something we could do in a follow-on if needed. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1815: > 1813: * larger integers with exact precision beyond this limit. > 1814: * > 1815: * @since 22 Minor: our usual pattern is to put `@since` as the last tag. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1817: > 1815: * @since 22 > 1816: * @param value The value that needs to be snapped > 1817: * @return value either as passed, or floored or ceiled with scale, based on snapToPixel property same comment here: "with scale" --> "to the nearest pixel". modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1289: > 1287: assertEquals(Double.POSITIVE_INFINITY, region.snapInnerSpaceY(Double.MAX_VALUE), 0.0); > 1288: assertEquals(Double.NEGATIVE_INFINITY, region.snapInnerSpaceX(-Double.MAX_VALUE), 0.0); > 1289: assertEquals(Double.NEGATIVE_INFINITY, region.snapInnerSpaceY(-Double.MAX_VALUE), 0.0); Why is the expected value infinity here? ------------- PR Review: https://git.openjdk.org/jfx/pull/1190#pullrequestreview-1553287860 PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1278303962 PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1317925910 PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1317910608 PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1317927611 PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1317916678 From kcr at openjdk.org Wed Sep 6 23:47:06 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 23:47:06 GMT Subject: RFR: 8301302: Platform preferences API [v14] In-Reply-To: <2EfuA1AARxBetI-Z4MzQ3vv16m4qWmwxdHGwDgNW7ug=.d9923026-1903-41be-8b28-164c9b52ae99@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <2EfuA1AARxBetI-Z4MzQ3vv16m4qWmwxdHGwDgNW7ug=.d9923026-1903-41be-8b28-164c9b52ae99@github.com> Message-ID: On Wed, 6 Sep 2023 23:03:46 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - Remove javadocs > - Add signal handler for gtk-theme-name I did a quick test, and it no longer crashes, and now reacts to the theme change. I'll look closer tomorrow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1709264180 From kcr at openjdk.org Wed Sep 6 23:50:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Sep 2023 23:50:44 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Sat, 29 Jul 2023 13:57:41 GMT, Kevin Rushforth wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1808: > >> 1806: * If this region's snapToPixel property is true, returns a value floored >> 1807: * to the nearest pixel in the horizontal direction, else returns the >> 1808: * same value, for any non-negative value. For negative values returns 0.0. > > I see this in the two new snap methods: > >> For negative values returns 0.0. > > Clamping to zero is not something any of the other snap methods do. It seems unexpected for a general purpose method such as this. If your use case really does require clamping to 0 (does it?), that should either be done by the caller, or it will need a name that implies clamping (e.g., has "clamp" or "positive" or similar in the name). > > So the first question to answer is whether this really needs to clamp to zero? > > Possibly worth noting is that this new method is similar to the existing private method `snapPortion`, but with a clamp to 0. I don't know if that might help inform the name (since it is non-public, it might not). Weird. When I submitted my review, GitHub posted this old pending comment on an outdated revision. Please ignore. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1317934040 From jhendrikx at openjdk.org Thu Sep 7 00:25:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 7 Sep 2023 00:25:48 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: > This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. > > In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. > > Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. > > The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. > > The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. > > A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. > > Although the test case above was extreme, this change should have positive effects for most applications. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Use standard asserts in test - Add copyright header ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1076/files - new: https://git.openjdk.org/jfx/pull/1076/files/7975ae99..e565f13c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=07-08 Stats: 35 lines in 2 files changed: 27 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1076.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076 PR: https://git.openjdk.org/jfx/pull/1076 From jhendrikx at openjdk.org Thu Sep 7 00:53:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 7 Sep 2023 00:53:49 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Sat, 29 Jul 2023 00:12:45 GMT, Andy Goryachev wrote: > Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). Are you sure you'll be needing these methods for solving the table column resizing issues? For dealing with space, there are already the `snapSpace` methods, which do rounding. The linked ticket does not really explain why these would be needed, just that they might be needed for a potential new algorithm that doesn't exist yet. The ticket also mentions that the table column resizing might need an algorithm that does multiple passes; I'm not sure if that's really needed -- it's tempting to write a column resizing algorithm by incrementally adjusting sizes during the resize, but that will lead to an accumulation of small errors eventually resulting in the mouse cursor no longer tracking the column edge being resized. If the algorithm were rewritten to track the initial state of all columns, then apply a calculation that takes initial state + current drag location for as long as the drag is in progress, then it becomes much more predictable and testable, ie: inputs: initial sizes: [10, 10, 10, 10] column being resized: 2 start mouse location: 20 current mouse location: 15 output (depending on the resize algorithm): sizes: [10, 5, 10, 15] When the mouse is moved again, the calculation is again done from the initial inputs, discarding anything that was calculated in the first calculation: inputs: initial sizes: [10, 10, 10, 10] column being resized: 2 start mouse location: 20 current mouse location: 25 output (depending on the resize algorithm): sizes: [10, 15, 10, 5] This will avoid errors accumulating, and moving the cursor around will give the same result column sizes as long as the drag operation is ongoing. Once the drag finishes, only then are the sizes finalized. Having a small helper class that can be easily unit tested for the various resize options may be good. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1709307950 From jdv at openjdk.org Thu Sep 7 08:05:11 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 7 Sep 2023 08:05:11 GMT Subject: [jfx-tests] RFR: 8315839: 3D shape tests fail because of invalid file path Message-ID: Currently only 18 out of 62 3D tests run properly in jfx-tests repo. All the shape tests under "test/scenegraph/fx3d/shapes" and "test/scenegraph/fx3d/subscene/shapes" fail because they are not able to find image input they need. Image files currently are at wrong place and they are moved to proper path where they are expected by these tests. This is first step for stabilizing 3D tests. Even with this change these test continue to fail because of some edge pixels are differing by minute value. Mostly we will add color tolerance to make these tests pass which will be taken up in follow-up bug. After this change we don't see "java.lang.IllegalArgumentException: Invalid URL: Invalid URL or resource not found" in these tests. ------------- Commit messages: - 8315839: 3D shape tests fail because of invalid file path Changes: https://git.openjdk.org/jfx-tests/pull/3/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=3&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315839 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx-tests/pull/3 From aghaisas at openjdk.org Thu Sep 7 09:34:09 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 7 Sep 2023 09:34:09 GMT Subject: [jfx-tests] RFR: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class Message-ID: A few SceneGraphTests and ControlsTests/chart test classes are abstract classes and serve as base classes for other tests. They are excluded from test execution and hence result in avoiding false failure reports. ------------- Commit messages: - 8315845 - exclude base class tests Changes: https://git.openjdk.org/jfx-tests/pull/4/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=4&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315845 Stats: 11 lines in 4 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx-tests/pull/4 From jdv at openjdk.org Thu Sep 7 10:23:04 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 7 Sep 2023 10:23:04 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences Message-ID: Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. These tests are used to verify 3D rendering with different parameters like translation, rotation. So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. Added 5% color tolerance and with this change 23 of these tests pass. Some sub-tests under below 3 tests continue to fail because of other reasons: [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) Also i see that some of the camera tests just draw white images, this also needs to be verified. With this change 41 out of 62 3D tests will run properly. ------------- Commit messages: - 8315842: 3D tests fail because of edge pixel differences Changes: https://git.openjdk.org/jfx-tests/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315842 Stats: 144 lines in 26 files changed: 144 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx-tests/pull/5 From angorya at openjdk.org Thu Sep 7 16:07:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 16:07:54 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: <4lid361Wy5gqJB2Bt8ysKjDQ9rZ9PzEI8kqGWngTEzQ=.c245ed19-7da6-4d74-93ab-5325056be95f@github.com> On Wed, 6 Sep 2023 23:10:11 GMT, Kevin Rushforth wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1289: > >> 1287: assertEquals(Double.POSITIVE_INFINITY, region.snapInnerSpaceY(Double.MAX_VALUE), 0.0); >> 1288: assertEquals(Double.NEGATIVE_INFINITY, region.snapInnerSpaceX(-Double.MAX_VALUE), 0.0); >> 1289: assertEquals(Double.NEGATIVE_INFINITY, region.snapInnerSpaceY(-Double.MAX_VALUE), 0.0); > > Why is the expected value infinity here? Good question! ScaledMath.floor() goes through Math.floor(d + Math.ulp(d)) / scale; which results in a value greater than Double.MAX_VALUE for positive input. Similarly, the negative input goes through Math.ceil(d - Math.ulp(d)) / scale; and the result is less than -Double.MAX_VALUE, so negative infinity. It's not really important because all these are way beyond the values acceptable as coordinates. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1318828360 From angorya at openjdk.org Thu Sep 7 16:18:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 16:18:51 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 23:29:35 GMT, Kevin Rushforth wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1808: > >> 1806: * If this region's snapToPixel property is true, then the value is either floored (positive values) or >> 1807: * ceiled (negative values) with a scale. When the absolute value of the given value >> 1808: * multiplied by the current scale is less than 10^15, then this method guarantees that: > > 1. This doesn't match the descriptions of the other snap methods. All of them say "to the nearest pixel" without mentioning "the given scale" (which isn't accurate anyway, since the scale isn't "given" here). I recommend doing the same here. If we want to add something about the scale, then it should be done for all of the snap methods, and in a follow-on issue. If we do this, I would add it after the first sentence, and it would need to say that it is the "render" scale, explaining that the scale is used so that it will be rounded/floored/ceiled to the nearest screen pixel after taking scale into account. > > 2. None of the other snap methods specify the guarantee you are making in this method, so we shouldn't add it here. This is also something we could do in a follow-on if needed. the javadoc was lifted almost verbatim from snapPortionX/Y (I did not find the words "given scale" though). Changing to be the same as snapSizeX/Y, although, technically speaking, that description is not correct either: the value in both sets of methods is ceiled/floored for positive values and floored/ceiled for negative values. We might reword both cases saying something like "rounded to the nearest pixel with larger/smaller value" which will capture the behavior exactly. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1318847823 From angorya at openjdk.org Thu Sep 7 16:27:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 16:27:54 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 00:51:11 GMT, John Hendrikx wrote: > Are you sure you'll be needing these methods for solving the table column resizing issues? Se here is the rules the way I see it: - For snapping the **min** constraint, we should be using snapSize, since the expected result should be the same or larger so as not to violate the constraint. - For snapping the **max** constraint, we should be using snapInnerSpace, since the expected result should be the same or smaller so as not to violate the constraint. - When both **min** and **max** constraints are set, we must pick the one than makes sense, typically the **min** one, and use the method corresponding to that. In the context of layouts, we should not have a situation when we lay out an inner Region and it goes beyond the boundaries of the enclosing container by one pixel, right? That's the rationale for having snapInnerSpace(). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1710449570 From kcr at openjdk.org Thu Sep 7 16:31:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 16:31:58 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:16:06 GMT, Andy Goryachev wrote: > the javadoc was lifted almost verbatim from snapPortionX/Y (I did not find the words "given scale" though). That's an internal method, not API docs. > Changing to be the same as snapSizeX/Y, although, technically speaking, that description is not correct either: the value in both sets of methods is ceiled/floored for positive values and floored/ceiled for negative values. Interesting. But I didn't mean to copy the entire thing, just the "to the nearest pixel" part (and don't say anything about scale, since we don't anywhere else). As for the fact that snapSize doesn't say anything about what it does for negative values, that should be fixed in a follow-on bug. > We might reword both cases saying something like "rounded to the nearest pixel with larger/smaller value" which will capture the behavior exactly. What do you think? I wouldn't use the word "rounded" for a floor or ceiling operation, since it will be too confusing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1190#discussion_r1318859766 From angorya at openjdk.org Thu Sep 7 16:41:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 16:41:23 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() [v2] In-Reply-To: References: Message-ID: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> > Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). 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 eight additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner - tests - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner - javadoc - snap portion - cleanup - 8311527: snap inner space ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1190/files - new: https://git.openjdk.org/jfx/pull/1190/files/ee0967f3..790325dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1190&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1190&range=00-01 Stats: 549 lines in 31 files changed: 448 ins; 48 del; 53 mod Patch: https://git.openjdk.org/jfx/pull/1190.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1190/head:pull/1190 PR: https://git.openjdk.org/jfx/pull/1190 From angorya at openjdk.org Thu Sep 7 18:46:09 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 18:46:09 GMT Subject: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale Message-ID: Snapping introduces differences between computed values and snapped values, so we need to use non-zero tolerance when checking for equality. The maximum tolerance is (1 / scale) - one display pixel scaled back to the local coordinates. The tests have been modified to use the scale-specific tolerance. Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). ------------- Commit messages: - tree table view - works - tolerance Changes: https://git.openjdk.org/jfx/pull/1234/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305709 Stats: 85 lines in 3 files changed: 37 ins; 11 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/1234.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1234/head:pull/1234 PR: https://git.openjdk.org/jfx/pull/1234 From kcr at openjdk.org Thu Sep 7 22:01:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 22:01:58 GMT Subject: RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 Message-ID: Fix icu to compile with the latest VS 2022 compilers. Note that this fix is already present in the upstream ICU repo. See unicode-org/icu at c7e967c456ceff6436607ca2a3da034320ca34c3 I've built this using the current compilers on all three platforms, and on Windows using VS 2022 17.6.5. ------------- Commit messages: - 8315870: icu fails to compile with Visual Studio 2022 17.6.5 Changes: https://git.openjdk.org/jfx/pull/1235/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315870 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1235.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1235/head:pull/1235 PR: https://git.openjdk.org/jfx/pull/1235 From kcr at openjdk.org Thu Sep 7 22:01:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 22:01:59 GMT Subject: RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: References: Message-ID: <1WwruoeIEBUVZcu6fo6jd1NIFF1FV_uhQXzWXnuk0KQ=.cb035117-68b6-4962-97bd-a019e254fc20@github.com> On Thu, 7 Sep 2023 21:55:31 GMT, Kevin Rushforth wrote: > Fix icu to compile with the latest VS 2022 compilers. Note that this fix is already present in the upstream ICU repo. See unicode-org/icu at c7e967c456ceff6436607ca2a3da034320ca34c3 > > I've built this using the current compilers on all three platforms, and on Windows using VS 2022 17.6.5. Reviewers: @arapte @jaybhaskar @tiainen @johanvos Did you also want to do a test build on your end (I can't imagine it would cause a problem, but wanted to give you a chance to comment). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1235#issuecomment-1710817669 From kcr at openjdk.org Thu Sep 7 22:09:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 22:09:44 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: <2vnOA9t454fkS0E29os8mAE5rfeHVcU0N63k3-oz_uY=.3fd344b7-4aaa-42a7-a52c-118cefe7c6c6@github.com> On Thu, 7 Sep 2023 00:51:11 GMT, John Hendrikx wrote: > Are you sure you'll be needing these methods for solving the table column resizing issues? For dealing with space, there are already the snapSpace methods, which do rounding. That's a good point. These methods might or might not be needed in layout or to address table column resizing, so until we know for sure that they are needed, and are generally useful in other cases, we don't need to add them to the public API. It seems best to move this PR to Draft until we are sure we need it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1710824974 From angorya at openjdk.org Thu Sep 7 22:19:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 22:19:45 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() [v2] In-Reply-To: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> References: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> Message-ID: On Thu, 7 Sep 2023 16:41:23 GMT, Andy Goryachev wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > 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 eight additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - tests > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - javadoc > - snap portion > - cleanup > - 8311527: snap inner space I see at least two use cases: 1. When laying out an unsnapped container which contains snapped children. In order to get the available (snapped) space, we'd need to floor the unsnapped size. 2. When laying out a complex constraint layout, such as a variant of TableLayout (see for example https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md ), where there might exist external constraints on one or more columns and/or rows, there might be a need to snap the constraint value. How it needs to be snapped depends on the actual constraint, for example when we have a **maximum width** constraint in an otherwise unconstrained situation, we need snapInnerSpace(). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1710832371 From angorya at openjdk.org Thu Sep 7 22:23:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 22:23:45 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: References: Message-ID: On Sat, 2 Sep 2023 13:09:14 GMT, Marius Hanl wrote: >> This PR adds a test that verifies the `SkinBase.layoutChildren(..)` method with different scales. >> While not explicitly documented, this method will receive the snapped and correctly calculated x, y, width and height values, so that children of the Control can be layouted correctly without requiring to do many more calculations regarding padding. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8315569: Set a min size modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 44: > 42: import static org.junit.jupiter.api.Assertions.assertTrue; > 43: > 44: class ControlContractTest { Do you plan to add more tests to this class? The name does not specify which contract is being tested. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 46: > 44: class ControlContractTest { > 45: > 46: private ControlStub control; Do you think it's worth to run this test against all of the existing Controls? modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 67: > 65: */ > 66: @ParameterizedTest > 67: @ValueSource(doubles = { 1.0, 1.25, 1.5, 1.75, 2.0 }) Could you please add 2.25 (I can see this one with the secondary monitor attached to my win11 box) modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 101: > 99: > 100: double expectedWidth = control.snapSizeX(control.getWidth()) - control.snappedLeftInset() - control.snappedRightInset(); > 101: assertEquals(expectedWidth, w); since we are performing floating point operations, we might accumulate small error. So this and 3 subsequent assertEquals() would need an EPSILON = 0.0000001 (an arbitrary value) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1319158123 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1319159680 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1319150932 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1319155511 From jhendrikx at openjdk.org Thu Sep 7 22:57:45 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 7 Sep 2023 22:57:45 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:24:47 GMT, Andy Goryachev wrote: > > Are you sure you'll be needing these methods for solving the table column resizing issues? > > Se here is the rules the way I see it: > > * For snapping the **min** constraint, we should be using snapSize, since the expected result should be the same or larger so as not to violate the constraint. > * For snapping the **max** constraint, we should be using snapInnerSpace, since the expected result should be the same or smaller so as not to violate the constraint. Are we going to be changing this, as that's not what current containers are doing? All calculations (min/pref/max) use the same function. That's probably a good idea as otherwise `min >= max` won't hold anymore if you use two different roundings. I see very little problem in exceeding max in order to do snapping. Snapping by definition has the leeway to slightly alter the constraints to align to pixels. > In the context of layouts, we should not have a situation when we lay out an inner Region and it goes beyond the boundaries of the enclosing container by one pixel, right? That's the rationale for having snapInnerSpace(). The off-by-one-pixel problem we've been seeing does not have its cause in using the wrong rounding AFAIK. It's because of accumulating errors in the float calculations that are not correctly handled. The problem also occurs when containers have not reached their maximum size, so it does not have its cause in the max size specified (often max size for resizable containers is `Double.MAX_VALUE` or infinity anyway). There's also a good chance that if you change the rounding without dealing with the accumulating errors, you'll just have the opposite problem (instead of the child being one pixel too big, it sometimes will be one pixel too small). > I see at least two use cases: > > 1. When laying out an unsnapped container which contains snapped children. In order to get the available (snapped) space, we'd need to floor the unsnapped size. I don't think we will want to start using different snap functions depending on the snapped status of the parent. Snapping doesn't work when any parent is unsnapped, as the snapping occurs relative to the parent. This was brought up before, and it's practically impossible to snap to nearest pixels when contained in an unsnapped parent (you also may not want to, because if the parent is animated this attempting to resnap a child will become visible as a weird jitter effect). There are also problems that when a parent has its start and end point not aligned to pixels, you can't actually render the child correctly without either foregoing some snapping (at the borders, which will impact the inner borders and margins in turn), or misaligning the child's borders with the parent ones (which can show artifacts like a thin line of the parent's background showing through). > 2. When laying out a complex constraint layout, such as a variant of TableLayout (see for example https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md ), where there might exist external constraints on one or more columns and/or rows, there might be a need to snap the constraint value. How it needs to be snapped depends on the actual constraint, for example when we have a **maximum width** constraint in an otherwise unconstrained situation, we need snapInnerSpace(). See above, I think min/pref/max should use the same roundings, and there is no need to strictly adhere to "min" or "max" when snapping is enabled -- snapping is allowed to ignore these values to align to the nearest pixel -- the docs can be made to mention this: `When snapping is enabled, positions, spacings and sizes may be violated up to a maximum of one pixel to ensure alignment to pixel boundaries` -- or you could be even more specific and mention that it is half a pixel up or down for spacings, up to one pixel more for sizes, etc... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1710860028 From kcr at openjdk.org Thu Sep 7 22:57:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 22:57:46 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 22:52:46 GMT, John Hendrikx wrote: > I see at least two use cases: > > 1. When laying out an unsnapped container which contains snapped children. In order to get the available (snapped) space, we'd need to floor the unsnapped size. Even if this is a valid use case (which I'm not sure it is), I don't see that we should do anything different based on whether ot not the parent is snapped. So this doesn't motivate the need for this method. > 2. When laying out a complex constraint layout, such as a variant of TableLayout (see for example https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md ), where there might exist external constraints on one or more columns and/or rows, there might be a need to snap the constraint value. How it needs to be snapped depends on the actual constraint, for example when we have a **maximum width** constraint in an otherwise unconstrained situation, we need snapInnerSpace(). Yes, if there is a complex case of layout that needs this, then it would be a good argument for adding this method. What I would want to see first, though, is an actual use case -- not a theoretical one -- that needs this method, and uses it in a way that shows it to be a generally useful method to add to the API. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1710862459 From kcr at openjdk.org Thu Sep 7 23:16:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 23:16:48 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v5] In-Reply-To: References: Message-ID: <3QadleQf_oZJhCjgkKdAuSiXUIWOeKwtWagWEAE2YCw=.80552538-14be-436c-8325-9743125b7be2@github.com> On Tue, 22 Aug 2023 15:34:17 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments The fix looks good. So does the test with a couple comments. I also noted a couple potential follow-up items. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 95: > 93: * > 94: * Currently uses a list of classes, so any new Controls must be added manually. > 95: * Perhaps the test should scan classpath and find all the Controls automagically. Minor: "classpath" --> "modulepath" More interesting question: Should we do this in other modules (e.g., javafx.graphics), too? If so, that would be for a follow-up issue. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 103: > 101: // list all descendants of Control class. > 102: // or perhaps collect all classes in a package as described here: > 103: // https://stackoverflow.com/questions/28678026/how-can-i-get-all-class-files-in-a-specific-package-in-java Please remove the reference to stackoverflow. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 212: > 210: private void checkModifiers(Method m) { > 211: int mod = m.getModifiers(); > 212: if (Modifier.isPublic(mod) && !Modifier.isFinal(mod)) { Should we also check `protected` methods? If so, that would be something for a follow-up issue. ------------- PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1616319317 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319172554 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319177546 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319181683 From kcr at openjdk.org Thu Sep 7 23:16:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Sep 2023 23:16:50 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v4] In-Reply-To: References: <1KzsYXUPmwJuMYEglMgpYuUczLtx8i9ldRSFbLfv4zM=.7a88941b-1d21-4812-aadb-957aecb6edb4@github.com> Message-ID: On Tue, 22 Aug 2023 15:15:29 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 172: >> >>> 170: @Test >>> 171: public void testMissingFinalMethods() { >>> 172: for (Class c: allControlClasses()) { >> >> I think we use a space before `:`. Don't know if it's being enforced. If you change it there are 2 more places. > > Adding superfluous spaces increases our carbon footprint ;-) > Modified the formatter to increase the footprint. The space before `:` is still missing here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319179201 From angorya at openjdk.org Thu Sep 7 23:32:15 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 23:32:15 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v6] In-Reply-To: References: Message-ID: <8SHzV8ZsFT8k7w6IEcoCVZ9GwtfNt0-dilYu27ZB9kY=.6dcef0dc-bf30-49a8-96a7-899bc578198e@github.com> > In the Control hierarchy, all property accessor methods must be declared `final`. > > Added a test to check for missing `final` keyword and added the said keyword where required. 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 10 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8313651.final - review comments - review comments - review comments - review comments - Merge remote-tracking branch 'origin/master' into 8313651.final - review comments - whitespace - added final keyword - test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1213/files - new: https://git.openjdk.org/jfx/pull/1213/files/38a4ba54..76b1283f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=04-05 Stats: 174 lines in 15 files changed: 139 ins; 21 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1213.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1213/head:pull/1213 PR: https://git.openjdk.org/jfx/pull/1213 From angorya at openjdk.org Thu Sep 7 23:32:16 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Sep 2023 23:32:16 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v5] In-Reply-To: <3QadleQf_oZJhCjgkKdAuSiXUIWOeKwtWagWEAE2YCw=.80552538-14be-436c-8325-9743125b7be2@github.com> References: <3QadleQf_oZJhCjgkKdAuSiXUIWOeKwtWagWEAE2YCw=.80552538-14be-436c-8325-9743125b7be2@github.com> Message-ID: On Thu, 7 Sep 2023 22:42:57 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 212: > >> 210: private void checkModifiers(Method m) { >> 211: int mod = m.getModifiers(); >> 212: if (Modifier.isPublic(mod) && !Modifier.isFinal(mod)) { > > Should we also check `protected` methods? If so, that would be something for a follow-up issue. easy enough to add, and makes sense. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319205285 From nlisker at gmail.com Fri Sep 8 01:06:38 2023 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 8 Sep 2023 04:06:38 +0300 Subject: JavaFX object traits In-Reply-To: References: Message-ID: I do something very similar in my own projects where I "decompose" my entities into such interfaces. I find it beneficial. We do need to figure out which makes sense and for what purpose. On Wed, Sep 6, 2023, 22:41 Andy Goryachev wrote: > I think this proposal makes a lot of sense. > > > > Having the trait interfaces inner classes of Trait clearly narrows down > semantics. "Trait" might be too generic, maybe FxTrait or something like > that? Just a thought. > > > > What other traits/properties should we include? > > > > Converting https://github.com/openjdk/jfx/pull/1215 to draft until this > discussion comes to a resolution. > > > > -andy > > > > > > *From: *openjfx-dev on behalf of Michael > Strau? > *Date: *Saturday, September 2, 2023 at 15:09 > *To: *openjfx-dev > *Subject: *JavaFX object traits > > There's a proposal to add a common interface that identifies JavaFX > objects that can hold an Observable property map: > https://github.com/openjdk/jfx/pull/1215 > > The reason for this is obvious: allow JavaFX objects that can hold > properties to be consumed by code without depending on brittle > `instanceof` checks. The problem is real, but I think we can do much > better than that. > > Why have a common interface at all? Well, of course it allows > consumers to treat different objects in a uniform way. But there's > more to it: the interface specifies the _meaning_ of the method; it > guarantees that `Foo::getProperties` and `Bar::getProperties` are, in > fact, not only methods with the same name, but the same semantics. > > `getProperties` and `hasProperties` is one example of such commonality > between dissimilar classes like `Node` and `MenuItem`. But I've come > across other examples in my own projects. For example, I'd like to > consume JavaFX objects that have the `visible` and `disable` > properties. Other applications will have different use cases, but > since we don't know all possible use cases, it's hard to come up with > a set of useful combinations of properties and methods. > > However, I think we can use the Java type system to allow applications > to compose types that fit their unique use case. > > We begin by identifying common properties, and create trait interfaces > that describe those properties: > > public final class javafx.scene.Trait { > public interface Visible { > BooleanProperty visibleProperty() > default boolean isVisible()... > default void setVisible(boolean value)... > } > public interface Disable { > BooleanProperty disableProperty() > default boolean isDisable()... > default void setDisable(boolean value)... > } > public interface Properties { > ObservableMap getProperties() > default boolean hasProperties()... > } > ... > } > > These interfaces can now be implemented by all relevant JavaFX > classes. This includes `Node`, `MenuItem`, and `Tab`, but applications > are free to implement these trait interfaces themselves. > > Applications can now consume objects that implement any combination of > traits, which gives applications the much-needed flexibility to use > shared code for all kinds of JavaFX objects: > > > void doSomething(T node) { > node.getProperties().put("foo", "bar"); > node.setVisible(true); > } > > > void doAnotherThing(T node) { > node.setText("hello"); > node.setGraphic(myGraphic); > } > > What do you think? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Fri Sep 8 04:36:30 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 8 Sep 2023 06:36:30 +0200 Subject: JavaFX object traits In-Reply-To: References: Message-ID: So far, I've identified these interfaces for the javafx.graphics module: Visible: Node, MenuItem, TableColumnBase Disable: Node, MenuItem, Tab Disabled: Node, Tab (should MenuItem also have a "disabled" property? it doesn't currently) Properties: Window, Scene, Node, MenuItem, Tab, Toggle, ToggleGroup, TableColumnBase UserData: Window, Scene, Node, MenuItem, Tab, Toggle, ToggleGroup, TableColumnBase Visible, Disable, and Disabled are useful because it allows reading and managing some basic visual state of UI components. Properties and UserData provide a common interface for objects that can store arbitrary data. Here are some interfaces that I would find questionable for the javafx.graphics module: Title: Stage, DirectoryChooser, FileChooser Text: javafx.scene.text.Text, TextInputControl, Labeled, Tab, MenuItem, TableColumnBase, Tooltip, Legend Note: the "Text" interface might also belong to javafx.controls, but then javafx.scene.text.Text couldn't implement it. On Fri, Sep 8, 2023 at 3:07?AM Nir Lisker wrote: > > I do something very similar in my own projects where I "decompose" my entities into such interfaces. I find it beneficial. > > We do need to figure out which makes sense and for what purpose. > > On Wed, Sep 6, 2023, 22:41 Andy Goryachev wrote: >> >> I think this proposal makes a lot of sense. >> >> >> >> Having the trait interfaces inner classes of Trait clearly narrows down semantics. "Trait" might be too generic, maybe FxTrait or something like that? Just a thought. >> >> >> >> What other traits/properties should we include? >> >> >> >> Converting https://github.com/openjdk/jfx/pull/1215 to draft until this discussion comes to a resolution. >> >> >> >> -andy >> >> >> >> >> >> From: openjfx-dev on behalf of Michael Strau? >> Date: Saturday, September 2, 2023 at 15:09 >> To: openjfx-dev >> Subject: JavaFX object traits >> >> There's a proposal to add a common interface that identifies JavaFX >> objects that can hold an Observable property map: >> https://github.com/openjdk/jfx/pull/1215 >> >> The reason for this is obvious: allow JavaFX objects that can hold >> properties to be consumed by code without depending on brittle >> `instanceof` checks. The problem is real, but I think we can do much >> better than that. >> >> Why have a common interface at all? Well, of course it allows >> consumers to treat different objects in a uniform way. But there's >> more to it: the interface specifies the _meaning_ of the method; it >> guarantees that `Foo::getProperties` and `Bar::getProperties` are, in >> fact, not only methods with the same name, but the same semantics. >> >> `getProperties` and `hasProperties` is one example of such commonality >> between dissimilar classes like `Node` and `MenuItem`. But I've come >> across other examples in my own projects. For example, I'd like to >> consume JavaFX objects that have the `visible` and `disable` >> properties. Other applications will have different use cases, but >> since we don't know all possible use cases, it's hard to come up with >> a set of useful combinations of properties and methods. >> >> However, I think we can use the Java type system to allow applications >> to compose types that fit their unique use case. >> >> We begin by identifying common properties, and create trait interfaces >> that describe those properties: >> >> public final class javafx.scene.Trait { >> public interface Visible { >> BooleanProperty visibleProperty() >> default boolean isVisible()... >> default void setVisible(boolean value)... >> } >> public interface Disable { >> BooleanProperty disableProperty() >> default boolean isDisable()... >> default void setDisable(boolean value)... >> } >> public interface Properties { >> ObservableMap getProperties() >> default boolean hasProperties()... >> } >> ... >> } >> >> These interfaces can now be implemented by all relevant JavaFX >> classes. This includes `Node`, `MenuItem`, and `Tab`, but applications >> are free to implement these trait interfaces themselves. >> >> Applications can now consume objects that implement any combination of >> traits, which gives applications the much-needed flexibility to use >> shared code for all kinds of JavaFX objects: >> >> >> void doSomething(T node) { >> node.getProperties().put("foo", "bar"); >> node.setVisible(true); >> } >> >> >> void doAnotherThing(T node) { >> node.setText("hello"); >> node.setGraphic(myGraphic); >> } >> >> What do you think? From mstrauss at openjdk.org Fri Sep 8 05:17:43 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Sep 2023 05:17:43 GMT Subject: RFR: 8301302: Platform preferences API [v15] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Handle key removals ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/aae55f99..cb817623 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=13-14 Stats: 35 lines in 2 files changed: 32 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Fri Sep 8 05:20:09 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Sep 2023 05:20:09 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> Message-ID: <8sypFqCQ51Gbc8RmTXebCnCD2_OBMJ2x5j-yNto6yRw=.88190627-9b1d-47bc-aa0d-71b5624f7ce8@github.com> On Tue, 5 Sep 2023 23:27:51 GMT, Michael Strau? wrote: >> is it actually possible to have keys removed at runtime? > > The set of preferences that is reported by a platform is hard-coded in the native platform implementation, and depends on the operating system version. It might indeed be the case that an OS upgrade/downgrade could result in a different set of reported properties, but can this happen while a JavaFX applications remains running? > > In any case, even if that were to happen, the current behavior is that a preference that was once reported will not be removed. Looks like I spoke too soon. Mappings can actually be removed at runtime, one such example is `Windows.SPI.HighContrastColorScheme`, which is only available if `Windows.SPI.HighContrast` is `true`. This doesn't change the `ChangedValue` implementation, and there are tests that cover the key removal scenario. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1319364873 From arapte at openjdk.org Fri Sep 8 06:04:48 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 8 Sep 2023 06:04:48 GMT Subject: RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 21:55:31 GMT, Kevin Rushforth wrote: > Fix icu to compile with the latest VS 2022 compilers. Note that this fix is already present in the upstream ICU repo. See unicode-org/icu at c7e967c456ceff6436607ca2a3da034320ca34c3 > > I've built this using the current compilers on all three platforms, and on Windows using VS 2022 17.6.5. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1235#pullrequestreview-1616736484 From psadhukhan at openjdk.org Fri Sep 8 06:09:45 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 8 Sep 2023 06:09:45 GMT Subject: RFR: 8315317: Add test for JDK-8262518 [v2] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:31:49 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Better failure detection > > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeContentMemoryLeakTest.java line 116: > >> 114: System.out.println("iteration " + count + " Panels in memory: " >> 115: + panelCount + " fail " + fail); >> 116: assertFalse(fail > 2); > > I actually seen the number to shoot up to 38 (albeit with Thread.sleep(1)). I wonder if there is a better way to detect failure? May be the fact that the 'panelCount` is ever increasing is the sign of failure, whereas if at least one time it's dropping we have succeeded. > Or perhaps look at the count when the test complete and fail if panelCount < (attempts / 2) or something Any more comments on this test fix after updation @andy-goryachev-oracle ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1228#discussion_r1319403741 From kpk at openjdk.org Fri Sep 8 07:09:47 2023 From: kpk at openjdk.org (Karthik P K) Date: Fri, 8 Sep 2023 07:09:47 GMT Subject: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:26:50 GMT, Andy Goryachev wrote: > Snapping introduces differences between computed values and snapped values, so we need to use non-zero tolerance when checking for equality. The maximum tolerance is (1 / scale) - one display pixel scaled back to the local coordinates. > > The tests have been modified to use the scale-specific tolerance. > > Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). Tested the changes in MacOS and Windows at different scales. Tests execute without error in all the cases. Added minor comment inline. tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewResizeColumnToFitContentTest.java line 69: > 67: @Test > 68: public void resizeColumnToFitContentTest() { > 69: double wid0 = table.getColumns().get(0).getWidth(); The variable names are changed to make L75 and L77 single line? the previous name was easy to understand in my opinion. tests/system/src/test/java/test/robot/javafx/scene/treetableview/TreeTableViewResizeColumnToFitContentTest.java line 70: > 68: @Test > 69: public void resizeColumnToFitContentTest() { > 70: double wid0 = treeTableView.getColumns().get(0).getWidth(); Same as the comment in previous file. The variable names are changed to make L76 and L78 single line? the previous name was easy to understand in my opinion. ------------- PR Review: https://git.openjdk.org/jfx/pull/1234#pullrequestreview-1616784990 PR Review Comment: https://git.openjdk.org/jfx/pull/1234#discussion_r1319430653 PR Review Comment: https://git.openjdk.org/jfx/pull/1234#discussion_r1319435705 From jdv at openjdk.org Fri Sep 8 07:14:01 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 8 Sep 2023 07:14:01 GMT Subject: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values Message-ID: Two perspective lod tests fail because of minute differences in expected values. Failing tests: test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: Exception: test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:833) These little difference in values are seen both initial drawing and updates. These tests are not run from long time and change in product might change lod values. With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1). ------------- Commit messages: - 8315896: Perspective lod tests fail because of minute difference in values Changes: https://git.openjdk.org/jfx-tests/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315896 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx-tests/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx-tests/pull/6 From jdv at openjdk.org Fri Sep 8 07:15:47 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 8 Sep 2023 07:15:47 GMT Subject: [jfx-tests] RFR: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 09:26:59 GMT, Ajit Ghaisas wrote: > A few SceneGraphTests and ControlsTests/chart test classes are abstract classes and serve as base classes for other tests. > They are excluded from test execution and hence result in avoiding false failure reports. LGTM. I think in 3D tests also we have similar problem. When i run sub-folders it runs some files which i think should not be run in standlone mode and they throw `java.lang.InstantiationException` ------------- Marked as reviewed by jdv (Author). PR Review: https://git.openjdk.org/jfx-tests/pull/4#pullrequestreview-1616835565 From arapte at openjdk.org Fri Sep 8 07:27:46 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 8 Sep 2023 07:27:46 GMT Subject: [jfx-tests] RFR: 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 18:22:38 GMT, Kevin Rushforth wrote: > As mentioned in the JBS Description, I generated this PR by running the same copyright tool we use to update the jfx repo, with a slight modification to not filter out those files that already had "Copyright.*2023", since those are the ones that need to be fixed up for incorrect formatting. > > I manually reverted two files that had an embedded copyright line in a String. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/2#pullrequestreview-1616854140 From john.hendrikx at gmail.com Fri Sep 8 09:30:49 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 8 Sep 2023 11:30:49 +0200 Subject: JavaFX object traits In-Reply-To: References: Message-ID: <31da753c-699c-244b-9ccd-4319608822f1@gmail.com> I think the interfaces may expose things that have been developed independently with different names but are the same thing. For example, Window has the `showing` property, but effectively it works similar to `visible`.? The split between `Disable` and `Disabled` should be removed IMHO by making `MenuItem` implement `disabled` -- in other words, don't introduce two interfaces where one is desired. The same goes for Properties and UserData; these serve a similar purpose and should IMHO be one interface. Most of the names violate the "is-a" rule for interface naming, which will make code using it akward to read.? A suffic `Accessor` works pretty well, but for some there are perhaps nicer solutions; suggestions on that front: ??? Disable/Disabled -> Disableable (dictionary: capable of being disabled) ??? Properties/UserData -> UserPropertyAccessor ??? Title -> Titled ??? Text -> there's actually `Labeled` for that already, although done differently ??? Visible -> tough one... Visualizable, Showable, VisibleAccessor --John On 08/09/2023 06:36, Michael Strau? wrote: > So far, I've identified these interfaces for the javafx.graphics module: > > Visible: > Node, MenuItem, TableColumnBase > > Disable: > Node, MenuItem, Tab > > Disabled: > Node, Tab > (should MenuItem also have a "disabled" property? it doesn't currently) > > Properties: > Window, Scene, Node, MenuItem, Tab, Toggle, ToggleGroup, TableColumnBase > > UserData: > Window, Scene, Node, MenuItem, Tab, Toggle, ToggleGroup, TableColumnBase > > Visible, Disable, and Disabled are useful because it allows reading > and managing some basic visual state of UI components. > Properties and UserData provide a common interface for objects that > can store arbitrary data. > > Here are some interfaces that I would find questionable for the > javafx.graphics module: > > Title: > Stage, DirectoryChooser, FileChooser > > Text: > javafx.scene.text.Text, TextInputControl, Labeled, Tab, MenuItem, > TableColumnBase, Tooltip, Legend > > Note: the "Text" interface might also belong to javafx.controls, but > then javafx.scene.text.Text couldn't implement it. > > > On Fri, Sep 8, 2023 at 3:07?AM Nir Lisker wrote: >> I do something very similar in my own projects where I "decompose" my entities into such interfaces. I find it beneficial. >> >> We do need to figure out which makes sense and for what purpose. >> >> On Wed, Sep 6, 2023, 22:41 Andy Goryachev wrote: >>> I think this proposal makes a lot of sense. >>> >>> >>> >>> Having the trait interfaces inner classes of Trait clearly narrows down semantics. "Trait" might be too generic, maybe FxTrait or something like that? Just a thought. >>> >>> >>> >>> What other traits/properties should we include? >>> >>> >>> >>> Converting https://github.com/openjdk/jfx/pull/1215 to draft until this discussion comes to a resolution. >>> >>> >>> >>> -andy >>> >>> >>> >>> >>> >>> From: openjfx-dev on behalf of Michael Strau? >>> Date: Saturday, September 2, 2023 at 15:09 >>> To: openjfx-dev >>> Subject: JavaFX object traits >>> >>> There's a proposal to add a common interface that identifies JavaFX >>> objects that can hold an Observable property map: >>> https://github.com/openjdk/jfx/pull/1215 >>> >>> The reason for this is obvious: allow JavaFX objects that can hold >>> properties to be consumed by code without depending on brittle >>> `instanceof` checks. The problem is real, but I think we can do much >>> better than that. >>> >>> Why have a common interface at all? Well, of course it allows >>> consumers to treat different objects in a uniform way. But there's >>> more to it: the interface specifies the _meaning_ of the method; it >>> guarantees that `Foo::getProperties` and `Bar::getProperties` are, in >>> fact, not only methods with the same name, but the same semantics. >>> >>> `getProperties` and `hasProperties` is one example of such commonality >>> between dissimilar classes like `Node` and `MenuItem`. But I've come >>> across other examples in my own projects. For example, I'd like to >>> consume JavaFX objects that have the `visible` and `disable` >>> properties. Other applications will have different use cases, but >>> since we don't know all possible use cases, it's hard to come up with >>> a set of useful combinations of properties and methods. >>> >>> However, I think we can use the Java type system to allow applications >>> to compose types that fit their unique use case. >>> >>> We begin by identifying common properties, and create trait interfaces >>> that describe those properties: >>> >>> public final class javafx.scene.Trait { >>> public interface Visible { >>> BooleanProperty visibleProperty() >>> default boolean isVisible()... >>> default void setVisible(boolean value)... >>> } >>> public interface Disable { >>> BooleanProperty disableProperty() >>> default boolean isDisable()... >>> default void setDisable(boolean value)... >>> } >>> public interface Properties { >>> ObservableMap getProperties() >>> default boolean hasProperties()... >>> } >>> ... >>> } >>> >>> These interfaces can now be implemented by all relevant JavaFX >>> classes. This includes `Node`, `MenuItem`, and `Tab`, but applications >>> are free to implement these trait interfaces themselves. >>> >>> Applications can now consume objects that implement any combination of >>> traits, which gives applications the much-needed flexibility to use >>> shared code for all kinds of JavaFX objects: >>> >>> >>> void doSomething(T node) { >>> node.getProperties().put("foo", "bar"); >>> node.setVisible(true); >>> } >>> >>> >>> void doAnotherThing(T node) { >>> node.setText("hello"); >>> node.setGraphic(myGraphic); >>> } >>> >>> What do you think? From aghaisas at openjdk.org Fri Sep 8 10:23:48 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Sep 2023 10:23:48 GMT Subject: [jfx-tests] RFR: 8315839: 3D shape tests fail because of invalid file path In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 07:58:08 GMT, Jayathirth D V wrote: > Currently only 18 out of 62 3D tests run properly in jfx-tests repo. > All the shape tests under "test/scenegraph/fx3d/shapes" and "test/scenegraph/fx3d/subscene/shapes" fail because they are not able to find image input they need. > > Image files currently are at wrong place and they are moved to proper path where they are expected by these tests. This is first step for stabilizing 3D tests. Even with this change these test continue to fail because of some edge pixels are differing by minute value. Mostly we will add color tolerance to make these tests pass which will be taken up in follow-up bug. > > After this change we don't see "java.lang.IllegalArgumentException: Invalid URL: Invalid URL or resource not found" in these tests. Marked as reviewed by aghaisas (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/3#pullrequestreview-1617156136 From aghaisas at openjdk.org Fri Sep 8 10:30:45 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Sep 2023 10:30:45 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: <1vE6hJwKRPy1pRAodRr4DXODYCY_GOFKgT_t7esyqAg=.3e4585e8-e4e3-400f-a307-d492a3e4b7b4@github.com> On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. The changes are fine and they work. One suggestion is to define a common constant for 5% of tolerance value rather than using 0.05 in each of the changed file. This will allow us to adjust the tolerance percentage more easily in future. One possible place to define this constant is - `test.scenegraph.fx3d.utils.FX3DAbstractApp` as this class is imported in all the test cases. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1711443217 From aghaisas at openjdk.org Fri Sep 8 10:34:47 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Sep 2023 10:34:47 GMT Subject: [jfx-tests] RFR: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class In-Reply-To: References: Message-ID: <6F0COJEWIs3Qb2f7eItz8H_U3HIBqNv955TJr3HQq_A=.ea5c35d3-592a-4e90-a5b9-8b18054511ee@github.com> On Thu, 7 Sep 2023 09:26:59 GMT, Ajit Ghaisas wrote: > A few SceneGraphTests and ControlsTests/chart test classes are abstract classes and serve as base classes for other tests. > They are excluded from test execution and hence result in avoiding false failure reports. Please collate such file names and then we can exclude them as a separate fix. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/4#issuecomment-1711448111 From aghaisas at openjdk.org Fri Sep 8 11:28:57 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Sep 2023 11:28:57 GMT Subject: [jfx-tests] RFR: 8315928: Few Scenegraph and Charts tests fail due to resource not found error Message-ID: Below tests fail due to "resource not found" error. - test/scenegraph/binding/effects/IdentityTest.java - test/scenegraph/lcd/controls/tests/AccordionTest.java - Almost all ControlsTests/Chart tests Fix : Moved required resources to appropriate directory. ------------- Commit messages: - address missing resources Changes: https://git.openjdk.org/jfx-tests/pull/7/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=7&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315928 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/7.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/7/head:pull/7 PR: https://git.openjdk.org/jfx-tests/pull/7 From jdv at openjdk.org Fri Sep 8 11:33:51 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 8 Sep 2023 11:33:51 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: <1vE6hJwKRPy1pRAodRr4DXODYCY_GOFKgT_t7esyqAg=.3e4585e8-e4e3-400f-a307-d492a3e4b7b4@github.com> References: <1vE6hJwKRPy1pRAodRr4DXODYCY_GOFKgT_t7esyqAg=.3e4585e8-e4e3-400f-a307-d492a3e4b7b4@github.com> Message-ID: On Fri, 8 Sep 2023 10:27:45 GMT, Ajit Ghaisas wrote: > The changes are fine and they work. One suggestion is to define a common constant for 5% of tolerance value rather than using 0.05 in each of the changed file. This will allow us to adjust the tolerance percentage more easily in future. One possible place to define this constant is - `test.scenegraph.fx3d.utils.FX3DAbstractApp` as this class is imported in all the test cases. I added tolerance variable in `test.scenegraph.fx3d.utils.FX3DAbstractApp` but i can access the member variable only after we get its instance at the end of setUp() functions of each test. We do other things before call getInstance() and the suggestion to set tolerance was at the start of these setUp() functions. Right now i am not sure whether we can add tolerance at the end of setUp() functions and how it might change test behaviour. Its better to add the common tolerance variable in a separate fix with additional verification. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1711522136 From jdv at openjdk.org Fri Sep 8 12:05:46 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 8 Sep 2023 12:05:46 GMT Subject: [jfx-tests] Integrated: 8315839: 3D shape tests fail because of invalid file path In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 07:58:08 GMT, Jayathirth D V wrote: > Currently only 18 out of 62 3D tests run properly in jfx-tests repo. > All the shape tests under "test/scenegraph/fx3d/shapes" and "test/scenegraph/fx3d/subscene/shapes" fail because they are not able to find image input they need. > > Image files currently are at wrong place and they are moved to proper path where they are expected by these tests. This is first step for stabilizing 3D tests. Even with this change these test continue to fail because of some edge pixels are differing by minute value. Mostly we will add color tolerance to make these tests pass which will be taken up in follow-up bug. > > After this change we don't see "java.lang.IllegalArgumentException: Invalid URL: Invalid URL or resource not found" in these tests. This pull request has now been integrated. Changeset: 30c25292 Author: Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/30c252929c3f8101c6e95972a0d14bdfdc8686d6 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod 8315839: 3D shape tests fail because of invalid file path Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx-tests/pull/3 From aghaisas at openjdk.org Fri Sep 8 12:17:50 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 8 Sep 2023 12:17:50 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. A static constant can be added to `test.scenegraph.fx3d.utils.FX3DAbstractApp` public static final float COLOR_TOLERANCE = 0.05f; This can easily be accessed in test classes without FX3DAbstractApp instance as - `Root.ROOT.getEnvironment().setProperty(ImageComparator.class, new GlassPixelImageComparator(new PixelEqualityRasterComparator(FX3DAbstractApp.COLOR_TOLERANCE)));` This will allow us to tweak the tolerance value at a single place in future and not in all the 26 files. This change is pretty safe as and just a sanity check would be needed. If a test does not use FX3DAbstractApp, then you can keep the hard-coded constant. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1711576867 From jvos at openjdk.org Fri Sep 8 12:31:52 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Sep 2023 12:31:52 GMT Subject: RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 21:55:31 GMT, Kevin Rushforth wrote: > Fix icu to compile with the latest VS 2022 compilers. Note that this fix is already present in the upstream ICU repo. See unicode-org/icu at c7e967c456ceff6436607ca2a3da034320ca34c3 > > I've built this using the current compilers on all three platforms, and on Windows using VS 2022 17.6.5. Tested with the required compilers, and didn't run into problems. Didn't test with VS 2022 17.6.5 though but most important is that we don't have regression with the required compilers, hence +1 ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1235#pullrequestreview-1617380917 From kcr at openjdk.org Fri Sep 8 13:09:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 13:09:56 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v6] In-Reply-To: <8SHzV8ZsFT8k7w6IEcoCVZ9GwtfNt0-dilYu27ZB9kY=.6dcef0dc-bf30-49a8-96a7-899bc578198e@github.com> References: <8SHzV8ZsFT8k7w6IEcoCVZ9GwtfNt0-dilYu27ZB9kY=.6dcef0dc-bf30-49a8-96a7-899bc578198e@github.com> Message-ID: On Thu, 7 Sep 2023 23:32:15 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > 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 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8313651.final > - review comments > - review comments > - review comments > - review comments > - Merge remote-tracking branch 'origin/master' into 8313651.final > - review comments > - whitespace > - added final keyword > - test modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 177: > 175: > 176: private void check(Class cls) { > 177: Method[] methods = cls.getMethods(); This will only return public methods. Since you modified `checkModifiers` to check protected methods, you will need to use `getDeclaredMethods` instead. This will return protected (and package scope) methods as well as public methods. It won't return any method in a superclass, but since the set of classes you are checking includes intermediate classes (such as `ButtonBase` and `Labeled`), you will still get the coverage (and without redundantly checking the same method in those classes multiple times). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319843979 From kcr at openjdk.org Fri Sep 8 13:16:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 13:16:50 GMT Subject: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 07:07:40 GMT, Jayathirth D V wrote: > Two perspective lod tests fail because of minute differences in expected values. > > Failing tests: > test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: > test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: > > Exception: > test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure > org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds > at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) > at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) > at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.lang.Thread.run(Thread.java:833) > > These little difference in values are seen both initial drawing and updates. > These tests are not run from long time and change in product might change lod values. > > With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1). Two questions: 1. Have you run this on Windows to ensure that the D3D pipeline also passes with this change? 2. It might be better to compare using a tolerance rather than relying on an exact value being computed in floating-point arithmetic. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/6#issuecomment-1711654062 From kcr at openjdk.org Fri Sep 8 13:25:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 13:25:47 GMT Subject: RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 12:29:28 GMT, Johan Vos wrote: > Didn't test with VS 2022 17.6.5 though but most important is that we don't have regression with the required compilers... My thoughts exactly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1235#issuecomment-1711664955 From kcr at openjdk.org Fri Sep 8 13:25:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 13:25:49 GMT Subject: Integrated: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 21:55:31 GMT, Kevin Rushforth wrote: > Fix icu to compile with the latest VS 2022 compilers. Note that this fix is already present in the upstream ICU repo. See unicode-org/icu at c7e967c456ceff6436607ca2a3da034320ca34c3 > > I've built this using the current compilers on all three platforms, and on Windows using VS 2022 17.6.5. This pull request has now been integrated. Changeset: ed921717 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/ed921717b3edbf3e76a888c0ddab83dcc1d7dbe7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8315870: icu fails to compile with Visual Studio 2022 17.6.5 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1235 From angorya at openjdk.org Fri Sep 8 14:34:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 14:34:21 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: <8sypFqCQ51Gbc8RmTXebCnCD2_OBMJ2x5j-yNto6yRw=.88190627-9b1d-47bc-aa0d-71b5624f7ce8@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> <8sypFqCQ51Gbc8RmTXebCnCD2_OBMJ2x5j-yNto6yRw=.88190627-9b1d-47bc-aa0d-71b5624f7ce8@github.com> Message-ID: On Fri, 8 Sep 2023 05:16:35 GMT, Michael Strau? wrote: >> The set of preferences that is reported by a platform is hard-coded in the native platform implementation, and depends on the operating system version. It might indeed be the case that an OS upgrade/downgrade could result in a different set of reported properties, but can this happen while a JavaFX applications remains running? >> >> In any case, even if that were to happen, the current behavior is that a preference that was once reported will not be removed. > > Looks like I spoke too soon. Mappings can actually be removed at runtime, one such example is `Windows.SPI.HighContrastColorScheme`, which is only available if `Windows.SPI.HighContrast` is `true`. > > This doesn't change the `ChangedValue` implementation, and there are tests that cover the key removal scenario. if that's the case, isn't it possible to have the same key added at runtime? this scenario cannot be handled by the current code, as far as I can tell. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1319949413 From angorya at openjdk.org Fri Sep 8 14:39:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 14:39:21 GMT Subject: RFR: 8301302: Platform preferences API [v15] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Fri, 8 Sep 2023 05:17:43 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Handle key removals modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/ChangedValue.java line 69: > 67: } > 68: } > 69: I suspect the code that handles added keys should be added here somewhere. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1319956114 From angorya at openjdk.org Fri Sep 8 14:47:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 14:47:48 GMT Subject: RFR: 8315317: Add test for JDK-8262518 [v2] In-Reply-To: <-2dACKZsXPuT8vm2Zcu5_qkjXsYzv88ZugV0wgCPBTs=.f394ffe7-aea7-4036-a465-2d786b96940d@github.com> References: <-2dACKZsXPuT8vm2Zcu5_qkjXsYzv88ZugV0wgCPBTs=.f394ffe7-aea7-4036-a465-2d786b96940d@github.com> Message-ID: On Mon, 4 Sep 2023 06:34:18 GMT, Prasanta Sadhukhan wrote: >> Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Better failure detection looking good?? even with Thread.sleep(1); ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1228#pullrequestreview-1617654536 From angorya at openjdk.org Fri Sep 8 14:54:47 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 14:54:47 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v6] In-Reply-To: References: <8SHzV8ZsFT8k7w6IEcoCVZ9GwtfNt0-dilYu27ZB9kY=.6dcef0dc-bf30-49a8-96a7-899bc578198e@github.com> Message-ID: On Fri, 8 Sep 2023 13:02:31 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8313651.final >> - review comments >> - review comments >> - review comments >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8313651.final >> - review comments >> - whitespace >> - added final keyword >> - test > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 177: > >> 175: >> 176: private void check(Class cls) { >> 177: Method[] methods = cls.getMethods(); > > This will only return public methods. Since you modified `checkModifiers` to check protected methods, you will need to use `getDeclaredMethods` instead. This will return protected (and package scope) methods as well as public methods. It won't return any method in a superclass, but since the set of classes you are checking includes intermediate classes (such as `ButtonBase` and `Labeled`), you will still get the coverage (and without redundantly checking the same method in those classes multiple times). Right, what was I thinking?? And we also have Region.setWidth() which is protected and not final by design. Reverting the last change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1319975064 From angorya at openjdk.org Fri Sep 8 15:01:34 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 15:01:34 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v7] In-Reply-To: References: Message-ID: > In the Control hierarchy, all property accessor methods must be declared `final`. > > Added a test to check for missing `final` keyword and added the said keyword where required. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: only public ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1213/files - new: https://git.openjdk.org/jfx/pull/1213/files/76b1283f..65aa0895 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=05-06 Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1213.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1213/head:pull/1213 PR: https://git.openjdk.org/jfx/pull/1213 From angorya at openjdk.org Fri Sep 8 15:05:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 15:05:46 GMT Subject: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 06:38:54 GMT, Karthik P K wrote: >> Snapping introduces differences between computed values and snapped values, so we need to use non-zero tolerance when checking for equality. The maximum tolerance is (1 / scale) - one display pixel scaled back to the local coordinates. >> >> The tests have been modified to use the scale-specific tolerance. >> >> Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). > > tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewResizeColumnToFitContentTest.java line 69: > >> 67: @Test >> 68: public void resizeColumnToFitContentTest() { >> 69: double wid0 = table.getColumns().get(0).getWidth(); > > The variable names are changed to make L75 and L77 single line? the previous name was easy to understand in my opinion. yes, also I find it more readable: the wider the scope, the longer the name. this might be a personal preference. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1234#discussion_r1319987627 From angorya at openjdk.org Fri Sep 8 15:13:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 15:13:48 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() [v2] In-Reply-To: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> References: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> Message-ID: On Thu, 7 Sep 2023 16:41:23 GMT, Andy Goryachev wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > 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 eight additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - tests > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - javadoc > - snap portion > - cleanup > - 8311527: snap inner space I don't understand the comment about "theoretical use case" - the case of CPane is practical enough for me. The fact that javafx does not provide a good table layout Pane (and a GridPane is as clunky as its ancestor GridBagLayout) and we have not yet encountered the need for it is not, in my opinion, a good argument. Can this functionality be written by an app developer? Yes, so I am not that concerned. I am even ok to withdraw this PR, but I still think there is a value in providing this API as a part of the core. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1711825547 From psadhukhan at openjdk.org Fri Sep 8 15:38:51 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 8 Sep 2023 15:38:51 GMT Subject: Integrated: 8315317: Add test for JDK-8262518 In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 03:16:11 GMT, Prasanta Sadhukhan wrote: > Added automated test for 8262518:SwingNode.setContent does not close previous content, resulting in memory leak This pull request has now been integrated. Changeset: eb7de72d Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jfx/commit/eb7de72dafecbedc83c2215b6aed7432d4ec80f9 Stats: 131 lines in 1 file changed: 131 ins; 0 del; 0 mod 8315317: Add test for JDK-8262518 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1228 From nlisker at openjdk.org Fri Sep 8 15:40:49 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Sep 2023 15:40:49 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. Not sure if it's relevant, but when I wrote a 3D test with a color tolerance value it turned out to be too low on Mac (but not on Windows), as Kevin pointed out to me: https://github.com/openjdk/jfx/pull/43#discussion_r502049390. We ended up using his suggested value (10/255 =~ 0.04) because it was good enough, but it could probably be a bit lower. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1711859852 From kcr at openjdk.org Fri Sep 8 15:56:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 15:56:48 GMT Subject: RFR: 8311527: Region.snapInnerSpace*() [v2] In-Reply-To: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> References: <_F9w0beR2jyYH7sZfEXCp1qbVgbchky2Uk-y6sNS9jc=.c1f572a2-bb83-453c-a315-4d9a597a43be@github.com> Message-ID: On Thu, 7 Sep 2023 16:41:23 GMT, Andy Goryachev wrote: >> Introduces Region.snapInnerSpaceX/Y() methods for dealing with inner space (using Math.floor), see for instance [JDK-8299753](https://bugs.openjdk.org/browse/JDK-8299753), using existing methods Region.snapPortionX/Y(). > > 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 eight additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - tests > - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner > - javadoc > - snap portion > - cleanup > - 8311527: snap inner space It's theoretical, because we haven't done a thorough evaluation as to whether such a layout would actually _need_ `snapInnerSpace` to correctly do snapping. You are hypothesizing that it would, but until we have a concrete use case to evaluate and test, it's just that -- a hypothesis. So my recommendation is not to withdraw this PR, but put it into Draft until we do the work needed to show that it is generally useful. We should keep this potential need in mind when we review your "Column Resizing With Fractional Scale" fix in PR #1156 and when we pursue the general issues of layout being explored in PR #1111. I think we'll have a better idea of whether we will need this once we do that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1190#issuecomment-1711881553 From kcr at openjdk.org Fri Sep 8 15:58:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 15:58:47 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v7] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:01:34 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > only public Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1617788895 From mstrauss at openjdk.org Fri Sep 8 16:55:12 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Sep 2023 16:55:12 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> <8sypFqCQ51Gbc8RmTXebCnCD2_OBMJ2x5j-yNto6yRw=.88190627-9b1d-47bc-aa0d-71b5624f7ce8@github.com> Message-ID: On Fri, 8 Sep 2023 14:31:07 GMT, Andy Goryachev wrote: >> Looks like I spoke too soon. Mappings can actually be removed at runtime, one such example is `Windows.SPI.HighContrastColorScheme`, which is only available if `Windows.SPI.HighContrast` is `true`. >> >> This doesn't change the `ChangedValue` implementation, and there are tests that cover the key removal scenario. > > if that's the case, isn't it possible to have the same key added at runtime? this scenario cannot be handled by the current code, as far as I can tell. I'm not sure if I understand what you mean that the same key can be added at runtime. The protocol is as follows: 1. The native toolkit reports either _all_ preferences, or the _changed_ preferences (or a mixture of both). If a report includes only changed preferences, this _doesn't_ imply that unreported preferences (that were reported earlier) are removed. 2. `PlatformPreferences.update` computes the difference between the _currently known_ preferences, and the _reported_ preferences. This is what `ChangedValue.getEffectiveChanges` does. A mapping that is not included in the reported preferences doesn't mean that it was removed; if the native toolkit wants to signal removal, it needs to map the respective key to `null` instead. 3. If there are any _effective changes_ (i.e. changes where the current value is actually different from the last known value), change notifications are fired. This includes additions (where new keys are seen for the first time), as well as removals (where a known key is now mapped to `null`). This protocol gives native toolkits the option to choose how preferences are reported, some toolkits may always want to report all preferences, while other toolkits may only want to report the changed preferences. The burden of keeping track of the total set of preferences is placed on `PlatformPreferences`, not on the native toolkit. This allows us to implement the book-keeping logic in a single place, rather than in each toolkit individually. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1320119628 From mstrauss at openjdk.org Fri Sep 8 16:55:14 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 8 Sep 2023 16:55:14 GMT Subject: RFR: 8301302: Platform preferences API [v15] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Fri, 8 Sep 2023 14:36:11 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle key removals > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/ChangedValue.java line 69: > >> 67: } >> 68: } >> 69: > > I suspect the code that handles added keys should be added here somewhere. See my comment [here](https://github.com/openjdk/jfx/pull/1014#discussion_r1320119628). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1320120993 From shurailine at openjdk.org Fri Sep 8 17:10:59 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Fri, 8 Sep 2023 17:10:59 GMT Subject: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE Message-ID: There was a field in a subclass hiding a field in a superclass. ------------- Commit messages: - JDK-8315895: Some 3D camera tests fail because of NPE Changes: https://git.openjdk.org/jfx-tests/pull/8/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=8&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315895 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/8.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/8/head:pull/8 PR: https://git.openjdk.org/jfx-tests/pull/8 From shurailine at openjdk.org Fri Sep 8 17:11:00 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Fri, 8 Sep 2023 17:11:00 GMT Subject: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 17:04:56 GMT, Alexandre Iline wrote: > There was a field in a subclass hiding a field in a superclass. @jayathirthrao FYI ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/8#issuecomment-1711980230 From shurailine at openjdk.org Fri Sep 8 17:17:17 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Fri, 8 Sep 2023 17:17:17 GMT Subject: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE [v2] In-Reply-To: References: Message-ID: > There was a field in a subclass hiding a field in a superclass. Alexandre Iline has updated the pull request incrementally with two additional commits since the last revision: - Copyright. :| - Copyright year ------------- Changes: - all: https://git.openjdk.org/jfx-tests/pull/8/files - new: https://git.openjdk.org/jfx-tests/pull/8/files/63dfe8e3..b2cbaa35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=8&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=8&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx-tests/pull/8.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/8/head:pull/8 PR: https://git.openjdk.org/jfx-tests/pull/8 From kcr at openjdk.org Fri Sep 8 17:22:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 17:22:47 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v4] In-Reply-To: References: <1KzsYXUPmwJuMYEglMgpYuUczLtx8i9ldRSFbLfv4zM=.7a88941b-1d21-4812-aadb-957aecb6edb4@github.com> Message-ID: On Tue, 22 Aug 2023 09:46:28 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > Looks good. Gave a couple of minor optional suggestions. > > As to the topic of class finding, I think it's fine to use a manual list, at least for now. The complexity of automatically detecting the classes might not be worth the hassle. Leaving it up to you. @nlisker @hjohn Can you re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1213#issuecomment-1711995781 From shurailine at openjdk.org Fri Sep 8 17:38:47 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Fri, 8 Sep 2023 17:38:47 GMT Subject: [jfx-tests] RFR: 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 In-Reply-To: References: Message-ID: <-WE30yhg2r0YVsyhCcBSbqC5KaBgyO-6CO5efOKhQnY=.5630435f-892a-4705-ae30-79782eb7475c@github.com> On Wed, 6 Sep 2023 18:22:38 GMT, Kevin Rushforth wrote: > As mentioned in the JBS Description, I generated this PR by running the same copyright tool we use to update the jfx repo, with a slight modification to not filter out those files that already had "Copyright.*2023", since those are the ones that need to be fixed up for incorrect formatting. > > I manually reverted two files that had an embedded copyright line in a String. Thank you for fixing that! LGTM ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/2#issuecomment-1712013079 From kcr at openjdk.org Fri Sep 8 17:45:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 17:45:52 GMT Subject: [jfx-tests] Integrated: 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 18:22:38 GMT, Kevin Rushforth wrote: > As mentioned in the JBS Description, I generated this PR by running the same copyright tool we use to update the jfx repo, with a slight modification to not filter out those files that already had "Copyright.*2023", since those are the ones that need to be fixed up for incorrect formatting. > > I manually reverted two files that had an embedded copyright line in a String. This pull request has now been integrated. Changeset: 93ae9396 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx-tests/commit/93ae9396986ff94e929515ad185361289daa6d58 Stats: 139 lines in 139 files changed: 0 ins; 0 del; 139 mod 8315809: Fix copyright lines in jfx-tests repo after JDK-8315409 Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx-tests/pull/2 From angorya at openjdk.org Fri Sep 8 17:46:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 17:46:14 GMT Subject: RFR: 8301302: Platform preferences API [v5] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <0V4zGELX5AVvukK2Jtorg9mzoWrVopVCiTfmCRx9LPA=.56af46c6-22f1-4e8f-979f-2751cc2ae19a@github.com> <7-QZTudJmH0aRERyPin_WLIQ4qwSxa4wx6dxSa0STi8=.ea9c36cb-596a-4282-81c5-31482a1d7487@github.com> <8sypFqCQ51Gbc8RmTXebCnCD2_OBMJ2x5j-yNto6yRw=.88190627-9b1d-47bc-aa0d-71b5624f7ce8@github.com> Message-ID: On Fri, 8 Sep 2023 16:50:25 GMT, Michael Strau? wrote: >> if that's the case, isn't it possible to have the same key added at runtime? this scenario cannot be handled by the current code, as far as I can tell. > > I'm not sure if I understand what you mean that the same key can be added at runtime. The protocol is as follows: > > 1. The native toolkit reports either _all_ preferences, or the _changed_ preferences (or a mixture of both). If a report includes only changed preferences, this _doesn't_ imply that unreported preferences (that were reported earlier) are removed. > 2. `PlatformPreferences.update` computes the difference between the _currently known_ preferences, and the _reported_ preferences. This is what `ChangedValue.getEffectiveChanges` does. A mapping that is not included in the reported preferences doesn't mean that it was removed; if the native toolkit wants to signal removal, it needs to map the respective key to `null` instead. > 3. If there are any _effective changes_ (i.e. changes where the current value is actually different from the last known value), change notifications are fired. This includes additions (where new keys are seen for the first time), as well as removals (where a known key is now mapped to `null`). > > This protocol gives native toolkits the option to choose how preferences are reported, some toolkits may always want to report all preferences, while other toolkits may only want to report the changed preferences. The burden of keeping track of the total set of preferences is placed on `PlatformPreferences`, not on the native toolkit. This allows us to implement the book-keeping logic in a single place, rather than in each toolkit individually. thanks for clarification. I misunderstood your earlier comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1320166663 From nlisker at openjdk.org Fri Sep 8 18:22:48 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Sep 2023 18:22:48 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v7] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:01:34 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > only public Looks good. Added some minor comments. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 99: > 97: public class ControlPropertiesTest { > 98: > 99: private static final boolean FAIL_FAST = true; Please add a short comment on what this is for. Like "If true, an exception will be thrown on encountering the first violating class, otherwise a list of all violating cases will be printed". modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 102: > 100: > 101: // list all current descendants of Control class. > 102: private Set allControlClasses() { Please use `Class` instead of raw types. In 2 other places below as well. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 103: > 101: // list all current descendants of Control class. > 102: private Set allControlClasses() { > 103: return Set.of( Not that it matters much since the method is called once, but why is there a need for a method that returns the same constant set? The set can just be a constant: `private final Set> = Set.of(...);` modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 216: > 214: } else { > 215: System.err.println(msg); > 216: } No need for an `else` clause since `throw` will exit the scope of the method if it's reached. ------------- PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1618032226 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320200154 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320199287 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320196311 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320197915 From angorya at openjdk.org Fri Sep 8 18:26:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 18:26:52 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v7] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:13:45 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> only public > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 103: > >> 101: // list all current descendants of Control class. >> 102: private Set allControlClasses() { >> 103: return Set.of( > > Not that it matters much since the method is called once, but why is there a need for a method that returns the same constant set? The set can just be a constant: `private final Set> = Set.of(...);` will keep as a method, if we ever get to extracting classes at run time. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 216: > >> 214: } else { >> 215: System.err.println(msg); >> 216: } > > No need for an `else` clause since `throw` will exit the scope of the method if it's reached. personal style. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320204615 PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320205003 From angorya at openjdk.org Fri Sep 8 18:37:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 18:37:43 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v8] In-Reply-To: References: Message-ID: > In the Control hierarchy, all property accessor methods must be declared `final`. > > Added a test to check for missing `final` keyword and added the said keyword where required. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1213/files - new: https://git.openjdk.org/jfx/pull/1213/files/65aa0895..0c5c3043 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1213&range=06-07 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1213.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1213/head:pull/1213 PR: https://git.openjdk.org/jfx/pull/1213 From nlisker at openjdk.org Fri Sep 8 18:37:44 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 8 Sep 2023 18:37:44 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v8] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:32:18 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1618055720 From angorya at openjdk.org Fri Sep 8 18:37:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 18:37:46 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v7] In-Reply-To: References: Message-ID: <7kK5-1_l2NgJqEnaGerjvNRup-XPDN2E4tJiFZtz_rw=.9b38241c-7569-4323-8780-e31e079df99c@github.com> On Fri, 8 Sep 2023 18:18:30 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> only public > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java line 99: > >> 97: public class ControlPropertiesTest { >> 98: >> 99: private static final boolean FAIL_FAST = true; > > Please add a short comment on what this is for. Like "If true, an exception will be thrown on encountering the first violating class, otherwise a list of all violating cases will be printed". good point, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1213#discussion_r1320207983 From kcr at openjdk.org Fri Sep 8 18:44:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 8 Sep 2023 18:44:48 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v8] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:37:43 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1618069254 From angorya at openjdk.org Fri Sep 8 18:59:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Sep 2023 18:59:11 GMT Subject: RFR: 8301302: Platform preferences API [v15] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Fri, 8 Sep 2023 05:17:43 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Handle key removals looking good?? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1014#pullrequestreview-1618088381 From jhendrikx at openjdk.org Sat Sep 9 00:05:44 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Sep 2023 00:05:44 GMT Subject: RFR: 8313651: Add 'final' keyword to public property methods in controls [v8] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:37:43 GMT, Andy Goryachev wrote: >> In the Control hierarchy, all property accessor methods must be declared `final`. >> >> Added a test to check for missing `final` keyword and added the said keyword where required. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1213#pullrequestreview-1618523970 From jhendrikx at openjdk.org Sun Sep 10 21:14:06 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 10 Sep 2023 21:14:06 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text Message-ID: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> There are a number of tickets open related to text rendering: https://bugs.openjdk.org/browse/JDK-8314215 https://bugs.openjdk.org/browse/JDK-8145496 https://bugs.openjdk.org/browse/JDK-8129014 They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attention. Now, for RIGHT alignment, the new code does change things a bit. Where before the single trailing space that was not collapsed was shown at the end of each wrapped line, this space is now gone. Typing further spaces after `AAA` will not show up, but they are still there, and moving the cursor through them will move the cursor beyond the right side of the control's bounds (just like LEFT alignment has such a case). Some Text rendering implementations will "clamp" the cursor to prevent this (browsers), while others will render the cursor in the margin (but eventually the cursor disappears if there is not enough margin and there are too many spaces). Personally, I think this is absolutely fine. Wrapped text controls all have this kind of behavior, where typing a space just before the wrapping point seemingly has no effect until a non-space character is typed. For CENTER alignment, the case is similar to LEFT alignment, except there is a bit less space available to render "invisible" spaces. # Screenshots Using `Label`s containing the text `AAA BBB CCC` (note the doubled space between words) ## First wrapping point ### Before ![image](https://github.com/openjdk/jfx/assets/995917/0b781556-30ee-4504-a222-e9daff756f7b) Note the odd trailing space in Center and Right alignments. ### After ![image](https://github.com/openjdk/jfx/assets/995917/429da72d-ded7-4ba6-9b6f-d1fbc7d753c0) ## Small but text would still fit ### Before ![image](https://github.com/openjdk/jfx/assets/995917/e19971f7-a36d-415a-b1a5-2ff3ac423c9b) Note how the wrapping occurs earlier than needed, leading to "empty" lines that contained invisible spaces ### After ![image](https://github.com/openjdk/jfx/assets/995917/e4344297-880e-4218-860b-e1ddfb2b46be) Note how everything still fits ------------- Commit messages: - Fix to ignore trailing white space for wrapping and alignment Changes: https://git.openjdk.org/jfx/pull/1236/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314215 Stats: 51 lines in 1 file changed: 47 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1236.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236 PR: https://git.openjdk.org/jfx/pull/1236 From jhendrikx at openjdk.org Sun Sep 10 21:26:43 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 10 Sep 2023 21:26:43 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... @prrace I've done an attempt to make a fix for this behavior, if you could take a look and let me know what you think, that'd be great ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1712940982 From jdv at openjdk.org Mon Sep 11 05:21:12 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 11 Sep 2023 05:21:12 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences [v2] In-Reply-To: References: Message-ID: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Use common tolerance variable ------------- Changes: - all: https://git.openjdk.org/jfx-tests/pull/5/files - new: https://git.openjdk.org/jfx-tests/pull/5/files/70f97e8c..b3d3aa25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=5&range=00-01 Stats: 53 lines in 27 files changed: 27 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jfx-tests/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx-tests/pull/5 From jdv at openjdk.org Mon Sep 11 05:21:12 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 11 Sep 2023 05:21:12 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 12:15:35 GMT, Ajit Ghaisas wrote: > A static constant can be added to `test.scenegraph.fx3d.utils.FX3DAbstractApp` public static final float COLOR_TOLERANCE = 0.05f; > > This can easily be accessed in test classes without FX3DAbstractApp instance as - `Root.ROOT.getEnvironment().setProperty(ImageComparator.class, new GlassPixelImageComparator(new PixelEqualityRasterComparator(FX3DAbstractApp.COLOR_TOLERANCE)));` > > This will allow us to tweak the tolerance value at a single place in future and not in all the 26 files. > > This change is pretty safe as and just a sanity check would be needed. If a test does not use FX3DAbstractApp, then you can keep the hard-coded constant. Thanks @aghaisas for your inputs. I have updated the code to use common variable. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1713179402 From jdv at openjdk.org Mon Sep 11 05:22:43 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 11 Sep 2023 05:22:43 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. > Not sure if it's relevant, but when I wrote a 3D test with a color tolerance value it turned out to be too low on Mac (but not on Windows), as Kevin pointed out to me: [openjdk/jfx#43 (comment)](https://github.com/openjdk/jfx/pull/43#discussion_r502049390). We ended up using his suggested value (10/255 =~ 0.04) because it was good enough, but it could probably be a bit lower. Thanks @nlisker for your inputs. Current change of 0.05 tolerance is tested on Mac only. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/5#issuecomment-1713182541 From aghaisas at openjdk.org Mon Sep 11 06:13:44 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 11 Sep 2023 06:13:44 GMT Subject: [jfx-tests] RFR: 8315842: 3D tests fail because of edge pixel differences [v2] In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 05:21:12 GMT, Jayathirth D V wrote: >> Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. >> These tests are used to verify 3D rendering with different parameters like translation, rotation. >> >> So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. >> >> Added 5% color tolerance and with this change 23 of these tests pass. >> >> Some sub-tests under below 3 tests continue to fail because of other reasons: >> [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) >> [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) >> [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) >> >> Also i see that some of the camera tests just draw white images, this also needs to be verified. >> With this change 41 out of 62 3D tests will run properly. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Use common tolerance variable Thanks for fixing these. Looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx-tests/pull/5#pullrequestreview-1619189128 From kpk at openjdk.org Mon Sep 11 06:25:44 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 11 Sep 2023 06:25:44 GMT Subject: RFR: 8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:26:50 GMT, Andy Goryachev wrote: > Snapping introduces differences between computed values and snapped values, so we need to use non-zero tolerance when checking for equality. The maximum tolerance is (1 / scale) - one display pixel scaled back to the local coordinates. > > The tests have been modified to use the scale-specific tolerance. > > Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%). LGTM ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1234#pullrequestreview-1619204773 From jdv at openjdk.org Mon Sep 11 06:40:44 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 11 Sep 2023 06:40:44 GMT Subject: [jfx-tests] Integrated: 8315842: 3D tests fail because of edge pixel differences In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 10:17:28 GMT, Jayathirth D V wrote: > Out of 62 3D tests, 26 tests fail because of minute color differences in edge pixels. > These tests are used to verify 3D rendering with different parameters like translation, rotation. > > So adding little color tolerance will not change the test behavior and allows us to use these tests to automatically verify any regression introduced in 3D rendering. > > Added 5% color tolerance and with this change 23 of these tests pass. > > Some sub-tests under below 3 tests continue to fail because of other reasons: > [test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/fixedeye/PerspectiveCameraFixedEyeIsolateTest.jtr) > [test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/parallel/ParallelCameraIsolateTest.jtr) > [test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.java](file:///Users/jdv/dev/workspace/jfx/jfx-tests/functional/3DTests/build/test.workdir/test/scenegraph/fx3d/camera/perspective/PerspectiveCameraIsolateTest.jtr) > > Also i see that some of the camera tests just draw white images, this also needs to be verified. > With this change 41 out of 62 3D tests will run properly. This pull request has now been integrated. Changeset: 0d35c195 Author: Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/0d35c195e060d6c3e77424853417d2a5fd47620c Stats: 171 lines in 27 files changed: 171 ins; 0 del; 0 mod 8315842: 3D tests fail because of edge pixel differences Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx-tests/pull/5 From jdv at openjdk.org Mon Sep 11 07:21:45 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 11 Sep 2023 07:21:45 GMT Subject: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 17:05:41 GMT, Alexandre Iline wrote: >> There was a field in a subclass hiding a field in a superclass. > > @jayathirthrao FYI Thanks @shurymury for fixing this. I have verified that this change fixes subtests which were failing because of `java.lang.NullPointerException: Cannot invoke "javafx.scene.Camera.setNearClip(double)" because "this.camera" is null ` LGTM. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/8#issuecomment-1713307191 From aghaisas at openjdk.org Mon Sep 11 08:19:47 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 11 Sep 2023 08:19:47 GMT Subject: [jfx-tests] RFR: JDK-8315895: Some 3D camera tests fail because of NPE [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 17:17:17 GMT, Alexandre Iline wrote: >> There was a field in a subclass hiding a field in a superclass. > > Alexandre Iline has updated the pull request incrementally with two additional commits since the last revision: > > - Copyright. :| > - Copyright year Marked as reviewed by aghaisas (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/8#pullrequestreview-1619390669 From arapte at openjdk.org Mon Sep 11 09:28:55 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 11 Sep 2023 09:28:55 GMT Subject: RFR: 8310666: gradle validateSourceSets task not run when TEST_ONLY=true Message-ID: The validateSourceSets task are created only for the test tasks. [check source](https://github.com/openjdk/jfx/blob/eb7de72dafecbedc83c2215b6aed7432d4ec80f9/build.gradle#L1848) So, validateSourceSets task must be executed when running test tasks even when TEST_ONLY=true. This had caused a regression [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654), where we missed a failing scenario as validateSourceSets did not run with -PTEST_ONLY=true ------------- Commit messages: - Don't skip validateSourceSets task when TEST_ONLY=true Changes: https://git.openjdk.org/jfx/pull/1237/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310666 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1237.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1237/head:pull/1237 PR: https://git.openjdk.org/jfx/pull/1237 From kcr at openjdk.org Mon Sep 11 11:38:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 11:38:47 GMT Subject: RFR: 8310666: gradle validateSourceSets task not run when TEST_ONLY=true In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 09:23:06 GMT, Ambarish Rapte wrote: > The validateSourceSets task are created only for the test tasks. [check source](https://github.com/openjdk/jfx/blob/eb7de72dafecbedc83c2215b6aed7432d4ec80f9/build.gradle#L1848) > So, validateSourceSets task must be executed when running test tasks even when TEST_ONLY=true. > This had caused a regression [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654), where we missed a failing scenario as validateSourceSets did not run with -PTEST_ONLY=true Looks good. One suggestion, possibly for a follow-up enhancement, would be to move all of the logic to `isTestTask`. As part of this, you could consider documenting and treating `validate` and/or `verify` as prefixes that are treated as test tasks. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1237#pullrequestreview-1619771102 From kcr at openjdk.org Mon Sep 11 11:43:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 11:43:14 GMT Subject: [jfx21u] RFR: 8315864: Change JavaFX release version to 21.0.2 in jfx21u In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 14:20:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.2 release. Reviewer: @arapte I plan to integrate this at or shortly after 1600 UTC today. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/13#issuecomment-1713705079 From kcr at openjdk.org Mon Sep 11 11:43:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 11:43:14 GMT Subject: [jfx21u] RFR: 8315864: Change JavaFX release version to 21.0.2 in jfx21u Message-ID: Updates for the beginning of the 21.0.2 release. ------------- Commit messages: - 8315864: Change JavaFX release version to 21.0.2 in jfx21u Changes: https://git.openjdk.org/jfx21u/pull/13/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=13&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315864 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/13.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/13/head:pull/13 PR: https://git.openjdk.org/jfx21u/pull/13 From arapte at openjdk.org Mon Sep 11 11:44:48 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 11 Sep 2023 11:44:48 GMT Subject: Integrated: 8310666: gradle validateSourceSets task not run when TEST_ONLY=true In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 09:23:06 GMT, Ambarish Rapte wrote: > The validateSourceSets task are created only for the test tasks. [check source](https://github.com/openjdk/jfx/blob/eb7de72dafecbedc83c2215b6aed7432d4ec80f9/build.gradle#L1848) > So, validateSourceSets task must be executed when running test tasks even when TEST_ONLY=true. > This had caused a regression [JDK-8310654](https://bugs.openjdk.org/browse/JDK-8310654), where we missed a failing scenario as validateSourceSets did not run with -PTEST_ONLY=true This pull request has now been integrated. Changeset: 325be565 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/325be5657b0ba9633917c90e23dd4e8f34234421 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8310666: gradle validateSourceSets task not run when TEST_ONLY=true Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1237 From arapte at openjdk.org Mon Sep 11 12:01:46 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 11 Sep 2023 12:01:46 GMT Subject: [jfx21u] RFR: 8315864: Change JavaFX release version to 21.0.2 in jfx21u In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 14:20:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.2 release. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/13#pullrequestreview-1619823330 From shurailine at openjdk.org Mon Sep 11 14:21:50 2023 From: shurailine at openjdk.org (Alexandre Iline) Date: Mon, 11 Sep 2023 14:21:50 GMT Subject: [jfx-tests] Integrated: JDK-8315895: Some 3D camera tests fail because of NPE In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 17:04:56 GMT, Alexandre Iline wrote: > There was a field in a subclass hiding a field in a superclass. This pull request has now been integrated. Changeset: ba883a27 Author: Alexandre Iline URL: https://git.openjdk.org/jfx-tests/commit/ba883a27904c23dc3d928eec664594ce416b3274 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8315895: Some 3D camera tests fail because of NPE Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx-tests/pull/8 From kcr at openjdk.org Mon Sep 11 15:25:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 15:25:46 GMT Subject: RFR: 8315074: Possible null pointer access in native glass [v2] In-Reply-To: References: <2aTPdN0TaxSBo9MgGxaJrZ-gLuvlQc14kFvLK3fGPEM=.4427a442-a790-4f26-99cd-6b8d66349834@github.com> Message-ID: On Tue, 29 Aug 2023 13:54:19 GMT, Kevin Rushforth wrote: >> I'm not against that, especially since it's in line with what we do in other functions in glass. >> However, I am worried about the consequences. In case we just return, the caller has no idea that there is a major problem. A Runnable is supplied to e.g. _invokeAndWait, but it will never get executed while the caller (and the application logic) assumes it is scheduled. This can have serious consequences and unexpected behavior in the application. >> But maybe I'm missing something and it is less severe than I'm picturing it? > > I can see what you are saying, but worth noting in this specific case is that if the malloc of `RunnableContext` (a 12-byte struct) fails, we're not going to be able to allocate an OOME anyway. > > My preference would be to leave this fix as is, and file a follow-up issue to change the return type of `GtkApplication::submitForLaterInvocation` (and the equivalent methods in the other glass pipelines) to `boolean` so we can return an error code and throw an exception (which would very likely provoke an OOME, but in any case would never silently fail). I filed the following two follow-on umbrella tasks: [JDK-8316020](https://bugs.openjdk.org/browse/JDK-8316020): ? Check memory allocation for null return value (P3) [JDK-8316022](https://bugs.openjdk.org/browse/JDK-8316022): ? Memory allocation failure should throw OOME (P4) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1223#discussion_r1321718226 From kcr at openjdk.org Mon Sep 11 15:25:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 15:25:46 GMT Subject: RFR: 8315074: Possible null pointer access in native glass [v2] In-Reply-To: References: <2aTPdN0TaxSBo9MgGxaJrZ-gLuvlQc14kFvLK3fGPEM=.4427a442-a790-4f26-99cd-6b8d66349834@github.com> Message-ID: <7pZ3Komr5lcScVcysSrSvNti8kk-bY-vw4brd4OsDGo=.59168074-f98b-45b3-b1fb-ece738f6b6a8@github.com> On Mon, 11 Sep 2023 15:21:37 GMT, Kevin Rushforth wrote: >> I can see what you are saying, but worth noting in this specific case is that if the malloc of `RunnableContext` (a 12-byte struct) fails, we're not going to be able to allocate an OOME anyway. >> >> My preference would be to leave this fix as is, and file a follow-up issue to change the return type of `GtkApplication::submitForLaterInvocation` (and the equivalent methods in the other glass pipelines) to `boolean` so we can return an error code and throw an exception (which would very likely provoke an OOME, but in any case would never silently fail). > > I filed the following two follow-on umbrella tasks: > > [JDK-8316020](https://bugs.openjdk.org/browse/JDK-8316020): ? Check memory allocation for null return value (P3) > [JDK-8316022](https://bugs.openjdk.org/browse/JDK-8316022): ? Memory allocation failure should throw OOME (P4) The first of these already has two linked blocking bugs (this one, and the previously integrated [JDK-8313900](https://bugs.openjdk.org/browse/JDK-8313900) / PR #1204) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1223#discussion_r1321720588 From kcr at openjdk.org Mon Sep 11 15:30:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 15:30:47 GMT Subject: RFR: 8315074: Possible null pointer access in native glass [v2] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 15:50:57 GMT, Jayathirth D V wrote: >> At multiple places in native glass code we don't have appropriate NULL checks which might result in null pointer access. >> >> Added appropriate checks and all test run is green. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1223#pullrequestreview-1620283099 From kcr at openjdk.org Mon Sep 11 15:30:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 15:30:48 GMT Subject: RFR: 8315074: Possible null pointer access in native glass [v2] In-Reply-To: References: Message-ID: <-WGO5szT3dP7D8HBSW-3YRZ_Vu88teuu4BhdRcB_mkw=.61e9df1a-a8c4-45d1-9252-8c20675971b6@github.com> On Tue, 29 Aug 2023 17:13:17 GMT, Johan Vos wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > the ios changes are fine. > In general, I'm still worried about the consequences of silently ignoring a fatal error (although there is a printf, but that doesn't propagate to the caller), but this can indeed be fixed in a follow-up issue. @johanvos Can you re-review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1223#issuecomment-1714119093 From angorya at openjdk.org Mon Sep 11 15:46:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Sep 2023 15:46:49 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v5] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). 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 23 additional commits since the last revision: - undo merge - no new api - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - using snap inner space api - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'ag.8311527.snap.inner' into 8299753.resize - tests - Merge remote-tracking branch 'origin/master' into ag.8311527.snap.inner - javadoc - ... and 13 more: https://git.openjdk.org/jfx/compare/28c7ae3e...df87de91 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/908203cd..df87de91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=03-04 Stats: 385274 lines in 6296 files changed: 217229 ins; 124607 del; 43438 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From kcr at openjdk.org Mon Sep 11 16:02:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 16:02:08 GMT Subject: RFR: 8315958: Missing range checks in GlassPasteboard Message-ID: This PR adds missing range checks in the native `_getItemAsRawImage` and `ByteArrayFromPixels` methods in `GlassPasteboard.m` (for both mac and ios). Note that these checks are _very_ unlikely to ever detect an error in practice, since they would require a huge image to be copied to the macOS system clipboard (larger than can be created using a Java program). If this were to be detected, no exception would (or should be) thrown, given that the method that triggers this is the reading of the clipboard (so there is nothing that the application is doing wrong for which an exception would make sense). ------------- Commit messages: - 8315958: Missing range checks in GlassPasteboard Changes: https://git.openjdk.org/jfx/pull/1238/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315958 Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1238.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1238/head:pull/1238 PR: https://git.openjdk.org/jfx/pull/1238 From kcr at openjdk.org Mon Sep 11 16:48:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 16:48:50 GMT Subject: [jfx21u] Integrated: 8315864: Change JavaFX release version to 21.0.2 in jfx21u In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 14:20:54 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 21.0.2 release. This pull request has now been integrated. Changeset: 149cf113 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/149cf113ff8321b487da2c8cd1ec2536fb667095 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8315864: Change JavaFX release version to 21.0.2 in jfx21u Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx21u/pull/13 From kcr at openjdk.org Mon Sep 11 17:59:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 17:59:56 GMT Subject: [jfx21u] RFR: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 Message-ID: <4UanPFsQH2ZYocLbljTpW9gYrN4PzWOzHhWSwEqdrio=.9e04364b-5bbc-43a6-bd42-19e4b1f155b4@github.com> Clean backport to jfx21u. ------------- Commit messages: - Backport ed921717b3edbf3e76a888c0ddab83dcc1d7dbe7 Changes: https://git.openjdk.org/jfx21u/pull/14/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=14&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315870 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/14.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/14/head:pull/14 PR: https://git.openjdk.org/jfx21u/pull/14 From angorya at openjdk.org Mon Sep 11 18:06:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Sep 2023 18:06:51 GMT Subject: Integrated: 8313651: Add 'final' keyword to public property methods in controls In-Reply-To: References: Message-ID: <2vYUPouCFi4LeIGoQ15rNU03taa6VGe9kLWp3GmUbaU=.b8299ad4-89c7-4eba-8200-e8f5b355a8af@github.com> On Thu, 17 Aug 2023 23:07:14 GMT, Andy Goryachev wrote: > In the Control hierarchy, all property accessor methods must be declared `final`. > > Added a test to check for missing `final` keyword and added the said keyword where required. This pull request has now been integrated. Changeset: 624fe86f Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/624fe86f4c22e43caa95cca03eb11230141d11da Stats: 266 lines in 8 files changed: 222 ins; 0 del; 44 mod 8313651: Add 'final' keyword to public property methods in controls Reviewed-by: jhendrikx, nlisker, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1213 From kcr at openjdk.org Mon Sep 11 19:00:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Sep 2023 19:00:48 GMT Subject: [jfx21u] Integrated: 8315870: icu fails to compile with Visual Studio 2022 17.6.5 In-Reply-To: <4UanPFsQH2ZYocLbljTpW9gYrN4PzWOzHhWSwEqdrio=.9e04364b-5bbc-43a6-bd42-19e4b1f155b4@github.com> References: <4UanPFsQH2ZYocLbljTpW9gYrN4PzWOzHhWSwEqdrio=.9e04364b-5bbc-43a6-bd42-19e4b1f155b4@github.com> Message-ID: On Mon, 11 Sep 2023 17:52:34 GMT, Kevin Rushforth wrote: > Clean backport to jfx21u. This pull request has now been integrated. Changeset: 400b8dd3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/400b8dd38396257d072b21a98c869ab6dc927e52 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8315870: icu fails to compile with Visual Studio 2022 17.6.5 Backport-of: ed921717b3edbf3e76a888c0ddab83dcc1d7dbe7 ------------- PR: https://git.openjdk.org/jfx21u/pull/14 From jvos at openjdk.org Mon Sep 11 19:53:51 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 11 Sep 2023 19:53:51 GMT Subject: RFR: 8315074: Possible null pointer access in native glass [v2] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 15:50:57 GMT, Jayathirth D V wrote: >> At multiple places in native glass code we don't have appropriate NULL checks which might result in null pointer access. >> >> Added appropriate checks and all test run is green. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1223#pullrequestreview-1620726016 From mhanl at openjdk.org Tue Sep 12 07:12:51 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 12 Sep 2023 07:12:51 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: References: Message-ID: <5oxIEZ5LuDVRwO7a0mclnLkug0FmMNJ2bRekkaqIJ1o=.bebb35bc-78f0-438f-8fda-34bcaa022f7c@github.com> On Thu, 7 Sep 2023 22:04:46 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8315569: Set a min size > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 44: > >> 42: import static org.junit.jupiter.api.Assertions.assertTrue; >> 43: >> 44: class ControlContractTest { > > Do you plan to add more tests to this class? The name does not specify which contract is being tested. Do you a better idea? I guess it would make sense to rename it to something more generic. Maybe ControlLayoutTest? > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 46: > >> 44: class ControlContractTest { >> 45: >> 46: private ControlStub control; > > Do you think it's worth to run this test against all of the existing Controls? Since no `Control` is overriding the `layoutChildren` method, I don't think it will make any difference as of now > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 67: > >> 65: */ >> 66: @ParameterizedTest >> 67: @ValueSource(doubles = { 1.0, 1.25, 1.5, 1.75, 2.0 }) > > Could you please add 2.25 (I can see this one with the secondary monitor attached to my win11 box) sure. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 101: > >> 99: >> 100: double expectedWidth = control.snapSizeX(control.getWidth()) - control.snappedLeftInset() - control.snappedRightInset(); >> 101: assertEquals(expectedWidth, w); > > since we are performing floating point operations, we might accumulate small error. > So this and 3 subsequent assertEquals() would need an EPSILON = 0.0000001 (an arbitrary value) Will have a look, but it worked without so I did not bothered adding an epsilon to the tests ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1322547208 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1322546539 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1322548432 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1322550303 From arapte at openjdk.org Tue Sep 12 10:05:47 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Sep 2023 10:05:47 GMT Subject: RFR: 8315958: Missing range checks in GlassPasteboard In-Reply-To: References: Message-ID: <9bIcWsuFz7m5G_U-SdHybp86rfNQ71TfSahvgaUi7ho=.4a616222-98a0-4230-a8a0-b2d9c683ace1@github.com> On Mon, 11 Sep 2023 15:55:44 GMT, Kevin Rushforth wrote: > This PR adds missing range checks in the native `_getItemAsRawImage` and `ByteArrayFromPixels` methods in `GlassPasteboard.m` (for both mac and ios). > > Note that these checks are _very_ unlikely to ever detect an error in practice, since they would require a huge image to be copied to the macOS system clipboard (larger than can be created using a Java program). If this were to be detected, no exception would (or should be) thrown, given that the method that triggers this is the reading of the clipboard (so there is nothing that the application is doing wrong for which an exception would make sense). Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1238#pullrequestreview-1621841010 From aghaisas at openjdk.org Tue Sep 12 10:40:02 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Sep 2023 10:40:02 GMT Subject: [jfx-tests] RFR: 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException Message-ID: test/scenegraph/richtext/RichTextLabeledsTest.java test/scenegraph/richtext/RichTextMixedTest.java test/scenegraph/richtext/RichTextRectangleTest.java test/scenegraph/richtext/RichTextTextTest.java These tests were failing with - java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Time-limited test. They are fixed with a change to single file `RichTextPropertiesApp.java` Another test - test/scenegraph/richtext/RichTextSpecSymbTest.java - was failing due to NPE. Added a null check to fix it. ------------- Commit messages: - fix richtext tests Changes: https://git.openjdk.org/jfx-tests/pull/9/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=9&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316097 Stats: 15 lines in 2 files changed: 11 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx-tests/pull/9.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/9/head:pull/9 PR: https://git.openjdk.org/jfx-tests/pull/9 From jhendrikx at openjdk.org Tue Sep 12 13:21:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 12 Sep 2023 13:21:56 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 00:25:48 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Use standard asserts in test > - Add copyright header I think this will be as ready as it gets, let me know if I missed anything. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1715713061 From aghaisas at openjdk.org Tue Sep 12 14:46:15 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Sep 2023 14:46:15 GMT Subject: [jfx-tests] RFR: 8316116: Ignore a single failing test case from Effects2Test Message-ID: test/scenegraph/functional/graphics/Effects2Test.java has a total of 123 test cases. Out of which 122 test cases pass and 1 test case (Lightningspotlight) fails consistently. Right now, the root cause of this test failure is unknown. This PR marks this test case with `@Ignore`. It will be fixed in future under [JDK-8316117](https://bugs.openjdk.org/browse/JDK-8316117). ------------- Commit messages: - ignore single test case Changes: https://git.openjdk.org/jfx-tests/pull/10/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=10&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316116 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/10.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/10/head:pull/10 PR: https://git.openjdk.org/jfx-tests/pull/10 From angorya at openjdk.org Tue Sep 12 14:49:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Sep 2023 14:49:53 GMT Subject: [jfx-tests] RFR: 8316116: Ignore a single failing test case from Effects2Test In-Reply-To: References: Message-ID: <7hIFKHn4FtFqiL7m0sVxa64_J1xHJFvxEFzkKEACKqU=.68dfdddd-7ab9-4ff2-b3f6-27b9b3658f15@github.com> On Tue, 12 Sep 2023 14:38:12 GMT, Ajit Ghaisas wrote: > test/scenegraph/functional/graphics/Effects2Test.java has a total of 123 test cases. Out of which 122 test cases pass and 1 test case (Lightningspotlight) fails consistently. Right now, the root cause of this test failure is unknown. > > This PR marks this test case with `@Ignore`. It will be fixed in future under [JDK-8316117](https://bugs.openjdk.org/browse/JDK-8316117). Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/10#pullrequestreview-1622442135 From aghaisas at openjdk.org Tue Sep 12 15:16:47 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 12 Sep 2023 15:16:47 GMT Subject: [jfx-tests] Integrated: 8316116: Ignore a single failing test case from Effects2Test In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 14:38:12 GMT, Ajit Ghaisas wrote: > test/scenegraph/functional/graphics/Effects2Test.java has a total of 123 test cases. Out of which 122 test cases pass and 1 test case (Lightningspotlight) fails consistently. Right now, the root cause of this test failure is unknown. > > This PR marks this test case with `@Ignore`. It will be fixed in future under [JDK-8316117](https://bugs.openjdk.org/browse/JDK-8316117). This pull request has now been integrated. Changeset: 082013f8 Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/082013f873be6a020d0d25497397faa8ee8fb2f9 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8316116: Ignore a single failing test case from Effects2Test Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx-tests/pull/10 From mstrauss at openjdk.org Tue Sep 12 17:01:51 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 12 Sep 2023 17:01:51 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 00:25:48 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Use standard asserts in test > - Add copyright header Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1622725289 From kcr at openjdk.org Tue Sep 12 17:21:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 17:21:20 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 Message-ID: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. ------------- Commit messages: - 8316135: Create release notes for JavaFX 21 Changes: https://git.openjdk.org/jfx/pull/1239/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316135 Stats: 152 lines in 1 file changed: 152 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1239.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1239/head:pull/1239 PR: https://git.openjdk.org/jfx/pull/1239 From kcr at openjdk.org Tue Sep 12 17:21:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 17:21:20 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:14:28 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. @johanvos @abhinayagarwal Can you review? @hjohn Can you review the important change notices for the return type of `javafx.css.Match::getPseudoClasses` and the addition of the event handler methods to the `EventTarget` interface? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1239#issuecomment-1716130104 From angorya at openjdk.org Tue Sep 12 17:27:47 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Sep 2023 17:27:47 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:14:28 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. doc-files/release-notes-21.md line 13: > 11: ### JavaFX Requires macOS 11 or Later > 12: > 13: On Mac platforms, JavaFX 21 requires macOS 11 or later. An exception will be thrown when initializing the JavaFX runtime on older versions of macOS. just curious: all these lists (CSRs, Enhancements, Bug Fixes) are compiled from JBS, correct? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1323352233 From kcr at openjdk.org Tue Sep 12 17:33:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 17:33:44 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:25:12 GMT, Andy Goryachev wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > doc-files/release-notes-21.md line 13: > >> 11: ### JavaFX Requires macOS 11 or Later >> 12: >> 13: On Mac platforms, JavaFX 21 requires macOS 11 or later. An exception will be thrown when initializing the JavaFX runtime on older versions of macOS. > > just curious: all these lists (CSRs, Enhancements, Bug Fixes) are compiled from JBS, correct? Yes, although there is no list of CSRs. The first section includes issues tagged with "release-note=yes". The list of enhancements and bugs are from the following JBS filter: [FX 21 RN Issues](https://bugs.openjdk.org/issues/?filter=44607) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1323358172 From angorya at openjdk.org Tue Sep 12 17:40:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Sep 2023 17:40:45 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:14:28 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. that's quite a few bugs fixed! looking good?? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1622798186 From kcr at openjdk.org Tue Sep 12 18:07:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 18:07:40 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 13:19:46 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use standard asserts in test >> - Add copyright header > > I think this will be as ready as it gets, let me know if I missed anything. @hjohn I'll do some testing and review today and tomorrow. While starting to test, I noticed that your branch is quite out of date. Can you merge in the latest upstream master? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1716191185 From duke at openjdk.org Tue Sep 12 20:40:44 2023 From: duke at openjdk.org (Abhinay Agarwal) Date: Tue, 12 Sep 2023 20:40:44 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:31:23 GMT, Kevin Rushforth wrote: >> doc-files/release-notes-21.md line 13: >> >>> 11: ### JavaFX Requires macOS 11 or Later >>> 12: >>> 13: On Mac platforms, JavaFX 21 requires macOS 11 or later. An exception will be thrown when initializing the JavaFX runtime on older versions of macOS. >> >> just curious: all these lists (CSRs, Enhancements, Bug Fixes) are compiled from JBS, correct? > > Yes, although there is no list of CSRs. The first section includes issues tagged with "release-note=yes". The list of enhancements and bugs are from the following JBS filter: > > [FX 21 RN Issues](https://bugs.openjdk.org/issues/?filter=44607) Why are [8305885](https://bugs.openjdk.org/browse/JDK-8305885) and [8304290](https://bugs.openjdk.org/browse/JDK-8304290) not included in release notes? Are issues JDK-8301022, JDK-8301712, JDK-8302294, JDK-8302684, JDK-8303217, JDK-8303748 not included because they were introduced and fixed in the same version? Lastly, I was of the opinion that backports are not a part of the release notes, but it seems that [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324) is still added? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1323536706 From kcr at openjdk.org Tue Sep 12 22:26:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 22:26:45 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 20:38:06 GMT, Abhinay Agarwal wrote: > Why are [8305885](https://bugs.openjdk.org/browse/JDK-8305885) and [8304290](https://bugs.openjdk.org/browse/JDK-8304290) not included in release notes? They were in the initial list I had, and then I went through and excluded a number of cleanup issues. I guess I excluded too many. I'll add these two back in. > Are issues JDK-8301022, JDK-8301712, JDK-8302294, JDK-8302684, JDK-8303217, JDK-8303748 not included because they were introduced and fixed in the same version? Yes, except for [JDK-8303748](https://bugs.openjdk.org/browse/JDK-8303748) which I excluded because it is a build issue that isn't relevant to application developers. > Lastly, I was of the opinion that backports are not a part of the release notes, but it seems that [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324) is still added? Prior to this release, we wouldn't have included backports. However, with the change to the stabilization process such that all fixes first go into master and are then backported to the stabilization release, we would miss actual fixes that are first delivered in this release if we didn't consider them. Note that we need to use the base bug ID for backports that were first fixed in jfx21. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1323664831 From kcr at openjdk.org Tue Sep 12 22:42:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Sep 2023 22:42:10 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Add missing bugs JDK-8305885 and JDK-8304290 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1239/files - new: https://git.openjdk.org/jfx/pull/1239/files/d663aee6..56120aec Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1239.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1239/head:pull/1239 PR: https://git.openjdk.org/jfx/pull/1239 From angorya at openjdk.org Tue Sep 12 22:47:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Sep 2023 22:47:17 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 00:25:48 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Use standard asserts in test > - Add copyright header ? looking good. tested dynamic stylesheet loading, no ill effects. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1623311466 From angorya at openjdk.org Tue Sep 12 22:55:43 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Sep 2023 22:55:43 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: <5oxIEZ5LuDVRwO7a0mclnLkug0FmMNJ2bRekkaqIJ1o=.bebb35bc-78f0-438f-8fda-34bcaa022f7c@github.com> References: <5oxIEZ5LuDVRwO7a0mclnLkug0FmMNJ2bRekkaqIJ1o=.bebb35bc-78f0-438f-8fda-34bcaa022f7c@github.com> Message-ID: On Tue, 12 Sep 2023 07:07:27 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 44: >> >>> 42: import static org.junit.jupiter.api.Assertions.assertTrue; >>> 43: >>> 44: class ControlContractTest { >> >> Do you plan to add more tests to this class? The name does not specify which contract is being tested. > > Do you a better idea? I guess it would make sense to rename it to something more generic. Maybe ControlLayoutTest? ControlLayoutChildrenContractTest perhaps, if that's the only thing being tested here (that is, if you don't plan to add anything to this test). Also, would it make sense to move javadoc from L58 to L43 since it describes the test (assuming no more changes) >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlContractTest.java line 101: >> >>> 99: >>> 100: double expectedWidth = control.snapSizeX(control.getWidth()) - control.snappedLeftInset() - control.snappedRightInset(); >>> 101: assertEquals(expectedWidth, w); >> >> since we are performing floating point operations, we might accumulate small error. >> So this and 3 subsequent assertEquals() would need an EPSILON = 0.0000001 (an arbitrary value) > > Will have a look, but it worked without so I did not bothered adding an epsilon to the tests I would have added an EPSILON. I suspect we just got lucky that with the default padding and a small subset of scales everything comes out ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1323684765 PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1323687129 From jhendrikx at openjdk.org Tue Sep 12 23:23:43 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 12 Sep 2023 23:23:43 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> Message-ID: On Tue, 12 Sep 2023 22:42:10 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add missing bugs JDK-8305885 and JDK-8304290 Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1623388124 From jhendrikx at openjdk.org Tue Sep 12 23:23:44 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 12 Sep 2023 23:23:44 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:17:09 GMT, Kevin Rushforth wrote: > @hjohn Can you review the important change notices for the return type of `javafx.css.Match::getPseudoClasses` and the addition of the event handler methods to the `EventTarget` interface? I've reviewed both, and they both look good to me. Perhaps @mstr2 should also take a look at the `EventTarget` notes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1239#issuecomment-1716660208 From jhendrikx at openjdk.org Tue Sep 12 23:28:37 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 12 Sep 2023 23:28:37 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v10] In-Reply-To: References: Message-ID: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> > This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. > > In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. > > Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. > > The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. > > The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. > > A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. > > Although the test case above was extreme, this change should have positive effects for most applications. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Use standard asserts in test - Add copyright header - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate - Fix another edge case in BitSet equals When arrays are not the same size, but there are no set bits in the ones the other set doesn't have, two bit sets can still be considered equal - Take element type into account for BitSet.equals() - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray - Removed faulty toArray implementations in PseudoClassState and StyleClassSet - Added test that verifies equals/hashCode for PseudoClassState respect Set contract now - Made getBits package private so it can't be inherited - ... and 9 more: https://git.openjdk.org/jfx/compare/624fe86f...962c43ea ------------- Changes: https://git.openjdk.org/jfx/pull/1076/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=09 Stats: 326 lines in 10 files changed: 195 ins; 90 del; 41 mod Patch: https://git.openjdk.org/jfx/pull/1076.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076 PR: https://git.openjdk.org/jfx/pull/1076 From nlisker at openjdk.org Wed Sep 13 00:12:43 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Sep 2023 00:12:43 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> Message-ID: On Tue, 12 Sep 2023 22:42:10 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add missing bugs JDK-8305885 and JDK-8304290 doc-files/release-notes-21.md line 139: > 137: [JDK-8299977](https://bugs.openjdk.org/browse/JDK-8299977)|Update WebKit to 615.1|web > 138: [JDK-8301009](https://bugs.openjdk.org/browse/JDK-8301009)|Update libxml2 to 2.10.3|web > 139: [JDK-8306115](https://bugs.openjdk.org/browse/JDK-8306115)|Update libxml2 to 2.10.4|web Do we really need the upgrade to 2.10.3 in the release notes if the release includes 2.10.4? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1323783309 From mstrauss at openjdk.org Wed Sep 13 00:37:46 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 13 Sep 2023 00:37:46 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> Message-ID: On Tue, 12 Sep 2023 22:42:10 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add missing bugs JDK-8305885 and JDK-8304290 LGTM ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1623450906 From mstrauss at openjdk.org Wed Sep 13 00:43:45 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 13 Sep 2023 00:43:45 GMT Subject: RFR: 8315958: Missing range checks in GlassPasteboard In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 15:55:44 GMT, Kevin Rushforth wrote: > This PR adds missing range checks in the native `_getItemAsRawImage` and `ByteArrayFromPixels` methods in `GlassPasteboard.m` (for both mac and ios). > > Note that these checks are _very_ unlikely to ever detect an error in practice, since they would require a huge image to be copied to the macOS system clipboard (larger than can be created using a Java program). If this were to be detected, no exception would (or should be) thrown, given that the method that triggers this is the reading of the clipboard (so there is nothing that the application is doing wrong for which an exception would make sense). Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1238#pullrequestreview-1623453967 From jvos at openjdk.org Wed Sep 13 06:11:45 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 13 Sep 2023 06:11:45 GMT Subject: RFR: 8315958: Missing range checks in GlassPasteboard In-Reply-To: References: Message-ID: On Mon, 11 Sep 2023 15:55:44 GMT, Kevin Rushforth wrote: > This PR adds missing range checks in the native `_getItemAsRawImage` and `ByteArrayFromPixels` methods in `GlassPasteboard.m` (for both mac and ios). > > Note that these checks are _very_ unlikely to ever detect an error in practice, since they would require a huge image to be copied to the macOS system clipboard (larger than can be created using a Java program). If this were to be detected, no exception would (or should be) thrown, given that the method that triggers this is the reading of the clipboard (so there is nothing that the application is doing wrong for which an exception would make sense). ios changes are ok ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1238#pullrequestreview-1623757178 From duke at openjdk.org Wed Sep 13 07:03:49 2023 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 13 Sep 2023 07:03:49 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> On Tue, 12 Sep 2023 22:23:51 GMT, Kevin Rushforth wrote: > Note that we need to use the base bug ID for backports that were first fixed in jfx21 Can you shed some light on this for future reference? In case of [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324), we do not use the base bug id. The same was also applied to jfx21.0.1, should we be using [JDK-8313331](https://bugs.openjdk.org/browse/JDK-8313331) or the base bug id for 21.0.1 release notes? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1324063257 From arapte at openjdk.org Wed Sep 13 08:05:46 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 13 Sep 2023 08:05:46 GMT Subject: [jfx-tests] RFR: 8315928: Few Scenegraph and Charts tests fail due to resource not found error In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 11:21:14 GMT, Ajit Ghaisas wrote: > Below tests fail due to "resource not found" error. > - test/scenegraph/binding/effects/IdentityTest.java > - test/scenegraph/lcd/controls/tests/AccordionTest.java > - Almost all ControlsTests/Chart tests > > Fix : > Moved required resources to appropriate directory. Without this change tests fail with exception like: `Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because the return value of "java.lang.Class.getResource(String)" is null` Above exception does not occur after this fix. Some tests continue to fail but with a different exception: `java.lang.AssertionError: org.jemmy.control.WrapperException: java.lang.Object is not accepted by org.jemmy.control.Wrap` ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx-tests/pull/7#pullrequestreview-1623939472 From aghaisas at openjdk.org Wed Sep 13 09:30:51 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 13 Sep 2023 09:30:51 GMT Subject: [jfx-tests] Integrated: 8315928: Few Scenegraph and Charts tests fail due to resource not found error In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 11:21:14 GMT, Ajit Ghaisas wrote: > Below tests fail due to "resource not found" error. > - test/scenegraph/binding/effects/IdentityTest.java > - test/scenegraph/lcd/controls/tests/AccordionTest.java > - Almost all ControlsTests/Chart tests > > Fix : > Moved required resources to appropriate directory. This pull request has now been integrated. Changeset: f1bed108 Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/f1bed1084df2160278abe228ae77ba7d1c9397b3 Stats: 0 lines in 4 files changed: 0 ins; 0 del; 0 mod 8315928: Few Scenegraph and Charts tests fail due to resource not found error Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx-tests/pull/7 From lkostyra at openjdk.org Wed Sep 13 11:44:15 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 13 Sep 2023 11:44:15 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) Message-ID: PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. All variants are tested with decorated stage style. Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. Verified to work on Windows 11, macOS and Linux. ------------- Commit messages: - Add Stage Attributes robot test Changes: https://git.openjdk.org/jfx/pull/1240/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298500 Stats: 187 lines in 1 file changed: 187 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1240.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1240/head:pull/1240 PR: https://git.openjdk.org/jfx/pull/1240 From kcr at openjdk.org Wed Sep 13 11:57:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 11:57:45 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> Message-ID: On Wed, 13 Sep 2023 07:01:14 GMT, Abhinay Agarwal wrote: >>> Why are [8305885](https://bugs.openjdk.org/browse/JDK-8305885) and [8304290](https://bugs.openjdk.org/browse/JDK-8304290) not included in release notes? >> >> They were in the initial list I had, and then I went through and excluded a number of cleanup issues. I guess I excluded too many. I'll add these two back in. >> >>> Are issues JDK-8301022, JDK-8301712, JDK-8302294, JDK-8302684, JDK-8303217, JDK-8303748 not included because they were introduced and fixed in the same version? >> >> Yes, except for [JDK-8303748](https://bugs.openjdk.org/browse/JDK-8303748) which I excluded because it is a build issue that isn't relevant to application developers. >> >>> Lastly, I was of the opinion that backports are not a part of the release notes, but it seems that [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324) is still added? >> >> Prior to this release, we wouldn't have included backports. However, with the change to the stabilization process such that all fixes first go into master and are then backported to the stabilization release, we would miss actual fixes that are first delivered in this release if we didn't consider them. Note that we need to use the base bug ID for backports that were first fixed in jfx21. > >> Note that we need to use the base bug ID for backports that were first fixed in jfx21 > > Can you shed some light on this for future reference? > > In case of [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324), we do not use the base bug id. The same was also applied to jfx21.0.1, should we be using [JDK-8313331](https://bugs.openjdk.org/browse/JDK-8313331) or the base bug id for 21.0.1 release notes? We should _always_ use the base bug ID and _never_ the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). I will look into adjusting the JBS filter to make this a less error-prone process (using the `masterbug` macro which will provide the base bug IDs for a given set of backports). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1324398344 From kcr at openjdk.org Wed Sep 13 12:06:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 12:06:44 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Review feedback: remove libxml2 2.10.3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1239/files - new: https://git.openjdk.org/jfx/pull/1239/files/56120aec..27a3d810 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1239.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1239/head:pull/1239 PR: https://git.openjdk.org/jfx/pull/1239 From kcr at openjdk.org Wed Sep 13 12:06:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 12:06:46 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v2] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <8DNktjWoYWlv-E2OqkJTJZqCtNfFXD__bMu_dn_uSxM=.1cd6a6db-cb38-4d86-9f27-ca9ee60de52b@github.com> Message-ID: On Wed, 13 Sep 2023 00:10:14 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing bugs JDK-8305885 and JDK-8304290 > > doc-files/release-notes-21.md line 139: > >> 137: [JDK-8299977](https://bugs.openjdk.org/browse/JDK-8299977)|Update WebKit to 615.1|web >> 138: [JDK-8301009](https://bugs.openjdk.org/browse/JDK-8301009)|Update libxml2 to 2.10.3|web >> 139: [JDK-8306115](https://bugs.openjdk.org/browse/JDK-8306115)|Update libxml2 to 2.10.4|web > > Do we really need the upgrade to 2.10.3 in the release notes if the release includes 2.10.4? Hmm. Good point. Using somewhat similar reasoning as to why we exclude bugs introduced and fixed in the same release, we can exclude a fix that was added and then superseded in the same release. I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1324402581 From kcr at openjdk.org Wed Sep 13 12:07:07 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 12:07:07 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> Message-ID: On Wed, 13 Sep 2023 11:54:51 GMT, Kevin Rushforth wrote: >>> Note that we need to use the base bug ID for backports that were first fixed in jfx21 >> >> Can you shed some light on this for future reference? >> >> In case of [JDK-8313324](https://bugs.openjdk.org/browse/JDK-8313324), we do not use the base bug id. The same was also applied to jfx21.0.1, should we be using [JDK-8313331](https://bugs.openjdk.org/browse/JDK-8313331) or the base bug id for 21.0.1 release notes? > > We should _always_ use the base bug ID and _never_ the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). > > I will look into adjusting the JBS filter to make this a less error-prone process (using the `masterbug` macro which will provide the base bug IDs for a given set of backports). > We should always use the base bug ID and never the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). And to be clear I meant that the "base bug ID" for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1324409266 From kcr at openjdk.org Wed Sep 13 12:13:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 12:13:52 GMT Subject: Integrated: 8315958: Missing range checks in GlassPasteboard In-Reply-To: References: Message-ID: <2dhVasmCjO-hIKJgffrUEQv1bEVF_iTQdsboycQsU6E=.5e875a15-4d37-4265-bfa6-7996fd975106@github.com> On Mon, 11 Sep 2023 15:55:44 GMT, Kevin Rushforth wrote: > This PR adds missing range checks in the native `_getItemAsRawImage` and `ByteArrayFromPixels` methods in `GlassPasteboard.m` (for both mac and ios). > > Note that these checks are _very_ unlikely to ever detect an error in practice, since they would require a huge image to be copied to the macOS system clipboard (larger than can be created using a Java program). If this were to be detected, no exception would (or should be) thrown, given that the method that triggers this is the reading of the clipboard (so there is nothing that the application is doing wrong for which an exception would make sense). This pull request has now been integrated. Changeset: 7c8dd1ec Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7c8dd1eca1a1114acd85471cd764ebf1941dda7c Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod 8315958: Missing range checks in GlassPasteboard Reviewed-by: arapte, mstrauss, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1238 From duke at openjdk.org Wed Sep 13 12:24:52 2023 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 13 Sep 2023 12:24:52 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> Message-ID: On Wed, 13 Sep 2023 12:06:44 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: remove libxml2 2.10.3 Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1624406477 From duke at openjdk.org Wed Sep 13 12:24:54 2023 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 13 Sep 2023 12:24:54 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> Message-ID: <_A8lgDwICpnAvq5jY44Z0s1KEbxTvlRqNteNRWZ82kE=.1b2b300c-1e9b-4acc-8680-0a8de753f444@github.com> On Wed, 13 Sep 2023 12:04:28 GMT, Kevin Rushforth wrote: >> We should _always_ use the base bug ID and _never_ the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). >> >> I will look into adjusting the JBS filter to make this a less error-prone process (using the `masterbug` macro which will provide the base bug IDs for a given set of backports). > >> We should always use the base bug ID and never the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). > > And to be clear I meant that the "base bug ID" for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). my bad, the release notes has the correct base bug id ? my local jfx21 release notes skipped [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227) as it was labelled as `hgupdate-sync`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1324428532 From jdv at openjdk.org Wed Sep 13 13:29:49 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 13 Sep 2023 13:29:49 GMT Subject: Integrated: 8315074: Possible null pointer access in native glass In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 04:58:31 GMT, Jayathirth D V wrote: > At multiple places in native glass code we don't have appropriate NULL checks which might result in null pointer access. > > Added appropriate checks and all test run is green. This pull request has now been integrated. Changeset: f7b21e54 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f7b21e5468f1aad18df17443590c0887b2cf0239 Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod 8315074: Possible null pointer access in native glass Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1223 From angorya at openjdk.org Wed Sep 13 15:10:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 13 Sep 2023 15:10:56 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 11:37:39 GMT, Lukasz Kostyra wrote: > PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. > > Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. tested on macOS 13.5.1 (looks good), with some minor comments and suggestions. tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 42: > 40: import javafx.scene.layout.Pane; > 41: import javafx.scene.paint.Color; > 42: import static junit.framework.Assert.assertFalse; should we use junit5 for new tests? tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 46: > 44: import test.robot.testharness.VisualTestBase; > 45: > 46: import static test.util.Util.TIMEOUT; this might be my personal preference - I think it's easier to read Util.TIMEOUT in the code rather to use a static import (especially since it's used only twice) tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 48: > 46: import static test.util.Util.TIMEOUT; > 47: > 48: public class AttributesTest extends VisualTestBase { a brief javadoc explaining what this test does would be nice. also, perhaps the class name could be more descriptive, i.e. StageAttributesTest or something like that. tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 56: > 54: private static final Color TOP_COLOR = Color.RED; > 55: > 56: private static final double TOLERANCE = 0.07; just curious: how did we arrive at this value? tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 103: > 101: } > 102: > 103: public @Test void testIconifiedStage() throws InterruptedException { could we use a more conventional formatting @ Test public void ... tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 134: > 132: > 133: // wait a bit to let window system animate the change > 134: sleep(1000); could we use Util.waitForIdle() here instead of the fixed timeout? tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 146: > 144: // wait a little bit between getColor() calls - on macOS the below one > 145: // would fail without this wait > 146: sleep(100); same - waitForIdle? ------------- PR Review: https://git.openjdk.org/jfx/pull/1240#pullrequestreview-1624765793 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324657804 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324656880 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324660804 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324671847 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324646642 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324668822 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324669434 From lkostyra at openjdk.org Wed Sep 13 15:35:48 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 13 Sep 2023 15:35:48 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 14:58:21 GMT, Andy Goryachev wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 42: > >> 40: import javafx.scene.layout.Pane; >> 41: import javafx.scene.paint.Color; >> 42: import static junit.framework.Assert.assertFalse; > > should we use junit5 for new tests? Fair point, import autocomplete got me there. > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 48: > >> 46: import static test.util.Util.TIMEOUT; >> 47: >> 48: public class AttributesTest extends VisualTestBase { > > a brief javadoc explaining what this test does would be nice. > also, perhaps the class name could be more descriptive, i.e. StageAttributesTest or something like that. I'll add the javadoc. I skipped the `Stage` prefix since this test is in a directory of `Stage`-related tests. Should I still add it despite that? > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 56: > >> 54: private static final Color TOP_COLOR = Color.RED; >> 55: >> 56: private static final double TOLERANCE = 0.07; > > just curious: how did we arrive at this value? I borrowed it from `IconifyTest.java` which most of this file is based on. Hard for me to say why is it exactly that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324707762 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324707030 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324705760 From angorya at openjdk.org Wed Sep 13 15:41:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 13 Sep 2023 15:41:46 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 15:32:15 GMT, Lukasz Kostyra wrote: >> tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 48: >> >>> 46: import static test.util.Util.TIMEOUT; >>> 47: >>> 48: public class AttributesTest extends VisualTestBase { >> >> a brief javadoc explaining what this test does would be nice. >> also, perhaps the class name could be more descriptive, i.e. StageAttributesTest or something like that. > > I'll add the javadoc. > > I skipped the `Stage` prefix since this test is in a directory of `Stage`-related tests. Should I still add it despite that? The more specific the class name, the better, I think (and also, specific names reduce collisions) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1324715928 From duke at openjdk.org Wed Sep 13 15:55:51 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 13 Sep 2023 15:55:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: References: Message-ID: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> On Sun, 2 Apr 2023 20:38:25 GMT, Thiago Milczarek Sayao wrote: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 91: > 89: void WindowContextBase::commitIME(gchar *str) { > 90: if (!im_ctx.on_preedit) { > 91: jchar key = g_utf8_get_char(str); This block is trying to set up calls to View.notifyKey. To get the correct KeyCode requires information in the original GdkEventKey like the hardware code and modifier state (for handling Num Lock on the key pad). The simplest solution is to record a pointer to the original GdkEventKey before calling `gtk_im_context_filter_keypress` and here pass that pointer to `process_key`. It will get the KeyCode right and generate the appropriate View.notifyKey calls. (In theory another approach is to ignore the commit and return 'false' from filterIME so the original GdkEvent isn't filtered. I tried that but it turned into a mess because I was seeing two key press events for every keystroke. `gtk_im_context_filter_keypress` filters out the original key press event without generating a commit. Instead it posts a duplicate event with a private modifier flag set and the commit signal is sent out when that second event is passed to `gtk_im_context_filter_keypress`.) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1324732939 From jdv at openjdk.org Wed Sep 13 16:08:01 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 13 Sep 2023 16:08:01 GMT Subject: [jfx21u] RFR: 8315074: Possible null pointer access in native glass Message-ID: This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8315074. It adds appropriate null checks in glass code. ------------- Commit messages: - Backport f7b21e5468f1aad18df17443590c0887b2cf0239 Changes: https://git.openjdk.org/jfx21u/pull/15/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=15&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315074 Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod Patch: https://git.openjdk.org/jfx21u/pull/15.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/15/head:pull/15 PR: https://git.openjdk.org/jfx21u/pull/15 From kcr at openjdk.org Wed Sep 13 16:34:08 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 16:34:08 GMT Subject: [jfx21u] RFR: 8315958: Missing range checks in GlassPasteboard Message-ID: Clean backport to jfx12u. ------------- Commit messages: - Backport 7c8dd1eca1a1114acd85471cd764ebf1941dda7c Changes: https://git.openjdk.org/jfx21u/pull/16/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=16&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315958 Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx21u/pull/16.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/16/head:pull/16 PR: https://git.openjdk.org/jfx21u/pull/16 From tsayao at openjdk.org Wed Sep 13 17:07:50 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 13 Sep 2023 17:07:50 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor In-Reply-To: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> References: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> Message-ID: On Wed, 13 Sep 2023 15:52:43 GMT, Martin Fox wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 91: > >> 89: void WindowContextBase::commitIME(gchar *str) { >> 90: if (!im_ctx.on_preedit) { >> 91: jchar key = g_utf8_get_char(str); > > This block is trying to set up calls to View.notifyKey. To get the correct KeyCode requires information in the original GdkEventKey like the hardware code and modifier state (for handling Num Lock on the key pad). The simplest solution is to record a pointer to the original GdkEventKey before calling `gtk_im_context_filter_keypress` and here pass that pointer to `process_key`. It will get the KeyCode right and generate the appropriate View.notifyKey calls. > > (In theory another approach is to ignore the commit and return 'false' from filterIME so the original GdkEvent isn't filtered. I tried that but it turned into a mess because I was seeing two key press events for every keystroke. `gtk_im_context_filter_keypress` filters out the original key press event without generating a commit. Instead it posts a duplicate event with a private modifier flag set and the commit signal is sent out when that second event is passed to `gtk_im_context_filter_keypress`.) I think the correct way is to generate a new gdk event. If I understood correctly, it's what gtk does [internally](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkimcontextsimple.c). I will experiment with that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1324816395 From kcr at openjdk.org Wed Sep 13 20:49:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Sep 2023 20:49:45 GMT Subject: [jfx21u] Integrated: 8315958: Missing range checks in GlassPasteboard In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 16:27:18 GMT, Kevin Rushforth wrote: > Clean backport to jfx12u. This pull request has now been integrated. Changeset: 1ea3460c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/1ea3460c6cc4ed1c3b044ad1dc104abf82e0fed0 Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod 8315958: Missing range checks in GlassPasteboard Backport-of: 7c8dd1eca1a1114acd85471cd764ebf1941dda7c ------------- PR: https://git.openjdk.org/jfx21u/pull/16 From nlisker at gmail.com Thu Sep 14 11:27:54 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 14 Sep 2023 14:27:54 +0300 Subject: Enabling debug messages Message-ID: Hi, I see that the D3D c++ files can output debug info via various DebugPrintD3DError and TraceLn functions. How can this output be enabled? - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdv at openjdk.org Thu Sep 14 11:58:50 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 14 Sep 2023 11:58:50 GMT Subject: [jfx21u] Integrated: 8315074: Possible null pointer access in native glass In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 16:01:34 GMT, Jayathirth D V wrote: > This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8315074. > It adds appropriate null checks in glass code. This pull request has now been integrated. Changeset: c80b74a2 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/c80b74a24c35be1128d8bf7f3a004feea79e7b3b Stats: 105 lines in 8 files changed: 70 ins; 7 del; 28 mod 8315074: Possible null pointer access in native glass Backport-of: f7b21e5468f1aad18df17443590c0887b2cf0239 ------------- PR: https://git.openjdk.org/jfx21u/pull/15 From kevin.rushforth at oracle.com Thu Sep 14 12:27:52 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Sep 2023 05:27:52 -0700 Subject: Enabling debug messages In-Reply-To: References: Message-ID: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> export NWT_TRACE_LEVEL=N where "N" is the trace level. See modules/javafx.graphics/src/main/native-prism-d3d/Trace.h Btw, you can ignore the part about it being only enabled in debug mode. That env var is recognized in production builds as well. -- Kevin On 9/14/2023 4:27 AM, Nir Lisker wrote: > Hi, > > I see that the D3D c++ files can output debug info via various > DebugPrintD3DError and TraceLn functions. How can?this output be enabled? > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Sep 14 13:02:05 2023 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 14 Sep 2023 16:02:05 +0300 Subject: Enabling debug messages In-Reply-To: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> References: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> Message-ID: Thanks, I set it to 5. On startup it prints info such as (I) D3DContext::InitContext device 0 (V) HARDWARE_VERTEXPROCESSING (I) D3DContext::InitContext: successfully created device: 0 (I) D3DContext::InitDevice: device 0 (I) D3DContext::InitDevice: successfully initialized device 0 (V) CAPS_TEXNONPOW2 (V) CAPS_TEXNONSQUARE but I don't see any DebugPrintD3DError or TraceLn1 output despite them being higher severity. I also tried setting it to 2 and then no additional output appeared. I added cout prints next to them so I know they are being reached. Any ideas? On Thu, Sep 14, 2023 at 3:29?PM Kevin Rushforth wrote: > export NWT_TRACE_LEVEL=N > > where "N" is the trace level. See > modules/javafx.graphics/src/main/native-prism-d3d/Trace.h > > Btw, you can ignore the part about it being only enabled in debug mode. > That env var is recognized in production builds as well. > > -- Kevin > > > On 9/14/2023 4:27 AM, Nir Lisker wrote: > > Hi, > > I see that the D3D c++ files can output debug info via various > DebugPrintD3DError and TraceLn functions. How can this output be enabled? > > - Nir > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Thu Sep 14 13:32:52 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 14 Sep 2023 13:32:52 GMT Subject: [jfx-tests] RFR: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 09:26:59 GMT, Ajit Ghaisas wrote: > A few SceneGraphTests and ControlsTests/chart test classes are abstract classes and serve as base classes for other tests. > They are excluded from test execution and hence result in avoiding false failure reports. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/4#pullrequestreview-1626898451 From aghaisas at openjdk.org Thu Sep 14 14:03:51 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 14 Sep 2023 14:03:51 GMT Subject: [jfx-tests] Integrated: 8315845: Exclude Scenegraph and Charts test classes that serve as a base class In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 09:26:59 GMT, Ajit Ghaisas wrote: > A few SceneGraphTests and ControlsTests/chart test classes are abstract classes and serve as base classes for other tests. > They are excluded from test execution and hence result in avoiding false failure reports. This pull request has now been integrated. Changeset: 35623633 Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/35623633b3bcda9f6a0573a0ad7510f97ba111b9 Stats: 11 lines in 4 files changed: 11 ins; 0 del; 0 mod 8315845: Exclude Scenegraph and Charts test classes that serve as a base class Reviewed-by: jdv, arapte ------------- PR: https://git.openjdk.org/jfx-tests/pull/4 From kevin.rushforth at oracle.com Thu Sep 14 15:08:58 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Sep 2023 08:08:58 -0700 Subject: [External] : Re: Enabling debug messages In-Reply-To: References: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> Message-ID: <4237fcd5-bb25-d72a-5aa2-dddd132510d6@oracle.com> In that case, my guess is that those really are enabled only for debug builds. You can build a debug build using "gradle -PCONF=DebugNative". -- Kevin On 9/14/2023 6:02 AM, Nir Lisker wrote: > Thanks, I set it to 5. On startup it prints info such as > > (I) D3DContext::InitContext device 0 > (V) HARDWARE_VERTEXPROCESSING > (I) D3DContext::InitContext: successfully created device: 0 > (I) D3DContext::InitDevice: device 0 > (I) D3DContext::InitDevice: successfully initialized device 0 > (V) CAPS_TEXNONPOW2 > (V) CAPS_TEXNONSQUARE > > but I don't see any DebugPrintD3DError or TraceLn1 output despite them > being higher severity. I also tried setting it to 2 and then no > additional output appeared. I added cout prints next to them so I know > they are being reached. > Any ideas? > > On Thu, Sep 14, 2023 at 3:29?PM Kevin Rushforth > wrote: > > export NWT_TRACE_LEVEL=N > > where "N" is the trace level. See > modules/javafx.graphics/src/main/native-prism-d3d/Trace.h > > Btw, you can ignore the part about it being only enabled in debug > mode. That env var is recognized in production builds as well. > > -- Kevin > > > On 9/14/2023 4:27 AM, Nir Lisker wrote: >> Hi, >> >> I see that the D3D c++ files can output debug info via various >> DebugPrintD3DError and TraceLn functions. How can?this output be >> enabled? >> >> - Nir >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 14 17:57:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 17:57:51 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 11:37:39 GMT, Lukasz Kostyra wrote: > PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. > > Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. I left a few inline comment. I still need to test it, but I'll wait until you address my main feedback about the order of operations before I do too much testing. tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 111: > 109: > 110: topStage.setIconified(true); > 111: }); This will show the stage before setting it as iconified. Testing correct behavior for a stage that is initially iconified/maximized/fullScreen prior to showing the stage is the main purpose of this test enhancement, so you will need to do something like split the creation and showing of the stages into separate methods or pass flags for the initial state of those three attributes as arguments to the setupStages method. tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 130: > 128: assertColorEquals(BOTTOM_COLOR, color, TOLERANCE); > 129: > 130: topStage.setMaximized(true); Same comment about needing to set maximized before showing topStage. tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 163: > 161: assertColorEquals(BOTTOM_COLOR, color, TOLERANCE); > 162: > 163: topStage.setFullScreen(true); Same comment about needing to set fullScreen before showing topStage. ------------- PR Review: https://git.openjdk.org/jfx/pull/1240#pullrequestreview-1627423784 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326315338 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326331934 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326331278 From kcr at openjdk.org Thu Sep 14 17:57:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 17:57:54 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 14:57:54 GMT, Andy Goryachev wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 46: > >> 44: import test.robot.testharness.VisualTestBase; >> 45: >> 46: import static test.util.Util.TIMEOUT; > > this might be my personal preference - I think it's easier to read Util.TIMEOUT in the code rather to use a static import (especially since it's used only twice) I prefer the static import in this case. More to the point, this is what most other tests do. > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 146: > >> 144: // wait a little bit between getColor() calls - on macOS the below one >> 145: // would fail without this wait >> 146: sleep(100); > > same - waitForIdle? I don't think so. This is a small sleep that isn't intended to wait for idle. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326307042 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326316769 From kcr at openjdk.org Thu Sep 14 17:57:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 17:57:56 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 15:31:15 GMT, Lukasz Kostyra wrote: >> tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 56: >> >>> 54: private static final Color TOP_COLOR = Color.RED; >>> 55: >>> 56: private static final double TOLERANCE = 0.07; >> >> just curious: how did we arrive at this value? > > I borrowed it from `IconifyTest.java` which most of this file is based on. Hard for me to say why is it exactly that. This constant, with the same value of `0.07`, is repeated in most of our robot screen capture tests. It seems a good candidate for moving it to the `VisualTestBase` parent class, as a future test enhancement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1326304679 From angorya at openjdk.org Thu Sep 14 18:15:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 18:15:20 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls Message-ID: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). In addition, the key bindings are documented in /doc-files/behavior markdown documents. ------------- Commit messages: - disabled keypad tests - text area tests - docs - text area doc - nbsp - text input control doc - doc - mac bindings - test navigation - robot test base - ... and 22 more: https://git.openjdk.org/jfx/compare/624fe86f...db657f76 Changes: https://git.openjdk.org/jfx/pull/1221/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314906 Stats: 2758 lines in 16 files changed: 2721 ins; 23 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From kcr at openjdk.org Thu Sep 14 18:42:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 18:42:49 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: On Wed, 23 Aug 2023 23:30:50 GMT, Andy Goryachev wrote: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents. This is a large enough set of tests that a second pair of eyes will be useful. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1221#issuecomment-1719956852 From kcr at openjdk.org Thu Sep 14 18:54:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 18:54:52 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: On Wed, 23 Aug 2023 23:30:50 GMT, Andy Goryachev wrote: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents. A couple quick comments I spotted while skimming this PR. modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubToolkit.java line 971: > 969: public static StubToolkit ensure() { > 970: return (StubToolkit)Toolkit.getToolkit(); > 971: } This is unused (and may not be needed). I think you can revert the changes to this file. tests/system/src/test/java/test/javafx/scene/control/behavior/Mod.java line 33: > 31: * Key Modifiers for use in behavior tests. > 32: */ > 33: public enum Mod { If this needs to be public (meaning visible to other tests outside this test package), I might recommend a more descriptive name. tests/system/src/test/java/test/util/Util.java line 67: > 65: private static final boolean MAC = OS.startsWith("Mac"); > 66: private static final boolean LINUX = OS.startsWith("Linux"); > 67: This duplicates the logic in PlatformUtil. We just fixed a few other places to get rid of this sort of duplication, so I recommend removing this. tests/system/src/test/java/test/util/Util.java line 480: > 478: */ > 479: public static boolean isWindows(){ > 480: return WINDOWS; Are these really needed or can the tests call PlatformUtil directly? If there is a good reason to add them, then they should delegate to PlatformUtil rather than duplicate the functionality. ------------- PR Review: https://git.openjdk.org/jfx/pull/1221#pullrequestreview-1627554862 PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326387332 PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326388978 PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326391012 PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326392044 From angorya at openjdk.org Thu Sep 14 19:18:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 19:18:48 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: <95li88N3ojoEo8eF9fYuzRT0inqtCN3P523JaqNY1CQ=.a7f5fdfe-4fcb-4747-86fb-5f2f27e76720@github.com> On Thu, 14 Sep 2023 18:48:39 GMT, Kevin Rushforth wrote: >> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. >> >> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). >> >> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. >> >> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). >> >> In addition, the key bindings are documented in /doc-files/behavior markdown documents. > > tests/system/src/test/java/test/javafx/scene/control/behavior/Mod.java line 33: > >> 31: * Key Modifiers for use in behavior tests. >> 32: */ >> 33: public enum Mod { > > If this needs to be public (meaning visible to other tests outside this test package), I might recommend a more descriptive name. the obvious would be KeyModifier, but we already have one in test.com.sun.javafx.scene.control.infrastructure with a different and less convenient semantics. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326414595 From angorya at openjdk.org Thu Sep 14 19:38:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 19:38:28 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v2] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: <1S6ZEVyIeb286i0xnXqlrCo_sQOhVY9OsoA9BPl_mLk=.a45c448c-eac0-45b0-bb7a-a06d60d4acfd@github.com> > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: win ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/db657f76..440c2b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=00-01 Stats: 52 lines in 1 file changed: 2 ins; 38 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From angorya at openjdk.org Thu Sep 14 19:44:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 19:44:10 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v3] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents. Andy Goryachev has updated the pull request incrementally with three additional commits since the last revision: - key modifier - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test - platform util ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/440c2b4e..34d0d6e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=01-02 Stats: 259 lines in 5 files changed: 99 ins; 130 del; 30 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From angorya at openjdk.org Thu Sep 14 19:44:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 19:44:10 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v3] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: <9Ikf1Gfk8HjmNPdRAwsZunWsIpgEfddX2PwoRU-7y1A=.b2d0095b-30ff-45e1-9cac-e5a340234f0d@github.com> On Thu, 14 Sep 2023 18:51:33 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with three additional commits since the last revision: >> >> - key modifier >> - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test >> - platform util > > tests/system/src/test/java/test/util/Util.java line 480: > >> 478: */ >> 479: public static boolean isWindows(){ >> 480: return WINDOWS; > > Are these really needed or can the tests call PlatformUtil directly? If there is a good reason to add them, then they should delegate to PlatformUtil rather than duplicate the functionality. was able to use PlatformUtils directly after adding --add-exports javafx.base/com.sun.javafx=ALL-UNNAMED to the launch configuration. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1326434128 From angorya at openjdk.org Thu Sep 14 19:50:31 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 19:50:31 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v4] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents: > > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/34d0d6e7..a90b4691 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=02-03 Stats: 86 lines in 2 files changed: 24 ins; 61 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From angorya at openjdk.org Thu Sep 14 21:09:22 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 21:09:22 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents: > > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md 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 38 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test - cleanup - key modifier - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test - win - platform util - disabled keypad tests - text area tests - docs - text area doc - ... and 28 more: https://git.openjdk.org/jfx/compare/2194d0c9...911e6d33 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/a90b4691..911e6d33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=03-04 Stats: 124 lines in 10 files changed: 84 ins; 7 del; 33 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From nlisker at gmail.com Thu Sep 14 21:54:02 2023 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Sep 2023 00:54:02 +0300 Subject: [External] : Re: Enabling debug messages In-Reply-To: <4237fcd5-bb25-d72a-5aa2-dddd132510d6@oracle.com> References: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> <4237fcd5-bb25-d72a-5aa2-dddd132510d6@oracle.com> Message-ID: This works, thanks. Needed to run clean first. On Thu, Sep 14, 2023 at 6:09?PM Kevin Rushforth wrote: > In that case, my guess is that those really are enabled only for debug > builds. You can build a debug build using "gradle -PCONF=DebugNative". > > -- Kevin > > > On 9/14/2023 6:02 AM, Nir Lisker wrote: > > Thanks, I set it to 5. On startup it prints info such as > > (I) D3DContext::InitContext device 0 > (V) HARDWARE_VERTEXPROCESSING > (I) D3DContext::InitContext: successfully created device: 0 > (I) D3DContext::InitDevice: device 0 > (I) D3DContext::InitDevice: successfully initialized device 0 > (V) CAPS_TEXNONPOW2 > (V) CAPS_TEXNONSQUARE > > but I don't see any DebugPrintD3DError or TraceLn1 output despite them > being higher severity. I also tried setting it to 2 and then no additional > output appeared. I added cout prints next to them so I know they are being > reached. > Any ideas? > > On Thu, Sep 14, 2023 at 3:29?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> export NWT_TRACE_LEVEL=N >> >> where "N" is the trace level. See >> modules/javafx.graphics/src/main/native-prism-d3d/Trace.h >> >> Btw, you can ignore the part about it being only enabled in debug mode. >> That env var is recognized in production builds as well. >> >> -- Kevin >> >> >> On 9/14/2023 4:27 AM, Nir Lisker wrote: >> >> Hi, >> >> I see that the D3D c++ files can output debug info via various >> DebugPrintD3DError and TraceLn functions. How can this output be enabled? >> >> - Nir >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Sep 14 22:15:51 2023 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Sep 2023 01:15:51 +0300 Subject: [External] : Re: Enabling debug messages In-Reply-To: References: <321aeeff-d911-5d08-40e3-1131f3e74139@oracle.com> <4237fcd5-bb25-d72a-5aa2-dddd132510d6@oracle.com> Message-ID: There is some bad news too though. The D3D debug runtime seems to only be available on Windows 7 and older because D3D9 is EOL. That means that detailed messages from the D3D runtime are not available. On Fri, Sep 15, 2023 at 12:54?AM Nir Lisker wrote: > This works, thanks. Needed to run clean first. > > On Thu, Sep 14, 2023 at 6:09?PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> In that case, my guess is that those really are enabled only for debug >> builds. You can build a debug build using "gradle -PCONF=DebugNative". >> >> -- Kevin >> >> >> On 9/14/2023 6:02 AM, Nir Lisker wrote: >> >> Thanks, I set it to 5. On startup it prints info such as >> >> (I) D3DContext::InitContext device 0 >> (V) HARDWARE_VERTEXPROCESSING >> (I) D3DContext::InitContext: successfully created device: 0 >> (I) D3DContext::InitDevice: device 0 >> (I) D3DContext::InitDevice: successfully initialized device 0 >> (V) CAPS_TEXNONPOW2 >> (V) CAPS_TEXNONSQUARE >> >> but I don't see any DebugPrintD3DError or TraceLn1 output despite them >> being higher severity. I also tried setting it to 2 and then no additional >> output appeared. I added cout prints next to them so I know they are being >> reached. >> Any ideas? >> >> On Thu, Sep 14, 2023 at 3:29?PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> export NWT_TRACE_LEVEL=N >>> >>> where "N" is the trace level. See >>> modules/javafx.graphics/src/main/native-prism-d3d/Trace.h >>> >>> Btw, you can ignore the part about it being only enabled in debug mode. >>> That env var is recognized in production builds as well. >>> >>> -- Kevin >>> >>> >>> On 9/14/2023 4:27 AM, Nir Lisker wrote: >>> >>> Hi, >>> >>> I see that the D3D c++ files can output debug info via various >>> DebugPrintD3DError and TraceLn functions. How can this output be enabled? >>> >>> - Nir >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 14 22:42:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 22:42:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v10] In-Reply-To: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> References: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> Message-ID: On Tue, 12 Sep 2023 23:28:37 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate > - Use standard asserts in test > - Add copyright header > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - ... and 9 more: https://git.openjdk.org/jfx/compare/624fe86f...962c43ea Looks good. All my testing is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1627841635 From kcr at openjdk.org Thu Sep 14 22:42:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 22:42:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: <-QLH1UzVZmZbNw7B3VAiEGcEEfIWaVAuUilpJ0Ss250=.ed2312ed-c48b-4169-a3d7-06c124d0ab62@github.com> <45LQVLXdcvBr0pLD0k2iQWJHfXL-YOJeggBjLcb5ThM=.794445a9-9742-4b8a-b250-8b99b0d47d4e@github.com> Message-ID: <0DY5w4aR1Vlv17BLu-ZRGwJ9SbvSXyagHH1vyLZbo3Y=.8c4b2e85-63cf-4af8-8ce4-459be81b2f4e@github.com> On Wed, 16 Aug 2023 14:02:01 GMT, John Hendrikx wrote: >> Then the map is just an optimization? If the set points to itself then a `Set` as a cache should be enough. > > No, a `Set` wouldn't work here, for this reason: > > if (CACHE.contains(mutableSet)) { > return ... // how do I get the immutable set from CACHE when it is a Set? > } I just finished my review of the code, and this (why a `Map` rather than a `Set`) was the only question I had. I looked at the resolved threads, and I see that it has been asked and answered. Good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1326581679 From angorya at openjdk.org Thu Sep 14 22:43:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Sep 2023 22:43:45 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> Message-ID: On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote: > There are a number of tickets open related to text rendering: > > https://bugs.openjdk.org/browse/JDK-8314215 > > https://bugs.openjdk.org/browse/JDK-8145496 > > https://bugs.openjdk.org/browse/JDK-8129014 > > They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). > > The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). > > If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. > > TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. > > For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. > > The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent... modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 965: > 963: > 964: for (int i = length + startOffset - 1; i >= startOffset; i--) { > 965: if (chars[i] != ' ') { should `Character.isWhitespace()` be used instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1326585928 From kcr at openjdk.org Thu Sep 14 22:46:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Sep 2023 22:46:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 13:17:14 GMT, Johan Vos wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > This is a great PR with a massive performance improvement. I'll have a more detailed look at the changes, but this looks great. @johanvos Do you want to re-review? The only changes since you reviewed (in addition to a merge from master) were some minor changes to the unit test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1720250132 From jvos at openjdk.org Fri Sep 15 06:37:19 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 15 Sep 2023 06:37:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v10] In-Reply-To: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> References: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> Message-ID: <6_nx6mBUM2JshU4_g6lDi7s44EUI3QkED5_U31_G47s=.1d0effd8-c537-43eb-8e63-c263a0be8938@github.com> On Tue, 12 Sep 2023 23:28:37 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate > - Use standard asserts in test > - Add copyright header > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - ... and 9 more: https://git.openjdk.org/jfx/compare/624fe86f...962c43ea Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1628291023 From aghaisas at openjdk.org Fri Sep 15 07:22:10 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Sep 2023 07:22:10 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo Message-ID: - Removed README file - Added README.md file with details For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme ------------- Commit messages: - add newline - Update bullet points - Add README.md Changes: https://git.openjdk.org/jfx-tests/pull/11/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=11&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8197397 Stats: 83 lines in 2 files changed: 69 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jfx-tests/pull/11.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/11/head:pull/11 PR: https://git.openjdk.org/jfx-tests/pull/11 From aghaisas at openjdk.org Fri Sep 15 07:22:10 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Sep 2023 07:22:10 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 07:09:13 GMT, Ajit Ghaisas wrote: > - Removed README file > - Added README.md file with details > > For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme @shurymury, @kevinrushforth - Can you please review? ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/11#issuecomment-1720796335 From mhanl at openjdk.org Fri Sep 15 08:28:49 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 15 Sep 2023 08:28:49 GMT Subject: RFR: JDK-8315569: Tests for the contract of SkinBase.layoutChildren(..) [v2] In-Reply-To: References: <5oxIEZ5LuDVRwO7a0mclnLkug0FmMNJ2bRekkaqIJ1o=.bebb35bc-78f0-438f-8fda-34bcaa022f7c@github.com> Message-ID: On Tue, 12 Sep 2023 22:48:26 GMT, Andy Goryachev wrote: >> Do you a better idea? I guess it would make sense to rename it to something more generic. Maybe ControlLayoutTest? > > ControlLayoutChildrenContractTest perhaps, if that's the only thing being tested here (that is, if you don't plan to add anything to this test). > > Also, would it make sense to move javadoc from L58 to L43 since it describes the test (assuming no more changes) Well right now there is no plan to add more tests but that may change in the future. Will rename it ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1229#discussion_r1326972845 From arapte at openjdk.org Fri Sep 15 08:36:47 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Sep 2023 08:36:47 GMT Subject: [jfx-tests] RFR: 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 10:33:07 GMT, Ajit Ghaisas wrote: > test/scenegraph/richtext/RichTextLabeledsTest.java > test/scenegraph/richtext/RichTextMixedTest.java > test/scenegraph/richtext/RichTextRectangleTest.java > test/scenegraph/richtext/RichTextTextTest.java > > These tests were failing with - java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Time-limited test. They are fixed with a change to single file `RichTextPropertiesApp.java` > > Another test - test/scenegraph/richtext/RichTextSpecSymbTest.java - was failing due to NPE. Added a null check to fix it. functional/SceneGraphTests/src/test/scenegraph/richtext/RichTextPropertiesApp.java line 256: > 254: } > 255: }); > 256: } minor : can be replaced with a lambda: PlatformImpl.runAndWait(() -> textFlowPage.addTextFlow.requestFocus()); ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/9#discussion_r1326983167 From mhanl at openjdk.org Fri Sep 15 08:56:27 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 15 Sep 2023 08:56:27 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v10] In-Reply-To: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> References: <0GKU4KaI6TC8GoNV8AejX-x-mnPikIh978ltqnNBb_4=.6b01b65b-238f-4a0e-9610-7131eac9af50@github.com> Message-ID: On Tue, 12 Sep 2023 23:28:37 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/immutable-pseudoclassstate > - Use standard asserts in test > - Add copyright header > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - ... and 9 more: https://git.openjdk.org/jfx/compare/624fe86f...962c43ea Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1076#pullrequestreview-1628506669 From aghaisas at openjdk.org Fri Sep 15 10:57:26 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Sep 2023 10:57:26 GMT Subject: [jfx-tests] RFR: 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException [v2] In-Reply-To: References: Message-ID: > test/scenegraph/richtext/RichTextLabeledsTest.java > test/scenegraph/richtext/RichTextMixedTest.java > test/scenegraph/richtext/RichTextRectangleTest.java > test/scenegraph/richtext/RichTextTextTest.java > > These tests were failing with - java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Time-limited test. They are fixed with a change to single file `RichTextPropertiesApp.java` > > Another test - test/scenegraph/richtext/RichTextSpecSymbTest.java - was failing due to NPE. Added a null check to fix it. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: review comment fix ------------- Changes: - all: https://git.openjdk.org/jfx-tests/pull/9/files - new: https://git.openjdk.org/jfx-tests/pull/9/files/08672c8c..ae6b1fc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx-tests&pr=9&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx-tests&pr=9&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx-tests/pull/9.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/9/head:pull/9 PR: https://git.openjdk.org/jfx-tests/pull/9 From arapte at openjdk.org Fri Sep 15 11:26:45 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 15 Sep 2023 11:26:45 GMT Subject: [jfx-tests] RFR: 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException [v2] In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 10:57:26 GMT, Ajit Ghaisas wrote: >> test/scenegraph/richtext/RichTextLabeledsTest.java >> test/scenegraph/richtext/RichTextMixedTest.java >> test/scenegraph/richtext/RichTextRectangleTest.java >> test/scenegraph/richtext/RichTextTextTest.java >> >> These tests were failing with - java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Time-limited test. They are fixed with a change to single file `RichTextPropertiesApp.java` >> >> Another test - test/scenegraph/richtext/RichTextSpecSymbTest.java - was failing due to NPE. Added a null check to fix it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > review comment fix Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/9#pullrequestreview-1628742580 From lkostyra at openjdk.org Fri Sep 15 12:22:51 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 15 Sep 2023 12:22:51 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Thu, 14 Sep 2023 17:37:23 GMT, Kevin Rushforth wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 111: > >> 109: >> 110: topStage.setIconified(true); >> 111: }); > > This will show the stage before setting it as iconified. Testing correct behavior for a stage that is initially iconified/maximized/fullScreen prior to showing the stage is the main purpose of this test enhancement, so you will need to do something like split the creation and showing of the stages into separate methods or pass flags for the initial state of those three attributes as arguments to the setupStages method. Seems like testing both pre- and post-show behaviors would be the best option. I'll expand this to test both paths. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1327210433 From aghaisas at openjdk.org Fri Sep 15 12:25:45 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 15 Sep 2023 12:25:45 GMT Subject: [jfx-tests] Integrated: 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 10:33:07 GMT, Ajit Ghaisas wrote: > test/scenegraph/richtext/RichTextLabeledsTest.java > test/scenegraph/richtext/RichTextMixedTest.java > test/scenegraph/richtext/RichTextRectangleTest.java > test/scenegraph/richtext/RichTextTextTest.java > > These tests were failing with - java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Time-limited test. They are fixed with a change to single file `RichTextPropertiesApp.java` > > Another test - test/scenegraph/richtext/RichTextSpecSymbTest.java - was failing due to NPE. Added a null check to fix it. This pull request has now been integrated. Changeset: 46f2827d Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx-tests/commit/46f2827d257e68e143006ab6e7ea9fd37b310f5a Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod 8316097: Some Scenegraph/richtext tests fail due to IllegalStateException Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx-tests/pull/9 From kcr at openjdk.org Fri Sep 15 12:52:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 12:52:19 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v9] In-Reply-To: References: Message-ID: <4TYJrIEuCgtS2kt3mFILVn9cUcCM2Ju0m5aHieGJ-14=.e44890dc-509a-481a-ba36-56b50f0f3686@github.com> On Tue, 12 Sep 2023 13:19:46 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use standard asserts in test >> - Add copyright header > > I think this will be as ready as it gets, let me know if I missed anything. @hjohn This is ready to integrate ------------- PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1721226383 From kcr at openjdk.org Fri Sep 15 12:52:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 12:52:51 GMT Subject: RFR: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: <1556Jy6lZMKlwsTbPAQWZzXmo3IUYovqqW3XRgFdTt0=.f1c5ffaf-df2e-4e8c-9fd6-b9e82fe6e586@github.com> References: <1556Jy6lZMKlwsTbPAQWZzXmo3IUYovqqW3XRgFdTt0=.f1c5ffaf-df2e-4e8c-9fd6-b9e82fe6e586@github.com> Message-ID: On Sun, 3 Sep 2023 15:33:33 GMT, Thiago Milczarek Sayao wrote: >> The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. >> >> Te fix replaces the usage of the function for already known extents value calculation. > > Can someone sponsor this? @tsayao This is ready to integrate when you are ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1173#issuecomment-1721228438 From kcr at openjdk.org Fri Sep 15 12:55:43 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 12:55:43 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 12:20:11 GMT, Lukasz Kostyra wrote: >> tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 111: >> >>> 109: >>> 110: topStage.setIconified(true); >>> 111: }); >> >> This will show the stage before setting it as iconified. Testing correct behavior for a stage that is initially iconified/maximized/fullScreen prior to showing the stage is the main purpose of this test enhancement, so you will need to do something like split the creation and showing of the stages into separate methods or pass flags for the initial state of those three attributes as arguments to the setupStages method. > > Seems like testing both pre- and post-show behaviors would be the best option. I'll expand this to test both paths. The post-show behavior is already covered by other tests (e.g., IconifyTest). It wouldn't hurt to provide additional tests if easy, but it's not really necessary. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1327247844 From tsayao at openjdk.org Fri Sep 15 12:59:49 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 15 Sep 2023 12:59:49 GMT Subject: Integrated: 8251240: Menus inaccessible on Linux with i3 wm In-Reply-To: References: Message-ID: On Sun, 9 Jul 2023 17:43:05 GMT, Thiago Milczarek Sayao wrote: > The bug happens because `gdk_window_get_frame_extents` is not returning the correct position when o i3-wm, probably by some bug on the wm itself. > > Te fix replaces the usage of the function for already known extents value calculation. This pull request has now been integrated. Changeset: f1859743 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/f18597430d44f70086364170f7bb1e5d30e7ce56 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod 8251240: Menus inaccessible on Linux with i3 wm Reviewed-by: jpereda, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1173 From kcr at openjdk.org Fri Sep 15 13:48:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 13:48:51 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 07:09:13 GMT, Ajit Ghaisas wrote: > - Removed README file > - Added README.md file with details > > For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme I was able to run the tests following the instructions. I left a few minor wording comment. README.md line 3: > 1: # JFX-Tests > 2: > 3: This repository contains the tests and tools for Java FX. JavaFX is one word. README.md line 21: > 19: 5) Jtreg - We need a jtreg that contains lib/junit.jar file. e.g. version jtreg-6.2.1. See [Jtreg](https://openjdk.org/jtreg) > 20: 6) Jemmy-v3 library > 21: - git clone https://github.com/openjdk/jemmy-v3 That should be: https://github.com/openjdk/jemmy-v3.git README.md line 52: > 50: 7) **Generating golden images** > 51: > 52: A golden image is a manually verified image of the expected graphical output of a test. Many of the javafx functional tests depend upon golden images for image comparison and assert. I recommend to either remove the "and assert" or else change it to "and assertion testing". README.md line 53: > 51: > 52: A golden image is a manually verified image of the expected graphical output of a test. Many of the javafx functional tests depend upon golden images for image comparison and assert. > 53: In the absence of a centrally hosted directory of golden images, it is imperative that one needs to generate these golden images once and then subsequently run the tests. Here are the steps to generate golden images the "needs to" is redundant. I would change "it is imperative that one needs to generate these golden images" to "you must generate these golden images". README.md line 55: > 53: In the absence of a centrally hosted directory of golden images, it is imperative that one needs to generate these golden images once and then subsequently run the tests. Here are the steps to generate golden images > 54: > 55: a) Run the required tests (e.g. functional/SceneGraphTests) as described in step (6) above. This test run results in multiple test failures, but generates screenshots of test window in `build/images` directory. If satisfied with the expected graphical output, these images can be used as golden images by copying them to `build/golden/SceneGraphTests/prism/mac` directory (for a test run on MacOS). Note - this directory structure needs to be created if not present. Minor: "MacOS" --> "macOs" ------------- PR Review: https://git.openjdk.org/jfx-tests/pull/11#pullrequestreview-1628899061 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327252095 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327252797 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327307580 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327310673 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327270450 From jhendrikx at openjdk.org Fri Sep 15 14:01:11 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Sep 2023 14:01:11 GMT Subject: Integrated: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 12:49:39 GMT, John Hendrikx wrote: > This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. > > In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. > > Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. > > The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. > > The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. > > A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. > > Although the test case above was extreme, this change should have positive effects for most applications. This pull request has now been integrated. Changeset: 5e145cc0 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/5e145cc06ef68c50a4ffc95574fdafd44e054100 Stats: 326 lines in 10 files changed: 195 ins; 90 del; 41 mod 8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet Reviewed-by: angorya, jvos, mstrauss, kcr, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1076 From jhendrikx at openjdk.org Fri Sep 15 14:01:07 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 15 Sep 2023 14:01:07 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> Message-ID: On Wed, 13 Sep 2023 12:06:44 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: remove libxml2 2.10.3 Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1629017465 From angorya at openjdk.org Fri Sep 15 14:16:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 14:16:52 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> Message-ID: <9QBM47OoWmmjfQm-8sTHCydAQjIyU2_2SfDDW34jN54=.77fd789a-d210-4148-8162-b3f88c75d511@github.com> On Wed, 13 Sep 2023 12:06:44 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: remove libxml2 2.10.3 Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1629048552 From angorya at openjdk.org Fri Sep 15 14:26:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 14:26:52 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 07:09:13 GMT, Ajit Ghaisas wrote: > - Removed README file > - Added README.md file with details > > For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme README.md line 15: > 13: ## Dependencies > 14: > 15: 1) Bash Shell consistency: either add newline on L7 or remove from L14 (here and elsewhere) README.md line 16: > 14: > 15: 1) Bash Shell > 16: 2) JDK (version 19) 19 or 19+? ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327363224 PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327363724 From angorya at openjdk.org Fri Sep 15 14:30:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 14:30:48 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 07:09:13 GMT, Ajit Ghaisas wrote: > - Removed README file > - Added README.md file with details > > For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme README.md line 50: > 48: - To run a single test provide - `-Dtests=` before `test` in above command > 49: > 50: 7) **Generating golden images** terminology: would a "reference images" be a better term? ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327367590 From angorya at openjdk.org Fri Sep 15 14:30:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 14:30:51 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 13:12:13 GMT, Kevin Rushforth wrote: >> - Removed README file >> - Added README.md file with details >> >> For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme > > README.md line 55: > >> 53: In the absence of a centrally hosted directory of golden images, it is imperative that one needs to generate these golden images once and then subsequently run the tests. Here are the steps to generate golden images >> 54: >> 55: a) Run the required tests (e.g. functional/SceneGraphTests) as described in step (6) above. This test run results in multiple test failures, but generates screenshots of test window in `build/images` directory. If satisfied with the expected graphical output, these images can be used as golden images by copying them to `build/golden/SceneGraphTests/prism/mac` directory (for a test run on MacOS). Note - this directory structure needs to be created if not present. > > Minor: "MacOS" --> "macOs" actually, it's "macOS": https://en.wikipedia.org/wiki/MacOS :-) ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327368827 From lkostyra at openjdk.org Fri Sep 15 14:43:23 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 15 Sep 2023 14:43:23 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v2] In-Reply-To: References: Message-ID: > PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. > > Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. Lukasz Kostyra has updated the pull request incrementally with three additional commits since the last revision: - Add pre-stage-show tests - Address review issues - Rename AttributesTest -> StageAttributesTest ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1240/files - new: https://git.openjdk.org/jfx/pull/1240/files/0924d43b..819144b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=00-01 Stats: 478 lines in 2 files changed: 291 ins; 187 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1240.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1240/head:pull/1240 PR: https://git.openjdk.org/jfx/pull/1240 From lkostyra at openjdk.org Fri Sep 15 14:50:48 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 15 Sep 2023 14:50:48 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v2] In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 14:43:23 GMT, Lukasz Kostyra wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > Lukasz Kostyra has updated the pull request incrementally with three additional commits since the last revision: > > - Add pre-stage-show tests > - Address review issues > - Rename AttributesTest -> StageAttributesTest I addressed review remarks. I noticed following behaviors when testing the change: - On Windows all tests pass - On macOS `testMaximizedStageBeforeShow` and `testIconifiedStageBeforeShow` fail because stages are not shown already iconified/maximized. Rest of the tests work fine - I assume a bug in functionality that needs to be fixed. - On Linux all tests fail, on my VM (Fedora 38 with X11) the stages are created without taking into account WIDTH/HEIGHT parameters provided to the Scene. They are created smaller than expected (I guess 100x100), so `getColor()` calls return background colors (terminal background/letters in my case). This could be cured in-test of course, but it also seems like a bug that should be ironed out (we do expect stages to be larger after all). After forcing proper width/height, testMaximizedStageBeforeShow/testFullScreenStageBeforeShow both fail - I noticed top stage is created maximized/fullscreen and immediately brought back to default dimensions, so I think it's another to-be-fixed bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1240#issuecomment-1721404497 From kcr at openjdk.org Fri Sep 15 15:03:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 15:03:49 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 14:28:31 GMT, Andy Goryachev wrote: >> README.md line 55: >> >>> 53: In the absence of a centrally hosted directory of golden images, it is imperative that one needs to generate these golden images once and then subsequently run the tests. Here are the steps to generate golden images >>> 54: >>> 55: a) Run the required tests (e.g. functional/SceneGraphTests) as described in step (6) above. This test run results in multiple test failures, but generates screenshots of test window in `build/images` directory. If satisfied with the expected graphical output, these images can be used as golden images by copying them to `build/golden/SceneGraphTests/prism/mac` directory (for a test run on MacOS). Note - this directory structure needs to be created if not present. >> >> Minor: "MacOS" --> "~~macOs~~" "macOS" > > actually, it's "macOS": > > https://en.wikipedia.org/wiki/MacOS > > :-) Very odd. I was sure that I had typed `macOS`. Yes, let's not substitute one typo for another. :) ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327423281 From kcr at openjdk.org Fri Sep 15 15:07:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 15:07:48 GMT Subject: [jfx-tests] RFR: 8197397: Document steps for setting up and executing manual/automated tests in jfx-tests repo In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 14:27:30 GMT, Andy Goryachev wrote: >> - Removed README file >> - Added README.md file with details >> >> For formatted output of README.md - See : https://github.com/aghaisas/jfx-tests/tree/update_readme > > README.md line 50: > >> 48: - To run a single test provide - `-Dtests=` before `test` in above command >> 49: >> 50: 7) **Generating golden images** > > terminology: would a "reference images" be a better term? The tool uses the term "golden image". Changing it would be a larger change than just the README file (and probably not worth the effort). ------------- PR Review Comment: https://git.openjdk.org/jfx-tests/pull/11#discussion_r1327427369 From kcr at openjdk.org Fri Sep 15 15:24:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 15:24:46 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v2] In-Reply-To: References: Message-ID: <8pTftHhTlFIP0jqZnNoQ_Xibwucl2L_M75O4cfCe4m4=.b5f0d754-5ebc-4da8-9bdf-c6fe5cde6c33@github.com> On Fri, 15 Sep 2023 14:48:03 GMT, Lukasz Kostyra wrote: > * On macOS `testMaximizedStageBeforeShow` and `testIconifiedStageBeforeShow` fail because stages are not shown already iconified/maximized. Rest of the tests work fine - I assume a bug in functionality that needs to be fixed. [JDK-8305675](https://bugs.openjdk.org/browse/JDK-8305675) is already tracking the failure of an initially iconified window. You can use that bug ID when adding the "assumeFalse" to exclude the test on macOS. I don't see a bug tracking the failure of a maximized window. [JDK-8253997](https://bugs.openjdk.org/browse/JDK-8253997) describes a problem where the window is shown normal size and then animated to maximized. Perhaps the behavior has changed on recent macOS systems. Can you check by running that test program attached to that bug? If it behaves the same way as your new test, then we can repurpose that bug; otherwise, please file a new bug. > * On Linux all tests fail, on my VM (Fedora 38 with X11) the stages are created without taking into account WIDTH/HEIGHT parameters provided to the Scene. They are created smaller than expected (I guess 100x100), so `getColor()` calls return background colors (terminal background/letters in my case). This could be cured in-test of course, but it also seems like a bug that should be ironed out (we do expect stages to be larger after all). After forcing proper width/height, testMaximizedStageBeforeShow/testFullScreenStageBeforeShow both fail - I noticed top stage is created maximized/fullscreen and immediately brought back to default dimensions, so I think it's another to-be-fixed bug. Yes, it does seem like there are two or three product bugs on Linux. Can you file new bugs, and then use those bug IDs to exclude the failing tests on Linux? I'll test this on Ubuntu and see if that behaves differently than Fedora. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1240#issuecomment-1721456629 From lkostyra at openjdk.org Fri Sep 15 15:27:56 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 15 Sep 2023 15:27:56 GMT Subject: RFR: 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling Message-ID: The instability came from the way Windows sets window's default position. When it is not predefined on Stage creation (which was the case in these Robot tests) the window is created at some arbitrary position chosen by Windows near top-left corner. It also seems like Windows first picks the position assuming 100% scaling and then multiplies it by UI scale, which can provide X/Y coordinates of Stage with a fractional value. Due to above behavior, there is a chance that the fractional part of X/Y will be above .5 which fails the test (X/Y values were fetched via casting directly to `int`, which drops the fractional part without rounding). Adding rounding makes the test always pass and the assumption in the comment below consistent. `unstable.test` property check was removed, since this change stabilizes the test and its results. Verified also on macOS to ensure the change did not affect the tests. ------------- Commit messages: - Round stage X/Y coordinates in testPixelCaptureAverage Changes: https://git.openjdk.org/jfx/pull/1242/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255079 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1242.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1242/head:pull/1242 PR: https://git.openjdk.org/jfx/pull/1242 From kcr at openjdk.org Fri Sep 15 15:52:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Sep 2023 15:52:46 GMT Subject: RFR: 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 15:20:36 GMT, Lukasz Kostyra wrote: > The instability came from the way Windows sets window's default position. When it is not predefined on Stage creation (which was the case in these Robot tests) the window is created at some arbitrary position chosen by Windows near top-left corner. It also seems like Windows first picks the position assuming 100% scaling and then multiplies it by UI scale, which can provide X/Y coordinates of Stage with a fractional value. > > Due to above behavior, there is a chance that the fractional part of X/Y will be above .5 which fails the test (X/Y values were fetched via casting directly to `int`, which drops the fractional part without rounding). Adding rounding makes the test always pass and the assumption in the comment below consistent. > > `unstable.test` property check was removed, since this change stabilizes the test and its results. > > Verified also on macOS to ensure the change did not affect the tests. Looks good. The test is now stable on my Windows 10 system using 125% scaling. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1242#pullrequestreview-1629272043 From angorya at openjdk.org Fri Sep 15 16:57:13 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 16:57:13 GMT Subject: RFR: 8307176: Monkey Tester Application Part 2 Message-ID: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> Adding changes to the MonkeyTester application accumulated since the last test sprint, from a separate repository https://github.com/andy-goryachev-oracle/MonkeyTest User preferences location: The applications stores its user preferences (window location, etc.) in ~/.MonkeyTester directory. - To use a different directory, redefine the "user.home" system property, -Duser.home=<...>. - To disable saving, specify -Ddisable.settings=true vm agrument. - ? replace setId() with some other way of setting component name - ? change property for ui.settings dir - ? add pie chart - ? ComboBox: The current two buttons don't seem all that useful. I'm not even sure what, exactly, they do. What would be useful is a way to select the number of items in the list (like there is with ChoiceBox) - ? ListView: Changing the selection model or checking / unchecking the "null focus model" option clears the list, which is unexpected. Given that there is a separate "clear list" button, it doesn't seem needed either. - ? TextField: The default alignment of BASELINE_RIGHT is unexpected (unless there is a good reason, defaults for properties should match the API default to avoid surprises). - ? Menu item: Window --> Open Modal Window "Platform.exit()" should not be the default choice (if you press the app will exit) - ? TableView: The column sorting feature would be more useful if it were possible to have different data for each row - ? Add Skin -> (null skin, set new skin) menus to all related controls to enable leak tests - ? TableView: cell factory, cell value factory - ? TreeTableView: cell factory - ? TreeView: cell factory - ? add massive CJK text for JDK-8090110 / JDK-8089418 - ? clipboard monitor tool - ? add to the status bar: JVM version, JFX version, current directory, screen scale - ? WebView page To be continued... JDK-8316372 ------------- Commit messages: - cleanup - scroll pane - whitespace - whitespace - whitespace - copied from another repo Changes: https://git.openjdk.org/jfx/pull/1241/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307176 Stats: 4533 lines in 54 files changed: 3115 ins; 869 del; 549 mod Patch: https://git.openjdk.org/jfx/pull/1241.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1241/head:pull/1241 PR: https://git.openjdk.org/jfx/pull/1241 From duke at openjdk.org Fri Sep 15 19:24:47 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 15 Sep 2023 19:24:47 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: On Thu, 14 Sep 2023 21:09:22 GMT, Andy Goryachev wrote: >> Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. >> >> This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). >> >> The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. >> >> Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). >> >> In addition, the key bindings are documented in /doc-files/behavior markdown documents: >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md >> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md >> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md >> https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md > > 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 38 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test > - cleanup > - key modifier > - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test > - win > - platform util > - disabled keypad tests > - text area tests > - docs > - text area doc > - ... and 28 more: https://git.openjdk.org/jfx/compare/431c94f1...911e6d33 tests/system/src/test/java/test/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 196: > 194: "9", KeyCode.DIGIT9, > 195: ".", KeyCode.PERIOD, > 196: ",", KeyCode.COMMA On French layouts the DIGIT codes don't actually produce digits (you have to hold down Shift) and there's no KeyCode.PERIOD (also a shifted character). You don't seem to be using those characters but you might want to remove them from this table so no one is tempted to use them in the future. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1327693041 From angorya at openjdk.org Fri Sep 15 20:14:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 20:14:45 GMT Subject: RFR: 8307176: Monkey Tester Application Part 2 [v2] In-Reply-To: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> References: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> Message-ID: > Adding changes to the MonkeyTester application accumulated since the last test sprint, from a separate repository > https://github.com/andy-goryachev-oracle/MonkeyTest > > User preferences location: > The applications stores its user preferences (window location, etc.) in ~/.MonkeyTester directory. > - To use a different directory, redefine the "user.home" system property, -Duser.home=<...>. > - To disable saving, specify -Ddisable.settings=true vm agrument. > > - ? replace setId() with some other way of setting component name > - ? change property for ui.settings dir > - ? add pie chart > - ? ComboBox: The current two buttons don't seem all that useful. I'm not even sure what, exactly, they do. What would be useful is a way to select the number of items in the list (like there is with ChoiceBox) > - ? ListView: Changing the selection model or checking / unchecking the "null focus model" option clears the list, which is unexpected. Given that there is a separate "clear list" button, it doesn't seem needed either. > - ? TextField: The default alignment of BASELINE_RIGHT is unexpected (unless there is a good reason, defaults for properties should match the API default to avoid surprises). > - ? Menu item: Window --> Open Modal Window "Platform.exit()" should not be the default choice (if you press the app will exit) > - ? TableView: The column sorting feature would be more useful if it were possible to have different data for each row > - ? Add Skin -> (null skin, set new skin) menus to all related controls to enable leak tests > - ? TableView: cell factory, cell value factory > - ? TreeTableView: cell factory > - ? TreeView: cell factory > - ? add massive CJK text for JDK-8090110 / JDK-8089418 > - ? clipboard monitor tool > - ? add to the status bar: JVM version, JFX version, current directory, screen scale > - ? WebView page > > To be continued... JDK-8316372 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: keyboard event viewer ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1241/files - new: https://git.openjdk.org/jfx/pull/1241/files/b5e0816a..aef9f54e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1241&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1241&range=00-01 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1241.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1241/head:pull/1241 PR: https://git.openjdk.org/jfx/pull/1241 From angorya at openjdk.org Fri Sep 15 20:18:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 20:18:53 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v6] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: <-PfZFjpx2r3bbkHhn0rphon2PlWx4thiLU06t-HtBeM=.3c400764-0ceb-42ed-98c2-31eefd0933d9@github.com> > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents: > > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: test typing ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/911e6d33..cbb3afd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=04-05 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From angorya at openjdk.org Fri Sep 15 20:18:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 20:18:57 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: On Fri, 15 Sep 2023 19:21:54 GMT, Martin Fox 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 38 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8314906.behavior.test >> - cleanup >> - key modifier >> - Merge remote-tracking branch 'origin/8314906.behavior.test' into 8314906.behavior.test >> - win >> - platform util >> - disabled keypad tests >> - text area tests >> - docs >> - text area doc >> - ... and 28 more: https://git.openjdk.org/jfx/compare/84b57701...911e6d33 > > tests/system/src/test/java/test/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 196: > >> 194: "9", KeyCode.DIGIT9, >> 195: ".", KeyCode.PERIOD, >> 196: ",", KeyCode.COMMA > > On French layouts the DIGIT codes don't actually produce digits (you have to hold down Shift) and there's no KeyCode.PERIOD (also a shifted character). You don't seem to be using those characters but you might want to remove them from this table so no one is tempted to use them in the future. Interesting. It is my understanding though that for the purposes of this test it should work as expected. I've added `TextAreaBehaviorRobotTest.testTyping()` - could you try running it with your setup please? @Test public void testTyping() throws Exception { execute( //addKeyListener(), "0123456789.,abracadabra", checkText("0123456789.,abracadabra", 23) ); } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1327740081 From angorya at openjdk.org Fri Sep 15 20:24:39 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Sep 2023 20:24:39 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v7] In-Reply-To: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: > Creating the first batch of tests and testing framework that enables writing behavior tests for javafx controls, focusing on key bindings. The idea is to make writing such tests a simple process. > > This PR deals with the descendants of TextInputControl (TextField, PasswordField, TextArea). Most of the tests are headless, but in some cases (TextArea) a headful test is required because the behavior needs rendered text to function (example: page up / page down / line start / line end and the like). > > The tests exercise the key bindings registered by the Skin (or, rather the associated Behavior) at least once, and sometimes more than once. > > Some mappings cannot be tested due to Robot not supporting keypad events (created [JDK-8316307](https://bugs.openjdk.org/browse/JDK-8316307)). > > In addition, the key bindings are documented in /doc-files/behavior markdown documents: > > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/PasswordField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextArea.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextField.md > https://github.com/andy-goryachev-oracle/jfx/blob/8314906.behavior.test/doc-files/behavior/TextInputControl.md Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: check ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1221/files - new: https://git.openjdk.org/jfx/pull/1221/files/cbb3afd8..157a66e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1221&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1221.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1221/head:pull/1221 PR: https://git.openjdk.org/jfx/pull/1221 From duke at openjdk.org Fri Sep 15 23:04:45 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 15 Sep 2023 23:04:45 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> Message-ID: <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> On Fri, 15 Sep 2023 20:13:31 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 196: >> >>> 194: "9", KeyCode.DIGIT9, >>> 195: ".", KeyCode.PERIOD, >>> 196: ",", KeyCode.COMMA >> >> On French layouts the DIGIT codes don't actually produce digits (you have to hold down Shift) and there's no KeyCode.PERIOD (also a shifted character). You don't seem to be using those characters but you might want to remove them from this table so no one is tempted to use them in the future. > > Interesting. > > It is my understanding though that for the purposes of this test it should work as expected. I've added `TextAreaBehaviorRobotTest.testTyping()` - could you try running it with your setup please? > > > @Test > public void testTyping() throws Exception { > execute( > //addKeyListener(), > "0123456789.,abracadabra", > checkText("0123456789.,abracadabra", 23) > ); > } I ran the TextAreaBehaviorRobotTest on macOS 13.5.2. Test passed with my keyboard set to U.S. English and failed when set to French. TextAreaBehaviorRobotTest > testTyping() FAILED org.opentest4j.AssertionFailedError: in step 2 ==> expected: <0123456789.,abracadabra> but was: ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1327849342 From fastegal at openjdk.org Sat Sep 16 09:18:49 2023 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Sat, 16 Sep 2023 09:18:49 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> Message-ID: On Wed, 13 Sep 2023 12:06:44 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback: remove libxml2 2.10.3 doc-files/release-notes-21.md line 46: > 44: A compilation error will occur in one of the following two unlikely cases: > 45: > 46: * An application class extends `Menu`, `MenuItem`, `TreeColumnBase`, or `TreeItem`, and overrides `addEventHandler` or `removeEventHandler` hmm .. did I miss a new class (TreeColumnBase), or shouldn't that be TableColumnBase? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1327936721 From kcr at openjdk.org Sat Sep 16 13:48:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Sep 2023 13:48:17 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix typo: TreeColumnBase --> TableColumnBase ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1239/files - new: https://git.openjdk.org/jfx/pull/1239/files/27a3d810..a64c0396 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1239&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1239.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1239/head:pull/1239 PR: https://git.openjdk.org/jfx/pull/1239 From kcr at openjdk.org Sat Sep 16 13:48:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Sep 2023 13:48:18 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v3] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6IBYWw-bFwLYjYSUC8v0_lHAHYxsxEjDsohWjbFiRbs=.c49652e3-386c-4ed6-8a20-bef84f99e21b@github.com> Message-ID: On Sat, 16 Sep 2023 09:16:02 GMT, Jeanette Winzenburg wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback: remove libxml2 2.10.3 > > doc-files/release-notes-21.md line 46: > >> 44: A compilation error will occur in one of the following two unlikely cases: >> 45: >> 46: * An application class extends `Menu`, `MenuItem`, `TreeColumnBase`, or `TreeItem`, and overrides `addEventHandler` or `removeEventHandler` > > hmm .. did I miss a new class (TreeColumnBase), or shouldn't that be TableColumnBase? Well how embarrassing! Thanks for pointing out the typo that none of the rest of us saw. In addition to fixing the release notes, I'll update the Risk and Solution sections of the CSR, which is where the typo originated (the Specification section of the CSR has it right). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1327962489 From jhendrikx at openjdk.org Sat Sep 16 13:54:43 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 16 Sep 2023 13:54:43 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: <721-_NLHFUfZfJ6OJtKhyoJbk0acJfKhxy9sPGJPxk0=.42698549-c041-4137-b0da-c3090653a8cf@github.com> On Sat, 16 Sep 2023 13:48:17 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: TreeColumnBase --> TableColumnBase Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1629965383 From nlisker at openjdk.org Sat Sep 16 14:03:47 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 16 Sep 2023 14:03:47 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Sat, 16 Sep 2023 13:48:17 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: TreeColumnBase --> TableColumnBase doc-files/release-notes-21.md line 72: > 70: [JDK-8307363](https://bugs.openjdk.org/browse/JDK-8307363)|TextFlow.underlineShape()|graphics > 71: [JDK-8299756](https://bugs.openjdk.org/browse/JDK-8299756)|Minor updates in CSS Reference|other > 72: [JDK-8306648](https://bugs.openjdk.org/browse/JDK-8306648)|Update the JavaDocs to show the NEW section and DEPRECATED versions|other Should we mention somewhere that this doesn't always work properly because of [JDK-8309765](https://bugs.openjdk.org/browse/JDK-8309765)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1327964863 From kcr at openjdk.org Sat Sep 16 14:54:43 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Sep 2023 14:54:43 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: <_A8lgDwICpnAvq5jY44Z0s1KEbxTvlRqNteNRWZ82kE=.1b2b300c-1e9b-4acc-8680-0a8de753f444@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> <6a15IJFN_VpSggq6Btff1jw2ObhOR8B7YaEUlqvjC3k=.40e7f1b4-b9d0-4c91-be1c-dde8dfaefa91@github.com> <_A8lgDwICpnAvq5jY44Z0s1KEbxTvlRqNteNRWZ82kE=.1b2b300c-1e9b-4acc-8680-0a8de753f444@github.com> Message-ID: On Wed, 13 Sep 2023 12:21:49 GMT, Abhinay Agarwal wrote: >>> We should always use the base bug ID and never the backport ID, which for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). >> >> And to be clear I meant that the "base bug ID" for this bug is [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227). > > my bad, the release notes has the correct base bug id ? > > my local jfx21 release notes skipped [JDK-8313227](https://bugs.openjdk.org/browse/JDK-8313227) as it was labelled as `hgupdate-sync`. This will need some careful JBS query logic when I update it to properly handle backports. The `hgupdate-sync` label is specific to the particular record (backport or main bug) for a particular code line. So the `hgupdate-sync` label on the main bug mean that the bug should be skipped, but only for jfx22 (by virtue of the fact that it is in jfx21). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1327970439 From kcr at openjdk.org Sat Sep 16 15:01:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Sep 2023 15:01:44 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Sat, 16 Sep 2023 14:01:22 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo: TreeColumnBase --> TableColumnBase > > doc-files/release-notes-21.md line 72: > >> 70: [JDK-8307363](https://bugs.openjdk.org/browse/JDK-8307363)|TextFlow.underlineShape()|graphics >> 71: [JDK-8299756](https://bugs.openjdk.org/browse/JDK-8299756)|Minor updates in CSS Reference|other >> 72: [JDK-8306648](https://bugs.openjdk.org/browse/JDK-8306648)|Update the JavaDocs to show the NEW section and DEPRECATED versions|other > > Should we mention somewhere that this doesn't always work properly because of [JDK-8309765](https://bugs.openjdk.org/browse/JDK-8309765)? This bug doesn't rise to the level of "Important Changes", which are mainly intended to alert developers to possible compatibility issues, so there isn't a good place to add it. I suppose we could add a "Known Bugs" section to list bugs that are either regressions from a prior release or are bugs in newly added features, but I don't want to do that this late in the cycle, especially not without discussing the general idea of whether or not to list known bugs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1239#discussion_r1327971463 From nlisker at openjdk.org Sat Sep 16 16:32:43 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 16 Sep 2023 16:32:43 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Sat, 16 Sep 2023 13:48:17 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: TreeColumnBase --> TableColumnBase Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1629983809 From tsayao at openjdk.org Sun Sep 17 00:44:10 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Sep 2023 00:44:10 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v2] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Rework to use process_key - Merge branch 'master' into new_ime # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp - Rework to use process_key - Don't highlight for dead keys - Don't move the caret on preedit - Add function to return relative location of the caret (it's how it's handled on Linux). - Merge branch 'master' into new_ime - Merge branch 'master' into new_ime - Weird API - JavaFX does not currently supports surrouding - ... and 64 more: https://git.openjdk.org/jfx/compare/5e145cc0...7bbfa914 ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=01 Stats: 520 lines in 15 files changed: 122 ins; 268 del; 130 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Sep 17 00:44:11 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Sep 2023 00:44:11 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v2] In-Reply-To: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> References: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> Message-ID: <6WjA6kwUZebJ75G4Y64OdDO5SNmMGEt_qaNb_RtL7jo=.a8cf6425-b5a2-4f3a-89f5-da9a731b24fc@github.com> On Wed, 13 Sep 2023 15:52:43 GMT, Martin Fox wrote: >> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Rework to use process_key >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp >> - Rework to use process_key >> - Don't highlight for dead keys >> - Don't move the caret on preedit >> - Add function to return relative location of the caret (it's how it's handled on Linux). >> - Merge branch 'master' into new_ime >> - Merge branch 'master' into new_ime >> - Weird API >> - JavaFX does not currently supports surrouding >> - ... and 64 more: https://git.openjdk.org/jfx/compare/5e145cc0...7bbfa914 > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 91: > >> 89: void WindowContextBase::commitIME(gchar *str) { >> 90: if (!im_ctx.on_preedit) { >> 91: jchar key = g_utf8_get_char(str); > > This block is trying to set up calls to View.notifyKey. To get the correct KeyCode requires information in the original GdkEventKey like the hardware code and modifier state (for handling Num Lock on the key pad). The simplest solution is to record a pointer to the original GdkEventKey before calling `gtk_im_context_filter_keypress` and here pass that pointer to `process_key`. It will get the KeyCode right and generate the appropriate View.notifyKey calls. > > (In theory another approach is to ignore the commit and return 'false' from filterIME so the original GdkEvent isn't filtered. I tried that but it turned into a mess because I was seeing two key press events for every keystroke. `gtk_im_context_filter_keypress` filters out the original key press event without generating a commit. Instead it posts a duplicate event with a private modifier flag set and the commit signal is sent out when that second event is passed to `gtk_im_context_filter_keypress`.) I did change it, but probably need some more work. I also discovered that I probably should use the `PANGO_ATTR_*` to set the `IME_ATTR_*` with boundaries. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1328025313 From tsayao at openjdk.org Sun Sep 17 22:07:10 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Sep 2023 22:07:10 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v3] In-Reply-To: References: Message-ID: <5zHf3EyUKQFpjOsjEQpn7eolaK9AGFmcqg8wRM2qwz0=.3106cf53-e514-4daa-a724-708b57e35da7@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: begin to use pango_attrs ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/7bbfa914..6bbecc15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=01-02 Stats: 71 lines in 4 files changed: 26 ins; 24 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Sep 17 22:50:12 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Sep 2023 22:50:12 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v4] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix Tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/6bbecc15..1a72a4ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=02-03 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Sep 17 23:56:19 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 17 Sep 2023 23:56:19 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v5] In-Reply-To: References: Message-ID: <5Vza1O6n1sRa7VCQEMGQMDC-XHMY-jToXAeUe3Dsyik=.5f57dc16-03a0-4737-9f5c-7ae8e67fbf5d@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix cursor pos (works for dead keys now) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/1a72a4ac..38729bea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=03-04 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Mon Sep 18 00:34:17 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Sep 2023 00:34:17 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v6] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix highlight ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/38729bea..521d0911 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=04-05 Stats: 77 lines in 5 files changed: 18 ins; 44 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Mon Sep 18 00:48:15 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Sep 2023 00:48:15 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v7] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Forgot one check ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/521d0911..61fe8ff3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Mon Sep 18 00:48:16 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Sep 2023 00:48:16 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v7] In-Reply-To: <6WjA6kwUZebJ75G4Y64OdDO5SNmMGEt_qaNb_RtL7jo=.a8cf6425-b5a2-4f3a-89f5-da9a731b24fc@github.com> References: <6aYACq53hvf6--PclCPNCZfdac1-UiQ4swUjADxZXG8=.793252e9-bfd1-4f6f-af6a-e1233481a41c@github.com> <6WjA6kwUZebJ75G4Y64OdDO5SNmMGEt_qaNb_RtL7jo=.a8cf6425-b5a2-4f3a-89f5-da9a731b24fc@github.com> Message-ID: On Sun, 17 Sep 2023 00:39:45 GMT, Thiago Milczarek Sayao wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 91: >> >>> 89: void WindowContextBase::commitIME(gchar *str) { >>> 90: if (!im_ctx.on_preedit) { >>> 91: jchar key = g_utf8_get_char(str); >> >> This block is trying to set up calls to View.notifyKey. To get the correct KeyCode requires information in the original GdkEventKey like the hardware code and modifier state (for handling Num Lock on the key pad). The simplest solution is to record a pointer to the original GdkEventKey before calling `gtk_im_context_filter_keypress` and here pass that pointer to `process_key`. It will get the KeyCode right and generate the appropriate View.notifyKey calls. >> >> (In theory another approach is to ignore the commit and return 'false' from filterIME so the original GdkEvent isn't filtered. I tried that but it turned into a mess because I was seeing two key press events for every keystroke. `gtk_im_context_filter_keypress` filters out the original key press event without generating a commit. Instead it posts a duplicate event with a private modifier flag set and the commit signal is sent out when that second event is passed to `gtk_im_context_filter_keypress`.) > > I did change it, but probably need some more work. > > I also discovered that I probably should use the `PANGO_ATTR_*` to set the `IME_ATTR_*` with boundaries. I did a simple logic that if filtered and commit is sent directly without a preedit it will send the event back to `process_key`. It seems to work but I'm not sure about an unknown complex scenario. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1328177741 From tsayao at openjdk.org Mon Sep 18 00:48:16 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 18 Sep 2023 00:48:16 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v6] In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 00:34:17 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 03-09-2023 19:10:36.webm](https://github.com/openjdk/jfx/assets/30704286/2a36e9d0-59be-4092-905f-e31fabc6e2e4) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix highlight I think it's usable now. I'm not really sure because I'm on unknown land here :). To my understanding the gtk ime system will use only one preedit attribute which I detect on pango attribute list where: - `PANGO_ATTR_BACKGROUND`: it's a IME preedit suggestion and must be highlighted - `PANGO_ATTR_UNDERLINE`: it's a dead key otherwise it's a normal input (probably will never hit this case on preedit as it will go to commit directly). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1722621185 From lkostyra at openjdk.org Mon Sep 18 07:09:47 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 18 Sep 2023 07:09:47 GMT Subject: Integrated: 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 15:20:36 GMT, Lukasz Kostyra wrote: > The instability came from the way Windows sets window's default position. When it is not predefined on Stage creation (which was the case in these Robot tests) the window is created at some arbitrary position chosen by Windows near top-left corner. It also seems like Windows first picks the position assuming 100% scaling and then multiplies it by UI scale, which can provide X/Y coordinates of Stage with a fractional value. > > Due to above behavior, there is a chance that the fractional part of X/Y will be above .5 which fails the test (X/Y values were fetched via casting directly to `int`, which drops the fractional part without rounding). Adding rounding makes the test always pass and the assumption in the comment below consistent. > > `unstable.test` property check was removed, since this change stabilizes the test and its results. > > Verified also on macOS to ensure the change did not affect the tests. This pull request has now been integrated. Changeset: 2ae8c270 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/2ae8c270ea99c2e979e4922a9652363f59d4b293 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1242 From lkostyra at openjdk.org Mon Sep 18 09:42:45 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 18 Sep 2023 09:42:45 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v2] In-Reply-To: <8pTftHhTlFIP0jqZnNoQ_Xibwucl2L_M75O4cfCe4m4=.b5f0d754-5ebc-4da8-9bdf-c6fe5cde6c33@github.com> References: <8pTftHhTlFIP0jqZnNoQ_Xibwucl2L_M75O4cfCe4m4=.b5f0d754-5ebc-4da8-9bdf-c6fe5cde6c33@github.com> Message-ID: On Fri, 15 Sep 2023 15:21:45 GMT, Kevin Rushforth wrote: > I don't see a bug tracking the failure of a maximized window. [JDK-8253997](https://bugs.openjdk.org/browse/JDK-8253997) describes a problem where the window is shown normal size and then animated to maximized I found out this is a problem when trying to call `setMaximized(true)` after establishing Stage position with `setX()` and `setY()`. Seems like a separate issue, I will file a bug with the test program I just made (also it is macOS exclusive, Windows handles this just fine). > Yes, it does seem like there are two or three product bugs on Linux. Can you file new bugs, and then use those bug IDs to exclude the failing tests on Linux? I'll test this on Ubuntu and see if that behaves differently than Fedora. Will do. I'll also attach test programs for these. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1240#issuecomment-1723067395 From lkostyra at openjdk.org Mon Sep 18 13:11:32 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 18 Sep 2023 13:11:32 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v3] In-Reply-To: References: Message-ID: > PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. > > Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Skip select failing tests on Linux and macOS ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1240/files - new: https://git.openjdk.org/jfx/pull/1240/files/819144b8..94fa4083 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=01-02 Stats: 34 lines in 1 file changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1240.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1240/head:pull/1240 PR: https://git.openjdk.org/jfx/pull/1240 From lkostyra at openjdk.org Mon Sep 18 13:14:34 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 18 Sep 2023 13:14:34 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v4] In-Reply-To: References: Message-ID: > PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. > > All variants are tested with decorated stage style. > > Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. > > Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. > > **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. > > Verified to work on Windows 11, macOS and Linux. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Fix skip comment on testMaximizedStageBeforeShow Comment pointed at wrong JDK issue (aka. Copy-Paste's Error) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1240/files - new: https://git.openjdk.org/jfx/pull/1240/files/94fa4083..37e3d31a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1240&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1240.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1240/head:pull/1240 PR: https://git.openjdk.org/jfx/pull/1240 From kcr at openjdk.org Mon Sep 18 14:26:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 14:26:51 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v4] In-Reply-To: References: Message-ID: <94GwSsqS-dubw-TzzSooUTXS5Ai4jnF1V4K9zOggp30=.8f320f01-8749-4172-b965-1f6c6e255881@github.com> On Mon, 18 Sep 2023 13:14:34 GMT, Lukasz Kostyra wrote: >> PR adds tests mentioned in the title - a new `AttributesTest` class is added testing iconification, maximization and full-screen-ification of a Stage. >> >> All variants are tested with decorated stage style. >> >> Iconification is tested via overlaying two stages on top of one another, and then iconifying the top one - this is similar to already existing `IconifyTest.java` but it tests just the iconfication process and nothing more. >> >> Maximization and FullScreen are both tested by creating two stages _not_ overlapping each other. After maximization/fullscreen top stage (being always on top as well) should cover the bottom stage. Moreover, FullScreen and Maximize are differentiated by checking if window decoration exists - maximized Stage will have its decoration taking space on top of the screen, whereas FullScreen one will not. >> >> **NOTE:** on macOS I had issues with `getColor()` returning a valid color when called a second time. This only happened on macOS and with FullScreen test (others worked fine). Unfortunately I couldn't figure out why it returned (0, 0, 0, 255) or (255, 255, 255, 255). To mitigate that I moved color checks into separate `runAndWait()`-s with a small sleep between them, which seemed to help `getColor()` return proper values. >> >> Verified to work on Windows 11, macOS and Linux. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Fix skip comment on testMaximizedStageBeforeShow > > Comment pointed at wrong JDK issue (aka. Copy-Paste's Error) On Windows 10 system, several tests fail for me: StageAttributesTest > testFullScreenStageBeforeShow FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(42,244,71,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testFullScreenStageBeforeShow$17(StageAttributesTest.java:298) StageAttributesTest > testIconifiedStageBeforeShow FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(28,248,48,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testIconifiedStageBeforeShow$12(StageAttributesTest.java:226) StageAttributesTest > testMaximizedStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(23,249,38,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testMaximizedStage$6(StageAttributesTest.java:147) StageAttributesTest > testFullScreenStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(28,248,48,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testFullScreenStage$9(StageAttributesTest.java:185) StageAttributesTest > testIconifiedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(177,84,13,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testIconifiedStage$4(StageAttributesTest.java:122) StageAttributesTest > testMaximizedStageBeforeShow FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(23,249,39,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:173) at test.robot.javafx.stage.StageAttributesTest.lambda$testMaximizedStageBeforeShow$14(StageAttributesTest.java:258) I tracked this down to a missing sleep in `setupStages` (see inline comments). tests/system/src/test/java/test/robot/javafx/stage/StageAttributesTest.java line 109: > 107: assertTrue("Timeout waiting for top stage to be shown", > 108: topShownLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); > 109: } Several tests fail for me without an additional sleep. I recommend adding `Util.sleep(1000)` here. tests/system/src/test/java/test/robot/javafx/stage/StageAttributesTest.java line 128: > 126: > 127: // wait a bit to let window system animate the change > 128: Util.waitForIdle(topScene); In looking at this more closely, this change should be reverted back to using `sleep(1000)`. `Util.waitForIdle` is intended to wait for scene graph changes to be propagated, not for platform windowing operations to settle down, so using it could lead to intermittent failures. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1240#pullrequestreview-1631184924 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1328803323 PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1328809860 From kcr at openjdk.org Mon Sep 18 14:29:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 14:29:53 GMT Subject: RFR: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen) [v4] In-Reply-To: References: Message-ID: <5p0CEr6e6OHlE1uB1xKzwT1VAn4cvdTyI28du-0Gnqo=.7640362b-e92a-4c60-b45b-09a4ecf8e199@github.com> On Wed, 13 Sep 2023 15:05:49 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix skip comment on testMaximizedStageBeforeShow >> >> Comment pointed at wrong JDK issue (aka. Copy-Paste's Error) > > tests/system/src/test/java/test/robot/javafx/stage/AttributesTest.java line 134: > >> 132: >> 133: // wait a bit to let window system animate the change >> 134: sleep(1000); > > could we use Util.waitForIdle() here instead of the fixed timeout? Actually, no. This isn't the intended use case for `waitForIdle`. That method should only be used when waiting for scene graph changes to propagate, not for the platform to finish showing or animating a window. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1240#discussion_r1328815606 From angorya at openjdk.org Mon Sep 18 14:45:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 14:45:48 GMT Subject: RFR: 8316135: Create release notes for JavaFX 21 [v4] In-Reply-To: References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: <2ZJ0aB6ZEElI310iqAojdNYVIvtRWZHnbUtiG9IWba0=.7e4732a2-acb3-4a08-9281-6da6df707f8d@github.com> On Sat, 16 Sep 2023 13:48:17 GMT, Kevin Rushforth wrote: >> Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. >> >> I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: TreeColumnBase --> TableColumnBase Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1239#pullrequestreview-1631243621 From kcr at openjdk.org Mon Sep 18 15:34:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 15:34:54 GMT Subject: Integrated: 8316135: Create release notes for JavaFX 21 In-Reply-To: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> References: <6RqZrpO8DbmkaOl1Z-rJ7NJVq2CtyQgCP8A4v2B-6Nc=.72143deb-05d7-44cb-a052-534047d9e029@github.com> Message-ID: On Tue, 12 Sep 2023 17:14:28 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 21, including four important changes, and the list of enhancements and bugs fixed in this release. > > I plan to integrate this on Monday, Sep 18th, and backport it to `jfx21` in time for Tuesday's release of JavaFX 21. This pull request has now been integrated. Changeset: fa73e0d2 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/fa73e0d247dcadc8f80586c52ba7f92f3bb7eadb Stats: 153 lines in 1 file changed: 153 ins; 0 del; 0 mod 8316135: Create release notes for JavaFX 21 Reviewed-by: angorya, jhendrikx, nlisker ------------- PR: https://git.openjdk.org/jfx/pull/1239 From kcr at openjdk.org Mon Sep 18 15:52:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 15:52:10 GMT Subject: [jfx21] RFR: 8316135: Create release notes for JavaFX 21 Message-ID: This is a necessary backport of the JavaFX 21 release notes to the `jfx21` branch. We will _not_ tag `jfx21` nor rebuild JavaFX 21 as a result of this commit. ------------- Commit messages: - Backport fa73e0d247dcadc8f80586c52ba7f92f3bb7eadb Changes: https://git.openjdk.org/jfx/pull/1243/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316135 Stats: 153 lines in 1 file changed: 153 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1243.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1243/head:pull/1243 PR: https://git.openjdk.org/jfx/pull/1243 From kcr at openjdk.org Mon Sep 18 15:52:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 15:52:10 GMT Subject: [jfx21] RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 15:39:18 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 21 release notes to the `jfx21` branch. We will _not_ tag `jfx21` nor rebuild JavaFX 21 as a result of this commit. @andy-goryachev-oracle Can you do a quick review of this clean backport? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1243#issuecomment-1723778550 From angorya at openjdk.org Mon Sep 18 16:25:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 16:25:49 GMT Subject: [jfx21] RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 15:39:18 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 21 release notes to the `jfx21` branch. We will _not_ tag `jfx21` nor rebuild JavaFX 21 as a result of this commit. looks good. will this create a merge conflict down the road? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1243#pullrequestreview-1631480621 From kcr at openjdk.org Mon Sep 18 16:37:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 16:37:45 GMT Subject: [jfx21] RFR: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 16:23:02 GMT, Andy Goryachev wrote: > will this create a merge conflict down the road? No it won't, since there will not be a merge at all. As of JDK 21 and JavaFX 21, the [rampdown procedure](https://mail.openjdk.org/pipermail/openjfx-dev/2023-July/041453.html) has changed to no longer merge the stabilization branch back to master. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1243#issuecomment-1723911087 From kcr at openjdk.org Mon Sep 18 16:41:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 16:41:47 GMT Subject: [jfx21] Integrated: 8316135: Create release notes for JavaFX 21 In-Reply-To: References: Message-ID: On Mon, 18 Sep 2023 15:39:18 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 21 release notes to the `jfx21` branch. We will _not_ tag `jfx21` nor rebuild JavaFX 21 as a result of this commit. This pull request has now been integrated. Changeset: 1b71f5b6 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1b71f5b63e8afa2575e0bde6d0a42ecb2e0ecde8 Stats: 153 lines in 1 file changed: 153 ins; 0 del; 0 mod 8316135: Create release notes for JavaFX 21 Reviewed-by: angorya Backport-of: fa73e0d247dcadc8f80586c52ba7f92f3bb7eadb ------------- PR: https://git.openjdk.org/jfx/pull/1243 From angorya at openjdk.org Mon Sep 18 16:44:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 16:44:49 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> Message-ID: On Fri, 15 Sep 2023 23:02:12 GMT, Martin Fox wrote: >> Interesting. >> >> It is my understanding though that for the purposes of this test it should work as expected. I've added `TextAreaBehaviorRobotTest.testTyping()` - could you try running it with your setup please? >> >> >> @Test >> public void testTyping() throws Exception { >> execute( >> //addKeyListener(), >> "0123456789.,abracadabra", >> checkText("0123456789.,abracadabra", 23) >> ); >> } > > I ran the TextAreaBehaviorRobotTest on macOS 13.5.2. Test passed with my keyboard set to U.S. English and failed when set to French. > > > TextAreaBehaviorRobotTest > testTyping() FAILED > org.opentest4j.AssertionFailedError: in step 2 ==> expected: <0123456789.,abracadabra> but was: Merci, Monsieur Fox! We seem to have quite a few tickets in this area (who created the first one in the list?): * [JDK-8278924](https://bugs.openjdk.org/browse/JDK-8278924) [Linux] Robot key test can fail if multiple keyboard layouts are installed * [JDK-8022079](https://bugs.openjdk.org/browse/JDK-8022079) [macosx] swing shortcuts are counterintuitive with non-english keyboard layouts * [JDK-8087915](https://bugs.openjdk.org/browse/JDK-8087915) Mac: accelerator doesn't take into account azerty keyboard layout * [JDK-4760902](https://bugs.openjdk.org/browse/JDK-4760902) java.awt.Robot can't generate % character on FRENCH keyboard Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( I have no idea how to fix this test... We could try to introduce a translation layer to emit the right sequences (for each keyboard layout), or, alternatively, we could skip the tests altogether for non-US keyboard, except ... there seems to be no easy way to determine the keyboard layout? (There are some suggestions involving InputContext or JNI on stackoverflow). We could also try to skip the test if Locale.getDefault is other than Locale.US, not sure if that would solve the issue. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329010494 From kcr at openjdk.org Mon Sep 18 17:19:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 18 Sep 2023 17:19:49 GMT Subject: RFR: 8307176: Monkey Tester Application Part 2 [v2] In-Reply-To: References: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> Message-ID: <_conOjCzVHHxbliSrAc7hpzkrjZIk32Qqsc_K_X72Vk=.f028035e-14d4-4471-a504-39af51c6fc7e@github.com> On Fri, 15 Sep 2023 20:14:45 GMT, Andy Goryachev wrote: >> Adding changes to the MonkeyTester application accumulated since the last test sprint, from a separate repository >> https://github.com/andy-goryachev-oracle/MonkeyTest >> >> User preferences location: >> The applications stores its user preferences (window location, etc.) in ~/.MonkeyTester directory. >> - To use a different directory, redefine the "user.home" system property, -Duser.home=<...>. >> - To disable saving, specify -Ddisable.settings=true vm agrument. >> >> - ? replace setId() with some other way of setting component name >> - ? change property for ui.settings dir >> - ? add pie chart >> - ? ComboBox: The current two buttons don't seem all that useful. I'm not even sure what, exactly, they do. What would be useful is a way to select the number of items in the list (like there is with ChoiceBox) >> - ? ListView: Changing the selection model or checking / unchecking the "null focus model" option clears the list, which is unexpected. Given that there is a separate "clear list" button, it doesn't seem needed either. >> - ? TextField: The default alignment of BASELINE_RIGHT is unexpected (unless there is a good reason, defaults for properties should match the API default to avoid surprises). >> - ? Menu item: Window --> Open Modal Window "Platform.exit()" should not be the default choice (if you press the app will exit) >> - ? TableView: The column sorting feature would be more useful if it were possible to have different data for each row >> - ? Add Skin -> (null skin, set new skin) menus to all related controls to enable leak tests >> - ? TableView: cell factory, cell value factory >> - ? TreeTableView: cell factory >> - ? TreeView: cell factory >> - ? add massive CJK text for JDK-8090110 / JDK-8089418 >> - ? clipboard monitor tool >> - ? add to the status bar: JVM version, JFX version, current directory, screen scale >> - ? WebView page >> - ? Tools -> Keyboard Events Viewer >> >> To be continued... JDK-8316372 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > keyboard event viewer Reviewers: @karthikpandelu @aghaisas ------------- PR Comment: https://git.openjdk.org/jfx/pull/1241#issuecomment-1724032703 From angorya at openjdk.org Mon Sep 18 18:00:34 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 18:00:34 GMT Subject: RFR: 8307176: Monkey Tester Application Part 2 [v3] In-Reply-To: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> References: <-VvcqwHDezQY4CgclWWcyuLvoEbzhFk7kNaudY5SO3I=.81abca48-4feb-4d2d-9620-4acdf3519d91@github.com> Message-ID: > Adding changes to the MonkeyTester application accumulated since the last test sprint, from a separate repository > https://github.com/andy-goryachev-oracle/MonkeyTest > > User preferences location: > The applications stores its user preferences (window location, etc.) in ~/.MonkeyTester directory. > - To use a different directory, redefine the "user.home" system property, -Duser.home=<...>. > - To disable saving, specify -Ddisable.settings=true vm agrument. > > - ? replace setId() with some other way of setting component name > - ? change property for ui.settings dir > - ? add pie chart > - ? ComboBox: The current two buttons don't seem all that useful. I'm not even sure what, exactly, they do. What would be useful is a way to select the number of items in the list (like there is with ChoiceBox) > - ? ListView: Changing the selection model or checking / unchecking the "null focus model" option clears the list, which is unexpected. Given that there is a separate "clear list" button, it doesn't seem needed either. > - ? TextField: The default alignment of BASELINE_RIGHT is unexpected (unless there is a good reason, defaults for properties should match the API default to avoid surprises). > - ? Menu item: Window --> Open Modal Window "Platform.exit()" should not be the default choice (if you press the app will exit) > - ? TableView: The column sorting feature would be more useful if it were possible to have different data for each row > - ? Add Skin -> (null skin, set new skin) menus to all related controls to enable leak tests > - ? TableView: cell factory, cell value factory > - ? TreeTableView: cell factory > - ? TreeView: cell factory > - ? add massive CJK text for JDK-8090110 / JDK-8089418 > - ? clipboard monitor tool > - ? add to the status bar: JVM version, JFX version, current directory, screen scale > - ? WebView page > - ? Tools -> Keyboard Events Viewer > - ? System Info tool that reports all the details about the environment such as reported OS version, number of displays, env, system properties > > To be continued... JDK-8316372 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: system info ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1241/files - new: https://git.openjdk.org/jfx/pull/1241/files/aef9f54e..5ba98186 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1241&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1241&range=01-02 Stats: 227 lines in 3 files changed: 227 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1241.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1241/head:pull/1241 PR: https://git.openjdk.org/jfx/pull/1241 From duke at openjdk.org Mon Sep 18 20:01:47 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 18 Sep 2023 20:01:47 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> Message-ID: On Mon, 18 Sep 2023 16:42:31 GMT, Andy Goryachev wrote: >> I ran the TextAreaBehaviorRobotTest on macOS 13.5.2. Test passed with my keyboard set to U.S. English and failed when set to French. >> >> >> TextAreaBehaviorRobotTest > testTyping() FAILED >> org.opentest4j.AssertionFailedError: in step 2 ==> expected: <0123456789.,abracadabra> but was: > > Merci, Monsieur Fox! > > We seem to have quite a few tickets in this area (who created the first one in the list?): > > * [JDK-8278924](https://bugs.openjdk.org/browse/JDK-8278924) [Linux] Robot key test can fail if multiple keyboard layouts are installed > * [JDK-8022079](https://bugs.openjdk.org/browse/JDK-8022079) [macosx] swing shortcuts are counterintuitive with non-english keyboard layouts > * [JDK-8087915](https://bugs.openjdk.org/browse/JDK-8087915) Mac: accelerator doesn't take into account azerty keyboard layout > * [JDK-4760902](https://bugs.openjdk.org/browse/JDK-4760902) java.awt.Robot can't generate % character on FRENCH keyboard > > Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( > > I have no idea how to fix this test... We could try to introduce a translation layer to emit the right sequences (for each keyboard layout), or, alternatively, we could skip the tests altogether for non-US keyboard, except ... there seems to be no easy way to determine the keyboard layout? (There are some suggestions involving InputContext or JNI on stackoverflow). We could also try to skip the test if Locale.getDefault is other than Locale.US, not sure if that would solve the issue. > > What do you think? The problem you're running into here isn't due to any bug in JavaFX. The way KeyCodes identify keys works well for defining accelerators but not for using a Robot to generate a specific printable character. As an extreme example, if you're using a Greek keyboard there will be a key that has KeyCode.Z assigned to it so you can use Shortcut+Z to invoke Undo. But that key will generate a Greek letter when pressed by a human or a Robot. You can probably assume that anyone running these tests is using a Latin/Roman keyboard that can generate the lower-case letters a-z so one approach is to just stick to those characters in the typing tests. The other is to try to identify the layout using a Robot. For example, send KeyCode.DIGIT1 and see if that generates a '1'. If not you're probably on a French layout. Punctation and symbols are hopeless, there's just too much variation in the keyboard layouts. > Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( Could you provide more details (platform, keyboard, keyboard layout, etc.)? On the Mac PR #425 cleaned all this up in jfx21. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329214340 From angorya at openjdk.org Mon Sep 18 20:24:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 20:24:48 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> Message-ID: On Mon, 18 Sep 2023 19:59:30 GMT, Martin Fox wrote: >> Merci, Monsieur Fox! >> >> We seem to have quite a few tickets in this area (who created the first one in the list?): >> >> * [JDK-8278924](https://bugs.openjdk.org/browse/JDK-8278924) [Linux] Robot key test can fail if multiple keyboard layouts are installed >> * [JDK-8022079](https://bugs.openjdk.org/browse/JDK-8022079) [macosx] swing shortcuts are counterintuitive with non-english keyboard layouts >> * [JDK-8087915](https://bugs.openjdk.org/browse/JDK-8087915) Mac: accelerator doesn't take into account azerty keyboard layout >> * [JDK-4760902](https://bugs.openjdk.org/browse/JDK-4760902) java.awt.Robot can't generate % character on FRENCH keyboard >> >> Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( >> >> I have no idea how to fix this test... We could try to introduce a translation layer to emit the right sequences (for each keyboard layout), or, alternatively, we could skip the tests altogether for non-US keyboard, except ... there seems to be no easy way to determine the keyboard layout? (There are some suggestions involving InputContext or JNI on stackoverflow). We could also try to skip the test if Locale.getDefault is other than Locale.US, not sure if that would solve the issue. >> >> What do you think? > > The problem you're running into here isn't due to any bug in JavaFX. The way KeyCodes identify keys works well for defining accelerators but not for using a Robot to generate a specific printable character. As an extreme example, if you're using a Greek keyboard there will be a key that has KeyCode.Z assigned to it so you can use Shortcut+Z to invoke Undo. But that key will generate a Greek letter when pressed by a human or a Robot. > > You can probably assume that anyone running these tests is using a Latin/Roman keyboard that can generate the lower-case letters a-z so one approach is to just stick to those characters in the typing tests. The other is to try to identify the layout using a Robot. For example, send KeyCode.DIGIT1 and see if that generates a '1'. If not you're probably on a French layout. > > Punctation and symbols are hopeless, there's just too much variation in the keyboard layouts. > >> Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( > > Could you provide more details (platform, keyboard, keyboard layout, etc.)? On the Mac PR #425 cleaned all this up in jfx21. I am running this on macOS 13.5.1 with several keyboard layouts enabled. A test that does keyPress(KecCode.A) followed by a keyRelease(KeyCode.A) generates the following sequence of events: With the US layout: KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = a, code = A] KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = a, text = , code = UNDEFINED] KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = a, code = A] With the French layout: KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = q, code = A] KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = q, text = , code = UNDEFINED] KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = q, code = A] And with a cyrillic layout it generates whatever cyrillic letter is mapped to the key. So, basically, KeyCode is more like a scan code, which means there is no reliable way to test key bindings using Robot, unless we limit ourselves (and the test) to the US layout. Or is there another way? Screenshot 2023-09-18 at 13 19 51 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329233409 From duke at openjdk.org Mon Sep 18 20:54:46 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 18 Sep 2023 20:54:46 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> Message-ID: On Mon, 18 Sep 2023 20:22:21 GMT, Andy Goryachev wrote: >> The problem you're running into here isn't due to any bug in JavaFX. The way KeyCodes identify keys works well for defining accelerators but not for using a Robot to generate a specific printable character. As an extreme example, if you're using a Greek keyboard there will be a key that has KeyCode.Z assigned to it so you can use Shortcut+Z to invoke Undo. But that key will generate a Greek letter when pressed by a human or a Robot. >> >> You can probably assume that anyone running these tests is using a Latin/Roman keyboard that can generate the lower-case letters a-z so one approach is to just stick to those characters in the typing tests. The other is to try to identify the layout using a Robot. For example, send KeyCode.DIGIT1 and see if that generates a '1'. If not you're probably on a French layout. >> >> Punctation and symbols are hopeless, there's just too much variation in the keyboard layouts. >> >>> Not only we get key events for wrong characters, but also shortcut(A) generates `character = q, text = , code = UNDEFINED, metaDown, shortcutDown]` which closes the test app :-( >> >> Could you provide more details (platform, keyboard, keyboard layout, etc.)? On the Mac PR #425 cleaned all this up in jfx21. > > I am running this on macOS 13.5.1 with several keyboard layouts enabled. > > A test that does keyPress(KeyCode.A) followed by a keyRelease(KeyCode.A) generates the following sequence of events: > > With the US layout: > > > KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = a, code = A] > KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = a, text = , code = UNDEFINED] > KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = a, code = A] > > > With the French layout: > > > KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = q, code = A] > KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = q, text = , code = UNDEFINED] > KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = q, code = A] > > > And with a cyrillic layout it generates whatever cyrillic letter is mapped to the key. So, basically, KeyCode is more like a scan code, which means there is no reliable way to test key bindings using Robot, unless we limit ourselves (and the test) to the US layout. Or is there another way? > > Screenshot 2023-09-18 at 13 19 51 This is the behavior we saw on the Mac before PR #425 was integrated. As of JavaFX 21 keyPress(KeyCode.A) should generate an 'a' and never a 'q' on all Latin layouts and all platforms (on a Cyrillic layout you'll still get a Cyrillic character). I can't reproduce this with the test app (tests/manual/events/KeyboardTest.java). Is there a test in this PR I should be trying? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329266886 From angorya at openjdk.org Mon Sep 18 21:16:45 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Sep 2023 21:16:45 GMT Subject: RFR: 8314906: [testbug] Create behavior tests for text input controls [v5] In-Reply-To: References: <8urJjtTrPNN6JtvbbQ81GpP8sQQ3WhpGW9UK0UjskqA=.610724aa-4a29-404e-9156-a441aaa7a4fa@github.com> <78qhtygTTyKLJ_j0VdhNAtrpv-Lzc4Nn6HY8oLV4fYU=.e16ae1aa-46a2-4324-aa6c-955ac62b8d0e@github.com> Message-ID: On Mon, 18 Sep 2023 20:51:47 GMT, Martin Fox wrote: >> I am running this on macOS 13.5.1 with several keyboard layouts enabled. >> >> A test that does keyPress(KeyCode.A) followed by a keyRelease(KeyCode.A) generates the following sequence of events: >> >> With the US layout: >> >> >> KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = a, code = A] >> KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = a, text = , code = UNDEFINED] >> KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = a, code = A] >> >> >> With the French layout: >> >> >> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = q, code = A] >> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = q, text = , code = UNDEFINED] >> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = q, code = A] >> >> >> And with a cyrillic layout it generates whatever cyrillic letter is mapped to the key. So, basically, KeyCode is more like a scan code, which means there is no reliable way to test key bindings using Robot, unless we limit ourselves (and the test) to the US layout. Or is there another way? >> >> Screenshot 2023-09-18 at 13 19 51 > > This is the behavior we saw on the Mac before PR #425 was integrated. As of JavaFX 21 keyPress(KeyCode.A) should generate an 'a' and never a 'q' on all Latin layouts and all platforms (on a Cyrillic layout you'll still get a Cyrillic character). > > I can't reproduce this with the test app (tests/manual/events/KeyboardTest.java). Is there a test in this PR I should be trying? You could try this code (using this PR's code): public class KeyboardLayoutTest extends TextInputBehaviorRobotTest
Windows
{@code Windows.SPI.HighContrast}{@link Boolean}
Windows
{@code Windows.SPI.HighContrast}{@link Boolean}
Windows
{@code Windows.SPI.HighContrast}{@link Boolean}