From arapte at openjdk.org Mon Aug 1 12:57:48 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 1 Aug 2022 12:57:48 GMT Subject: [jfx19] RFR: 8291588: Update boot JDK to 18.0.2 Message-ID: Update Boot JDK to 18.0.2. Tested build on all platforms and full test run on MacOS Catalina. ------------- Commit messages: - 8291588: Update boot JDK to 18.0.2 Changes: https://git.openjdk.org/jfx/pull/857/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291588 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/857.diff Fetch: git fetch https://git.openjdk.org/jfx pull/857/head:pull/857 PR: https://git.openjdk.org/jfx/pull/857 From kcr at openjdk.org Mon Aug 1 13:06:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 13:06:06 GMT Subject: [jfx19] RFR: 8291588: Update boot JDK to 18.0.2 In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 12:06:31 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.2. > Tested build on all platforms and full test run on MacOS Catalina. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/857 From nlisker at gmail.com Mon Aug 1 15:28:33 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 1 Aug 2022 18:28:33 +0300 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <20220715121854.Horde.FlmIMnPdvjjysdSD89SmYyj@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: But that has no effect on previous JavaFX builds, I don't see a retroactive value here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Aug 1 15:32:28 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Aug 2022 08:32:28 -0700 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> Message-ID: <5d1ed15e-b1ec-a01e-1a27-d74abb7cc8cf@oracle.com> I was going to ask the same question. Let's just fix this in the mainline jfx release. Developers are only going to care about jfx19 for another 4 days. -- Kevin On 8/1/2022 8:20 AM, Nir Lisker wrote: > What's the value of backporting a build change? > > On Mon, Aug 1, 2022 at 6:16 PM Andy Goryachev > wrote: > > Nir: > > I am planning to create a PR today which fixes all the build and > test issues in apps/ and buildSrc/ > > I'll ask Kevin to backport the changes to jfx19. > > Cheers, > > -andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Aug 1 15:33:07 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 Aug 2022 15:33:07 +0000 Subject: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader In-Reply-To: <5d1ed15e-b1ec-a01e-1a27-d74abb7cc8cf@oracle.com> References: <20220715114406.Horde.RrhaNBe-GeQVSOhZp8gHsY4@webmail.df.eu> <8d1f8597-94d0-b691-9e73-0b1b3181edd4@oracle.com> <5d1ed15e-b1ec-a01e-1a27-d74abb7cc8cf@oracle.com> Message-ID: Sounds good to me. -andy From: Kevin Rushforth Date: Monday, 2022/08/01 at 08:32 To: Nir Lisker , Andy Goryachev Cc: Jeanette Winzenburg , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Eclipse: ClassNotFoundException: com.sun.prism.shader.FillPgram_Color_Loader I was going to ask the same question. Let's just fix this in the mainline jfx release. Developers are only going to care about jfx19 for another 4 days. -- Kevin On 8/1/2022 8:20 AM, Nir Lisker wrote: What's the value of backporting a build change? On Mon, Aug 1, 2022 at 6:16 PM Andy Goryachev > wrote: Nir: I am planning to create a PR today which fixes all the build and test issues in apps/ and buildSrc/ I'll ask Kevin to backport the changes to jfx19. Cheers, -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Mon Aug 1 15:42:08 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 1 Aug 2022 15:42:08 GMT Subject: [jfx19] Integrated: 8291588: Update boot JDK to 18.0.2 In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 12:06:31 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.2. > Tested build on all platforms and full test run on MacOS Catalina. This pull request has now been integrated. Changeset: 8fa89199 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/8fa89199e2d07763a3aaab3f3a7904c73457d4a0 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8291588: Update boot JDK to 18.0.2 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/857 From mstrauss at openjdk.org Mon Aug 1 16:30:06 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 1 Aug 2022 16:30:06 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner In-Reply-To: References: Message-ID: <-L4lyCipZaYb4GOi-jGNE6Z0mY0vbRXPRoqO3HzNIqI=.1822f90d-f1e9-411d-aad1-6a61338f2ad9@github.com> On Thu, 28 Jul 2022 14:59:06 GMT, Michael Strau? wrote: > The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. > > It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. > > Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. > > There are two additional noteworthy changes with this PR: > 1. Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. > This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. > > 2. The changes around `KeyHandler` might seem to be excessive for the scope of this PR. However, this is mostly just code that was moved to another place (it was moved right next to the rest of the focus-related functionality in `Scene`). `KeyHandler` was a dubious class before (since it didn't seem to have a clear purpose, mixing focus handling with event propagation), but with the need to call `KeyHandler.setFocusVisible` from mouse and touch event handlers, its purpose became even less pronounced. > I think that moving the focus-related functionality next to the other focus functions in the `Scene` class is a safe and straightforward change, and it makes it easier to work with the code in the future. > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, I decided to roll this code into `Scene.processKeyEvent` and remove the now-empty `KeyHandler` class. > > Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. In addition to automated testing, I also manually tested this change by building and running SceneBuilder with it. As far as I can tell, there's no regression in functionality. The behavior of the feature after this PR is applied mostly resembles how Windows 10/11, Chrome, and Firefox handle visible focus indicators. There are some very minor differences, which can be addressed later (for example, clicking on scroll bars doesn't seem to count as a mouse interaction Windows/Chrome/Firefox, where it does in this iteration of the `focusVisible` feature). ------------- PR: https://git.openjdk.org/jfx/pull/852 From kcr at openjdk.org Mon Aug 1 18:10:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 18:10:08 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 14:59:06 GMT, Michael Strau? wrote: > The changes around KeyHandler might seem to be excessive for the scope of this PR. They do indeed. > I think that moving the focus-related functionality next to the other focus functions in the Scene class is a safe and straightforward change, and it makes it easier to work with the code in the future. Be that as it may, this sort of refactoring is discouraged, especially in the case of a fix you want to get in late in the release (we have 3 days left before the RDP2 deadline of JavaFX 19). This will cause extra time for the reviewers and could jeopardize getting it into the release. It would have been better to save this change for a future bug fix. ------------- PR: https://git.openjdk.org/jfx/pull/852 From mstrauss at openjdk.org Mon Aug 1 18:33:01 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 1 Aug 2022 18:33:01 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner [v2] In-Reply-To: References: Message-ID: > The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. > > It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. > > Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. > > There are two additional noteworthy changes with this PR: > 1. Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. > This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. > > 2. The changes around `KeyHandler` might seem to be excessive for the scope of this PR. However, this is mostly just code that was moved to another place (it was moved right next to the rest of the focus-related functionality in `Scene`). `KeyHandler` was a dubious class before (since it didn't seem to have a clear purpose, mixing focus handling with event propagation), but with the need to call `KeyHandler.setFocusVisible` from mouse and touch event handlers, its purpose became even less pronounced. > I think that moving the focus-related functionality next to the other focus functions in the `Scene` class is a safe and straightforward change, and it makes it easier to work with the code in the future. > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, I decided to roll this code into `Scene.processKeyEvent` and remove the now-empty `KeyHandler` class. > > Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Revert changes around KeyHandler ------------- Changes: - all: https://git.openjdk.org/jfx/pull/852/files - new: https://git.openjdk.org/jfx/pull/852/files/9d0f98f8..e9d5a822 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=852&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=852&range=00-01 Stats: 180 lines in 1 file changed: 93 ins; 69 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/852.diff Fetch: git fetch https://git.openjdk.org/jfx pull/852/head:pull/852 PR: https://git.openjdk.org/jfx/pull/852 From mstrauss at openjdk.org Mon Aug 1 18:42:46 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 1 Aug 2022 18:42:46 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner [v3] In-Reply-To: References: Message-ID: > The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. > > It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. > > Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. > > There are two additional noteworthy changes with this PR: > 1. Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. > This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. > > 2. The changes around `KeyHandler` might seem to be excessive for the scope of this PR. However, this is mostly just code that was moved to another place (it was moved right next to the rest of the focus-related functionality in `Scene`). `KeyHandler` was a dubious class before (since it didn't seem to have a clear purpose, mixing focus handling with event propagation), but with the need to call `KeyHandler.setFocusVisible` from mouse and touch event handlers, its purpose became even less pronounced. > I think that moving the focus-related functionality next to the other focus functions in the `Scene` class is a safe and straightforward change, and it makes it easier to work with the code in the future. > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, I decided to roll this code into `Scene.processKeyEvent` and remove the now-empty `KeyHandler` class. > > Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: null focus owner never has visible focus ------------- Changes: - all: https://git.openjdk.org/jfx/pull/852/files - new: https://git.openjdk.org/jfx/pull/852/files/e9d5a822..56d2d6ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=852&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=852&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/852.diff Fetch: git fetch https://git.openjdk.org/jfx pull/852/head:pull/852 PR: https://git.openjdk.org/jfx/pull/852 From mstrauss at openjdk.org Mon Aug 1 18:59:02 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 1 Aug 2022 18:59:02 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner In-Reply-To: References: Message-ID: <69fZkFJ2rTGucAkils8vxb62VLv7W3_flZQGvy-xn20=.0e48acf1-a7f4-4ffa-978d-14cb64ead477@github.com> On Mon, 1 Aug 2022 18:06:15 GMT, Kevin Rushforth wrote: > Be that as it may, this sort of refactoring is discouraged, especially in the case of a fix you want to get in late in the release (we have 3 days left before the RDP2 deadline of JavaFX 19). This will cause extra time for the reviewers and could jeopardize getting it into the release. It would have been better to save this change for a future bug fix. I've reverted most of the changes around `KeyHandler`. ------------- PR: https://git.openjdk.org/jfx/pull/852 From angorya at openjdk.org Mon Aug 1 19:46:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Aug 2022 19:46:24 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc Message-ID: - updated .classpath entries in apps/ - added utf-8 prefs in .settings/ ------------- Commit messages: - 8290473: added ColorCube project - 8290473: eclipse config for apps Changes: https://git.openjdk.org/jfx/pull/858/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290473 Stats: 97 lines in 12 files changed: 55 ins; 8 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Mon Aug 1 19:46:25 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 1 Aug 2022 19:46:25 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ I'm don't think that this is the right approach with the apps. I think that each app should be its own project. See the branch I linked in the previous PR. I don't see why the containing folders like samples and toys should be java projects. buildSrc/.classpath line 10: > 8: > 9: > 10: Why does buildSrc need to be a project? It contains no relevant sources. modules/javafx.graphics/.classpath line 5: > 3: > 4: > 5: How do you not get errors on these on Mac/Linux if they are not declared optional? Additionally, you need the hlsl folders as shown in the mailing list. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 1 19:46:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Aug 2022 19:46:26 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ @nlisker : could you please take a look at this draft PR? with these changes, I get no errors in eclipse, I can run tests and standalone applications. I still cannot launch apps - for example, Jfx3dViewerApp fails with Error: JavaFX runtime components are missing, and are required to run this application Here is the command line eclipse generates: Thank you, Kevin. The goal of this PR is to enable simultaneous development in jfx and the apps or tests in Eclipse. I should be able to modify and debug the code in both parts. Of course, in case of tests, the final test is using gradle test as it guarantees to set up every dependency just right. I specifically do not want to run apps against jars, as I won't be able to use eclipse incremental build feature and see the changes immediately. I can run/debug the tests in Eclipse. With apps, using the same configuration essentially, I am getting Error: JavaFX runtime components are missing, and are required to run this application Not sure what runtime components are missing (I wish the error message was more descriptive). -andy From: Kevin Rushforth ***@***.***> Date: Monday, 2022/08/01 at 10:16 To: openjdk/jfx ***@***.***> Cc: Andy Goryachev ***@***.***>, Author ***@***.***> Subject: [External] : Re: [openjdk/jfx] 8290473: update Eclipse .classpath in apps, buildSrc (PR #858) One quick comment. Compiling or running the apps should not need any additional --add-exports, --add-reads, or --add-opens arguments, and they should not need to load the shims or junit. Those should only be needed for building and running unit tests. Applications should be run with just the modular jars. ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***> Thanks to Kevin's help, we were able to launch an ColorCube app with the following configuration (below). The key point is to Override Dependencies and -add-modules directly, instead of --add-exports that Eclipse adds by default: Screen Shot 2022-08-01 at 12 03 00 ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Mon Aug 1 19:46:27 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 19:46:27 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: <0PJhU1xK_u48oSAOTB14VBiu3ivziZY75XmtCVXdDbk=.3cc45523-0785-4146-8775-dcbab6391007@github.com> On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ One quick comment. Compiling or running the apps should not need any additional `--add-exports`, `--add-reads`, or `--add-opens` arguments, and they should not need to load the shims or junit. Those should only be needed for building and running unit tests. Applications should be run with just the modular jars. Even if you use the Eclipse-generated class files, apps shouldn't need anything from the unit test infrastructure (which is the reason for needing all those `--add-exports`). Since I'm not an Eclipse user, I will defer to those who are, so @nlisker can make this call. As long as you use this as a convenience, then I have no objection. Just be aware that this will mean you aren't running in the real environment. It would therefore be possible to make an app change that accidentally uses an internal package, so would run in Eclipse but fail to compile with `gradle apps`. As for the error message, "JavaFX runtime components are missing" means that the Java launcher cannot load the `javafx.graphics` module. It looks like the `--add-modules` arguments are missing, but that should prevent the unit tests from running as well, and yet those are working for you. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 1 19:46:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Aug 2022 19:46:29 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:47:14 GMT, Nir Lisker wrote: >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > buildSrc/.classpath line 10: > >> 8: >> 9: >> 10: > > Why does buildSrc need to be a project? It contains no relevant sources. It probably does not, the file was added in 2013 as a part of RT-31216: Ensure NetBeans development in Gradle build works [Eclipse files] Turns out, eclipse can work with nested projects. Shows multiple hits when looking for resources, but it does. I've added a separate project for ColorCube app as an example, but since this PR is about making all directories to build on Eclipse, I'd rather not fix all the apps in this PR. (I would keep ColorCube as a reference though). > modules/javafx.graphics/.classpath line 5: > >> 3: >> 4: >> 5: > > How do you not get errors on these on Mac/Linux if they are not declared optional? > > Additionally, you need the hlsl folders as shown in the mailing list. As with any multi-stage project, we need to run 'gradle sdk' (or perhaps 'gradle sdk apps' for good measure) to build these directories. Then, in Eclipse, clean all projects. These steps produce a working configuration. I do not see hlsl folders being build on Mac. Are these being built on windows/linux? If these are platform-specific, then we should add them to the gradle build. Maybe an additional target that creates the empty directories, and upon which sdk depends on. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 1 20:11:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Aug 2022 20:11:53 GMT Subject: RFR: 8289605: Robot capture tests fail intermittently on Mac M1 [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 23:01:27 GMT, Kevin Rushforth wrote: > The fix works on my M1 system for the two failing tests. So my only feedback is the suggestion to move the `before` method from `RegionBackgroundImageUITest` to `VisualTestBase`. VisualTestBase is a base class to the whole gallery of tests, some of which have more than one stage (IconifyTest). I've limited the changes to RegionBackgroundImageUITest because I did not want to expand the scope unnecessarily. We could add it to RegionUITestBase instead (RegionBackgroundImageUITest extends RegionUITestBase extends VisualTestBase), but I got an impression that it is better for a single PR to limit the scope of the change. Affected tests (extend RegionBackgroundImageUITest): RegionBackgroundFillUITest RegionBackgroundImageUITest RegionBorderImageUITest RegionBorderStrokeUITest (empty) RegionShapeUITest (empty) ------------- PR: https://git.openjdk.org/jfx/pull/854 From kcr at openjdk.org Mon Aug 1 20:15:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 20:15:56 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner In-Reply-To: <69fZkFJ2rTGucAkils8vxb62VLv7W3_flZQGvy-xn20=.0e48acf1-a7f4-4ffa-978d-14cb64ead477@github.com> References: <69fZkFJ2rTGucAkils8vxb62VLv7W3_flZQGvy-xn20=.0e48acf1-a7f4-4ffa-978d-14cb64ead477@github.com> Message-ID: On Mon, 1 Aug 2022 18:55:29 GMT, Michael Strau? wrote: > I've reverted most of the changes around `KeyHandler`. Thank you. That will make this much easier to review. ------------- PR: https://git.openjdk.org/jfx/pull/852 From kcr at openjdk.org Mon Aug 1 20:17:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 20:17:08 GMT Subject: RFR: 8289605: Robot capture tests fail intermittently on Mac M1 [v2] In-Reply-To: References: Message-ID: <2pxsyZUQz2iLrPEIdMv932WqdLS4Yc5vb21463uExEw=.c3e6b659-cad8-4cc5-94e0-6c554946ec8b@github.com> On Fri, 29 Jul 2022 21:40:40 GMT, Andy Goryachev wrote: >> - moving mouse pointer to stage lower right corner in order to avoid interference with the Robot screen capture. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8289605: 2022 Looks good. You could simplify the lambda as @Maran23 suggests, but I'll leave that up to you. I'll re-approve if you do. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/854 From kcr at openjdk.org Mon Aug 1 20:17:10 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 20:17:10 GMT Subject: RFR: 8289605: Robot capture tests fail intermittently on Mac M1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 20:08:18 GMT, Andy Goryachev wrote: > VisualTestBase is a base class to the whole gallery of tests, some of which have more than one stage (IconifyTest). I've limited the changes to RegionBackgroundImageUITest because I did not want to expand the scope unnecessarily. OK. ------------- PR: https://git.openjdk.org/jfx/pull/854 From angorya at openjdk.org Mon Aug 1 20:58:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Aug 2022 20:58:55 GMT Subject: Integrated: 8289605: Robot capture tests fail intermittently on Mac M1 In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:11:53 GMT, Andy Goryachev wrote: > - moving mouse pointer to stage lower right corner in order to avoid interference with the Robot screen capture. This pull request has now been integrated. Changeset: 08ec9c87 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/08ec9c8781a57b49a13a2b7febbe33172ebc1a5a Stats: 35 lines in 2 files changed: 23 ins; 1 del; 11 mod 8289605: Robot capture tests fail intermittently on Mac M1 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/854 From kcr at openjdk.org Mon Aug 1 22:27:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 22:27:03 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:42:46 GMT, Michael Strau? wrote: >> The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. >> >> It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. >> >> Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. >> >> There is an additional noteworthy change with this PR: >> Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. >> This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. >> >> Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > null focus owner never has visible focus This looks good, with a possible follow-up item to clarify the docs. I think it would be worth updating the spec to say that `focusVisible` is cleared on a `MOUSE_PRESSED` or `TOUCH_PRESSED` event (in addition to the other events that can clear it). I recommend doing this in a follow-up bug, so it doesn't derail getting this bug fix in. Since this would be a doc-only change, it could be done during RDP2 of JavaFX 19 (or even deferred to JavaFX 20, but it seems best to shoot for 19). Either way, it will need a CSR. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/852 From kcr at openjdk.org Mon Aug 1 23:18:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Aug 2022 23:18:55 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner [v3] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 18:42:46 GMT, Michael Strau? wrote: >> The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. >> >> It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. >> >> Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. >> >> There is an additional noteworthy change with this PR: >> Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. >> This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. >> >> Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > null focus owner never has visible focus As a possible additional follow-on bug for the original feature, in a future release, is that navigating using the Windows Narrator's focus traversal keys doesn't set `focusVisible`. This is independent of this bug (this PR doesn't change that behavior). ------------- PR: https://git.openjdk.org/jfx/pull/852 From arapte at openjdk.org Tue Aug 2 07:41:13 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 Aug 2022 07:41:13 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: Message-ID: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> On Sat, 30 Jul 2022 11:01:59 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 201: >> >>> 199: >>> 200: /** >>> 201: * If no lights are in the scene, add a default white point light at the camera's. The light uses the default >> >> minor: `at the camera's` -> `at the camera's (eye) position` >> >> Additionally would recommend to move the first line `If no lights are in the scene, add a default white point light at the camera's position.` above line number 128 before calling `createDefaultLight` > > I thought that the code > > if (noLights(lights)) { > createDefaultLight(g); > > speaks for itself: if there are no lights, add a default light. The details of what that light is are in the method doc. Can still add a comment there. Sounds good. minor: On another thought, how about naming the method as `setDefaultLight`. >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 211: >> >>> 209: (float) cameraPos.x, (float) cameraPos.y, (float) cameraPos.z, >>> 210: 1.0f, 1.0f, 1.0f, 1.0f, >>> 211: NGPointLight.getDefaultCa(), NGPointLight.getDefaultLa(), NGPointLight.getDefaultQa(), 0, >> >> `isAttenuated` was passed as 1 earlier. Is changing it to `0` works same ? > > Yes, in `PsMath.h::computeLight`, there is a check if the light requests attenuation. In general, this is done only for directional lights (that are not attenuated), but in this case we know that this point light is not attenuated so passing 0 skips the redundant calculation. In theory this would improve performance, but because this light can only exist alone I don't expect anything measurable. I see 4 tests in `PointLightIlluminationTest` fail due to this change, on MacOS and Windows. Tests: sphereLowerRightPixelColorShouldBeDarkRed sphereUpperRightPixelColorShouldBeDarkRed sphereUpperLeftPixelColorShouldBeDarkRed sphereLowerLeftPixelColorShouldBeDarkRed Error: expected:rgba(139,0,0,255) but was:rgba(180,0,0,255) The tests pass if isAttenuated is 1. >> modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h line 36: >> >>> 34: static const int isSkinned = Skin; >>> 35: >>> 36: static const int maxLights = 3; >> >> May be name as `MAX_LIGHTS` similar to `static const int MAX_BONES = 70;` on line 28 in same file. ? >> of preferably use `MAX_NUM_LIGHTS` which we already use in .h, .cpp files. > > The max lights limitation is going to be removed in the following change set (at least I intend to do it), so I don't think it's worth touching all those constants. Ok, that change would touch glsl shaders too. Sounds good, we can talk about it with that change. ------------- PR: https://git.openjdk.org/jfx/pull/789 From nlisker at openjdk.org Tue Aug 2 09:47:21 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 2 Aug 2022 09:47:21 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: > Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. > > Since there are many small changes, I'm giving a full list here: > > **Java** > > * `NGShape3D.java` > * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. > * Normalized the direction here instead of in the native code. > * Ambient light is now only set when it exists (and is not black). > * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). > * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. > > **Native C++** > > * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). > * `D3DLight` > * Commented out unused methods. Were they supposed to be used at some point? > * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. > * `D3DPhongShader.h` > * Renamed some of the register constants for more clarity. > * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. > * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. > * `D3DMeshView.cc` > * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. > * Removed the direction normalization as stated in the change for `NGShape3D.java`. > * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. > > **Native shaders** > * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). > * Commented out many unused functions. I don't know what they are for, so I didn't remove them. > * `vsConstants` > * Removed the light color from here since it's unused, only the position is. > * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. > * `vs2ps` > * Removed the ambient color interpolation, which frees a register (no change in performance). > * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). > * `Mtl1PS` and `psMath` > * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. > * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. > > No changes in performance were measured and the behavior stayed the same. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Renamed method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/789/files - new: https://git.openjdk.org/jfx/pull/789/files/025feea4..689497a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/789.diff Fetch: git fetch https://git.openjdk.org/jfx pull/789/head:pull/789 PR: https://git.openjdk.org/jfx/pull/789 From nlisker at openjdk.org Tue Aug 2 10:33:22 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 2 Aug 2022 10:33:22 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> References: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> Message-ID: <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com> On Tue, 2 Aug 2022 07:36:11 GMT, Ambarish Rapte wrote: >> Yes, in `PsMath.h::computeLight`, there is a check if the light requests attenuation. In general, this is done only for directional lights (that are not attenuated), but in this case we know that this point light is not attenuated so passing 0 skips the redundant calculation. In theory this would improve performance, but because this light can only exist alone I don't expect anything measurable. > > I see 4 tests in `PointLightIlluminationTest` fail due to this change, on MacOS and Windows. > Tests: > sphereLowerRightPixelColorShouldBeDarkRed > sphereUpperRightPixelColorShouldBeDarkRed > sphereUpperLeftPixelColorShouldBeDarkRed > sphereLowerLeftPixelColorShouldBeDarkRed > > Error: > expected:rgba(139,0,0,255) but was:rgba(180,0,0,255) > > The tests pass if isAttenuated is 1. I'll have a look. What command did you run this test with? Can you also test the point light attenuation under `tests\system\src\test\java\test\javafx\scene\lighting3D\PointLightAttenuationTest.java`? (I think there's a bit of a mess in the tests folders.) ------------- PR: https://git.openjdk.org/jfx/pull/789 From aghaisas at openjdk.org Tue Aug 2 10:55:03 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 2 Aug 2022 10:55:03 GMT Subject: [jfx19] RFR: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner [v3] In-Reply-To: References: Message-ID: <1vewvAUE22s9aH3cD_peeJxim3ZmM58v-CczhfRwxjU=.3c503f9b-7b85-4606-a47d-3b87672d3093@github.com> On Mon, 1 Aug 2022 18:42:46 GMT, Michael Strau? wrote: >> The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. >> >> It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. >> >> Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. >> >> There is an additional noteworthy change with this PR: >> Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. >> This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. >> >> Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > null focus owner never has visible focus Looks good to me. I have identified potential cleanup that may be required. It can be done as part of [JDK-8253769](https://bugs.openjdk.org/browse/JDK-8253769) modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java line 63: > 61: this.target = target; > 62: > 63: // Use the alternative creation path for MouseEvent by default, see JDK-8253769 If the alternative path is made the default then this class needs some cleanup. That can be done as part of `JDK-8253769`. Request you to add a comment in JBS on `JDK-8253769` to clean up the unused portion of `MouseEventFirer.java` ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/852 From arapte at openjdk.org Tue Aug 2 11:00:50 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 Aug 2022 11:00:50 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com> References: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com> Message-ID: <0okvvkrjS89IXbBAtr_N2OqaXgXjg2gRW_wggc7pzHQ=.65c7501d-b1e5-4abd-8d57-9b30114841de@github.com> On Tue, 2 Aug 2022 10:30:55 GMT, Nir Lisker wrote: >> I see 4 tests in `PointLightIlluminationTest` fail due to this change, on MacOS and Windows. >> Tests: >> sphereLowerRightPixelColorShouldBeDarkRed >> sphereUpperRightPixelColorShouldBeDarkRed >> sphereUpperLeftPixelColorShouldBeDarkRed >> sphereLowerLeftPixelColorShouldBeDarkRed >> >> Error: >> expected:rgba(139,0,0,255) but was:rgba(180,0,0,255) >> >> The tests pass if isAttenuated is 1. > > I'll have a look. What command did you run this test with? > > Can you also test the point light attenuation under `tests\system\src\test\java\test\javafx\scene\lighting3D\PointLightAttenuationTest.java`? (I think there's a bit of a mess in the tests folders.) Command to run the system test: `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test --tests test.robot.test3d.PointLightIlluminationTest` I ran all the tests, only above test failed: Command to run all the system tests: `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test` ------------- PR: https://git.openjdk.org/jfx/pull/789 From jpereda at openjdk.org Tue Aug 2 11:09:13 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 2 Aug 2022 11:09:13 GMT Subject: RFR: 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane Message-ID: This PR fixes an issue when there is a DialogPane that has no header and no graphic is set, by adding the `graphic-container` styleclass only when there is a non-null graphic applied, preventing the padding that otherwise the graphic container will keep. Two tests have been added, to verify that the padding is 0 when there is no graphic (this test fails without this PR) and to verify that the padding is correct when there is a graphic to the left of the content area. As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area. ------------- Commit messages: - Add graphic-container styleclass only when there is a graphic Changes: https://git.openjdk.org/jfx/pull/859/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291625 Stats: 47 lines in 2 files changed: 40 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/859.diff Fetch: git fetch https://git.openjdk.org/jfx pull/859/head:pull/859 PR: https://git.openjdk.org/jfx/pull/859 From arapte at openjdk.org Tue Aug 2 13:43:51 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 Aug 2022 13:43:51 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: <_8lQZcrIFrEr2KkQue0YRN-7FJI-t5Xs_61oHw0YlbM=.cf5d8729-c7bf-4e67-8001-3f5f1d2921b5@github.com> On Tue, 2 Aug 2022 09:47:21 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Renamed method Found few minor corrections. I need to do one more pass at the hlsl code. modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 227: > 225: status = SUCCEEDED(device->SetPixelShaderConstantF(PSR_MAT_DIFFUSE_COLOR, material->getDiffuseColor(), 1)); > 226: if (!status) { > 227: cout << "D3DMeshView.render() - SetPixelShaderConstantF (PSR_DIFFUSECOLOR) failed !!!" << endl; Minor: in cout, `PSR_DIFFUSECOLOR` -> `PSR_MAT_DIFFUSE_COLOR` modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 233: > 231: status = SUCCEEDED(device->SetPixelShaderConstantF(PSR_MAT_SPECULAR_COLOR, material->getSpecularColor(), 1)); > 232: if (!status) { > 233: cout << "D3DMeshView.render() - SetPixelShaderConstantF (PSR_SPECULARCOLOR) failed !!!" << endl; Minor: in cout, `PSR_SPECULARCOLOR` -> `PSR_MAT_SPECULAR_COLOR` modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 245: > 243: status = SUCCEEDED(device->SetPixelShaderConstantF(PSR_LIGHT_COLOR, lightsColor, MAX_NUM_LIGHTS)); > 244: if (!status) { > 245: cout << "D3DMeshView.render() - SetPixelShaderConstantF(PSR_LIGHTCOLOR) failed !!!" << endl; Minor: in cout, `PSR_LIGHTCOLOR` -> `PSR_LIGHT_COLOR` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/789 From mstrauss at openjdk.org Tue Aug 2 14:39:05 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 2 Aug 2022 14:39:05 GMT Subject: [jfx19] Integrated: 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 14:59:06 GMT, Michael Strau? wrote: > The `focusVisible` flag is only set on a node when it acquires input focus using a keyboard interaction, and it is cleared by mouse and touch interactions. > > It is not necessary for a node to lose input focus in order to lose `focusVisible`. Currently, clicking on a region of the scene that does not contain a focusable node does not clear the `focusVisible` flag. > > Detecting clicks or touches that should clear `focusVisible` can be achieved by adding an event filter for `MOUSE_PRESSED` and `TOUCH_PRESSED` to the `Scene`. > > There is an additional noteworthy change with this PR: > Adding event filters to `Scene` causes many tests to fail due to a bug in `MouseEventFirer` that was identified in [8253769](https://bugs.openjdk.org/browse/JDK-8253769). Previously, mouse events generated by `MouseEventFirer` skipped a code path that causes test failures due to incorrect coordinates. With the added event filters, the code path for mouse events is slightly different, exposing the incorrect coordinates and causing tests to fail. > This problem can be solved by making the "alternative" `MouseEvent` generation path the default path. > > Note: Since this is a follow-up fix for [8268225](https://bugs.openjdk.org/browse/JDK-8268225), I'm targeting this fix for `jfx19`. This pull request has now been integrated. Changeset: 5febacae Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/5febacae1bf6776a31e151ef223739576dab67e6 Stats: 87 lines in 3 files changed: 82 ins; 1 del; 4 mod 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/852 From kcr at openjdk.org Tue Aug 2 16:00:46 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Aug 2022 16:00:46 GMT Subject: RFR: Merge jfx19 Message-ID: Merge `jfx19` into `master`. ------------- Commit messages: - Merge jfx19 - 8291502: Mouse or touch presses on a non-focusable region don't clear the focusVisible flag of the current focus owner - 8291588: Update boot JDK to 18.0.2 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jfx&pr=860&range=00.0 - jfx19: https://webrevs.openjdk.org/?repo=jfx&pr=860&range=00.1 Changes: https://git.openjdk.org/jfx/pull/860/files Stats: 98 lines in 5 files changed: 82 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/860.diff Fetch: git fetch https://git.openjdk.org/jfx pull/860/head:pull/860 PR: https://git.openjdk.org/jfx/pull/860 From kcr at openjdk.org Tue Aug 2 16:14:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Aug 2022 16:14:29 GMT Subject: RFR: Merge jfx19 [v2] In-Reply-To: References: Message-ID: > Merge `jfx19` into `master`. Kevin Rushforth 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 jfx19 - 8289605: Robot capture tests fail intermittently on Mac M1 Reviewed-by: kcr - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment Reviewed-by: kcr - 8290530: Bump minimum JDK version for JavaFX to JDK 17 Reviewed-by: prr, jvos - 8290990: Clear .root style class from a root node that is removed from a Scene/SubScene Reviewed-by: jhendrikx, aghaisas, mhanl - 8285881: Update WebKit to 614.1 Co-authored-by: Ambarish Rapte Co-authored-by: Kevin Rushforth Co-authored-by: Jay Bhaskar Reviewed-by: kcr, arapte, mstrauss, jvos - 8290527: Bump macOS GitHub actions to macOS 11 Reviewed-by: arapte - 8289388: Fix warnings: method is overriding a synchronized method without being synchronized Reviewed-by: kcr - 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() Reviewed-by: kcr - Merge - ... and 6 more: https://git.openjdk.org/jfx/compare/5febacae...1679f5cc ------------- Changes: https://git.openjdk.org/jfx/pull/860/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=860&range=01 Stats: 454251 lines in 7392 files changed: 301187 ins; 110186 del; 42878 mod Patch: https://git.openjdk.org/jfx/pull/860.diff Fetch: git fetch https://git.openjdk.org/jfx pull/860/head:pull/860 PR: https://git.openjdk.org/jfx/pull/860 From kcr at openjdk.org Tue Aug 2 16:14:32 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Aug 2022 16:14:32 GMT Subject: Integrated: Merge jfx19 In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 15:54:17 GMT, Kevin Rushforth wrote: > Merge `jfx19` into `master`. This pull request has now been integrated. Changeset: 779365f1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/779365f1af8dc837d7b6d292de5bd8dcd8947290 Stats: 98 lines in 5 files changed: 82 ins; 1 del; 15 mod Merge ------------- PR: https://git.openjdk.org/jfx/pull/860 From thiago.sayao at gmail.com Tue Aug 2 16:50:44 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 2 Aug 2022 13:50:44 -0300 Subject: JavaFx Linux vs Glibc Message-ID: Hi, I have built my own jmods, but when running it complained about GLIBC version. ldd libglassgtk3.so ./libglassgtk3.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./libglassgtk3.so) ./libglassgtk3.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./libglassgtk3.so) I have built it on a Ubuntu 22.04 VM and tried to run on 20.04. Any build flags I should pass? -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Aug 2 16:57:51 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 2 Aug 2022 09:57:51 -0700 Subject: JavaFx Linux vs Glibc In-Reply-To: References: Message-ID: On Linux you always need to be careful if you build on a newer machine that you intended to deploy on. In our builds, we compile and statically link with libc libraries from a devkit similar to what the JDK build does. We do the same for the gtk3 libraries. In both cases, we try to avoid linking with whatever happens to be on the build machine. We also build on Oracle Linux 7 to avoid any problems for those cases where we do pick up a system library. I believe Gluon does something similar, although I think they use a different Linux system for their builds (but still older than Ubuntu 20.04). -- Kevin On 8/2/2022 9:50 AM, Thiago Milczarek Say?o wrote: > Hi, > > I have built my own jmods, but when running it complained about GLIBC > version. > > ldd libglassgtk3.so > ./libglassgtk3.so: /lib/x86_64-linux-gnu/libc.so.6: version > `GLIBC_2.32' not found (required by ./libglassgtk3.so) > ./libglassgtk3.so: /lib/x86_64-linux-gnu/libc.so.6: version > `GLIBC_2.34' not found (required by ./libglassgtk3.so) > > I have built it on a Ubuntu 22.04 VM and tried to run on 20.04. > > Any build flags I should pass? > > -- Thiago. From john at status6.com Tue Aug 2 17:06:34 2022 From: john at status6.com (John Neffenger) Date: Tue, 2 Aug 2022 10:06:34 -0700 Subject: JavaFx Linux vs Glibc In-Reply-To: References: Message-ID: On 8/2/22 9:50 AM, Thiago Milczarek Say?o wrote: > I have built it on a Ubuntu 22.04 VM and tried to run on 20.04. If you want to keep your current build process, try building on Ubuntu 18.04, which is still receiving updates until next year. Ubuntu Updates GLIBC 16.04 2021-04-30 2.23 18.04 2023-04-26 2.27 20.04 2025-04-23 2.31 20.10 2021-07-22 2.32 21.04 2022-01-20 2.33 21.10 2022-07-14 2.34 22.04 2027-04-21 2.34 That way you'll be compatible with any system having GLIBC 2.27 or later, such as Ubuntu 18.04, Fedora 28, or later versions. Fedora Updates GLIBC 24 2017-08-08 2.23 25 2017-12-12 2.24 26 2018-05-29 2.25 27 2018-11-30 2.26 28 2019-05-28 2.27 29 2019-11-26 2.28 30 2020-05-26 2.29 31 2020-11-24 2.30 32 2021-05-25 2.31 33 2021-11-30 2.32 34 2022-05-17 2.33 35 2022-12-07 2.34 36 2023-05-24 2.35 John From arapte at openjdk.org Tue Aug 2 18:09:53 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 Aug 2022 18:09:53 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 09:47:21 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Renamed method Providing few more comments. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1VS.hlsl line 32: > 30: //float2 transformTexture(float2 t) { return t; } > 31: > 32: VsOutput main(VsInput vsInput) { The input struct name was earlier passed from build.gradle, https://github.com/openjdk/jfx/blob/08ec9c8781a57b49a13a2b7febbe33172ebc1a5a/build.gradle#L2344 This change needs to be reflected in build.gradle. so, either 1. Remove `"/DVertexType=ObjVertex",` in build.gradle OR 2. Change `"/DVertexType=ObjVertex",` in build.gradle to `"/DVertexType=VsInput",` and revert the type function parameter here. I would recommend option 2, as it would remind us to use this approach in future if we needed multiple types of vs input structs. But I leave it to you. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vs2ps.h line 26: > 24: */ > 25: > 26: struct PsInput { The `struct VsOutput` is the actual input to pixel shader. Naming this struct as `PsInput` may not be correct. I would recommend to have only one struct that is `PsInput` and move member variable texD of `VsOutput` to `PsInput`. In vertex and pixel shaders use correct names for the variables of `PsInput`. In vertex shader the variable would be names as output, and in pixel shader as input. For example: https://github.com/caioteixeira/GameEngines/blob/master/lab5/Assets/Shaders/Phong.hlsl modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vs2ps.h line 38: > 36: float3 worldVecToEye : texcoord2; > 37: float3 worldVecsToLights[nLights] : texcoord3; // 3, 4, 5 > 38: float3 worldNormLightDirs[nLights] : texcoord6; // 6, 7, 8 This is an existing behavior, and I just want to open it for discussion and bring it to your consideration for future changes. These are per vertex attributes and they may cause un-required processing/overhead during rasterization. In a regular scenario where only one light i.e. default light is set, the other two values in these arrays are reset and are unused in pixel shader. But rasterizer interpolates these values for all pixel pass as input to pixel shader. May be in future we can find a way to avoid this. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsMath.h line 56: > 54: } > 55: > 56: void calcLocalBump(float4 modelVertexPos, float4 modelVertexNormal, out PsInput psInput) { Looks like the function name `calcLocalBump` was in accordance with the structs `LocalBump` and `LocalBumpOut`. Now, as these structs are getting removed, we can change this name. May be something like, `transformVertexAttributes()`? modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsMath.h line 56: > 54: } > 55: > 56: void calcLocalBump(float4 modelVertexPos, float4 modelVertexNormal, out PsInput psInput) { In continuation to comment in vs2ps.h : While in vertex shader: `PsInput` is the output of vertex shader. So It would be more suitable to name the variable as `output` or `vsOutput` instead of `psInput`. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/789 From arapte at openjdk.org Tue Aug 2 19:22:23 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 Aug 2022 19:22:23 GMT Subject: [jfx19] RFR: 8291589: Update copyright header for files modified in 2022 Message-ID: Updating last modified year in the files that were modified during year 2022. ------------- Commit messages: - Copyright year 2022 update for jfx19 Changes: https://git.openjdk.org/jfx/pull/861/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291589 Stats: 194 lines in 194 files changed: 0 ins; 0 del; 194 mod Patch: https://git.openjdk.org/jfx/pull/861.diff Fetch: git fetch https://git.openjdk.org/jfx pull/861/head:pull/861 PR: https://git.openjdk.org/jfx/pull/861 From johan at lodgon.com Tue Aug 2 21:28:02 2022 From: johan at lodgon.com (Johan Vos) Date: Tue, 2 Aug 2022 23:28:02 +0200 Subject: JavaFx Linux vs Glibc In-Reply-To: References: Message-ID: Hi John, The problem with this is that there is no GCC 11.2 (which is required per the build.properties) that comes with Ubuntu 20.04. As Kevin said, as of recently, we build with a devkit based on the OpenJDK devkit instructions (https://github.com/openjdk/jdk/tree/master/make/devkit) and that allows us to create builds [that work] on older systems (there are nu unresolved @GLIBC_X symbols in the libs) while still using GCC 11.2 -- - Johan Op di 2 aug. 2022 om 19:07 schreef John Neffenger : > On 8/2/22 9:50 AM, Thiago Milczarek Say?o wrote: > > I have built it on a Ubuntu 22.04 VM and tried to run on 20.04. > > If you want to keep your current build process, try building on Ubuntu > 18.04, which is still receiving updates until next year. > > Ubuntu Updates GLIBC > 16.04 2021-04-30 2.23 > 18.04 2023-04-26 2.27 > 20.04 2025-04-23 2.31 > 20.10 2021-07-22 2.32 > 21.04 2022-01-20 2.33 > 21.10 2022-07-14 2.34 > 22.04 2027-04-21 2.34 > > That way you'll be compatible with any system having GLIBC 2.27 or > later, such as Ubuntu 18.04, Fedora 28, or later versions. > > Fedora Updates GLIBC > 24 2017-08-08 2.23 > 25 2017-12-12 2.24 > 26 2018-05-29 2.25 > 27 2018-11-30 2.26 > 28 2019-05-28 2.27 > 29 2019-11-26 2.28 > 30 2020-05-26 2.29 > 31 2020-11-24 2.30 > 32 2021-05-25 2.31 > 33 2021-11-30 2.32 > 34 2022-05-17 2.33 > 35 2022-12-07 2.34 > 36 2023-05-24 2.35 > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Tue Aug 2 21:56:48 2022 From: john at status6.com (John Neffenger) Date: Tue, 2 Aug 2022 14:56:48 -0700 Subject: JavaFx Linux vs Glibc In-Reply-To: References: Message-ID: <5c7fb16c-1bb5-2d51-25d1-87cfc3d4b3ce@status6.com> On 8/2/22 2:28 PM, Johan Vos wrote: > The problem with this is that there is no GCC 11.2 (which is required > per the build.properties) that comes with Ubuntu 20.04. Thanks, Johan. You've mentioned that before, but I feel like I'm missing some information. What is in the JavaFX build that requires GCC 11.2? I'm building JavaFX without problems using the GCC from Ubuntu 18.04. JavaFX 'build.properties' file: jfx.build.linux.gcc.version=gcc11.2.0-OL6.4+1.0 Ubuntu 18.04 LTS: gcc=4:7.4.0-1ubuntu2.3 I'm not building WebKit or the media libraries, though -- just a simple: $ gradle sdk jmods javadoc Maybe Ubuntu has back-ported whatever feature is required in GCC? I understand why OpenJDK and OpenJFX might want to be compatible with very old C libraries back to GLIBC version 2.9. In fact, that compatibility has allowed me to run Java on old embedded ARM devices that support only up to Ubuntu 14.04 LTS and nothing later. But if you're targeting the currently supported Linux distributions (Ubuntu 18.04 LTS, Fedora 35, or later), there's nothing wrong with supporting just GLIBC 2.27 or later. Right? I feel I might be missing some hidden trap. Thanks, John From kevin.rushforth at oracle.com Tue Aug 2 22:50:11 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 2 Aug 2022 15:50:11 -0700 Subject: JavaFx Linux vs Glibc In-Reply-To: <5c7fb16c-1bb5-2d51-25d1-87cfc3d4b3ce@status6.com> References: <5c7fb16c-1bb5-2d51-25d1-87cfc3d4b3ce@status6.com> Message-ID: Nothing requires gcc 11.2, but we've updated to using that for our builds. -- Kevin On 8/2/2022 2:56 PM, John Neffenger wrote: > On 8/2/22 2:28 PM, Johan Vos wrote: >> The problem with this is that there is no GCC 11.2 (which is required >> per the build.properties) that comes with Ubuntu 20.04. > > Thanks, Johan. You've mentioned that before, but I feel like I'm > missing some information. What is in the JavaFX build that requires > GCC 11.2? > > I'm building JavaFX without problems using the GCC from Ubuntu 18.04. > > ? JavaFX 'build.properties' file: > ??? jfx.build.linux.gcc.version=gcc11.2.0-OL6.4+1.0 > > ? Ubuntu 18.04 LTS: > ??? gcc=4:7.4.0-1ubuntu2.3 > > I'm not building WebKit or the media libraries, though -- just a simple: > > ? $ gradle sdk jmods javadoc > > Maybe Ubuntu has back-ported whatever feature is required in GCC? > > I understand why OpenJDK and OpenJFX might want to be compatible with > very old C libraries back to GLIBC version 2.9. In fact, that > compatibility has allowed me to run Java on old embedded ARM devices > that support only up to Ubuntu 14.04 LTS and nothing later. But if > you're targeting the currently supported Linux distributions (Ubuntu > 18.04 LTS, Fedora 35, or later), there's nothing wrong with supporting > just GLIBC 2.27 or later. Right? > > I feel I might be missing some hidden trap. > > Thanks, > John From kcr at openjdk.org Tue Aug 2 23:10:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Aug 2022 23:10:49 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v8] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 09:15:36 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul has updated the pull request incrementally with one additional commit since the last revision: > > A few more minor code cleanups The fix looks good with a couple comments inline. I tested it on all platforms (since there is a small change in shared code), and it all looks good. modules/javafx.graphics/src/main/native-glass/mac/GlassMenu.m line 272: > 270: && (jPixelsHeightField > 0) > 271: && (jPixelsScaleXField > 0) > 272: && (jPixelsScaleYField > 0) Since this is a `jField`, it should be tested for non-zero rather than `> 0`, so the better test would be: if (jPixelsWidthField && jPixelsHeightField && jPixelsScaleXField && jPixelsScaleYField) The code should never get here, though, if those fields are not initialized in `initIDs`, so you could remove the check entirely, or else move it to the top of the method (before the test for pixel != null) as a sanity check, and return if any are null. I'll leave that part of the change up to you. modules/javafx.graphics/src/main/native-glass/mac/GlassMenu.m line 279: > 277: jfloat scaley = (*env)->GetFloatField(env, pixels, jPixelsScaleYField); > 278: > 279: if ((scalex > 1) && (scaley > 1) && (width > 1) && (height > 1)) { The check for `width` or `height` should be `> 0`, since a width or height of 1 is valid (perhaps not a likely value for an icon, but I see no reason to exclude it). Also, in theory, `scalex` and `scaley` could be different such that one of them is `1` and the other is `> 1`, in which case you would still want to apply the scale. That might not be worth worrying about here (I doubt it can ever happen on macOS). ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Tue Aug 2 23:20:58 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Aug 2022 23:20:58 GMT Subject: [jfx19] RFR: 8291589: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 19:16:26 GMT, Ambarish Rapte wrote: > Updating last modified year in the files that were modified during year 2022. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/861 From arapte at openjdk.org Wed Aug 3 10:55:58 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 3 Aug 2022 10:55:58 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: Message-ID: <5lpwAMZV3NGMAoaQ_IpnjsRRnO47wqzZOsG70--cwkU=.edd7ecb8-f162-41e7-a020-8d3c0af96753@github.com> On Sat, 30 Jul 2022 10:48:07 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 98: >> >>> 96: * specular component. The computation is done in world space. >>> 97: */ >>> 98: void computeLight(float i, float3 n, float3 refl, float specPower, float3 toLight, float3 lightDir, in out float3 d, in out float3 s) { >> >> `toLight` -> `vertexToLightVec` ? > > The computation at this point is for pixels, and the argument type tells you if it's a vector (`float3`). When working with fields in the shaders' input/output it was convenient to be more descriptive with the names. Here everything is confined, so I don't think the descriptive names help much. Can still do a naming pass on these if you want. Agreed, `vertexToLightVec` does not fit here. I am not able to convince myself with naming pass. I guess the variable which have proper names are fine. May be rename the variable that are single lettered, Leaving it to you. ------------- PR: https://git.openjdk.org/jfx/pull/789 From andre.gqueiroz at gmail.com Wed Aug 3 12:07:09 2022 From: andre.gqueiroz at gmail.com (Andre Queiroz) Date: Wed, 3 Aug 2022 09:07:09 -0300 Subject: 8087577: Fix host OS check with refactoring Message-ID: Hi, I've tried JFX cross building (Windows > Android; Linux > Android) and things got wrong, mainly on Windows. The build script tried to build native Windows libraries instead only Android native libraries. I'm working on a refactoring of the build script. There is a lot of work but, also, a lot to learn. I appreciate comments and tips for this work, initially on how to easily debug build script (watch execution steps and variables). Regards, Andr? Queiroz -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Aug 3 12:24:56 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 3 Aug 2022 05:24:56 -0700 Subject: 8087577: Fix host OS check with refactoring In-Reply-To: References: Message-ID: <558b686f-f94d-d24d-d305-ad2058b1419e@oracle.com> A refactoring of build.gradle would be a very large undertaking that would likely not be accepted. Before you invest time in such an effort, you should describe at a high-level the sort of changes you envision. Starting with the high-level goal, it isn't clear to me that cross-building for Android on Windows is worth spending much effort on, so I recommend that you start with the motivation for doing this. -- Kevin On 8/3/2022 5:07 AM, Andre Queiroz wrote: > Hi, > > I've tried JFX cross building (Windows > Android; Linux > Android) and > things got wrong, mainly on Windows. The build script tried to build > native Windows libraries instead only Android native libraries. > > I'm working on a refactoring of the build script. There is a lot of > work but, also, a lot to learn. I appreciate comments and tips for > this work, initially on how to easily debug build script (watch > execution steps and variables). > > Regards, > > Andr? Queiroz From aghaisas at openjdk.org Wed Aug 3 14:45:58 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 3 Aug 2022 14:45:58 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 15:19:50 GMT, Marius Hanl wrote: >> This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. >> As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. >> >> The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. >> When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. >> >> Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10 (=padding left+right = 10), then only the first cell should start at 10 and the other cells follow as usual) >> Also the `compute...` methods needs to add the padding as well. >> >> **Example:** >> _Row padding left right 0:_ >> [Cell1][Cell2][Cell3] >> _Row padding left right 10:_ >> [ 10 ][Cell1][Cell2][Cell3][ 10 ] (`compute...` method also needs to account the padding) >> _Same for top bottom._ >> >> When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). >> Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. >> >> This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly (probably at the cost of performance). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8218826: changed test file to use junit5 api Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/800 From kcr at openjdk.org Wed Aug 3 15:14:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 15:14:54 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v5] In-Reply-To: <5i0ztOzetIFtHCpKLpStDQEmfpGSJ32hwZZbKamNlw4=.e95f63da-24e3-40ad-b2b3-6ece70803401@github.com> References: <6L5lKtJQoYNoo0FjHo4xyha5dXhmjU03BBzENNCBAdg=.15313546-706c-4109-b051-ec150399fef3@github.com> <5i0ztOzetIFtHCpKLpStDQEmfpGSJ32hwZZbKamNlw4=.e95f63da-24e3-40ad-b2b3-6ece70803401@github.com> Message-ID: On Mon, 25 Jul 2022 18:53:21 GMT, Paul wrote: >> Looks good (and tested on Mac). I have some comments. > > Thanks for all the feedback. I've updated as per your suggestions @jperedadnr and @kevinrushforth. Let me know how this looks to you - I'm learning a lot here :-) > > I ran the tests as per your example and got `802 tests completes, 28 failed, 108 skipped`, which is exactly the same as when I run them on the `master` branch. Is there something I should be doing on a Mac to get zero failures? (Although, it's a lot better than my Linux box which gets 200 failed!) @gargoyle To clarify my inline comments, the minimal change you need to make is: 1. Change the tests of the four `jField` variables to remove the `> 0` (so it becomes a boolean test for non-null). 2. Change the tests of `width` and `height` to be `> 0` (rather than `> 1`) My other suggestions are optional. ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Wed Aug 3 15:25:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 15:25:54 GMT Subject: RFR: 8271395: Fixing crash at printing [v2] In-Reply-To: References: <02K0ao_vWR0JEjBwNRu9wwG-Vbx-10Wl8Dw6V3UGoxA=.7ae7c2b4-b915-4940-866c-13dd94a5fcd0@github.com> Message-ID: On Thu, 21 Jul 2022 11:54:01 GMT, Florian Kirmaier wrote: >> Inline > > I've worked in the feedback, thank you @kevinrushforth > Small note, this change is not used for a while and is therefore well tested. @FlorianKirmaier This PR is pending the following: 1. Merge upstream master into your PR branch (so we can get a clean test run on the latest + your changes) 2. Change this PR title to `8271395: Crash during printing when disposing textures` ------------- PR: https://git.openjdk.org/jfx/pull/618 From arapte at openjdk.org Wed Aug 3 15:32:50 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 3 Aug 2022 15:32:50 GMT Subject: [jfx19] Integrated: 8291589: Update copyright header for files modified in 2022 In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 19:16:26 GMT, Ambarish Rapte wrote: > Updating last modified year in the files that were modified during year 2022. This pull request has now been integrated. Changeset: dd30402a Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/dd30402a5c22daf79b88dd35b42f32d0a0e28867 Stats: 194 lines in 194 files changed: 0 ins; 0 del; 194 mod 8291589: Update copyright header for files modified in 2022 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/861 From angorya at openjdk.org Wed Aug 3 17:32:21 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 17:32:21 GMT Subject: RFR: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private Looks like the general sentiment is to keep the code as is and disable the warning. Withdrawing this PR. ------------- PR: https://git.openjdk.org/jfx/pull/824 From angorya at openjdk.org Wed Aug 3 17:32:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 17:32:22 GMT Subject: Withdrawn: 8289384: Fix warnings: method does not override the inherited method since it is private to a different package In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev wrote: > The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/824 From angorya at openjdk.org Wed Aug 3 17:47:54 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 17:47:54 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Nir: would it be possible to move on with this change? You've raised some good questions that do warrant additional investigation and/or work, though I feel they go beyond the scope of this PR. With these changes integrated, we'd finally have an Eclipse config with 0 errors and warnings. Thank you. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Wed Aug 3 17:47:56 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 Aug 2022 17:47:56 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: <8DYT3i0J_PG0ls35DA5PTGXS_GjbTnFd4EA1-zgnN7w=.423c1754-c330-4553-87c3-694d76483fd5@github.com> On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ It will take me time as I have other obligations. Also, my Eclipse is configured with additional warnings, so I have thousands of them. It's a matter of personal choice which warnings to show. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 3 17:53:44 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 17:53:44 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Thank you, Nir. As a side note, I've attached the errors/warnings config screenshots to https://bugs.openjdk.org/browse/JDK-8289379 I personally prefer to work with 0 errors and warnings as the actual problems do not get lost in the noise. Cheers, -andy From: nlisker ***@***.***> Date: Wednesday, 2022/08/03 at 10:45 To: openjdk/jfx ***@***.***> Cc: Andy Goryachev ***@***.***>, Author ***@***.***> Subject: [External] : Re: [openjdk/jfx] 8290473: update Eclipse .classpath in apps, buildSrc (PR #858) It will take me time as I have other obligations. Also, my Eclipse is configured with additional warnings, so I have thousands of them. It's a matter of personal choice which warnings to show. ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***> ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Wed Aug 3 18:38:07 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 18:38:07 GMT Subject: RFR: Merge jfx19 Message-ID: Merge `jfx19` into `master`. ------------- Commit messages: - Merge jfx19 - 8291589: Update copyright header for files modified in 2022 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jfx&pr=862&range=00.0 - jfx19: https://webrevs.openjdk.org/?repo=jfx&pr=862&range=00.1 Changes: https://git.openjdk.org/jfx/pull/862/files Stats: 190 lines in 190 files changed: 0 ins; 0 del; 190 mod Patch: https://git.openjdk.org/jfx/pull/862.diff Fetch: git fetch https://git.openjdk.org/jfx pull/862/head:pull/862 PR: https://git.openjdk.org/jfx/pull/862 From kcr at openjdk.org Wed Aug 3 19:26:18 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 19:26:18 GMT Subject: RFR: Merge jfx19 [v2] In-Reply-To: References: Message-ID: > Merge `jfx19` into `master`. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge jfx19 - Merge - 8289605: Robot capture tests fail intermittently on Mac M1 Reviewed-by: kcr - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment Reviewed-by: kcr - 8290530: Bump minimum JDK version for JavaFX to JDK 17 Reviewed-by: prr, jvos - 8290990: Clear .root style class from a root node that is removed from a Scene/SubScene Reviewed-by: jhendrikx, aghaisas, mhanl - 8285881: Update WebKit to 614.1 Co-authored-by: Ambarish Rapte Co-authored-by: Kevin Rushforth Co-authored-by: Jay Bhaskar Reviewed-by: kcr, arapte, mstrauss, jvos - 8290527: Bump macOS GitHub actions to macOS 11 Reviewed-by: arapte - 8289388: Fix warnings: method is overriding a synchronized method without being synchronized Reviewed-by: kcr - 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() Reviewed-by: kcr - ... and 7 more: https://git.openjdk.org/jfx/compare/dd30402a...bedd31db ------------- Changes: https://git.openjdk.org/jfx/pull/862/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=862&range=01 Stats: 454247 lines in 7392 files changed: 301187 ins; 110186 del; 42874 mod Patch: https://git.openjdk.org/jfx/pull/862.diff Fetch: git fetch https://git.openjdk.org/jfx pull/862/head:pull/862 PR: https://git.openjdk.org/jfx/pull/862 From kcr at openjdk.org Wed Aug 3 20:00:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 20:00:38 GMT Subject: Integrated: Merge jfx19 In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 18:30:20 GMT, Kevin Rushforth wrote: > Merge `jfx19` into `master`. This pull request has now been integrated. Changeset: 4c1f4c20 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/4c1f4c20b99dfc8c8016c305983dfea5e1b9d6f2 Stats: 190 lines in 190 files changed: 0 ins; 0 del; 190 mod Merge ------------- PR: https://git.openjdk.org/jfx/pull/862 From angorya at openjdk.org Wed Aug 3 23:28:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 23:28:24 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - 8235491: whitespace - 8235491: additional tests - Merge remote-tracking branch 'origin/master' into 8235491.isselected - 8235491: javadoc - 8235491: tree table view - Merge remote-tracking branch 'origin/master' into 8235491.isselected - 8235491: review comments - 8235491: whitespace - 8235491: javadoc - 8235491: 2022 - ... and 1 more: https://git.openjdk.org/jfx/compare/c300ac30...ad3c70b9 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/6267a0e4..ad3c70b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=04-05 Stats: 447536 lines in 7514 files changed: 300975 ins; 103527 del; 43034 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Wed Aug 3 23:28:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Aug 2022 23:28:26 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v4] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <5vHuJ5xzmkcC2SYqZwpyN7yazrKqRAEdr4Yp_qOhBRY=.3ef6aa05-c7ca-4d0f-b574-7918f20496bd@github.com> On Thu, 28 Jul 2022 16:00:11 GMT, Jeanette Winzenburg 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 seven additional commits since the last revision: >> >> - 8235491: tree table view >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: review comments >> - 8235491: whitespace >> - 8235491: javadoc >> - 8235491: 2022 >> - 8235491: Tree/TableView: implementation of isSelected(int) violates contract > > forgot: will not be near my IDE until next Monday - then I'll run the tests and see for myself :) @kleopatra : Various scenarios are pretty well covered by the existing tests. Just in case, I've added tests to exercise the model with cell selection enabled. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Wed Aug 3 23:50:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 23:50:09 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi I've tested this on all three platforms and everything looks good. I can confirm that the newly added test fails without the fix and passes with the fix, as does the test program attached to [JDK-8274066](https://bugs.openjdk.org/browse/JDK-8274066). I've reviewed most of the code, except for the DPQS sorter itself; I'll do at least a cursory review of that in the next couple of days. I left an inline question as to whether it might make sense to initially leave it disabled by default for this release in order to reduce the risk of regression. modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinProperties.java line 206: > 204: > 205: public static boolean isUseDPQS() { > 206: return getBoolean("prism.marlin.useDPQS", "true"); In order to reduce risk, it might make sense to disable DPQS by default initially. It would then be available to anyone who wants to try it out with more complex paths, but would be less prone to possible regressions. What do you think? tests/system/src/test/java/test/com/sun/marlin/HugePolygonClipTest.java line 149: > 147: err.initCause(ex); > 148: throw err; > 149: } Suggestion: if you add `throws Exception` to the method signature, this try/catch block can be simplified to a single assert statement: assertTrue("Timeout waiting for Application to launch", launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); Many of our older tests use the patter in this method, but most newer tests use the simplified check. ------------- PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Wed Aug 3 23:50:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Aug 2022 23:50:11 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Fri, 29 Jul 2022 11:55:22 GMT, Laurent Bourg?s wrote: >> At this point, due to time constraints, we will need to do this early in JavaFX 20 rather than late in JavaFX 19 (which is probably better anyway). > > @kevinrushforth could you tell me approximately when you will have free cycles to review this PR ? > I plan to make minor updates by that time. @bourgesl One more thing: can you please merge the latest upstream master into your branch, since it is now several months out of date. ------------- PR: https://git.openjdk.org/jfx/pull/674 From duke at openjdk.org Thu Aug 4 08:26:02 2022 From: duke at openjdk.org (Paul) Date: Thu, 4 Aug 2022 08:26:02 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v5] In-Reply-To: References: <6L5lKtJQoYNoo0FjHo4xyha5dXhmjU03BBzENNCBAdg=.15313546-706c-4109-b051-ec150399fef3@github.com> <5i0ztOzetIFtHCpKLpStDQEmfpGSJ32hwZZbKamNlw4=.e95f63da-24e3-40ad-b2b3-6ece70803401@github.com> Message-ID: On Wed, 3 Aug 2022 15:11:31 GMT, Kevin Rushforth wrote: >> Thanks for all the feedback. I've updated as per your suggestions @jperedadnr and @kevinrushforth. Let me know how this looks to you - I'm learning a lot here :-) >> >> I ran the tests as per your example and got `802 tests completes, 28 failed, 108 skipped`, which is exactly the same as when I run them on the `master` branch. Is there something I should be doing on a Mac to get zero failures? (Although, it's a lot better than my Linux box which gets 200 failed!) > > @gargoyle To clarify my inline comments, the minimal change you need to make is: > > 1. Change the tests of the four `jField` variables to remove the `> 0` (so it becomes a boolean test for non-null). > 2. Change the tests of `width` and `height` to be `> 0` (rather than `> 1`) > > My other suggestions are optional. Thanks @kevinrushforth. Thinking about it, is there merit in changing the `scalex` and `scaley` checks to be `!= 0`, as The main reason for checking at all is to prevent a division by zero. Although unlikely, could fractional values < 1 reach this code? ------------- PR: https://git.openjdk.org/jfx/pull/743 From fastegal at openjdk.org Thu Aug 4 11:00:13 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 4 Aug 2022 11:00:13 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ modules/javafx.graphics/.classpath line 5: > 3: > 4: > 5: these two seem not enough for running projects that depend on the graphics project, without the other two (from the original before the [PR 804](https://github.com/openjdk/jfx/pull/804) I'm still getting runtime exceptions (though different from those copied shown on the [mailinglist](https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034806.html)), see below. It's only working with all four of the original, that is stacktrace if both build/hsls/xx are missing: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:429) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.RuntimeException: InputStream must be non-null at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.getBuffer(D3DResourceFactory.java:365) at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createShader(D3DResourceFactory.java:409) at javafx.graphics/com.sun.prism.shader.FillPgram_Color_Loader.loadShader(FillPgram_Color_Loader.java:47) ... 27 more java.lang.InternalError: Error loading stock shader FillPgram_Color at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) at java.base/java.lang.Thread.run(Thread.java:835) ------------- PR: https://git.openjdk.org/jfx/pull/858 From fastegal at openjdk.org Thu Aug 4 11:28:09 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 4 Aug 2022 11:28:09 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v2] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <0BHAM92Ixnd5GJq8ru6ptLarsL3FuUttsg04eepuAFg=.d48bd100-a7f4-49fc-9cc0-165a54204601@github.com> On Wed, 27 Jul 2022 05:47:56 GMT, Ajit Ghaisas wrote: >> thank you for your comments, Ajit! below are responses, please let me know if you agree or not: >> >> 1. javadoc for TableSelectionModel.isSelected(int, TablecolumnBase) already describes the logic: >> ` >> /** >> * Convenience function which tests whether the given row and column index >> * is currently selected in this table instance. If the table control is in its >> * 'cell selection' mode (where individual cells can be selected, rather than >> * entire rows), and if the column argument is null, this method should return >> * true only if all cells in the given row are selected. >> * @param row the row >> * @param column the column >> * @return true if the given row and column index is currently selected in >> * this table instance >> */ >> public abstract boolean isSelected(int row, TableColumnBase column); >> ` >> >> 2. TreeTableView.TreeTableViewSelectionModel extends TableSelectionModel, so the changes affect both. >> 3. good point, fixed. > >> 1. javadoc for TableSelectionModel.isSelected(int, TablecolumnBase) already describes the logic: > Yes. I am aware of this documentation. I was thinking of making it clear for the users if they see their application breaks due to this change. I see that you have captured this in "Compatibility Impact" section of the CSR. > > >> 2. TreeTableView.TreeTableViewSelectionModel extends TableSelectionModel, so the changes affect both. > I see that there are overridden methods `public boolean isSelected(int index)` and `public boolean isSelected(int row, TableColumnBase,?> column)` in class `TreeTableViewArrayListSelectionModel` present in TreeTableView.java. Hence, I think that the change that you have made in `TableView.java - isSelected(int index)` method should also be made in `TreeTableView.java - isSelected(int index)` as well. > > >> 3. good point, fixed. > Thanks! @aghaisas > Yes. I am aware of this documentation. I was thinking of making it clear for the users if they see their application breaks due to this change. If any application breaks, it's its own fault: they coded against the implementation of TableXXSelectionModels which was (incorrectly) `isSelected(int) == isSelected(int, null)`. That might be due to the specification mess, though: - the old spec on `SelectionModel.isSelected(int)` was incorrectly arguing with api on MultipleSelectionModel, that is _Is functionally equivalent to calling getSelectedIndices().contains(index)_ - that invariant actually belongs into `MultipleSelectionModel.isSelected(int)` which has no specialized spec - the method is first implemented in the (unfortunately hidden) `MultipleSelectionModelBase.isSelected(int)` fulfilling the constraint but also without spec. To clean this up completely, we could also change the of MultipleSelectionModel and move the old `isSelected(int) == getSelectedIndices().contains(int)` into the spec of its isSelected. Probably could be done in a follow-up issue (or added to one of the open doc errors around selection models). What do you think? ------------- PR: https://git.openjdk.org/jfx/pull/839 From jvos at openjdk.org Thu Aug 4 14:36:55 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 4 Aug 2022 14:36:55 GMT Subject: RFR: 8291908: VirtualFlow creates unneeded empty cells Message-ID: When calculating the viewportOffset, we now already take into account that cells will have to shift. This prevents the creation of temporary empty cells in the layout phase. One test needed to be fixed, since the number of invocations to updateItem() was hardcoded (and it is decreased by this commit). ------------- Commit messages: - When calculating the viewportOffset, we now already take into account that cells will have to shift. Changes: https://git.openjdk.org/jfx/pull/863/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291908 Stats: 40 lines in 3 files changed: 38 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/863.diff Fetch: git fetch https://git.openjdk.org/jfx pull/863/head:pull/863 PR: https://git.openjdk.org/jfx/pull/863 From angorya at openjdk.org Thu Aug 4 15:37:14 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 15:37:14 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:53:07 GMT, Jeanette Winzenburg wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > modules/javafx.graphics/.classpath line 5: > >> 3: >> 4: >> 5: > > these two seem not enough for running projects that depend on the graphics project, without the other two (from the original before the [PR 804](https://github.com/openjdk/jfx/pull/804) I'm still getting runtime exceptions (though different from those copied shown on the [mailinglist](https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034806.html)), see below. > > It's only working with all four of the original, that is > > > > > > > > > > > > > > > stacktrace if both build/hsls/xx are missing: > > > java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:429) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:835) > Caused by: java.lang.RuntimeException: InputStream must be non-null > at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.getBuffer(D3DResourceFactory.java:365) > at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createShader(D3DResourceFactory.java:409) > at javafx.graphics/com.sun.prism.shader.FillPgram_Color_Loader.loadShader(FillPgram_Color_Loader.java:47) > ... 27 more > java.lang.InternalError: Error loading stock shader FillPgram_Color > at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) > at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) > at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) > at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:835) @kleopatra : thank you for your feedback! a couple of questions: 1. which tests are failing? 2. are you testing on windows? ------------- PR: https://git.openjdk.org/jfx/pull/858 From fastegal at openjdk.org Thu Aug 4 16:46:16 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 4 Aug 2022 16:46:16 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:33:11 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/.classpath line 5: >> >>> 3: >>> 4: >>> 5: >> >> these two seem not enough for running projects that depend on the graphics project, without the other two (from the original before the [PR 804](https://github.com/openjdk/jfx/pull/804) I'm still getting runtime exceptions (though different from those copied shown on the [mailinglist](https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034806.html)), see below. >> >> It's only working with all four of the original, that is >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> stacktrace if both build/hsls/xx are missing: >> >> >> java.lang.reflect.InvocationTargetException >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:429) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) >> Caused by: java.lang.RuntimeException: InputStream must be non-null >> at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.getBuffer(D3DResourceFactory.java:365) >> at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createShader(D3DResourceFactory.java:409) >> at javafx.graphics/com.sun.prism.shader.FillPgram_Color_Loader.loadShader(FillPgram_Color_Loader.java:47) >> ... 27 more >> java.lang.InternalError: Error loading stock shader FillPgram_Color >> at javafx.graphics/com.sun.prism.d3d.D3DResourceFactory.createStockShader(D3DResourceFactory.java:432) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:269) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:500) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:369) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:919) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:620) >> at javafx.graphics/com.sun.prism.impl.ps.BaseShaderGraphics.fillRect(BaseShaderGraphics.java:1526) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1112) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:852) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:754) >> at javafx.graphics/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) >> at javafx.graphics/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at javafx.graphics/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) >> at javafx.graphics/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) >> at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:92) >> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126) >> at java.base/java.lang.Thread.run(Thread.java:835) > > @kleopatra : > thank you for your feedback! a couple of questions: > 1. which tests are failing? > 2. are you testing on windows? the tests are fine - it happens if I have a separate project and let that depend on the controls, basic, graphics projects (just the same setup as described on the mailinglist) ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Thu Aug 4 17:11:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 17:11:05 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 16:41:20 GMT, Jeanette Winzenburg wrote: >> @kleopatra : >> thank you for your feedback! a couple of questions: >> 1. which tests are failing? >> 2. are you testing on windows? > > the tests are fine - it happens if I have a separate project and let that depend on the controls, basic, graphics projects (just the same setup as described on the mailinglist) This is puzzling, @kleopatra . I don't see a reference to [hlsl/]Prism or [hlsl/]Decora anywhere. Not in any gradle.build file, not in every file. I don't think these two directories are being built, though I can only test on Mac at the moment. I have a separate (modular) project that builds and runs as well, and I don't see the exceptions (I am running against 8290473.apps branch). I had to execute the 'sdk' target via gradle first, in order to generate stuff in build/gensrc/jsl-prism and build/gensrc/jsl-decora in graphics. ------------- PR: https://git.openjdk.org/jfx/pull/858 From kevin.rushforth at oracle.com Thu Aug 4 17:52:53 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 4 Aug 2022 10:52:53 -0700 Subject: JavaFX 19 is in Rampdown Phase Two (RDP2) Message-ID: To: OpenJFX Developers As a reminder, JavaFX 19 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bugs, and test or doc bugs of any priority, can be fixed during RDP2. Explicit approval is needed for bug fixes (except for doc and test fixes), and all enhancements to go in to the jfx19 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. We will use the same rules for RDP2 that the JDK uses [3], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 19 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx19-fix-request", "openjfx19-fix-yes", "openjfx19-fix-no" and "openjfx19-fix-nmi", "openjfx19-enhancement-request", "openjfx19-enhancement-yes", "openjfx19-enhancement-no" and "openjfx19-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into jfx19 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx19 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx19 --> master for the duration of the openjfx19 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in openjfx19. We need to be extremely careful about including anything that introduces risk. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 20 as of today). This is usually what we want. A PR should be targeted to `jfx19` if, and only if, it is intended for OpenJFX 19 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx19`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 20. Reviewers also need to be extra careful when reviewing PRs targeted to jfx19 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-May/034217.html [2] https://github.com/openjdk/jfx/tree/jfx19 [3] http://openjdk.java.net/jeps/3 From angorya at openjdk.org Thu Aug 4 18:37:52 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 18:37:52 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ 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 three additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8290473.apps - 8290473: added ColorCube project - 8290473: eclipse config for apps ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/e681d49a..fef3fadf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=00-01 Stats: 323 lines in 195 files changed: 105 ins; 2 del; 216 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Thu Aug 4 21:43:57 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 21:43:57 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); I'd like to see this get resolved for JavaFX 20. I note there is a similar issue with `TableView`, which is tracked by [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145). As I mentioned in that JBS issue, I tend to agree that if we were starting today with a blank sheet of paper, we might have disallowed null and defined a "noop" selection model and/or focus model. At this point, though, it would be a breaking change, even though we don't specify the behavior of null, so we ought to make it work in those places where it doesn't. > So there is no consistent behaviour for this, but a lot of code already handles null by behaving in some kind of default way without changing the property directly, and I think it might be the best to adapt to this. This seems like the best way forward to me, but let's see what comes out of the review. As part of this, we should clarify the spec that a null selection (and focus) model is allowed, and say what it does. This might mean a CSR, but I'd want to look at the current docs first. ------------- PR: https://git.openjdk.org/jfx/pull/711 From angorya at openjdk.org Thu Aug 4 21:51:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 21:51:47 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 21:29:49 GMT, Kevin Rushforth wrote: >> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. >> >> The following NPEs are fixed (all are also covered by exactly one test case): >> NPEs with null selection model: >> - Mouse click on a `ListCell` >> - SPACE key press >> - KP_UP (arrow up) key press >> - HOME key press >> - END key press >> - BACK_SLASH + CTRL key press >> >> NPEs with null focus model: >> - SPACE key press >> - Select an items: getSelectionModel().select(1) >> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); > > I'd like to see this get resolved for JavaFX 20. I note there is a similar issue with `TableView`, which is tracked by [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145). > > As I mentioned in that JBS issue, I tend to agree that if we were starting today with a blank sheet of paper, we might have disallowed null and defined a "noop" selection model and/or focus model. At this point, though, it would be a breaking change, even though we don't specify the behavior of null, so we ought to make it work in those places where it doesn't. > >> So there is no consistent behaviour for this, but a lot of code already handles null by behaving in some kind of default way without changing the property directly, and I think it might be the best to adapt to this. > > This seems like the best way forward to me, but let's see what comes out of the review. > > As part of this, we should clarify the spec that a null selection (and focus) model is allowed, and say what it does. This might mean a CSR, but I'd want to look at the current docs first. Setting selection model to null (i.e. disabling selection) is a fairly frequent operation, @kevinrushforth . The code must support that. So no CSR is needed, I think. ------------- PR: https://git.openjdk.org/jfx/pull/711 From kcr at openjdk.org Thu Aug 4 21:51:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 21:51:49 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); I took a look at the bug description for [JDK-8230098](https://bugs.openjdk.org/browse/JDK-8230098), and it should be closed as a duplicate of [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640) rather than adding both as solved by this PR (adding additional issues to a PR is used when that PR solves two different, but related issues). So let's closed JDK-8230098 as a duplicate and you can remove it from this PR with `/issue remove`. ------------- PR: https://git.openjdk.org/jfx/pull/711 From kcr at openjdk.org Thu Aug 4 22:00:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 22:00:54 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 21:47:15 GMT, Andy Goryachev wrote: > So no CSR is needed, I think. Probably you are right if all we end up doing is clarifying existing behavior. For example, if we add a sentence to the effect that "a null selection model disables selection", and that is what already happens today, then a CSR would likely not be needed. Unlike the JDK, which requires a CSR for any non-trivial spec change, we have often added clarifying comments to JavaFX API without a CSR. ------------- PR: https://git.openjdk.org/jfx/pull/711 From angorya at openjdk.org Thu Aug 4 22:12:20 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 22:12:20 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: <_wXhVNj5yBjlTklx5RdZT0nEtb6djCkIzMRvOt5r0ao=.f206d701-e722-4ea0-ad7f-3cee463d4238@github.com> On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); good point. +1 for clarification; same applies to TableView JDK-8187145. I wonder if we also need to apply the same treatment to TreeTableView. ------------- PR: https://git.openjdk.org/jfx/pull/711 From kcr at openjdk.org Thu Aug 4 22:14:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 22:14:30 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v5] In-Reply-To: References: <6L5lKtJQoYNoo0FjHo4xyha5dXhmjU03BBzENNCBAdg=.15313546-706c-4109-b051-ec150399fef3@github.com> <5i0ztOzetIFtHCpKLpStDQEmfpGSJ32hwZZbKamNlw4=.e95f63da-24e3-40ad-b2b3-6ece70803401@github.com> Message-ID: On Thu, 4 Aug 2022 08:22:29 GMT, Paul wrote: > Thinking about it, is there merit in changing the scalex and scaley checks to be != 0, as The main reason for checking at all is to prevent a division by zero. Although unlikely, could fractional values < 1 reach this code? I doubt that a scale `< 1` is possible on Mac, although we don't preclude it in other places in the code. Negative scales would be a problem, so a `> 0` check seems fine. ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Thu Aug 4 22:26:32 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 22:26:32 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); Quite possibly. Can you check it as part of fixing [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145) and expand that issue to cover TreeTableView if needed? ------------- PR: https://git.openjdk.org/jfx/pull/711 From angorya at openjdk.org Thu Aug 4 22:26:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 Aug 2022 22:26:33 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: <72GK2iMyy8X4FRMp65qK-E5ISBz_Ht0yd6rrNQ-PfLA=.e3595b6d-1ab6-41d8-a818-df0a049dba5e@github.com> On Thu, 4 Aug 2022 22:19:40 GMT, Kevin Rushforth wrote: > Can you check it as part of fixing [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145) and expand that issue to cover TreeTableView if needed? Absolutely. Just checked - we have the same problem there. Should it be a different ticket though? ------------- PR: https://git.openjdk.org/jfx/pull/711 From kcr at openjdk.org Thu Aug 4 23:38:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 23:38:00 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Wed, 3 Aug 2022 23:28:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - 8235491: whitespace > - 8235491: additional tests > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: javadoc > - 8235491: tree table view > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: review comments > - 8235491: whitespace > - 8235491: javadoc > - 8235491: 2022 > - ... and 1 more: https://git.openjdk.org/jfx/compare/6dce75f4...ad3c70b9 The doc changes look fine to me, since I agree that further clarification of `MultipleSelectionModel.isSelected` can be done in a follow-up. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Thu Aug 4 23:38:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Aug 2022 23:38:01 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v2] In-Reply-To: <0BHAM92Ixnd5GJq8ru6ptLarsL3FuUttsg04eepuAFg=.d48bd100-a7f4-49fc-9cc0-165a54204601@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <0BHAM92Ixnd5GJq8ru6ptLarsL3FuUttsg04eepuAFg=.d48bd100-a7f4-49fc-9cc0-165a54204601@github.com> Message-ID: On Thu, 4 Aug 2022 11:24:34 GMT, Jeanette Winzenburg wrote: > To clean this up completely, we could also change the of MultipleSelectionModel and move the old `isSelected(int) == getSelectedIndices().contains(int)` into the spec of its isSelected. Probably could be done in a follow-up issue (or added to one of the open doc errors around selection models). > > What do you think? I like this idea. Either filing a new bug or fold into an existing one seems fine. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Fri Aug 5 07:19:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 07:19:01 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 7 Jul 2022 22:46:53 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed pixel color tests on hi-dpi I did a quick skim of the DPQS class, enough to know that code review is unlikely to spot the kind of subtle bugs that such code might have. So my main question is around testing of DQPS itself. How much standalone testing has been done on the sort algorithm? I did see that several of the methods are missing `@param` tags in the docs, and while this isn't public API, it would aid understanding it a bit better if those were added. I'm still wondering whether it should be enabled by default. On the one hand, it would reduce risk to have it disabled by default. On the other hand, if we enable it now, we are early enough in JavaFX 20 that if problems are found, they can be fixed and/or it can be disabled by default later. ------------- PR: https://git.openjdk.org/jfx/pull/674 From lbourges at openjdk.org Fri Aug 5 07:19:02 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 5 Aug 2022 07:19:02 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 4 Aug 2022 23:01:37 GMT, Kevin Rushforth wrote: > I did a quick skim of the DPQS class, enough to know that code review is unlikely to spot the kind of subtle bugs that such code might have. So my main question is around testing of DQPS itself. How much standalone testing has been done on the sort algorithm? I explained previously this DPQS implementation with 2 arrays has been developped in 2019-2020, tested using unit tests, benchmarks in other github repositories and released in Marlin2d 0.9.4. I propose to leave it enabled in jfx20 now and if any bug is finally found, we will be able to disable dpqs easily using this flag. > > I did see that several of the methods are missing `@param` tags in the docs, and while this isn't public API, it would aid understanding it a bit better if those were added. > > I'm still wondering whether it should be enabled by default. On the one hand, it would reduce risk to have it disabled by default. On the other hand, if we enable it now, we are early enough in JavaFX 20 that if problems are found, they can be fixed and/or it can be disabled by default later. I totally agree. PS: I will make the test fix before sunday I hope and backport 1 one-liner fix in Stroker. See: https://github.com/openjdk/jdk/pull/8943/files Thanks ------------- PR: https://git.openjdk.org/jfx/pull/674 From mhanl at openjdk.org Fri Aug 5 07:38:09 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 5 Aug 2022 07:38:09 GMT Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can cause endless loop/crash and other performance issues [v3] In-Reply-To: References: Message-ID: <8KHPZhz6IrC74E9dFYFfMzsxdhn_RkF_lg8zuOcMejQ=.9b0652d9-1168-4dd0-ac9a-358ce9257eff@github.com> On Tue, 26 Jul 2022 11:51:10 GMT, Florian Kirmaier wrote: >> It's "a bit" complicated. >> In some situations, getRuns get's called because listeners on bounds are set. >> This causes TextFlow to layout to compute the runs. >> Afterward, the bounds of the parents get updated. >> This triggers a call to compute bounds - which cascades up to the children. >> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer. >> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack) >> >> In the case it happened - it didn't repair and the application kinda crashed. >> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds. >> It also can cause unpredictable performance issues. >> >> Unit test and example stacktrace are in the ticket. >> >> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. >> The Textflow should be layouting by the Parent. >> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications. >> >> Benefits: >> * Better Tooling Support For ScenicView etc. >> * Fixes complicated but reproducible crashes >> * Might fix some rare crashes, which are hard to reproduce >> * Likely improves performance - might fix some edge cases with unpredictable bad performance > > Florian Kirmaier 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 three additional commits since the last revision: > > - Merge remote-tracking branch 'origjfx/master' into JDK-8269921-textflow-bug > - JDK-8269921 > Added a copyright header > - JDK-8269921 > Fixing a crash related to Text and TextFlow with bounds listeners I got this problem as well today. NPE as `runs` is null in line `359`. Does it make sense to first 'resolve' this by adding a simple null check and later we may try your other change which removes the call to `getParent().layout()`? ------------- PR: https://git.openjdk.org/jfx/pull/564 From mhanl at openjdk.org Fri Aug 5 08:36:00 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 5 Aug 2022 08:36:00 GMT Subject: Integrated: 8218826: TableRowSkinBase: horizontal layout broken if row has padding In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:25:23 GMT, Marius Hanl wrote: > This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. > As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. > > The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. > When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. > > Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10 (=padding left+right = 10), then only the first cell should start at 10 and the other cells follow as usual) > Also the `compute...` methods needs to add the padding as well. > > **Example:** > _Row padding left right 0:_ > [Cell1][Cell2][Cell3] > _Row padding left right 10:_ > [ 10 ][Cell1][Cell2][Cell3][ 10 ] (`compute...` method also needs to account the padding) > _Same for top bottom._ > > When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). > Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. > > This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly (probably at the cost of performance). This pull request has now been integrated. Changeset: b4d86bdf Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/b4d86bdffc2dd89e3473884b4079092e7e2843d1 Stats: 439 lines in 3 files changed: 417 ins; 10 del; 12 mod 8218826: TableRowSkinBase: horizontal layout broken if row has padding Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/800 From fastegal at openjdk.org Fri Aug 5 10:47:05 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 5 Aug 2022 10:47:05 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <6M6xmEgRJCcIOHFDqWwiWTF78IsEJU4GdcZ3ArZtTxQ=.c61bc125-3d1b-4c69-aba5-965b0689b600@github.com> On Wed, 3 Aug 2022 23:28:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - 8235491: whitespace > - 8235491: additional tests > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: javadoc > - 8235491: tree table view > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: review comments > - 8235491: whitespace > - 8235491: javadoc > - 8235491: 2022 > - ... and 1 more: https://git.openjdk.org/jfx/compare/e7aa41f8...ad3c70b9 a bit confused about the [csr](https://bugs.openjdk.org/browse/JDK-8290741) - shouldn't that be focused entirely on SelectionModel.isSelected)? That's where we clarify the contract - all changes to TableXXSelectionModels are implementation changes, fixing their contract violation. So I would expect these not to be mentioned at all in the csr. BTW: isSelected is _not_ a convenience method - that's already changed here, all mentions of its being so should be removed from the csr as well, IMO :) ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Fri Aug 5 10:51:08 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 5 Aug 2022 10:51:08 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: <6M6xmEgRJCcIOHFDqWwiWTF78IsEJU4GdcZ3ArZtTxQ=.c61bc125-3d1b-4c69-aba5-965b0689b600@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <6M6xmEgRJCcIOHFDqWwiWTF78IsEJU4GdcZ3ArZtTxQ=.c61bc125-3d1b-4c69-aba5-965b0689b600@github.com> Message-ID: On Fri, 5 Aug 2022 10:44:55 GMT, Jeanette Winzenburg 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 11 additional commits since the last revision: >> >> - 8235491: whitespace >> - 8235491: additional tests >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: javadoc >> - 8235491: tree table view >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: review comments >> - 8235491: whitespace >> - 8235491: javadoc >> - 8235491: 2022 >> - ... and 1 more: https://git.openjdk.org/jfx/compare/262a884f...ad3c70b9 > > a bit confused about the [csr](https://bugs.openjdk.org/browse/JDK-8290741) - shouldn't that be focused entirely on SelectionModel.isSelected)? That's where we clarify the contract - all changes to TableXXSelectionModels are implementation changes, fixing their contract violation. So I would expect these not to be mentioned at all in the csr. > > BTW: isSelected is _not_ a convenience method - that's already changed here, all mentions of its being so should be removed from the csr as well, IMO :) > @kleopatra : Various scenarios are pretty well covered by the existing tests. good - we seem to be lucky :) ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Fri Aug 5 11:05:00 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 5 Aug 2022 11:05:00 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 17:07:53 GMT, Andy Goryachev wrote: >> the tests are fine - it happens if I have a separate project and let that depend on the controls, basic, graphics projects (just the same setup as described on the mailinglist) > > This is puzzling, @kleopatra . > I don't see a reference to [hlsl/]Prism or [hlsl/]Decora anywhere. Not in any gradle.build file, not in every file. I don't think these two directories are being built, though I can only test on Mac at the moment. > > I have a separate (modular) project that builds and runs as well, and I don't see the exceptions (I am running against 8290473.apps branch). I had to execute the 'sdk' target via gradle first, in order to generate stuff in build/gensrc/jsl-prism and build/gensrc/jsl-decora in graphics. hmm .. that's indeed weird - here (on win) both graphics/build/hlsl/Prism and graphics/build/hlsl/Decora are created by running ./gradlew sdk ... will re-check ------------- PR: https://git.openjdk.org/jfx/pull/858 From fastegal at openjdk.org Fri Aug 5 12:04:58 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 5 Aug 2022 12:04:58 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 11:02:50 GMT, Jeanette Winzenburg wrote: >> This is puzzling, @kleopatra . >> I don't see a reference to [hlsl/]Prism or [hlsl/]Decora anywhere. Not in any gradle.build file, not in every file. I don't think these two directories are being built, though I can only test on Mac at the moment. >> >> I have a separate (modular) project that builds and runs as well, and I don't see the exceptions (I am running against 8290473.apps branch). I had to execute the 'sdk' target via gradle first, in order to generate stuff in build/gensrc/jsl-prism and build/gensrc/jsl-decora in graphics. > > hmm .. that's indeed weird - here (on win) both graphics/build/hlsl/Prism and graphics/build/hlsl/Decora are created by running ./gradlew sdk ... will re-check did re-check (added your fork as remote, checkout this branch, run gradle clean and sdk): all four (as in original classpath) folders are under graphics build. And same errors as above when running a project that has the Eclipse fx projects base, graphics, controls on its module path. ------------- PR: https://git.openjdk.org/jfx/pull/858 From mhanl at openjdk.org Fri Aug 5 12:34:02 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 5 Aug 2022 12:34:02 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 21:29:49 GMT, Kevin Rushforth wrote: > As I mentioned in that JBS issue, I tend to agree that if we were starting today with a blank sheet of paper, we might have disallowed null and defined a "noop" selection model and/or focus model. At this point, though, it would be a breaking change, even though we don't specify the behavior of null, so we ought to make it work in those places where it doesn't. I agree, if we could do it from scratch we can just implement something like a `NonNullObjectProperty` which won't allow null in some way. Or the JDK implements some way of declaring a variable as not nullable. ? And I agree that improving the docs makes sense and more information is always good. ------------- PR: https://git.openjdk.org/jfx/pull/711 From kcr at openjdk.org Fri Aug 5 14:17:27 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 14:17:27 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Wed, 3 Aug 2022 23:28:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - 8235491: whitespace > - 8235491: additional tests > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: javadoc > - 8235491: tree table view > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: review comments > - 8235491: whitespace > - 8235491: javadoc > - 8235491: 2022 > - ... and 1 more: https://git.openjdk.org/jfx/compare/240a9eba...ad3c70b9 > a bit confused about the csr - shouldn't that be focused entirely on SelectionModel.isSelected)? That's where we clarify the contract - all changes to TableXXSelectionModels are implementation changes, fixing their contract violation. So I would expect these not to be mentioned at all in the csr. The specification section of the CSR should (and does) list only the spec change to `SelectionModel.isSelected`. Since there could be an impact to applications that rely on the current behavior, it also seems reasonable to list those in the Solution section (as well as the Compatibility concerns section). I think that the Summary should start by listing the spec change to `SelectionModel.isSelected`, but it seems useful to also say that the implementation of `TableXXSelectionModel` is changing as a result. > BTW: isSelected is not a convenience method - that's already changed here, all mentions of its being so should be removed from the csr as well, IMO :) Agreed. ------------- PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Fri Aug 5 18:29:21 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 Aug 2022 18:29:21 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 12:01:27 GMT, Jeanette Winzenburg wrote: >> hmm .. that's indeed weird - here (on win) both graphics/build/hlsl/Prism and graphics/build/hlsl/Decora are created by running ./gradlew sdk ... will re-check > > did re-check (added your fork as remote, checkout this branch, run gradle clean and sdk): all four (as in original classpath) folders are under graphics build. And same errors as above when running a project that has the Eclipse fx projects base, graphics, controls on its module path. thank you for checking! it looks like there is no way around creating these directories before the 'sdk' task in build.gradle, to silence the missing path warning in eclipse (and adding them back to the .classpath) i was thinking of merely creating these two dirs in a new task 'initDirs' and make 'sdk' depend on that task, in the top level build.gradle. Any objections, @kevinrushforth ? ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Fri Aug 5 18:42:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 18:42:34 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 [v2] In-Reply-To: References: Message-ID: > When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. > > The fix is to adjust the bounds by the screen scale before returning it. > > You can test it on a Windows machine with scaling set to >= 125% as follows: > 1. Turn on Windows Narrator > 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` > 3. TAB between the controls > > Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. > > Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix conversion to platform coords ------------- Changes: - all: https://git.openjdk.org/jfx/pull/853/files - new: https://git.openjdk.org/jfx/pull/853/files/a991c463..554fae4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=853&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=853&range=00-01 Stats: 46 lines in 3 files changed: 18 ins; 11 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/853.diff Fetch: git fetch https://git.openjdk.org/jfx pull/853/head:pull/853 PR: https://git.openjdk.org/jfx/pull/853 From kcr at openjdk.org Fri Aug 5 18:42:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 18:42:34 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 15:01:34 GMT, Kevin Rushforth wrote: > When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. > > The fix is to adjust the bounds by the screen scale before returning it. > > You can test it on a Windows machine with scaling set to >= 125% as follows: > 1. Turn on Windows Narrator > 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` > 3. TAB between the controls > > Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. > > Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. Getting back to this, I discovered what the problem was with some multi-screens layouts when two screens have a different scale. Computing the platform x and y by simply multiplying by the scale is not right, and only work for a screen that touches the origin of the virtual screen space (in both X and Y). When the secondary screen is to the left or above the primary screen, the simple (but incorrect) calculation gives the same result as the correct calculation. For a secondary screen below or to the right of the primary screen, it doesn't. Simply scaling the coordinate about the origin produces a value that is either too small or too large when the two screens have a different scale. The right fix is to use the `Screen.toPlatformX` and `Screen.toPlatformY` methods, which take this into account, and translates the coordinate to the right origin, scales it, and then translates it back. In order to do that, I needed to get the `Window` from which I could get the `Screen`, which required making the quantum `WindowStage` class public along with its `getWindow` method. This is an internal implementation class, so is not a concern. I've tested this updated version in various combinations of layout and screen scales, and everything now works as expected. ------------- PR: https://git.openjdk.org/jfx/pull/853 From angorya at openjdk.org Fri Aug 5 18:48:13 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 Aug 2022 18:48:13 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:38:28 GMT, Kevin Rushforth wrote: >> When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. >> >> The fix is to adjust the bounds by the screen scale before returning it. >> >> You can test it on a Windows machine with scaling set to >= 125% as follows: >> 1. Turn on Windows Narrator >> 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` >> 3. TAB between the controls >> >> Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. >> >> Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. > > Getting back to this, I discovered what the problem was with some multi-screens layouts when two screens have a different scale. Computing the platform x and y by simply multiplying by the scale is not right, and only work for a screen that touches the origin of the virtual screen space (in both X and Y). When the secondary screen is to the left or above the primary screen, the simple (but incorrect) calculation gives the same result as the correct calculation. For a secondary screen below or to the right of the primary screen, it doesn't. Simply scaling the coordinate about the origin produces a value that is either too small or too large when the two screens have a different scale. > > The right fix is to use the `Screen.toPlatformX` and `Screen.toPlatformY` methods, which take this into account, and translates the coordinate to the right origin, scales it, and then translates it back. In order to do that, I needed to get the `Window` from which I could get the `Screen`, which required making the quantum `WindowStage` class public along with its `getWindow` method. This is an internal implementation class, so is not a concern. > > I've tested this updated version in various combinations of layout and screen scales, and everything now works as expected. @kevinrushforth : on windows, a window can be positioned to span two monitors. you can't do this on Mac - once dropped, only a part of the window remains (on the monitor which contains the title bar, it seems). but on windows, the app continues to work on both monitors. what happens then? ------------- PR: https://git.openjdk.org/jfx/pull/853 From kcr at openjdk.org Fri Aug 5 18:54:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 18:54:14 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:42:34 GMT, Kevin Rushforth wrote: >> When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. >> >> The fix is to adjust the bounds by the screen scale before returning it. >> >> You can test it on a Windows machine with scaling set to >= 125% as follows: >> 1. Turn on Windows Narrator >> 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` >> 3. TAB between the controls >> >> Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. >> >> Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix conversion to platform coords Much of my testing was done with a window straddling two screens. It works as expected in all cases I checked. If a single control spans both screens, the part that is on each screen is correctly highlighted by the Windows Narrator visible focus. Note that in this mode, the window is considered to be "on" one of the screens, and all scales are relative to that screen (not just for accessibility, this is how HiDPI works on Windows if you are multi-monitor HiDPI aware). ------------- PR: https://git.openjdk.org/jfx/pull/853 From kcr at openjdk.org Fri Aug 5 18:57:23 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 Aug 2022 18:57:23 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:25:50 GMT, Andy Goryachev wrote: > i was thinking of merely creating these two dirs in a new task 'initDirs' and make 'sdk' depend on that task, in the top level build.gradle. Any objections I suppose that would be OK. I presume you'll check that the presence of the empty dirs on Mac doesn't cause any problems? ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Sat Aug 6 02:32:20 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 6 Aug 2022 02:32:20 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 19:30:28 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/.classpath line 5: >> >>> 3: >>> 4: >>> 5: >> >> How do you not get errors on these on Mac/Linux if they are not declared optional? >> >> Additionally, you need the hlsl folders as shown in the mailing list. > > As with any multi-stage project, we need to run 'gradle sdk' (or perhaps 'gradle sdk apps' for good measure) to build these directories. Then, in Eclipse, clean all projects. These steps produce a working configuration. > > I do not see hlsl folders being build on Mac. Are these being built on windows/linux? > If these are platform-specific, then we should add them to the gradle build. Maybe an additional target that creates the empty directories, and upon which sdk depends on. As @kleopatra noted below, you need to add the hlsl folders that are built on Windows. Add them as an optional source to avoid errors on other OS's: And the same for `````` `````` `````` This will allow to run dependent projects on Windows and won't cause build issues on other OS's as Eclipse ignores errors on these. There is no need to create empty folders. I tested both on Windows and Linux. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Sat Aug 6 02:37:18 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 6 Aug 2022 02:37:18 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 19:34:11 GMT, Andy Goryachev wrote: >> buildSrc/.classpath line 10: >> >>> 8: >>> 9: >>> 10: >> >> Why does buildSrc need to be a project? It contains no relevant sources. > > It probably does not, the file was added in 2013 as a part of > RT-31216: Ensure NetBeans development in Gradle build works [Eclipse files] > > Turns out, eclipse can work with nested projects. Shows multiple hits when looking for resources, but it does. > > I've added a separate project for ColorCube app as an example, but since this PR is about making all directories to build on Eclipse, I'd rather not fix all the apps in this PR. (I would keep ColorCube as a reference though). Then best to remove the `buildSrc` project files. I will look at the apps later. I think it's best to create a project per app while we are touching this point. I don't see a reason not to. ------------- PR: https://git.openjdk.org/jfx/pull/858 From fastegal at openjdk.org Sat Aug 6 09:17:16 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Sat, 6 Aug 2022 09:17:16 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Fri, 5 Aug 2022 14:07:29 GMT, Kevin Rushforth wrote: > > The specification section of the CSR should (and does) list only the spec change to `SelectionModel.isSelected`. Since there could be an impact to applications that rely on the current behavior, it also seems reasonable to list those in the Solution section (as well as the Compatibility concerns section). I think that the Summary should start by listing the spec change to `SelectionModel.isSelected`, but it seems useful to also say that the implementation of `TableXXSelectionModel` is changing as a result. makes sense - thanks for the explanation :) ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at swingempire.de Sat Aug 6 12:56:24 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 06 Aug 2022 14:56:24 +0200 Subject: JBS: broken commit references for old (fx8) fixes Message-ID: <20220806145624.Horde.3INGlNCEhYv3gO9AoH8axqL@webmail.df.eu> an example is https://bugs.openjdk.org/browse/JDK-8123472 (was: RT-33442) - it's fixed Oct. 2013 (after the history of the current repository starts, which is Nov. 2011), the commit ref is http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6d1c6c47a5dd which opens an error page: "An error occurred while processing your request: revision not found: rt" Bug or feature? Thought the old references are redirected to the current rep? If not, any way to fix them automatically? Or if intended for older commit refs: what's the cut-off date/version? Not blocking, but a nuisance: need to find the commit manually in the local rep. -- Jeanette From kevin.rushforth at oracle.com Sat Aug 6 13:08:45 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 6 Aug 2022 06:08:45 -0700 Subject: JBS: broken commit references for old (fx8) fixes In-Reply-To: <20220806145624.Horde.3INGlNCEhYv3gO9AoH8axqL@webmail.df.eu> References: <20220806145624.Horde.3INGlNCEhYv3gO9AoH8axqL@webmail.df.eu> Message-ID: <3853ac96-67e8-353e-1658-05fd832c1dbb@oracle.com> There is no automatic redirect, but you can replace 8/graphics/rt with 8u-dev/rt using the same hash: https://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6d1c6c47a5dd -- Kevin On 8/6/2022 5:56 AM, Jeanette Winzenburg wrote: > > an example is https://bugs.openjdk.org/browse/JDK-8123472 (was: > RT-33442) - it's fixed Oct. 2013 (after the history of the current > repository starts, which is Nov. 2011), the commit ref is > > ?http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6d1c6c47a5dd > > > which opens an error page: "An error occurred while processing your > request: revision not found: rt" > > Bug or feature? Thought the old references are redirected to the > current rep? If not, any way to fix them automatically? Or if intended > for older commit refs: what's the cut-off date/version? > > Not blocking, but a nuisance: need to find the commit manually in the > local rep. > > -- Jeanette > > > > > > > From kcr at openjdk.org Sat Aug 6 13:27:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Aug 2022 13:27:13 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 02:28:27 GMT, Nir Lisker wrote: >> As with any multi-stage project, we need to run 'gradle sdk' (or perhaps 'gradle sdk apps' for good measure) to build these directories. Then, in Eclipse, clean all projects. These steps produce a working configuration. >> >> I do not see hlsl folders being build on Mac. Are these being built on windows/linux? >> If these are platform-specific, then we should add them to the gradle build. Maybe an additional target that creates the empty directories, and upon which sdk depends on. > > As @kleopatra noted below, you need to add the hlsl folders that are built on Windows. Add them as an optional source to avoid errors on other OS's: > > > > > > > > And the same for > `````` > `````` > `````` > > This will allow to run dependent projects on Windows and won't cause build issues on other OS's as Eclipse ignores errors on these. There is no need to create empty folders. I tested both on Windows and Linux. I agree that an optional dependency for a platform-specific generated source directory is a much better solution than creating an empty dir. ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Sat Aug 6 13:27:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 Aug 2022 13:27:14 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:55:15 GMT, Kevin Rushforth wrote: >> thank you for checking! >> >> it looks like there is no way around creating these directories before the 'sdk' task in build.gradle, to silence the missing path warning in eclipse (and adding them back to the .classpath) >> >> i was thinking of merely creating these two dirs in a new task 'initDirs' and make 'sdk' depend on that task, in the top level build.gradle. Any objections, @kevinrushforth ? > >> i was thinking of merely creating these two dirs in a new task 'initDirs' and make 'sdk' depend on that task, in the top level build.gradle. Any objections > > I suppose that would be OK. I presume you'll check that the presence of the empty dirs on Mac doesn't cause any problems? As mentioned in an earlier comment, the better way to address this is with an optional dependency on the generated sources. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Sat Aug 6 13:37:13 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 6 Aug 2022 13:37:13 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: <7gMEcVgvp3IKobF6-U3p1eF53bjkkLh98ulPDv_7qII=.bb1d5fae-7703-4a76-905f-fac050db08cd@github.com> On Sat, 6 Aug 2022 13:22:17 GMT, Kevin Rushforth wrote: >> As @kleopatra noted below, you need to add the hlsl folders that are built on Windows. Add them as an optional source to avoid errors on other OS's: >> >> >> >> >> >> >> >> And the same for >> `````` >> `````` >> `````` >> >> This will allow to run dependent projects on Windows and won't cause build issues on other OS's as Eclipse ignores errors on these. There is no need to create empty folders. I tested both on Windows and Linux. > > I agree that an optional dependency for a platform-specific generated source directory is a much better solution than creating an empty dir. I don't know what the platform-specific ones are for Mac. I can check on Linux if there's a problem running dependent projects with/without the sources and I think that it will cover Mac too. ------------- PR: https://git.openjdk.org/jfx/pull/858 From fastegal at swingempire.de Sat Aug 6 13:55:12 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Sat, 06 Aug 2022 15:55:12 +0200 Subject: JBS: broken commit references for old (fx8) fixes In-Reply-To: <3853ac96-67e8-353e-1658-05fd832c1dbb@oracle.com> References: <20220806145624.Horde.3INGlNCEhYv3gO9AoH8axqL@webmail.df.eu> <3853ac96-67e8-353e-1658-05fd832c1dbb@oracle.com> Message-ID: <20220806155512.Horde.j2J5t7bn1ghVdW2BqEEArl3@webmail.df.eu> that's working, thanks Kevin :) Zitat von Kevin Rushforth : > There is no automatic redirect, but you can replace 8/graphics/rt > with 8u-dev/rt using the same hash: > > https://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6d1c6c47a5dd > > -- Kevin > > > On 8/6/2022 5:56 AM, Jeanette Winzenburg wrote: >> >> an example is https://bugs.openjdk.org/browse/JDK-8123472 (was: >> RT-33442) - it's fixed Oct. 2013 (after the history of the current >> repository starts, which is Nov. 2011), the commit ref is >> >> ?http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6d1c6c47a5dd >> >> >> which opens an error page: "An error occurred while processing your >> request: revision not found: rt" >> >> Bug or feature? Thought the old references are redirected to the >> current rep? If not, any way to fix them automatically? Or if >> intended for older commit refs: what's the cut-off date/version? >> >> Not blocking, but a nuisance: need to find the commit manually in >> the local rep. >> >> -- Jeanette >> >> >> >> >> >> >> From fastegal at openjdk.org Sat Aug 6 14:30:18 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Sat, 6 Aug 2022 14:30:18 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v4] In-Reply-To: <7uD0H0mRZa5uAz-KXqxn-UwjfC3WR4pAKqa0MfNBpqQ=.f571d017-f3ef-43cd-ba06-44b1dc4ce61f@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <7uD0H0mRZa5uAz-KXqxn-UwjfC3WR4pAKqa0MfNBpqQ=.f571d017-f3ef-43cd-ba06-44b1dc4ce61f@github.com> Message-ID: On Thu, 28 Jul 2022 16:37:33 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 2829: >> >>> 2827: return selectedCellsMap.isSelected(index, -1); >>> 2828: } >>> 2829: } >> >> wondering why you distinguish between not/ cellSelection? This method is all about row selection (that is the dimension available in base/multiple selection) - shouldn't it behave the same way, independent of whether the second - cell - dimension is turned on? If so, we could simply delegate to super - or not override it at all. > > Good question! > The implementation is lifted from its isSelected(int,Tree/TableColumn) sibling with the logic altered for the case of enabled cell selection. > Let me check if the logic can be delegated to superclass. Think that I found a case where this implementation violates the invariant `getSelectedIndices().contains(row) == isSelected(row)` - happens in cell selection mode when we select the last column and then hide that column: sm.select(row, column); assertTrue("sanity: row " + row + "contained in selectedIndices", sm.getSelectedIndices().contains(row)); assertTrue("sanity: row must be selected" , sm.isSelected(row)); column.setVisible(false); assertTrue("after hiding column: row " + row + "contained in selectedIndices", sm.getSelectedIndices().contains(row)); assertTrue("after hiding column: row must be selected" , sm.isSelected(row)); the last line fails for cell selection enabled with this implementation and passes when delegating to super (or not override `isSelected(int)` at all) Aside: there is a general issue with cell selection not updated on columns modification (the selection visual is kept on the same column index without changing selectedCells accordingly - technically due to looping across the visibleLeafCells vs. all leaf columns. Might or might not be what ux requires, but the selectedCells must be in sync with the visuals always). Don't remember if we have it covered in JBS? The complete test set: @Test public void testRowSelectionAfterSelectAndHideLastColumnMultipleCellEnabled() { assertRowSelectionAfterSelectAndHideLastColumn(SelectionMode.MULTIPLE, true); } @Test public void testRowSelectionAfterSelectAndHideLastColumnMultipleNotCellEnabled() { assertRowSelectionAfterSelectAndHideLastColumn(SelectionMode.MULTIPLE, false); } @Test public void testRowSelectionAfterSelectAndHideLastColumnSingleCellEnabled() { assertRowSelectionAfterSelectAndHideLastColumn(SelectionMode.SINGLE, true); } @Test public void testRowSelectionAfterSelectAndHideLastColumnSingleNotCellEnabled() { assertRowSelectionAfterSelectAndHideLastColumn(SelectionMode.SINGLE, false); } public void assertRowSelectionAfterSelectAndHideLastColumn(SelectionMode mode, boolean cellEnabled) { TableView table = createPersonTableView(); TableView.TableViewSelectionModel sm = table.getSelectionModel(); sm.setCellSelectionEnabled(cellEnabled); sm.setSelectionMode(mode); int row = 1; int col = table.getColumns().size() - 1; assertRowSelectionAfterSelectAndHideColumn(table, row, col); } private void assertRowSelectionAfterSelectAndHideColumn(TableView table, int row, int col) { TableViewSelectionModel sm = table.getSelectionModel(); TableColumn column = table.getColumns().get(col); TablePosition pos = new TablePosition<>(table, row, column); sm.select(row, column); assertTrue("sanity: row " + row + "contained in selectedIndices", sm.getSelectedIndices().contains(row)); assertTrue("sanity: row must be selected" , sm.isSelected(row)); column.setVisible(false); assertTrue("after hiding column: row " + row + "contained in selectedIndices", sm.getSelectedIndices().contains(row)); assertTrue("after hiding column: row must be selected" , sm.isSelected(row)); } /** * Creates and returns a TableView with Persons and columns for all their properties. */ private TableView createPersonTableView() { final ObservableList data = FXCollections.observableArrayList( new Person("Jacob", "Smith", "jacob.smith at example.com"), new Person("Isabella", "Johnson", "isabella.johnson at example.com"), new Person("Ethan", "Williams", "ethan.williams at example.com"), new Person("Emma", "Jones", "emma.jones at example.com"), new Person("Michael", "Brown", "michael.brown at example.com")); TableView table = new TableView<>(); table.setItems(data); TableColumn firstNameCol = new TableColumn("First Name"); firstNameCol.setCellValueFactory(new PropertyValueFactory("firstName")); TableColumn lastNameCol = new TableColumn("Last Name"); lastNameCol.setCellValueFactory(new PropertyValueFactory("lastName")); TableColumn emailCol = new TableColumn("Email"); emailCol.setCellValueFactory(new PropertyValueFactory("email")); table.getColumns().addAll(firstNameCol, lastNameCol, emailCol); return table; } arrgg .. this site is killing me again - no idea why this comment is duplicated .. sry ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Sat Aug 6 14:30:26 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Sat, 6 Aug 2022 14:30:26 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Wed, 3 Aug 2022 23:28:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - 8235491: whitespace > - 8235491: additional tests > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: javadoc > - 8235491: tree table view > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: review comments > - 8235491: whitespace > - 8235491: javadoc > - 8235491: 2022 > - ... and 1 more: https://git.openjdk.org/jfx/compare/da54d9a2...ad3c70b9 modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewMouseInputTest.java line 558: > 556: sm.setSelectionMode(SelectionMode.MULTIPLE); > 557: sm.clearSelection(); > 558: wondering: why did you add the clearSelection? ------------- PR: https://git.openjdk.org/jfx/pull/839 From duke at openjdk.org Sun Aug 7 03:06:07 2022 From: duke at openjdk.org (mohsem almri) Date: Sun, 7 Aug 2022 03:06:07 GMT Subject: RFR: 8262023: Scrolled button is pressed using Monocle on Raspberry Pi with Touchscreen In-Reply-To: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> References: <4YyAvpO4RJ1mBJUgtyMVTJhvFXqkcC1IcamCWI8XGis=.ecdad078-22b0-4b9f-aef5-29ed7108f806@github.com> Message-ID: On Fri, 19 Feb 2021 14:19:35 GMT, Alexander Scherbatiy wrote: > The issue is reproduced on Raspberry Pi 3 B+ with Touchscreen display. > > To reproduce the issue run the [ScrollPaneSample](https://bugs.openjdk.java.net/secure/attachment/93270/ScrollPaneSample.java) with Monocle: >> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=monocle -Dembedded=monocle -Dglass.platform=Monocle ScrollPaneSample > > > An application consists of a ScrollPane with buttons. if a button is touched by a finger, moved up/down and released, the button is scrolled and the button's action is fired. > > This happens because Monocle generates mouse pressed, mouse dragged, scroll, mouse released events when touch events are received. > Even a button is scrolled on a ScrollPane it still fires the button's action on the synthesized mouse release event. > > My first attempt was to add a scroll event listener to a ButtonBehavior class and disarm the button when the scroll event is received. > This does work not in the case where buttons are small and scrolling buttons leads that a finger is released on the next button (the scrolling process is remained a slightly behind the touched finger so the finger is touched on one button and released on another). > In this case all scroll events goes to the first button and the second button still fires its action (it does not disarmed because it does not receive scroll events). > > The current fix adds drag event listener to ButtonBehavior to disarm the button. Drag events goes to the touched and released buttons. > > Than I checked the fix on the same Raspberry Pi using GTK with touchscreen. >> sudo jdk/bin/java -Dprism.verbose=true -Djavafx.platform=gtk ScrollPaneSample > > I have not seen scroll events using GTK (even using -Dgtk.com.sun.javafx.gestures.scroll=true option), but GTK sends mouse drag events on a button touch. > The mouse drag event between a button touch and release events would disarm the button in the proposed ButtonBehavior drag event handler. So I added the check if the mouse drag is synthesized. If the mouse drag is synthesized (Monocle case on touchscreen) it disarms the button, otherwise (GTK case) not. > > I checked the fix for the following controls placed on a ScrollPane (see [ScrollPaneControlsSample](https://bugs.openjdk.java.net/secure/attachment/93271/ScrollPaneControlsSample.java) sample) : > - Fixed in corresponding behavior classes or its parents: Button, ToggleButton, CheckBox, ComboBox, ChoiceBox, ColorPicker, DatePicker, RadioButton > - Works because an action is not fired on mouse release event: TextField > - Does not work: Slider > > The Slider control does not work with the fix because it reacts not only on mouse release event but on mouse drag event as well. It requires a separate fix. > > I checked the Ensemble8 sample with the fix. It works with Monocle on Raspberry Pi 3B+ on Touchscreen. Scrolling the main page by a finger does not makes it to be pressed. > > The Ensemble8 sample does not work with GTK on Raspberry Pi 3B+ with Touchscreen. I see it generates scroll events ( it has its own [ScrollEventSynthesizer](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/src/app/java/ensemble/ScrollEventSynthesizer.java)) and action events and it can makes the Ensemble8 buttons on a ScrollPane to be pressed. Marked as reviewed by m7snxx at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jfx/pull/406 From aghaisas at openjdk.org Mon Aug 8 10:43:20 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 8 Aug 2022 10:43:20 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:42:34 GMT, Kevin Rushforth wrote: >> When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. >> >> The fix is to adjust the bounds by the screen scale before returning it. >> >> You can test it on a Windows machine with scaling set to >= 125% as follows: >> 1. Turn on Windows Narrator >> 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` >> 3. TAB between the controls >> >> Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. >> >> Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix conversion to platform coords The fix looks good! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/853 From lbourges at openjdk.org Mon Aug 8 13:17:45 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 8 Aug 2022 13:17:45 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v4] In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <7V81rSM-Gyj9aJtjTbQkYFhQG2n2lEPCbLxUjou5wiA=.42ea2a54-6bde-482a-a278-3491573b51d8@github.com> > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Laurent Bourg?s 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: - Merge remote-tracking branch 'upstream/master' into marlinFX-0.9.4.5 - fixed pixel color tests on hi-dpi - added test for huge polygon coords - fixed jcheck warning (tab) - Merge branch 'openjdk:master' into marlinFX-0.9.4.5 - minor changes (syntax, warnings) + merge with marlin 0.9.4.5 (jdk) - fixed bad IntArrayCache usages + clean white spaces - initial marlinFX 0.9.4.5 for openjfx 18 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/674/files - new: https://git.openjdk.org/jfx/pull/674/files/f7e5eb5e..eb85b946 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=02-03 Stats: 974899 lines in 11220 files changed: 574194 ins; 263423 del; 137282 mod Patch: https://git.openjdk.org/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.org/jfx pull/674/head:pull/674 PR: https://git.openjdk.org/jfx/pull/674 From lbourges at openjdk.org Mon Aug 8 13:41:24 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Mon, 8 Aug 2022 13:41:24 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v5] In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <__CEpoj1PkSTpUyfcf8C3kjGJMiX5x9smyMPrtblB0c=.d55033b3-81c4-4fc2-a825-d6d6bb6cfa95@github.com> > Changelog for this MarlinFX 0.9.4.5 release: > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: upgraded to 0.9.4.6 (no repeated lineTo) + fixed tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/674/files - new: https://git.openjdk.org/jfx/pull/674/files/eb85b946..b348079b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=03-04 Stats: 37 lines in 7 files changed: 9 ins; 11 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.org/jfx pull/674/head:pull/674 PR: https://git.openjdk.org/jfx/pull/674 From angorya at openjdk.org Mon Aug 8 15:21:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 15:21:24 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: <7gMEcVgvp3IKobF6-U3p1eF53bjkkLh98ulPDv_7qII=.bb1d5fae-7703-4a76-905f-fac050db08cd@github.com> References: <7gMEcVgvp3IKobF6-U3p1eF53bjkkLh98ulPDv_7qII=.bb1d5fae-7703-4a76-905f-fac050db08cd@github.com> Message-ID: On Sat, 6 Aug 2022 13:33:09 GMT, Nir Lisker wrote: >> I agree that an optional dependency for a platform-specific generated source directory is a much better solution than creating an empty dir. > > I don't know what the platform-specific ones are for Mac. I can check on Linux if there's a problem running dependent projects with/without the sources and I think that it will cover Mac too. @nlisker : adding sources with *does not* remove the warning. also, this warning cannot be turned off. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 15:25:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 15:25:25 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 13:22:17 GMT, Kevin Rushforth wrote: >> As @kleopatra noted below, you need to add the hlsl folders that are built on Windows. Add them as an optional source to avoid errors on other OS's: >> >> >> >> >> >> >> >> And the same for >> `````` >> `````` >> `````` >> >> This will allow to run dependent projects on Windows and won't cause build issues on other OS's as Eclipse ignores errors on these. There is no need to create empty folders. I tested both on Windows and Linux. > > I agree that an optional dependency for a platform-specific generated source directory is a much better solution than creating an empty dir. @kevinrushforth : Eclipse does not support conditionals in the .classpath files. The warning cannot be turned off. I see no other way but to create empty folders. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Mon Aug 8 15:35:28 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 8 Aug 2022 15:35:28 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:21:58 GMT, Andy Goryachev wrote: >> I agree that an optional dependency for a platform-specific generated source directory is a much better solution than creating an empty dir. > > @kevinrushforth : > Eclipse does not support conditionals in the .classpath files. The warning cannot be turned off. I see no other way but to create empty folders. On Linux there is no such warning., neither is there on Windows if I add a non-existing folder (to simulate the ones for other OS's). I posted the screenshots on the mailing list. If Eclipse for Mac is the only one producing these warnings, a bug should be filed with Eclipse JDT. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 15:42:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 15:42:26 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v2] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:31:49 GMT, Nir Lisker wrote: >> @kevinrushforth : >> Eclipse does not support conditionals in the .classpath files. The warning cannot be turned off. I see no other way but to create empty folders. > > On Linux there is no such warning., neither is there on Windows if I add a non-existing folder (to simulate the ones for other OS's). I posted the screenshots on the mailing list. If Eclipse for Mac is the only one producing these warnings, a bug should be filed with Eclipse JDT. I respectfully disagree. I see no harm in creating empty directories in this case if it solves the problem. We can log a bug against eclipse, and it will be fixed in several years, if ever. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 16:41:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 16:41:38 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v3] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: added initDirs task ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/fef3fadf..b7ed2c84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=01-02 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 16:45:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 16:45:11 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v4] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/b7ed2c84..ab04c3b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 17:22:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 17:22:10 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v5] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: removed eclipse project in buildSrc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/ab04c3b0..3238b5f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=03-04 Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 17:22:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 17:22:12 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v5] In-Reply-To: References: Message-ID: <78RXofAL3LCN245W60fpoNqaMOoAKtOEgrGCSGPbQ5A=.aeea4b66-6562-4dc2-bf1b-99113cc36066@github.com> On Sat, 6 Aug 2022 02:35:10 GMT, Nir Lisker wrote: >> It probably does not, the file was added in 2013 as a part of >> RT-31216: Ensure NetBeans development in Gradle build works [Eclipse files] >> >> Turns out, eclipse can work with nested projects. Shows multiple hits when looking for resources, but it does. >> >> I've added a separate project for ColorCube app as an example, but since this PR is about making all directories to build on Eclipse, I'd rather not fix all the apps in this PR. (I would keep ColorCube as a reference though). > > Then best to remove the `buildSrc` project files. > > I will look at the apps later. I think it's best to create a project per app while we are touching this point. I don't see a reason not to. I agree with Nir - eclipse project in buildSrc is unnecessary. Removing. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 17:29:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 17:29:12 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v5] In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 13:23:05 GMT, Kevin Rushforth wrote: >>> i was thinking of merely creating these two dirs in a new task 'initDirs' and make 'sdk' depend on that task, in the top level build.gradle. Any objections >> >> I suppose that would be OK. I presume you'll check that the presence of the empty dirs on Mac doesn't cause any problems? > > As mentioned in an earlier comment, the better way to address this is with an optional dependency on the generated sources. @kevinrushforth : these empty directories created do not seem to pose a problem on Mac, all the tests are passing (incl. web ones). ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 20:13:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:13:01 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v6] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Sat, 6 Aug 2022 14:24:59 GMT, Jeanette Winzenburg 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 11 additional commits since the last revision: >> >> - 8235491: whitespace >> - 8235491: additional tests >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: javadoc >> - 8235491: tree table view >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: review comments >> - 8235491: whitespace >> - 8235491: javadoc >> - 8235491: 2022 >> - ... and 1 more: https://git.openjdk.org/jfx/compare/40ef8a73...ad3c70b9 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewMouseInputTest.java line 558: > >> 556: sm.setSelectionMode(SelectionMode.MULTIPLE); >> 557: sm.clearSelection(); >> 558: > > wondering: why did you add the clearSelection? it was an attempt to ensure a clear initial state, but you are right - it is unnecessary. ------------- PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Mon Aug 8 20:15:00 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:15:00 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8235491: revert clear selection ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/ad3c70b9..7fa25883 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Mon Aug 8 20:30:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:30:01 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ 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: - 8290473: junit 5 - Merge remote-tracking branch 'origin/master' into 8290473.apps - 8290473: removed eclipse project in buildSrc - 8290473: whitespace - 8290473: added initDirs task - Merge remote-tracking branch 'origin/master' into 8290473.apps - 8290473: added ColorCube project - 8290473: eclipse config for apps ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/3238b5f0..b63f4d19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=04-05 Stats: 440 lines in 4 files changed: 417 ins; 10 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Mon Aug 8 20:37:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:37:49 GMT Subject: RFR: 8290844: Add Skin.install() method Message-ID: - added Skin.install() - javadoc changes for Skinnable.setSkin(Skin) no code changes for Skinnable.setSkin(Skin) yet. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8289397: added space - 8290844: skin.install - 8290844: whitespace - 8290844: validate input - 8290844: illegal argument exception - 8290844: illegal argument exception - 8290844: whitespace - 8290844:

- 8290844: add Skin.install() Changes: https://git.openjdk.org/jfx/pull/845/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290844 Stats: 53 lines in 4 files changed: 48 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From mstrauss at openjdk.org Mon Aug 8 20:37:50 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 8 Aug 2022 20:37:50 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 19:22:48 GMT, Andy Goryachev wrote: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. 1. In a property setter, you cannot do anything other than call `property.set(...)`, since `setFoo(...)` and `fooProperty().set(...)` must be equivalent. 2. As you discovered, `ComboBoxPopupControl` implements a skin that violates the `getSkinnable()` specification. But that seems to be completely unnecessary. When I change the implementation to conform to the specification, everything works just as well: all tests pass, and I can run a large application (SceneBuilder) without problems. Here's the code in `ComboBoxPopupControl` that I've tested: private void createPopup() { class PopupControlImpl extends PopupControl { @Override public Styleable getStyleableParent() { return ComboBoxPopupControl.this.getSkinnable(); } PopupControlImpl() { setSkin(new Skin<>() { @Override public Skinnable getSkinnable() { return PopupControlImpl.this; } @Override public Node getNode() { return getPopupContent(); } @Override public void dispose() { } }); } } popup = new PopupControlImpl(); .... } modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 269: > 267: if(skin != null) { > 268: skin.install(); > 269: } You should probably also add the check for PopupControl. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 8 20:37:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:37:50 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: <9cHQiTtVZJXpdk0aoQfOLhdEO4ON0iBGYri14NPRjDg=.8a2f4b68-48b8-49b0-a2a2-b5676a41a60c@github.com> On Fri, 22 Jul 2022 19:22:48 GMT, Andy Goryachev wrote: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. All good points, many thanks! Fixed the setSkin(), changed the javadoc for setSkin() to indicate that this method *might* throw an IAE. modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 205: > 203: if(value != null) { > 204: if(value.getSkinnable() != this) { > 205: throw new IllegalArgumentException("There must be 1:1 relationship between Skin and Skinnable"); this check always fails in case of PopupControl. ------------- PR: https://git.openjdk.org/jfx/pull/845 From jhendrikx at openjdk.org Mon Aug 8 20:37:50 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 8 Aug 2022 20:37:50 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 19:22:48 GMT, Andy Goryachev wrote: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 244: > 242: // check whether the skin is for right control > 243: if (skin != null) { > 244: if(skin.getSkinnable() != Control.this) { minor: Perhaps write this as one `if` (saves an indent level) or at least make the space after `if` consistent between the two. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 8 20:37:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:37:50 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 06:57:16 GMT, John Hendrikx wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 244: > >> 242: // check whether the skin is for right control >> 243: if (skin != null) { >> 244: if(skin.getSkinnable() != Control.this) { > > minor: Perhaps write this as one `if` (saves an indent level) or at least make the space after `if` consistent between the two. added space. with your permission, I'd rather have one statement per line - it's easier to step through in a debugger. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 8 20:37:51 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:37:51 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: Message-ID: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> On Wed, 27 Jul 2022 19:06:30 GMT, Michael Strau? wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 269: > >> 267: if(skin != null) { >> 268: skin.install(); >> 269: } > > You should probably also add the check for PopupControl. sorry, what check? if you mean if (skin != null) { if(skin.getSkinnable() != Control.this) { we can't because PopupControl violates the 1:1 rule. ------------- PR: https://git.openjdk.org/jfx/pull/845 From mstrauss at openjdk.org Mon Aug 8 20:37:51 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 8 Aug 2022 20:37:51 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> References: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> Message-ID: On Wed, 27 Jul 2022 19:28:28 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 269: >> >>> 267: if(skin != null) { >>> 268: skin.install(); >>> 269: } >> >> You should probably also add the check for PopupControl. > > sorry, what check? > > if you mean > if (skin != null) { > if(skin.getSkinnable() != Control.this) { > > we can't because PopupControl violates the 1:1 rule. Yes, but that can be fixed so the rule is not violated. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 8 20:37:51 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 20:37:51 GMT Subject: RFR: 8290844: Add Skin.install() method In-Reply-To: References: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> Message-ID: <3D2MXlqCsqqkyU57pNeVz9aqlwwwSW3MLmTHjNf408M=.e0e117a3-37f2-4443-849d-a20dd10ffb06@github.com> On Wed, 27 Jul 2022 20:02:37 GMT, Michael Strau? wrote: >> sorry, what check? >> >> if you mean >> if (skin != null) { >> if(skin.getSkinnable() != Control.this) { >> >> we can't because PopupControl violates the 1:1 rule. > > Yes, but that can be fixed so the rule is not violated. I like this idea. However, I am afraid that the impact of the check in PopupControl might be greater than expected. In addition to your ComboBoxPopupcontrol.createPopup() fix you provided earlier, there is a similar situation with TooltipSkin in PopupcontrolTest:604: Tooltip tooltip = new Tooltip("Hello"); TooltipSkin skin = new TooltipSkin(tooltip); popup.setSkin(skin); it is not entirely clear to me why a TooltipSkin is installed as a skin for the popup instead of the tooltip. I think we should rather say that this 1:1 rule does not apply to PopupControls. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 8 21:54:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 21:54:35 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Mon, 8 Aug 2022 20:15:00 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: revert clear selection > the last line fails for cell selection enabled with this implementation and passes when delegating to super (or not override isSelected(int) at all) I think you are right, @kleopatra ! Took me a while, but I see your point now. This method should indeed delegate to super(), or not be overridden at all. Thank you for creating the tests - they deserve to be integrated into TableViewSelectionModelImplTest, with your permission. ------------- PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Mon Aug 8 21:58:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 21:58:40 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v8] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8235491: delegate to super() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/7fa25883..9de5858b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=06-07 Stats: 86 lines in 2 files changed: 75 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Mon Aug 8 22:10:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Aug 2022 22:10:32 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v8] In-Reply-To: <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> Message-ID: On Mon, 8 Aug 2022 21:58:40 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: delegate to super() > Aside: there is a general issue with cell selection not updated on columns modification (the selection visual is kept on the same column index without changing selectedCells accordingly - technically due to looping across the visibleLeafCells vs. all leaf columns. Might or might not be what ux requires, but the selectedCells must be in sync with the visuals always). Personally, I feel that any manipulations with the columns structure should clear the existing selection. I would imagine it's such a rare operation, and the "fix" is so easy (clear selection) that it's not worth even creating an issue for - but I could be wrong. > Don't remember if we have it covered in JBS? I did not find a close match. There is JDK-8095010; there is ticket you might be familiar with JDK-8093855; and one possibly related JDK-8091191. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Mon Aug 8 22:39:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Aug 2022 22:39:34 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v8] In-Reply-To: <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> Message-ID: On Mon, 8 Aug 2022 21:58:40 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: delegate to super() I would lean towards creating a new issue, unless one of the three you listed above is a natural fit. ------------- PR: https://git.openjdk.org/jfx/pull/839 From nlisker at openjdk.org Tue Aug 9 00:56:32 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 9 Aug 2022 00:56:32 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: References: Message-ID: <9me__KsPGkfS5pxGZuYh5mSDaUhyKBhsHhTZ2F35cqw=.033e167b-6e4f-4564-b452-e61df0338422@github.com> On Mon, 8 Aug 2022 15:38:35 GMT, Andy Goryachev wrote: >> On Linux there is no such warning., neither is there on Windows if I add a non-existing folder (to simulate the ones for other OS's). I posted the screenshots on the mailing list. If Eclipse for Mac is the only one producing these warnings, a bug should be filed with Eclipse JDT. > > I respectfully disagree. > I see no harm in creating empty directories in this case if it solves the problem. > We can log a bug against eclipse, and it will be fixed in several years, if ever. This is up to Kevin. It's changing the build file specifically to remove a warning for Eclipse Mac users. I don't mind. Might need to do the same for the other OS-specific folders. ------------- PR: https://git.openjdk.org/jfx/pull/858 From lbourges at openjdk.org Tue Aug 9 07:39:35 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 9 Aug 2022 07:39:35 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Thu, 4 Aug 2022 23:01:37 GMT, Kevin Rushforth wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed pixel color tests on hi-dpi > > I did a quick skim of the DPQS class, enough to know that code review is unlikely to spot the kind of subtle bugs that such code might have. So my main question is around testing of DQPS itself. How much standalone testing has been done on the sort algorithm? > > I did see that several of the methods are missing `@param` tags in the docs, and while this isn't public API, it would aid understanding it a bit better if those were added. > > I'm still wondering whether it should be enabled by default. On the one hand, it would reduce risk to have it disabled by default. On the other hand, if we enable it now, we are early enough in JavaFX 20 that if problems are found, they can be fixed and/or it can be disabled by default later. @kevinrushforth I merged with master and made requested changes. It is ready for me. Could you have a look ? Thanks ------------- PR: https://git.openjdk.org/jfx/pull/674 From arapte at openjdk.org Tue Aug 9 08:15:26 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 08:15:26 GMT Subject: RFR: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 18:42:34 GMT, Kevin Rushforth wrote: >> When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. >> >> The fix is to adjust the bounds by the screen scale before returning it. >> >> You can test it on a Windows machine with scaling set to >= 125% as follows: >> 1. Turn on Windows Narrator >> 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` >> 3. TAB between the controls >> >> Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. >> >> Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix conversion to platform coords Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/853 From kcr at openjdk.org Tue Aug 9 11:32:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 11:32:33 GMT Subject: Integrated: 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 In-Reply-To: References: Message-ID: <5HUXpWDLJDjJbQY1H_Uhmpio4dEEhOu5fqM_4zZLSA0=.dd72655e-614a-4821-98a5-7ebf2c97010f@github.com> On Thu, 28 Jul 2022 15:01:34 GMT, Kevin Rushforth wrote: > When using the Windows Narrator screen reader on a Hi-DPI screen, the visible focus is drawn in the wrong location and with the wrong size. This happens because the the JavaFX Windows accessibility code that returns the screen bounds of the requested UI element does not take the screen scale into account. > > The fix is to adjust the bounds by the screen scale before returning it. > > You can test it on a Windows machine with scaling set to >= 125% as follows: > 1. Turn on Windows Narrator > 2. Run any JavaFX program with at least UI controls, for example, `hello.HelloTextField` in `apps/toys/Hello` > 3. TAB between the controls > > Without the fix, Narrator shows the focus indicator in the wrong position and is too small. With the fix, it is correct. While testing this, I discovered an unrelated (and preexisting) bug where the focus indicator for a TextField or TextArea whose content is larger that the control (and is displayed with scroll bars) is not clipped to the visible area. This happens regardless of screen scale. I will file a follow-up bug for this. > > Note that this bug is specific to Windows. It does not occur on macOS, which works correctly on a retina or non-retina display. This pull request has now been integrated. Changeset: 38324a70 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/38324a70c3054e75cb22865e7ffcc5375b62939d Stats: 41 lines in 3 files changed: 33 ins; 0 del; 8 mod 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 Reviewed-by: aghaisas, arapte ------------- PR: https://git.openjdk.org/jfx/pull/853 From fastegal at openjdk.org Tue Aug 9 11:54:23 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 9 Aug 2022 11:54:23 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Mon, 8 Aug 2022 21:51:05 GMT, Andy Goryachev wrote: > > I think you are right, @kleopatra ! Took me a while, but I see your point now. This method should indeed delegate to super(), or not be overridden at all. > I would prefer removing it (reducing clutter :) As it's a private class, there will be no publicly visible change. > Thank you for creating the tests - they deserve to be integrated into TableViewSelectionModelImplTest, with your permission. sure, everything here is open source and we don't want to duplicate efforts :) Probably need to do the same fix and test in TreeTableView selection? ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Tue Aug 9 11:59:34 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 9 Aug 2022 11:59:34 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v8] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> Message-ID: On Mon, 8 Aug 2022 22:07:17 GMT, Andy Goryachev wrote: > > Personally, I feel that any manipulations with the columns structure should clear the existing selection. I would imagine it's such a rare operation, and the "fix" is so easy (clear selection) that it's not worth even creating an issue for - but I could be wrong. > haha .. are you prepared to get lynched by furious users ? Just imagine you selected several cells across the table, then decide to hide an unrelated column (which is not as rare as you assume :) and all your previous selection work is destroyed. > > Don't remember if we have it covered in JBS? > > I did not find a close match. There is JDK-8095010; there is ticket you might be familiar with JDK-8093855; and one possibly related JDK-8091191. none of those seem to be related to modification of columns, so tend to agree with Kevin that we should file a new issue ------------- PR: https://git.openjdk.org/jfx/pull/839 From arapte at openjdk.org Tue Aug 9 12:15:55 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 12:15:55 GMT Subject: [jfx17u] RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Message-ID: Clean backport to jfx17u ------------- Commit messages: - 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Changes: https://git.openjdk.org/jfx17u/pull/72/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=72&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283786 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx17u/pull/72.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/72/head:pull/72 PR: https://git.openjdk.org/jfx17u/pull/72 From arapte at openjdk.org Tue Aug 9 12:21:31 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 12:21:31 GMT Subject: [jfx17u] RFR: 8088420: JavaFX WebView memory leak via EventListener Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8088420: JavaFX WebView memory leak via EventListener Changes: https://git.openjdk.org/jfx17u/pull/73/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=73&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8088420 Stats: 1509 lines in 11 files changed: 1503 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jfx17u/pull/73.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/73/head:pull/73 PR: https://git.openjdk.org/jfx17u/pull/73 From arapte at openjdk.org Tue Aug 9 12:23:10 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 12:23:10 GMT Subject: [jfx17u] RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Message-ID: <5auywnOXwIAzkOrHbogpXk_IvMvQ3fZN3yRP64ywLYk=.5acc3078-2182-489c-ac01-7d13509a5b37@github.com> Clean backport to `jfx17u`. ------------- Commit messages: - 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Changes: https://git.openjdk.org/jfx17u/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=74&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289587 Stats: 180 lines in 3 files changed: 174 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/74.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/74/head:pull/74 PR: https://git.openjdk.org/jfx17u/pull/74 From arapte at openjdk.org Tue Aug 9 12:26:44 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 12:26:44 GMT Subject: [jfx17u] RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Message-ID: <1wocgmuTk3cjiHZZoqwVtBA0F7elGmCqvskcpDQrY1I=.333438e2-c3db-49fe-b7bc-13a453ea14b0@github.com> Clean backport to `jfx17u`. ------------- Commit messages: - 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Changes: https://git.openjdk.org/jfx17u/pull/75/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=75&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289952 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/75.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/75/head:pull/75 PR: https://git.openjdk.org/jfx17u/pull/75 From arapte at openjdk.org Tue Aug 9 12:27:22 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Aug 2022 12:27:22 GMT Subject: [jfx17u] RFR: 8284676: TreeTableView loses sort ordering when applied on empty table Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8284676: TreeTableView loses sort ordering when applied on empty table Changes: https://git.openjdk.org/jfx17u/pull/76/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=76&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284676 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/76.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/76/head:pull/76 PR: https://git.openjdk.org/jfx17u/pull/76 From kcr at openjdk.org Tue Aug 9 15:06:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 15:06:42 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v5] In-Reply-To: <__CEpoj1PkSTpUyfcf8C3kjGJMiX5x9smyMPrtblB0c=.d55033b3-81c4-4fc2-a825-d6d6bb6cfa95@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <__CEpoj1PkSTpUyfcf8C3kjGJMiX5x9smyMPrtblB0c=.d55033b3-81c4-4fc2-a825-d6d6bb6cfa95@github.com> Message-ID: <167foVI8gNxJZn4daa8Nl10mg5W6gg2SZ8Q698O-mHo=.bc600b00-3d50-4e90-a02a-7985457ba6e0@github.com> On Mon, 8 Aug 2022 13:41:24 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > upgraded to 0.9.4.6 (no repeated lineTo) + fixed tests The updates looks good with three comments left inline, summarized here: 1. The title (both in JBS and in this PR) should be change to reflect `0.9.4.6` as the version 2. There are several missing `@param` tags in DPQS that would be helpful to add 3. You can remove the try/catch entirely from the `setupOnce` methods of the tests modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 116: > 114: * @param high the index of the last element, exclusive, to be sorted > 115: */ > 116: static void sort(DPQSSorterContext sorter, int[] a, int[] auxA, int[] b, int[] auxB, int low, int high) { Here is one example of missing `@param` tags, in this case `sorter`, `auxA`, and `auxB`, but most methods are missing tags for some of their arguments. modules/javafx.graphics/src/main/java/com/sun/marlin/Version.java line 30: > 28: public final class Version { > 29: > 30: private static final String VERSION = "marlinFX-0.9.4.6-Unsafe-OpenJFX"; Can you change the title of the JBS bug and this PR to reflect the `.6` version bump? tests/system/src/test/java/test/com/sun/marlin/ClipShapeTest.java line 984: > 982: assertTrue("Timeout waiting for Application to launch", > 983: launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); > 984: } catch (InterruptedException ex) { You can also remove the try / catch entirely if you change the method signature to: public static void setupOnce() throws Exception (applies to other tests that were updated, too) ------------- PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Tue Aug 9 15:06:45 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 15:06:45 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v3] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <4pXmc2rSivyBW4dSaG0s6Y7gIyP_A50QLedTeo9l4PQ=.1f62a4b4-1e3a-44b8-ab7d-b089cf83feae@github.com> Message-ID: On Wed, 3 Aug 2022 23:41:54 GMT, Kevin Rushforth wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed pixel color tests on hi-dpi > > modules/javafx.graphics/src/main/java/com/sun/marlin/MarlinProperties.java line 206: > >> 204: >> 205: public static boolean isUseDPQS() { >> 206: return getBoolean("prism.marlin.useDPQS", "true"); > > In order to reduce risk, it might make sense to disable DPQS by default initially. It would then be available to anyone who wants to try it out with more complex paths, but would be less prone to possible regressions. What do you think? I withdraw this suggestion. ------------- PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Tue Aug 9 15:15:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 15:15:24 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: <9me__KsPGkfS5pxGZuYh5mSDaUhyKBhsHhTZ2F35cqw=.033e167b-6e4f-4564-b452-e61df0338422@github.com> References: <9me__KsPGkfS5pxGZuYh5mSDaUhyKBhsHhTZ2F35cqw=.033e167b-6e4f-4564-b452-e61df0338422@github.com> Message-ID: On Tue, 9 Aug 2022 00:52:36 GMT, Nir Lisker wrote: >> I respectfully disagree. >> I see no harm in creating empty directories in this case if it solves the problem. >> We can log a bug against eclipse, and it will be fixed in several years, if ever. > > This is up to Kevin. It's changing the build file specifically to remove a warning for Eclipse Mac users. I don't mind. Might need to do the same for the other OS-specific folders. While not ideal, I suppose it's OK. I'm still amazed that Eclipse doesn't have the notion of optional source paths. How do people deal with this when debugging the JDK? Many modules (`java.base` and `java.desktop`, just to name two) have entire directories of platform-specific sources. I will review the changes to `build.gradle`. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Tue Aug 9 15:28:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 9 Aug 2022 15:28:24 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: References: <9me__KsPGkfS5pxGZuYh5mSDaUhyKBhsHhTZ2F35cqw=.033e167b-6e4f-4564-b452-e61df0338422@github.com> Message-ID: On Tue, 9 Aug 2022 15:11:49 GMT, Kevin Rushforth wrote: >> This is up to Kevin. It's changing the build file specifically to remove a warning for Eclipse Mac users. I don't mind. Might need to do the same for the other OS-specific folders. > > While not ideal, I suppose it's OK. I'm still amazed that Eclipse doesn't have the notion of optional source paths. How do people deal with this when debugging the JDK? Many modules (`java.base` and `java.desktop`, just to name two) have entire directories of platform-specific sources. > > I will review the changes to `build.gradle`. It does have optional source paths, this is what I showed above: I never had any issue with optional sources. According to Andy, it's only on Mac that Eclipse generates a warning (though not an error?), on Win and Linux there is no issue. ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Tue Aug 9 16:08:36 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 16:08:36 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: References: Message-ID: <9cy4lvL0FjUZuwF3IzJvMkrP8ZrTa2MM666mQSbA5wQ=.cc210992-090b-4a16-93b4-04943799eda7@github.com> On Mon, 8 Aug 2022 20:30:01 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > 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: > > - 8290473: junit 5 > - Merge remote-tracking branch 'origin/master' into 8290473.apps > - 8290473: removed eclipse project in buildSrc > - 8290473: whitespace > - 8290473: added initDirs task > - Merge remote-tracking branch 'origin/master' into 8290473.apps > - 8290473: added ColorCube project > - 8290473: eclipse config for apps Regarding the `build.gradle` changes, I think it's better to create the needed dirs in the `:graphics` project rather than in the configure step of the global `sdk` task. build.gradle line 4176: > 4174: > 4175: task sdk() { > 4176: dependsOn(initDirs) I think this should be done in the graphics project, closer to the build logic for the shaders, maybe something like this: --- a/build.gradle +++ b/build.gradle @@ -2501,6 +2501,15 @@ project(":graphics") { } } + task initShaderDirs() { + doLast { + // Create empty hlsl dirs on all platforms for IDE support + file("$project.buildDir/hlsl/Decora").mkdirs() + file("$project.buildDir/hlsl/Prism").mkdirs() + } + } + project.processShaders.dependsOn(initShaderDirs) + nativePrism.dependsOn compilePrismHLSLShaders; project.nativeAllTask.dependsOn nativeDecora ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Tue Aug 9 16:15:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 16:15:24 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v6] In-Reply-To: <9cy4lvL0FjUZuwF3IzJvMkrP8ZrTa2MM666mQSbA5wQ=.cc210992-090b-4a16-93b4-04943799eda7@github.com> References: <9cy4lvL0FjUZuwF3IzJvMkrP8ZrTa2MM666mQSbA5wQ=.cc210992-090b-4a16-93b4-04943799eda7@github.com> Message-ID: <41ngAsujweNLOFAp_Qhh6aSQm83BN6mpAiy8-LEKf3A=.cf5d72be-85ae-4cf0-9902-5bf46fd80b65@github.com> On Tue, 9 Aug 2022 15:14:15 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 eight additional commits since the last revision: >> >> - 8290473: junit 5 >> - Merge remote-tracking branch 'origin/master' into 8290473.apps >> - 8290473: removed eclipse project in buildSrc >> - 8290473: whitespace >> - 8290473: added initDirs task >> - Merge remote-tracking branch 'origin/master' into 8290473.apps >> - 8290473: added ColorCube project >> - 8290473: eclipse config for apps > > build.gradle line 4176: > >> 4174: >> 4175: task sdk() { >> 4176: dependsOn(initDirs) > > I think this should be done in the graphics project, closer to the build logic for the shaders, maybe something like this: > > > --- a/build.gradle > +++ b/build.gradle > @@ -2501,6 +2501,15 @@ project(":graphics") { > } > } > > + task initShaderDirs() { > + doLast { > + // Create empty hlsl dirs on all platforms for IDE support > + file("$project.buildDir/hlsl/Decora").mkdirs() > + file("$project.buildDir/hlsl/Prism").mkdirs() > + } > + } > + project.processShaders.dependsOn(initShaderDirs) > + > nativePrism.dependsOn compilePrismHLSLShaders; > > project.nativeAllTask.dependsOn nativeDecora the reason I put them at the top level is to avoid a situation when gradle thinks that the graphics task is up-to-date (ex.: after a branch change) but the directories are not there. but you are right, this is a better place to add. thank you. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Tue Aug 9 17:14:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 17:14:59 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v7] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: init shader dirs ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/b63f4d19..f86d0737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=05-06 Stats: 17 lines in 1 file changed: 9 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Tue Aug 9 17:17:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 17:17:12 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v8] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/f86d0737..791552c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=06-07 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Tue Aug 9 18:48:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 18:48:45 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v8] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <6h9xGjVMWqTjGdWx-NT0rZ19YB_JbB9Am1jLoBwWn7Q=.958ab9d6-38ec-4669-9111-4fb1d345bb2a@github.com> Message-ID: On Tue, 9 Aug 2022 11:57:32 GMT, Jeanette Winzenburg wrote: >>> Aside: there is a general issue with cell selection not updated on columns modification (the selection visual is kept on the same column index without changing selectedCells accordingly - technically due to looping across the visibleLeafCells vs. all leaf columns. Might or might not be what ux requires, but the selectedCells must be in sync with the visuals always). >> >> Personally, I feel that any manipulations with the columns structure should clear the existing selection. I would imagine it's such a rare operation, and the "fix" is so easy (clear selection) that it's not worth even creating an issue for - but I could be wrong. >> >>> Don't remember if we have it covered in JBS? >> >> I did not find a close match. There is JDK-8095010; there is ticket you might be familiar with JDK-8093855; and one possibly related JDK-8091191. > >> >> Personally, I feel that any manipulations with the columns structure should clear the existing selection. I would imagine it's such a rare operation, and the "fix" is so easy (clear selection) that it's not worth even creating an issue for - but I could be wrong. >> > > haha .. are you prepared to get lynched by furious users ? Just imagine you selected several cells across the table, then decide to hide an unrelated column (which is not as rare as you assume :) and all your previous selection work is destroyed. > >> > Don't remember if we have it covered in JBS? >> >> I did not find a close match. There is JDK-8095010; there is ticket you might be familiar with JDK-8093855; and one possibly related JDK-8091191. > > none of those seem to be related to modification of columns, so tend to agree with Kevin that we should file a new issue @kleopatra : good point! I've tested with swing / JTable, and removing a column seem to deselect the cells in the removed column. I guess this should be the expected behavior - to clear selection in the hidden column(s)? If the app requirements call for preserving selection, this can be done on the app level (store the hidden cell selection and restore once the cells come to view)? I'll create a separate ticket (TBD). On another note, it seems the changes impacted/broke cell selection via mouse. Need to investigate. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Tue Aug 9 21:22:54 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 21:22:54 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 17:17:12 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: whitespace Build changes look fine now. ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Tue Aug 9 21:38:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Aug 2022 21:38:40 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v5] In-Reply-To: References: Message-ID: <35Vr_olNbCyI4NcLcGcWTJfqC8bP0i526nGSOuCoU9U=.aff4b42a-c5d7-47a7-b4b7-74cfc1c2673e@github.com> On Tue, 5 Jul 2022 23:30:48 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing I just noticed comments in [JDK-8292009](https://bugs.openjdk.org/browse/JDK-8292009) indicating that this PR fixes that bug as well. It would be good to get the review for this fix done. Since JDK-8292009 described a different problem that is also fixed as a result, it seems good to add that issue to this PR. @Maran23 GitHub is reporting a merge conflict in two of the test files. Can you merge the latest upstream master into your branch? ------------- PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Tue Aug 9 21:43:58 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 21:43:58 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v9] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: - 8235491: updated test - 8235491: removed unnecessary method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/9de5858b..76466935 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=07-08 Stats: 23 lines in 4 files changed: 0 ins; 20 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Tue Aug 9 21:46:48 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Aug 2022 21:46:48 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 17:17:12 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: whitespace Thank you all! If there are no more objections, I'd like to get this integrated, as it will save me from duplicate branches and continuous cherry-picking. ------------- PR: https://git.openjdk.org/jfx/pull/858 From aghaisas at openjdk.org Wed Aug 10 07:03:10 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 10 Aug 2022 07:03:10 GMT Subject: RFR: 8279514: NPE on clearing value of IntegerSpinnerValueFactory Message-ID: A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners- - `IntegerSpinnerValueFactory` - `LocalDateSpinnerValueFactory` - `LocalTimeSpinnerValueFactory` - `ListSpinnerValueFactory` Added 5 tests that detect NPE for above 4 Spinner factories. Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after. ------------- Commit messages: - Add null checks to SpinnerValueFactories Changes: https://git.openjdk.org/jfx/pull/865/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=865&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279514 Stats: 46 lines in 2 files changed: 46 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/865.diff Fetch: git fetch https://git.openjdk.org/jfx pull/865/head:pull/865 PR: https://git.openjdk.org/jfx/pull/865 From mhanl at openjdk.org Wed Aug 10 08:14:13 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Aug 2022 08:14:13 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Added other ticket as reference in javadoc - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin  Conflicts:  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java - Enable tests again - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing ------------- Changes: https://git.openjdk.org/jfx/pull/805/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=05 Stats: 109 lines in 8 files changed: 98 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From lbourges at openjdk.org Wed Aug 10 08:24:52 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 10 Aug 2022 08:24:52 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v5] In-Reply-To: <167foVI8gNxJZn4daa8Nl10mg5W6gg2SZ8Q698O-mHo=.bc600b00-3d50-4e90-a02a-7985457ba6e0@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> <__CEpoj1PkSTpUyfcf8C3kjGJMiX5x9smyMPrtblB0c=.d55033b3-81c4-4fc2-a825-d6d6bb6cfa95@github.com> <167foVI8gNxJZn4daa8Nl10mg5W6gg2SZ8Q698O-mHo=.bc600b00-3d50-4e90-a02a-7985457ba6e0@github.com> Message-ID: On Tue, 9 Aug 2022 14:52:12 GMT, Kevin Rushforth wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> upgraded to 0.9.4.6 (no repeated lineTo) + fixed tests > > modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 116: > >> 114: * @param high the index of the last element, exclusive, to be sorted >> 115: */ >> 116: static void sort(DPQSSorterContext sorter, int[] a, int[] auxA, int[] b, int[] auxB, int low, int high) { > > Here is one example of missing `@param` tags, in this case `sorter`, `auxA`, and `auxB`, but most methods are missing tags for some of their arguments. Will fix javadoc in that class... > modules/javafx.graphics/src/main/java/com/sun/marlin/Version.java line 30: > >> 28: public final class Version { >> 29: >> 30: private static final String VERSION = "marlinFX-0.9.4.6-Unsafe-OpenJFX"; > > Can you change the title of the JBS bug and this PR to reflect the `.6` version bump? Done ------------- PR: https://git.openjdk.org/jfx/pull/674 From mhanl at openjdk.org Wed Aug 10 08:45:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Aug 2022 08:45:53 GMT Subject: RFR: 8279514: NPE on clearing value of IntegerSpinnerValueFactory In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 06:56:50 GMT, Ajit Ghaisas wrote: > A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners- > - `IntegerSpinnerValueFactory` > - `LocalDateSpinnerValueFactory` > - `LocalTimeSpinnerValueFactory` > - `ListSpinnerValueFactory` > > Added 5 tests that detect NPE for above 4 Spinner factories. > Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after. Fix looks good and follows the same pattern as in `DoubleSpinnerValueFactory`. Left one minor suggestion for all added tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1498: > 1496: @Test public void testSetValueNull_IntegerSpinner() { > 1497: intValueFactory.setValue(null); > 1498: assertEquals(null, intSpinner.getValue()); All the tests can be simplified to just use `assertNull()` instead. -> `assertNull(intSpinner.getValue());` ------------- Marked as reviewed by mhanl (Committer). PR: https://git.openjdk.org/jfx/pull/865 From mhanl at openjdk.org Wed Aug 10 09:30:41 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Aug 2022 09:30:41 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v5] In-Reply-To: <35Vr_olNbCyI4NcLcGcWTJfqC8bP0i526nGSOuCoU9U=.aff4b42a-c5d7-47a7-b4b7-74cfc1c2673e@github.com> References: <35Vr_olNbCyI4NcLcGcWTJfqC8bP0i526nGSOuCoU9U=.aff4b42a-c5d7-47a7-b4b7-74cfc1c2673e@github.com> Message-ID: On Tue, 9 Aug 2022 21:35:11 GMT, Kevin Rushforth wrote: > @Maran23 GitHub is reporting a merge conflict in two of the test files. Can you merge the latest upstream master into your branch? Didn't noticed, thanks for the ping. For some reason the macOS build can not download ant: --2022-08-10 08:14:06-- (try: 2) https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.5-bin.tar.gz Connecting to archive.apache.org (archive.apache.org)|138.201.131.134|:443... failed: Operation timed out. Retrying. I will trigger a rebuild soon. ------------- PR: https://git.openjdk.org/jfx/pull/805 From aghaisas at openjdk.org Wed Aug 10 09:40:02 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 10 Aug 2022 09:40:02 GMT Subject: RFR: 8279514: NPE on clearing value of IntegerSpinnerValueFactory [v2] In-Reply-To: References: Message-ID: > A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners- > - `IntegerSpinnerValueFactory` > - `LocalDateSpinnerValueFactory` > - `LocalTimeSpinnerValueFactory` > - `ListSpinnerValueFactory` > > Added 5 tests that detect NPE for above 4 Spinner factories. > Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Simplify null asserts ------------- Changes: - all: https://git.openjdk.org/jfx/pull/865/files - new: https://git.openjdk.org/jfx/pull/865/files/6d27071d..b04a79a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=865&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=865&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/865.diff Fetch: git fetch https://git.openjdk.org/jfx pull/865/head:pull/865 PR: https://git.openjdk.org/jfx/pull/865 From jbhaskar at openjdk.org Wed Aug 10 10:14:19 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 10 Aug 2022 10:14:19 GMT Subject: RFR: 8290274: DRT 27 tests fail due to xml not well formed error on window Message-ID: Issue: xml not well-formed error occurs at XML document parser. Issue: doEnd() call not needed for JAVA platform, as it is making XMLDocumentParserLibxml2 xml not well-formed error. ------------- Commit messages: - 8290274: DRT 27 tests fail due to xml not well formed error on window Changes: https://git.openjdk.org/jfx/pull/866/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290274 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/866.diff Fetch: git fetch https://git.openjdk.org/jfx pull/866/head:pull/866 PR: https://git.openjdk.org/jfx/pull/866 From arapte at openjdk.org Wed Aug 10 10:53:47 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 10:53:47 GMT Subject: [jfx17u] Integrated: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:11:18 GMT, Ambarish Rapte wrote: > Clean backport to jfx17u This pull request has now been integrated. Changeset: 60311082 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/603110823e59016fd422fd4a129e520e90e2e0ea Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Backport-of: 6d126382ddd59757081a866517c36ff09ba20125 ------------- PR: https://git.openjdk.org/jfx17u/pull/72 From arapte at openjdk.org Wed Aug 10 10:56:51 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 10:56:51 GMT Subject: [jfx17u] Integrated: 8088420: JavaFX WebView memory leak via EventListener In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:13:46 GMT, Ambarish Rapte wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: cd39e0bb Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/cd39e0bb3515aafc39d97f719695ff807f27e497 Stats: 1509 lines in 11 files changed: 1503 ins; 3 del; 3 mod 8088420: JavaFX WebView memory leak via EventListener Backport-of: f5348503143e8d08f09b4cd48b6a3864bd09c336 ------------- PR: https://git.openjdk.org/jfx17u/pull/73 From arapte at openjdk.org Wed Aug 10 10:56:53 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 10:56:53 GMT Subject: [jfx17u] Integrated: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: <5auywnOXwIAzkOrHbogpXk_IvMvQ3fZN3yRP64ywLYk=.5acc3078-2182-489c-ac01-7d13509a5b37@github.com> References: <5auywnOXwIAzkOrHbogpXk_IvMvQ3fZN3yRP64ywLYk=.5acc3078-2182-489c-ac01-7d13509a5b37@github.com> Message-ID: On Tue, 9 Aug 2022 12:16:43 GMT, Ambarish Rapte wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 525e854f Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/525e854fbcf0f696969f4230303c14a1ed82f6a4 Stats: 180 lines in 3 files changed: 174 ins; 0 del; 6 mod 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Backport-of: fc6a60234b0feec80b05257cc93407f651805303 ------------- PR: https://git.openjdk.org/jfx17u/pull/74 From arapte at openjdk.org Wed Aug 10 10:59:44 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 10:59:44 GMT Subject: [jfx17u] Integrated: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: <1wocgmuTk3cjiHZZoqwVtBA0F7elGmCqvskcpDQrY1I=.333438e2-c3db-49fe-b7bc-13a453ea14b0@github.com> References: <1wocgmuTk3cjiHZZoqwVtBA0F7elGmCqvskcpDQrY1I=.333438e2-c3db-49fe-b7bc-13a453ea14b0@github.com> Message-ID: On Tue, 9 Aug 2022 12:18:51 GMT, Ambarish Rapte wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: f961fa80 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/f961fa80131480b4742f8eb9daf9122a35a6a2c6 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Backport-of: cbb53b22fc87e880d59ac3e217a86a4733d2b0f3 ------------- PR: https://git.openjdk.org/jfx17u/pull/75 From arapte at openjdk.org Wed Aug 10 10:59:57 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 10:59:57 GMT Subject: [jfx17u] Integrated: 8284676: TreeTableView loses sort ordering when applied on empty table In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 12:20:35 GMT, Ambarish Rapte wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: e363c7a3 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/e363c7a39eca30227ef8c79a16e7132937783904 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod 8284676: TreeTableView loses sort ordering when applied on empty table Backport-of: 0132ac89033334ec9d9ec6149d116e8c352f89ec ------------- PR: https://git.openjdk.org/jfx17u/pull/76 From arapte at openjdk.org Wed Aug 10 11:55:42 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 11:55:42 GMT Subject: [jfx17u] RFR: 8285881: Update WebKit to 614.1 Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8285881: Update WebKit to 614.1 Changes: https://git.openjdk.org/jfx17u/pull/77/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=77&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285881 Stats: 447029 lines in 7346 files changed: 300706 ins; 103521 del; 42802 mod Patch: https://git.openjdk.org/jfx17u/pull/77.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/77/head:pull/77 PR: https://git.openjdk.org/jfx17u/pull/77 From arapte at openjdk.org Wed Aug 10 11:56:57 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Aug 2022 11:56:57 GMT Subject: [jfx17u] Integrated: 8285881: Update WebKit to 614.1 In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 11:00:23 GMT, Ambarish Rapte wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: ae0b9fa8 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx17u/commit/ae0b9fa8d41beb077ead26507e4d3aaf708ec36e Stats: 447029 lines in 7346 files changed: 300706 ins; 103521 del; 42802 mod 8285881: Update WebKit to 614.1 Backport-of: 7e48413eb0f9eb3dcbd9d3a1572fc311036092c8 ------------- PR: https://git.openjdk.org/jfx17u/pull/77 From kcr at openjdk.org Wed Aug 10 12:48:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Aug 2022 12:48:48 GMT Subject: RFR: 8290274: DRT 27 tests fail due to xml not well formed error on window In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 10:06:21 GMT, Jay Bhaskar wrote: > Issue: xml not well-formed error occurs at XML document parser. > Issue: doEnd() call not needed for JAVA platform, as it is making XMLDocumentParserLibxml2 xml not well-formed error. Can you say why the `doEnd` call is not needed for the Java platform? Have you verified that there is no adverse effect to skipping it? ------------- PR: https://git.openjdk.org/jfx/pull/866 From kcr at openjdk.org Wed Aug 10 12:54:45 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Aug 2022 12:54:45 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing > For some reason the macOS build can not download ant: > ... > I will trigger a rebuild soon. @andy-goryachev-oracle and I have both seen this recently on some of our GHA runs. It's an intermittent failure, so a rebuild usually works. ------------- PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Wed Aug 10 15:33:15 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 15:33:15 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v10] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). 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 16 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8235491.isselected - 8235491: updated test - 8235491: removed unnecessary method - 8235491: delegate to super() - 8235491: revert clear selection - 8235491: whitespace - 8235491: additional tests - Merge remote-tracking branch 'origin/master' into 8235491.isselected - 8235491: javadoc - 8235491: tree table view - ... and 6 more: https://git.openjdk.org/jfx/compare/03253b00...35247bc6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/76466935..35247bc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=08-09 Stats: 480 lines in 6 files changed: 450 ins; 10 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Wed Aug 10 19:13:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 19:13:40 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 09:25:57 GMT, Sai Pradeep Dandem wrote: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. With the EPSILON change the horizontal bar disappears for good! Tried with setSnapToPixel(false) on TableView, table columns, split pane. @SaiPradeepDandem I might have accidentally reassigned JDK-8089009 to myself, you can grab it back if it was yours (for a full credit!). This change might also fix [JDK-8089280](https://bugs.openjdk.org/browse/JDK-8089280) (or JDK-8089280 should be closed as a duplicate). ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Wed Aug 10 20:01:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 20:01:50 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: <-nQdMpVNlCx7LBnmZD02pOOdb4kEBKmnOF0Rf_2hYPA=.1732b7cd-2667-4882-ab7e-d56f473dd335@github.com> On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 673: > 671: tableRow.updateIndex(-1); > 672: cell.updateIndex(-1); > 673: would we need tableRow.setTableView(null) here? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 767: > 765: } > 766: tableSkin.getChildren().remove(treeTableRow); > 767: would we need treeTableRow.updateTreeTableView(null); here to prevent a memory leak? ------------- PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Wed Aug 10 20:01:52 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 20:01:52 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 09:25:57 GMT, Sai Pradeep Dandem wrote: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Changes requested by angorya (Author). ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Wed Aug 10 20:01:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 20:01:53 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. In-Reply-To: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Tue, 26 Jul 2022 00:28:59 GMT, Sai Pradeep Dandem wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableUtil.java line 226: >> >>> 224: } >>> 225: >>> 226: if (Math.abs(colWidth - tableWidth) > 0) { >> >> Related to Andy's question, shouldn't this be `> EPSILON` (for some small value of EPSILON), since floating-point arithmetic isn't precise? > > @kevinrushforth We can consider EPSILON with value of `.0000001`. This value is already used in the same method for another bounds checking. Below is the part of the code where it is used.. > > // Check for zero. This happens when the distribution of the delta > // finishes early due to a series of "fixed" entries at the end. > // In this case, lowerBound == upperBound, for all subsequent terms. > double newSize; > if (Math.abs(totalLowerBound - totalUpperBound) < .0000001) { > newSize = lowerBound; > } else { > double f = (target - totalLowerBound) / (totalUpperBound - totalLowerBound); > newSize = Math.round(lowerBound + f * (upperBound - lowerBound)); > } I am also for declaring a constant private static final double EPSILON = .0000001; and using it in on lines 226 and 251. ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Wed Aug 10 22:14:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 22:14:53 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/de5ac792..cfa99760 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Wed Aug 10 23:24:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 23:24:41 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); I wonder if a null check should be added to: - ListViewSkin:381 calls getSelectionModel() ------------- PR: https://git.openjdk.org/jfx/pull/711 From angorya at openjdk.org Wed Aug 10 23:30:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Aug 2022 23:30:53 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: <8gsp8GGHH6ORcZdzC_fRKq9A9w4Cn9j_uMG6ldqex9E=.0f2ecb1c-4d7f-4424-95d8-572664ea6f68@github.com> On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl wrote: > This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`. > > The following NPEs are fixed (all are also covered by exactly one test case): > NPEs with null selection model: > - Mouse click on a `ListCell` > - SPACE key press > - KP_UP (arrow up) key press > - HOME key press > - END key press > - BACK_SLASH + CTRL key press > > NPEs with null focus model: > - SPACE key press > - Select an items: getSelectionModel().select(1) > - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3"); Changes requested by angorya (Author). There is a condition observed while debugging [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145), when a non-null selection model is set, the user creates a non-empty selection, then the selection is set to null. The UI still shows selected cells - does the same bug exists in ListView? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 268: > 266: return; > 267: } > 268: line 281 (below): could sm be null there? ------------- PR: https://git.openjdk.org/jfx/pull/711 From duke at openjdk.org Thu Aug 11 00:00:58 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Thu, 11 Aug 2022 00:00:58 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: Message-ID: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Included a constant 'EPSILON' for floating-point arithmetic precision. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/c5942695..b2e1c2bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From nlisker at openjdk.org Thu Aug 11 00:05:51 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 11 Aug 2022 00:05:51 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 18:01:06 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed method > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vs2ps.h line 38: > >> 36: float3 worldVecToEye : texcoord2; >> 37: float3 worldVecsToLights[nLights] : texcoord3; // 3, 4, 5 >> 38: float3 worldNormLightDirs[nLights] : texcoord6; // 6, 7, 8 > > This is an existing behavior, and I just want to open it for discussion and bring it to your consideration for future changes. > These are per vertex attributes and they may cause un-required processing/overhead during rasterization. > In a regular scenario where only one light i.e. default light is set, the other two values in these arrays are reset and are unused in pixel shader. But rasterizer interpolates these values for all pixel and pass them as input to pixel shader. > May be in future we can find a way to avoid this. I think that when the strict limit of 3 lights is removed then we will touch this as well. ------------- PR: https://git.openjdk.org/jfx/pull/789 From mhanl at openjdk.org Thu Aug 11 08:29:44 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 08:29:44 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: <-nQdMpVNlCx7LBnmZD02pOOdb4kEBKmnOF0Rf_2hYPA=.1732b7cd-2667-4882-ab7e-d56f473dd335@github.com> References: <-nQdMpVNlCx7LBnmZD02pOOdb4kEBKmnOF0Rf_2hYPA=.1732b7cd-2667-4882-ab7e-d56f473dd335@github.com> Message-ID: <3LAWDm4DkSSnQDeMb8YjOSVojkT2-BMMrGS0Z8rka-s=.0dac2172-f362-4c0d-92fd-5a4e38cc5078@github.com> On Wed, 10 Aug 2022 19:50:02 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Added other ticket as reference in javadoc >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin >> >>  Conflicts: >>  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >>  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java >> - Enable tests again >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin >> - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing >> - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup >> - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener >> - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 767: > >> 765: } >> 766: tableSkin.getChildren().remove(treeTableRow); >> 767: > > would we need > > treeTableRow.updateTreeTableView(null); > > here to prevent a memory leak? I don't think so. The row and cell should be gc'ed after this method since there are not used anywhere ------------- PR: https://git.openjdk.org/jfx/pull/805 From mhanl at openjdk.org Thu Aug 11 08:31:54 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 08:31:54 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 23:21:20 GMT, Andy Goryachev wrote: > ListViewSkin:381 calls getSelectionModel() probably, same to focusModel here. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 268: > >> 266: return; >> 267: } >> 268: > > line 281 (below): could sm be null there? no, as this is listener is added to a particular selection model. ------------- PR: https://git.openjdk.org/jfx/pull/711 From mhanl at openjdk.org Thu Aug 11 09:31:34 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 09:31:34 GMT Subject: RFR: 8279514: NPE on clearing value of IntegerSpinnerValueFactory [v2] In-Reply-To: References: Message-ID: <9cZki-BVhmDkdYm1zJhHECpCQaDJZ7h95Dzh8dQVvs0=.e487cc6e-06cc-4c4f-aef8-83d7dab88b51@github.com> On Wed, 10 Aug 2022 09:40:02 GMT, Ajit Ghaisas wrote: >> A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners- >> - `IntegerSpinnerValueFactory` >> - `LocalDateSpinnerValueFactory` >> - `LocalTimeSpinnerValueFactory` >> - `ListSpinnerValueFactory` >> >> Added 5 tests that detect NPE for above 4 Spinner factories. >> Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Simplify null asserts LGTM ------------- Marked as reviewed by mhanl (Committer). PR: https://git.openjdk.org/jfx/pull/865 From aghaisas at openjdk.org Thu Aug 11 11:06:34 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 11 Aug 2022 11:06:34 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:14:53 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: javadoc modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 60: > 58: * {@link Skin#getSkinnable()} against this Skinnable, > 59: * and may throw an IllegalArgumentException if it is not the same. > 60: * `@throws` tag can be used ------------- PR: https://git.openjdk.org/jfx/pull/845 From jbhaskar at openjdk.org Thu Aug 11 11:41:36 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 11 Aug 2022 11:41:36 GMT Subject: RFR: 8290274: DRT 27 tests fail due to xml not well formed error on window In-Reply-To: References: Message-ID: <0XoEgLvp1PD8F61mOurmWXBBLa8nOJzsEOoAJ1fDZYA=.2521360f-d1d6-4d43-a906-c4d41da8d698@github.com> On Wed, 10 Aug 2022 10:06:21 GMT, Jay Bhaskar wrote: > Issue: xml not well-formed error occurs at XML document parser. > Issue: doEnd() call not needed for JAVA platform, as it is making XMLDocumentParserLibxml2 xml not well-formed error. According to comments mention in the source code: void XMLDocumentParser::end() { // XMLDocumentParserLibxml2 will do bad things to the document if doEnd() is called. // I don't believe XMLDocumentParserQt needs doEnd called in the fragment case. The doEnd() call not needed for JAVA Platform also, as it is affecting libxml2 parser to generate xml not well formed error. I have tested it , it fixes 27 test cases with no side effects for other drt tests. ------------- PR: https://git.openjdk.org/jfx/pull/866 From fastegal at openjdk.org Thu Aug 11 12:06:44 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 11 Aug 2022 12:06:44 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v10] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Wed, 10 Aug 2022 15:33:15 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > 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 16 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: updated test > - 8235491: removed unnecessary method > - 8235491: delegate to super() > - 8235491: revert clear selection > - 8235491: whitespace > - 8235491: additional tests > - Merge remote-tracking branch 'origin/master' into 8235491.isselected > - 8235491: javadoc > - 8235491: tree table view > - ... and 6 more: https://git.openjdk.org/jfx/compare/fac7b47a...35247bc6 modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 445: > 443: > 444: boolean isSelected = getTreeTableView().getSelectionModel().isSelected(index, null); > 445: if (isSelected() == isSelected) return; good example of when using the two-param method makes sense - we probably should do the same in TableRow (which does some convoluted ifs for the same result) to keep both as similar as possible. Might be done a new low-priority follow-up issue ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Thu Aug 11 12:10:38 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 11 Aug 2022 12:10:38 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Tue, 9 Aug 2022 11:51:09 GMT, Jeanette Winzenburg wrote: > the tests - they deserve to be integrated into TableViewSelectionModelImplTest, with your permission. similar tests (along with that in the bug report) adapted to treeTable should be added to the treeTable test - we should keep them as sync'ed as possible, to not make future maintainers wonder why they aren't included :) ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Thu Aug 11 12:18:37 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 11 Aug 2022 12:18:37 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:14:53 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: javadoc modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 33: > 31: * An interface for defining the visual representation of user interface controls > 32: * by defining a scene graph of nodes to represent the skin. > 33: * A user interface control is abstracted behind the {@link Skinnable} interface. shouldn't that be _to represent the skinnable_? ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Thu Aug 11 12:33:38 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 11 Aug 2022 12:33:38 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:14:53 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: javadoc modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > 76: /** > 77: * Called by {@link Control#setSkin(Skin)} on a pristine control, or after the > 78: * previous skin has been uninstalled via its {@link #dispose()} method. Hmm .. as formulated that sounds to me like an implementation detail of Control (which shouldn't appear here). We might think of something unrelated to specific users. Also: the congenial partner of a Skin is a Skinnable - all narrowing to a special implementator of Skinnable here should be avoided. We have an open issue for the invers, that is Skinnable overspecifying itself as Control [JDK-8260364](https://bugs.openjdk.org/browse/JDK-8260364) ------------- PR: https://git.openjdk.org/jfx/pull/845 From mhanl at openjdk.org Thu Aug 11 13:20:39 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 13:20:39 GMT Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws NPE In-Reply-To: <8gsp8GGHH6ORcZdzC_fRKq9A9w4Cn9j_uMG6ldqex9E=.0f2ecb1c-4d7f-4424-95d8-572664ea6f68@github.com> References: <8gsp8GGHH6ORcZdzC_fRKq9A9w4Cn9j_uMG6ldqex9E=.0f2ecb1c-4d7f-4424-95d8-572664ea6f68@github.com> Message-ID: On Wed, 10 Aug 2022 23:28:04 GMT, Andy Goryachev wrote: > There is a condition observed while debugging [JDK-8187145](https://bugs.openjdk.org/browse/JDK-8187145), when a non-null selection model is set, the user creates a non-empty selection, then the selection is set to null. > > The UI still shows selected cells - does the same bug exists in ListView? Just tried and it looks fine for `ListView`. ------------- PR: https://git.openjdk.org/jfx/pull/711 From fastegal at openjdk.org Thu Aug 11 13:21:35 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 11 Aug 2022 13:21:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:14:53 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: javadoc >From a purist perspective, I love this change :) But .. jumping to the impact analysis (and playing devil's advocate, a bit :) > The changes should be fairly trivial. Only a subset of skins needs to be refactored, and the refactoring itself is trivial. optimistic ? On the bright side: that subset are the harder ones, some being in a hierarchy of skins where every level might do its own evil .. so we can eat our own dog food (dealing with the added life-cyle). > The new API is backwards compatible with the existing code, the customer-developed skins can remain unchanged (thanks to default implementation). hmm ... probably I'm missing something but I don't see how that would be the case for the subset of core skins that have to be refactored and moved their installation into the install() method. Typically, custom skins do their own stuff on top of what super did at the end of the constructor, assuming that everything is fully installed. Depending on what exactly will be moved into install, their behavior will be broken after the change. Examples: // prepending a listener Consumer old = unregisterXXListener(someProperty); registerXXListener(someProperty, consumer); registerXXListener(someProperty, old); // lookup a child added by super Node child = control.lookup(..) // replace singleton event handlers control.setOnXX(...) // probably more that I don't remember right now .. ------------- PR: https://git.openjdk.org/jfx/pull/845 From mhanl at openjdk.org Thu Aug 11 13:58:36 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 13:58:36 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: <3D2MXlqCsqqkyU57pNeVz9aqlwwwSW3MLmTHjNf408M=.e0e117a3-37f2-4443-849d-a20dd10ffb06@github.com> References: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> <3D2MXlqCsqqkyU57pNeVz9aqlwwwSW3MLmTHjNf408M=.e0e117a3-37f2-4443-849d-a20dd10ffb06@github.com> Message-ID: On Wed, 27 Jul 2022 20:28:31 GMT, Andy Goryachev wrote: >> Yes, but that can be fixed so the rule is not violated. > > I like this idea. > > However, I am afraid that the impact of the check in PopupControl might be greater than expected. In addition to your ComboBoxPopupcontrol.createPopup() fix you provided earlier, there is a similar situation with TooltipSkin in PopupcontrolTest:604: > > > Tooltip tooltip = new Tooltip("Hello"); > TooltipSkin skin = new TooltipSkin(tooltip); > popup.setSkin(skin); > > > it is not entirely clear to me why a TooltipSkin is installed as a skin for the popup instead of the tooltip. > > I think we should rather say that this 1:1 rule does not apply to PopupControls. It is a bit weird as `Popups` are not using the `getSkinnable` method it looks like. And also the `getSkinnable` method javadoc states: `Gets the Skinnable to which this Skin is assigned.` which is not true for the `ComboBox` Popup (as it sets the `ComboBox` as the skinnable) - while it makes sense that the `ComboBox` is set as styleable parent. ------------- PR: https://git.openjdk.org/jfx/pull/845 From mhanl at openjdk.org Thu Aug 11 14:08:37 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 14:08:37 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> <3D2MXlqCsqqkyU57pNeVz9aqlwwwSW3MLmTHjNf408M=.e0e117a3-37f2-4443-849d-a20dd10ffb06@github.com> Message-ID: On Thu, 11 Aug 2022 13:55:10 GMT, Marius Hanl wrote: >> I like this idea. >> >> However, I am afraid that the impact of the check in PopupControl might be greater than expected. In addition to your ComboBoxPopupcontrol.createPopup() fix you provided earlier, there is a similar situation with TooltipSkin in PopupcontrolTest:604: >> >> >> Tooltip tooltip = new Tooltip("Hello"); >> TooltipSkin skin = new TooltipSkin(tooltip); >> popup.setSkin(skin); >> >> >> it is not entirely clear to me why a TooltipSkin is installed as a skin for the popup instead of the tooltip. >> >> I think we should rather say that this 1:1 rule does not apply to PopupControls. > > It is a bit weird as `Popups` are not using the `getSkinnable` method it looks like. And also the `getSkinnable` method javadoc states: `Gets the Skinnable to which this Skin is assigned.` which is not true for the `ComboBox` Popup (as it sets the `ComboBox` as the skinnable) - while it makes sense that the `ComboBox` is set as styleable parent. So it is even more weird: `getSkinnable()` is always called in `Control` skins, `getNode()` is only called in `Control.getSkinNode()`, `PaginationSkin` and `TableColumnHeader` (so not very much). `getNode()` is always called for `Popups` (no `getSkinnable()` is called). The only exception is the internal class `InputFieldSkin`, where the node is an 'inner TextField' and the skinnable the control where it is installed on. ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Aug 11 15:47:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 15:47:38 GMT Subject: RFR: 8290274: DRT 27 tests fail due to xml not well formed error on window In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 10:06:21 GMT, Jay Bhaskar wrote: > Issue: xml not well-formed error occurs at XML document parser. > Issue: doEnd() call not needed for JAVA platform, as it is making XMLDocumentParserLibxml2 xml not well-formed error. Looks fine then. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/866 From angorya at openjdk.org Thu Aug 11 15:54:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 15:54:37 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 00:00:58 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. >> >> **Cause:** >> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. >> >> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). >> >> To confirm this behaviour, please find the below example that showcases the issue: >> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. >> >> >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.beans.property.StringProperty; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.geometry.Insets; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.control.*; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class ConstrainedResizePolicyIssueDemo extends Application { >> @Override >> public void start(Stage primaryStage) throws Exception { >> TableColumn fnCol = new TableColumn<>("First Name"); >> fnCol.setMinWidth(100); >> fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); >> >> TableColumn priceCol = new TableColumn<>("Price"); >> priceCol.setMinWidth(100); >> priceCol.setMaxWidth(150); >> priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); >> >> TableColumn totalCol = new TableColumn<>("Total"); >> totalCol.setMinWidth(100); >> totalCol.setMaxWidth(150); >> totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); >> >> ObservableList persons = FXCollections.observableArrayList(); >> persons.add(new Person("Harry", "200.00", "210.00")); >> persons.add(new Person("Jacob", "260.00", "260.00")); >> >> TableView tableView = new TableView<>(); >> tableView.getColumns().addAll(fnCol, priceCol, totalCol); >> tableView.setItems(persons); >> tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); >> tableView.setMinWidth(500); >> tableView.maxWidthProperty().bind(tableView.minWidthProperty()); >> >> Button button1 = new Button("Reduce 1px"); >> button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); >> Button button2 = new Button("Reduce 10px"); >> button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); >> Button button3 = new Button("Reset"); >> button3.setOnAction(e -> tableView.setMinWidth(500)); >> Button button4 = new Button("Increase 1px"); >> button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); >> Button button5 = new Button("Increase 10px"); >> button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); >> >> HBox row = new HBox(button1, button2, button3, button4, button5); >> row.setSpacing(10); >> TextArea output = new TextArea(); >> >> addWidthListeners(tableView, output); >> VBox root = new VBox(row, new Group(tableView), output); >> root.setSpacing(10); >> root.setPadding(new Insets(10)); >> >> Scene scene = new Scene(root); >> primaryStage.setScene(scene); >> primaryStage.setTitle("Constrained Resize Policy Issue TableView"); >> primaryStage.show(); >> } >> >> private void addWidthListeners(TableView tableView, TextArea output) { >> tableView.widthProperty().addListener((obs, old, val) -> { >> String str = "Table width changed :: " + val + "\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> tableView.getColumns().forEach(column -> { >> column.widthProperty().addListener((obs, old, width) -> { >> String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> }); >> } >> >> class Person { >> private StringProperty firstName = new SimpleStringProperty(); >> private StringProperty price = new SimpleStringProperty(); >> private StringProperty total = new SimpleStringProperty(); >> >> public Person(String fn, String price, String total) { >> setFirstName(fn); >> setPrice(price); >> setTotal(total); >> } >> >> public StringProperty firstNameProperty() { >> return firstName; >> } >> >> public void setFirstName(String firstName) { >> this.firstName.set(firstName); >> } >> >> public StringProperty priceProperty() { >> return price; >> } >> >> public void setPrice(String price) { >> this.price.set(price); >> } >> >> public StringProperty totalProperty() { >> return total; >> } >> >> public void setTotal(String total) { >> this.total.set(total); >> } >> } >> } >> >> >> **Fix:** >> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. >> >> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 >> >> `if (Math.abs(colWidth - tableWidth) > 1) {` >> >> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > Included a constant 'EPSILON' for floating-point arithmetic precision. Changes requested by angorya (Author). modules/javafx.controls/src/main/java/javafx/scene/control/TableUtil.java line 41: > 39: class TableUtil { > 40: > 41: /** please update copyright year, line 2 ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Thu Aug 11 15:59:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 15:59:42 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 10:47:35 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290844: javadoc > > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 60: > >> 58: * {@link Skin#getSkinnable()} against this Skinnable, >> 59: * and may throw an IllegalArgumentException if it is not the same. >> 60: * > > `@throws` tag can be used In this case, a IllegalArgumentException is not a checked exception (not a part of general contract). Just like in TextInputControl.getText(int, int) : 457, for example. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 16:17:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 16:17:40 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Thu, 11 Aug 2022 12:08:36 GMT, Jeanette Winzenburg wrote: > similar tests (along with that in the bug report) adapted to treeTable should be added to the treeTable test - we should keep them as sync'ed as possible, to not make future maintainers wonder why they aren't included :) The tests were added to both TableViewSelectionModelImplTest and TreeTableViewSelectionModelImplTest. ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Thu Aug 11 16:27:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 16:27:25 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 15:57:30 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 60: >> >>> 58: * {@link Skin#getSkinnable()} against this Skinnable, >>> 59: * and may throw an IllegalArgumentException if it is not the same. >>> 60: * >> >> `@throws` tag can be used > > In this case, a IllegalArgumentException is not a checked exception (not a part of general contract). > > Just like in TextInputControl.getText(int, int) : 457, for example. Whether or not it is a checked exception, we should document exceptions that are thrown with `@throws`. In this case, I see that it says the exception "might" be thrown, so if we add an `@throws` (which seems a good idea), it would need to describe the conditions under which it might be thrown. ------------- PR: https://git.openjdk.org/jfx/pull/845 From prr at openjdk.org Thu Aug 11 16:36:35 2022 From: prr at openjdk.org (Phil Race) Date: Thu, 11 Aug 2022 16:36:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:24:19 GMT, Kevin Rushforth wrote: >> In this case, a IllegalArgumentException is not a checked exception (not a part of general contract). >> >> Just like in TextInputControl.getText(int, int) : 457, for example. > > Whether or not it is a checked exception, we should document exceptions that are thrown with `@throws`. > > In this case, I see that it says the exception "might" be thrown, so if we add an `@throws` (which seems a good idea), it would need to describe the conditions under which it might be thrown. Yes, even if there are some places in FX that don't, the expectation is that it is listed in an @throws. There are hundreds of examples of this in the JDK. Also whenever you have the name of a class (etc) in the comment use {@code IllegalArgumentException) ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 16:36:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 16:36:35 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:30:48 GMT, Phil Race wrote: >> Whether or not it is a checked exception, we should document exceptions that are thrown with `@throws`. >> >> In this case, I see that it says the exception "might" be thrown, so if we add an `@throws` (which seems a good idea), it would need to describe the conditions under which it might be thrown. > > Yes, even if there are some places in FX that don't, the expectation is that it is listed in an @throws. > There are hundreds of examples of this in the JDK. > Also whenever you have the name of a class (etc) in the comment use {@code IllegalArgumentException) thank you all, will fix. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 18:00:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 18:00:37 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v10] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Thu, 11 Aug 2022 12:02:16 GMT, Jeanette Winzenburg 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 16 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: updated test >> - 8235491: removed unnecessary method >> - 8235491: delegate to super() >> - 8235491: revert clear selection >> - 8235491: whitespace >> - 8235491: additional tests >> - Merge remote-tracking branch 'origin/master' into 8235491.isselected >> - 8235491: javadoc >> - 8235491: tree table view >> - ... and 6 more: https://git.openjdk.org/jfx/compare/d1fee347...35247bc6 > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 445: > >> 443: >> 444: boolean isSelected = getTreeTableView().getSelectionModel().isSelected(index, null); >> 445: if (isSelected() == isSelected) return; > > good example of when using the two-param method makes sense - we probably should do the same in TableRow (which does some convoluted ifs for the same result) to keep both as similar as possible. Might be done a new low-priority follow-up issue unnecessary in the case of TableRow. the change in TreeTableRow was necessary because otherwise selecting a cell by mouse selected the whole row. ------------- PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Thu Aug 11 19:26:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 19:26:37 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: <6du8GgNm_8oIa77P2fZCqyPkTpaqnw_l7PXcY3T81vM=.5e958952-4f78-4da4-94e4-d1ff8d0d3c16@github.com> <3D2MXlqCsqqkyU57pNeVz9aqlwwwSW3MLmTHjNf408M=.e0e117a3-37f2-4443-849d-a20dd10ffb06@github.com> Message-ID: On Thu, 11 Aug 2022 14:04:25 GMT, Marius Hanl wrote: >> It is a bit weird as `Popups` are not using the `getSkinnable` method it looks like. And also the `getSkinnable` method javadoc states: `Gets the Skinnable to which this Skin is assigned.` which is not true for the `ComboBox` Popup (as it sets the `ComboBox` as the skinnable) - while it makes sense that the `ComboBox` is set as styleable parent. > > So it is even more weird: > `getSkinnable()` is always called in `Control` skins, `getNode()` is only called in `Control.getSkinNode()`, `PaginationSkin` and `TableColumnHeader` (so not very much). > `getNode()` is always called for `Popups` (no `getSkinnable()` is called). > > The only exception is the internal class `InputFieldSkin`, where the node is an 'inner TextField' and the skinnable the control where it is installed on. I agree. The whole mess stems from the fact that Skinnable is being passed to the Skin's constructor, instead of being passed to install(), as in Swing. But, at this point, _it is what it is_. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 19:35:04 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 19:35:04 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: <7uPiI_Sgp-dgPJdNvz3wsACVHPWH9TJLrX0pzyNSqhI=.c9992b00-7f18-4f35-96ce-9e9c789e8a74@github.com> On Thu, 11 Aug 2022 13:17:43 GMT, Jeanette Winzenburg wrote: > hmm ... probably I'm missing something but I don't see how that would be the case for the subset of core skins that have to be refactored and moved their installation into the install() method. You are right - some of the core skins will have to be refactored. As a result, any skin that user derived from those _might need_ to change as well. I shall update the CSR. This is a price to pay for fixing a design error, I think. Either fix it now, or forever stay with memory leaks and resulting bugs. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 19:55:15 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 19:55:15 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 12:29:57 GMT, Jeanette Winzenburg wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290844: javadoc > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > >> 76: /** >> 77: * Called by {@link Control#setSkin(Skin)} on a pristine control, or after the >> 78: * previous skin has been uninstalled via its {@link #dispose()} method. > > Hmm .. as formulated that sounds to me like an implementation detail of Control (which shouldn't appear here). We might think of something unrelated to specific users. > > Also: the congenial partner of a Skin is a Skinnable - all narrowing to a special implementator of Skinnable here should be avoided. We have an open issue for the invers, that is Skinnable overspecifying itself as Control [JDK-8260364](https://bugs.openjdk.org/browse/JDK-8260364) Reworded the description to refer to Skinnable.setSkin(). I feel it is important to mention where in the life cycle of the Skin the install() is getting invoked, without changing too much, but any suggestions will be greatly appreciated! ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Thu Aug 11 19:59:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 19:59:10 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 12:16:35 GMT, Jeanette Winzenburg wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290844: javadoc > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 33: > >> 31: * An interface for defining the visual representation of user interface controls >> 32: * by defining a scene graph of nodes to represent the skin. >> 33: * A user interface control is abstracted behind the {@link Skinnable} interface. > > shouldn't that be _to represent the skinnable_? I think this description is good. How would you change it? ------------- PR: https://git.openjdk.org/jfx/pull/845 From mhanl at openjdk.org Thu Aug 11 20:55:06 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Aug 2022 20:55:06 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Wed, 10 Aug 2022 18:54:47 GMT, Andy Goryachev wrote: >> @kevinrushforth We can consider EPSILON with value of `.0000001`. This value is already used in the same method for another bounds checking. Below is the part of the code where it is used.. >> >> // Check for zero. This happens when the distribution of the delta >> // finishes early due to a series of "fixed" entries at the end. >> // In this case, lowerBound == upperBound, for all subsequent terms. >> double newSize; >> if (Math.abs(totalLowerBound - totalUpperBound) < .0000001) { >> newSize = lowerBound; >> } else { >> double f = (target - totalLowerBound) / (totalUpperBound - totalLowerBound); >> newSize = Math.round(lowerBound + f * (upperBound - lowerBound)); >> } > > I am also for declaring a constant > > > private static final double EPSILON = .0000001; > > > and using it in on lines 226 and 251. Just a question out of curiosity, is there some kind of recommended value for epsilon? I remember we also have very small epsilon in `Region` for snapping. ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Thu Aug 11 22:01:09 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 22:01:09 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Thu, 11 Aug 2022 20:51:50 GMT, Marius Hanl wrote: >> I am also for declaring a constant >> >> >> private static final double EPSILON = .0000001; >> >> >> and using it in on lines 226 and 251. > > Just a question out of curiosity, is there some kind of recommended value for epsilon? > I remember we also have very small epsilon in `Region` for snapping. This is a *good* question. In this case, we are summing column widths, so we can estimate the worst case scenario by simply adding max errors accumulated after each addition: sum(N * 2 * ? * |w|) where N = number of columns ? = upper bound for rounding error, or epsilon which is about 1e-16 [0] w = column width So, plugging a 100 columns of 200 px wide we get something to the order of 1e-12 .. 1e-11. On a side note, we could have used Unicode here private static final double ? = .0000001; [0] https://en.wikipedia.org/wiki/Machine_epsilon [1] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html ------------- PR: https://git.openjdk.org/jfx/pull/848 From kcr at openjdk.org Thu Aug 11 22:16:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 22:16:39 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Thu, 11 Aug 2022 21:56:44 GMT, Andy Goryachev wrote: > On a side note, we could have used Unicode here > > private static final double ? = .0000001; But let's not. ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Thu Aug 11 22:16:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 22:16:39 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v2] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Thu, 11 Aug 2022 22:09:10 GMT, Kevin Rushforth wrote: >> This is a *good* question. >> In this case, we are summing column widths, so we can estimate the worst case scenario by simply adding max errors accumulated after each addition: >> >> sum(N * 2 * ? * |w|) >> >> where >> N = number of columns >> ? = upper bound for rounding error, or epsilon which is about 1e-16 [0] >> w = column width >> >> So, plugging a 100 columns of 200 px wide we get something to the order of 1e-12 .. 1e-11. >> >> On a side note, we could have used Unicode here >> >> private static final double ? = .0000001; >> >> >> [0] https://en.wikipedia.org/wiki/Machine_epsilon >> [1] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html > >> On a side note, we could have used Unicode here >> >> private static final double ? = .0000001; > > But let's not. you are right, we should not use non-ascii identifiers. it was a joke, sorry. ------------- PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Thu Aug 11 22:19:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Aug 2022 22:19:39 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: Message-ID: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. 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 13 additional commits since the last revision: - 8290844: review comments - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8290844: javadoc - Merge remote-tracking branch 'origin/master' into 8290844.skin.install - 8289397: added space - 8290844: skin.install - 8290844: whitespace - 8290844: validate input - 8290844: illegal argument exception - 8290844: illegal argument exception - ... and 3 more: https://git.openjdk.org/jfx/compare/bcd10d1b...647ecd6c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/cfa99760..647ecd6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=01-02 Stats: 447938 lines in 7521 files changed: 301334 ins; 103537 del; 43067 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Aug 11 23:20:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 23:20:39 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Thu, 11 Aug 2022 22:19:39 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > 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 13 additional commits since the last revision: > > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8289397: added space > - 8290844: skin.install > - 8290844: whitespace > - 8290844: validate input > - 8290844: illegal argument exception > - 8290844: illegal argument exception > - ... and 3 more: https://git.openjdk.org/jfx/compare/9063b6c9...647ecd6c I left a few comments / questions / suggestions on the docs. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 245: > 243: if (skin != null) { > 244: if (skin.getSkinnable() != Control.this) { > 245: throw new IllegalArgumentException("There must be 1:1 relationship between Skin and Skinnable"); I wonder an error message like "Skin was not created for this Skinnable" or "Skin does not correspond to this Skinnable" would be clearer? For the implementation, you should also unbind, if needed, before throwing the exception (we really should have made this a read-only property so it couldn't be bound, since a Skin is a "use once" object). if (isBound()) { unbind(); } modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 36: > 34: *

> 35: * A Skin implementation should generally avoid modifying its control outside of > 36: * {@link #install()} method. The recommended life cycle of a Skin implementation The life-cycle is what the Control (Skinnable) does regardless of the implementation of the Skin, so I would drop the word "recommended" (the recommendation for the Skin implementation is the previous sentence to avoid modifying the control outside the install method). modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > 76: /** > 77: * Called by {@link Skinnable#setSkin(Skin)} on a pristine control, or after the > 78: * previous skin has been uninstalled via its {@link #dispose()} method. Suggestion: You might be able to simplify this a bit by saying: "Called by {@link Skinnable#setSkin(Skin)}, after the previous skin, if any, has been uninstalled." I don't have a strong opinion on this. modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 80: > 78: * previous skin has been uninstalled via its {@link #dispose()} method. > 79: * This method allows a Skin to register listeners, add child nodes, set > 80: * required properties and/or event handlers. It might be good to add a sentence at the end saying: "The default implementation of this method does nothing". modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 43: > 41: * It listens and responds to changes in state in a {@code Skinnable}. > 42: *

> 43: * There is typically a one-to-one relationship between a {@code Skinnable} and its When isn't it a 1-to-1 relationship? Is it just for the special case of `PopupControl`? modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 59: > 57: * {@code Skin}, this method may check the return value of > 58: * {@link Skin#getSkinnable()} against this Skinnable, > 59: * and may throw an {@code IllegalArgumentException} if it is not the same. Since most implementations of `Skinnable` will do this check, we probably want to strengthen this statement. I like the language you added to the `@throws` tag, which says that it will throw an exception if the Skin does not "correspond to" this Skinnable. Is there a way to work this in, by defining what we mean to "correspond to"? modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 64: > 62: * @throws IllegalArgumentException if {@code Skin} does not correspond to this {@code Skinnable} > 63: */ > 64: public void setSkin(Skin value); Generally docs for properties should go on just the property and not the setter or getter. The docs will be copied and cross linked by the javadoc tool. Can you try that, and generate a javadoc, and see if that holds in this case (we don't have many cases where a property is in an interface). ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Aug 11 23:27:47 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 23:27:47 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: Message-ID: <_7Nvguz3QTYy64Vn9PmRucog4eTDK2uvhJTc-PADtLs=.bb4e25df-b782-4518-b865-9b6b09770716@github.com> On Thu, 11 Aug 2022 13:17:43 GMT, Jeanette Winzenburg wrote: > > The new API is backwards compatible with the existing code, the customer-developed skins can remain unchanged (thanks to default implementation). > > hmm ... probably I'm missing something but I don't see how that would be the case for the subset of core skins that have to be refactored and moved their installation into the install() method. Typically, custom skins do their own stuff on top of what super did at the end of the constructor, assuming that everything is fully installed. Depending on what exactly will be moved into install, their behavior will be broken after the change. Maybe. As you say, it depends on what is moved from the constructor into `install()`. > Examples: [snip] How common do you think this sort of thing is in practice? This seems like a case of the subclass "peeking" at the implementation of its superclass, and then coding in such a way as to rely on that implementation. This does suggest that we ought to take a cautious approach, only overriding and implementing `Skin::install` for those built-in controls where it is needed to fix bugs. It also suggests that this possible incompatibility ought to be highlighted in a release note (in addition to updating the CSR, which Andy has indicated that he will do). ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Thu Aug 11 23:46:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 23:46:31 GMT Subject: RFR: 8291908: VirtualFlow creates unneeded empty cells In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 14:30:40 GMT, Johan Vos wrote: > When calculating the viewportOffset, we now already take into account that cells will have to shift. > > This prevents the creation of temporary empty cells in the layout phase. > One test needed to be fixed, since the number of invocations to updateItem() was hardcoded (and it > is decreased by this commit). This fix looks good. I confirmed that the new test fails without the fix and passes with the fix. I also confirmed that this also fixes [JDK-8291467](https://bugs.openjdk.org/browse/JDK-8291467). @johanvos As noted in JBS, this PR also fixes [JDK-8291467](https://bugs.openjdk.org/browse/JDK-8291467). Can you add that issue to this PR? Alternatively, you could change [JDK-8291908](https://bugs.openjdk.org/browse/JDK-8291908) to a bug and close JDK-8291467 as a duplicate. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/863 From duke at openjdk.org Thu Aug 11 23:51:16 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Thu, 11 Aug 2022 23:51:16 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v3] In-Reply-To: References: Message-ID: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/b2e1c2bc..03f484f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From kcr at openjdk.org Thu Aug 11 23:56:27 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Aug 2022 23:56:27 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v3] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 23:51:16 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. >> >> **Cause:** >> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. >> >> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). >> >> To confirm this behaviour, please find the below example that showcases the issue: >> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. >> >> >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.beans.property.StringProperty; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.geometry.Insets; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.control.*; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class ConstrainedResizePolicyIssueDemo extends Application { >> @Override >> public void start(Stage primaryStage) throws Exception { >> TableColumn fnCol = new TableColumn<>("First Name"); >> fnCol.setMinWidth(100); >> fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); >> >> TableColumn priceCol = new TableColumn<>("Price"); >> priceCol.setMinWidth(100); >> priceCol.setMaxWidth(150); >> priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); >> >> TableColumn totalCol = new TableColumn<>("Total"); >> totalCol.setMinWidth(100); >> totalCol.setMaxWidth(150); >> totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); >> >> ObservableList persons = FXCollections.observableArrayList(); >> persons.add(new Person("Harry", "200.00", "210.00")); >> persons.add(new Person("Jacob", "260.00", "260.00")); >> >> TableView tableView = new TableView<>(); >> tableView.getColumns().addAll(fnCol, priceCol, totalCol); >> tableView.setItems(persons); >> tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); >> tableView.setMinWidth(500); >> tableView.maxWidthProperty().bind(tableView.minWidthProperty()); >> >> Button button1 = new Button("Reduce 1px"); >> button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); >> Button button2 = new Button("Reduce 10px"); >> button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); >> Button button3 = new Button("Reset"); >> button3.setOnAction(e -> tableView.setMinWidth(500)); >> Button button4 = new Button("Increase 1px"); >> button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); >> Button button5 = new Button("Increase 10px"); >> button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); >> >> HBox row = new HBox(button1, button2, button3, button4, button5); >> row.setSpacing(10); >> TextArea output = new TextArea(); >> >> addWidthListeners(tableView, output); >> VBox root = new VBox(row, new Group(tableView), output); >> root.setSpacing(10); >> root.setPadding(new Insets(10)); >> >> Scene scene = new Scene(root); >> primaryStage.setScene(scene); >> primaryStage.setTitle("Constrained Resize Policy Issue TableView"); >> primaryStage.show(); >> } >> >> private void addWidthListeners(TableView tableView, TextArea output) { >> tableView.widthProperty().addListener((obs, old, val) -> { >> String str = "Table width changed :: " + val + "\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> tableView.getColumns().forEach(column -> { >> column.widthProperty().addListener((obs, old, width) -> { >> String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> }); >> } >> >> class Person { >> private StringProperty firstName = new SimpleStringProperty(); >> private StringProperty price = new SimpleStringProperty(); >> private StringProperty total = new SimpleStringProperty(); >> >> public Person(String fn, String price, String total) { >> setFirstName(fn); >> setPrice(price); >> setTotal(total); >> } >> >> public StringProperty firstNameProperty() { >> return firstName; >> } >> >> public void setFirstName(String firstName) { >> this.firstName.set(firstName); >> } >> >> public StringProperty priceProperty() { >> return price; >> } >> >> public void setPrice(String price) { >> this.price.set(price); >> } >> >> public StringProperty totalProperty() { >> return total; >> } >> >> public void setTotal(String total) { >> this.total.set(total); >> } >> } >> } >> >> >> **Fix:** >> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. >> >> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 >> >> `if (Math.abs(colWidth - tableWidth) > 1) {` >> >> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright year. modules/javafx.controls/src/main/java/javafx/scene/control/TableUtil.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2016, 2022 Oracle and/or its affiliates. All rights reserved. Not quite. There should be at most two years, and there must be a comma after each one. So: * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jfx/pull/848 From duke at openjdk.org Fri Aug 12 00:52:29 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Fri, 12 Aug 2022 00:52:29 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v4] In-Reply-To: References: Message-ID: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/03f484f5..330e0368 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From duke at openjdk.org Fri Aug 12 00:57:14 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Fri, 12 Aug 2022 00:57:14 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v5] In-Reply-To: References: Message-ID: <8-cmqM9aNt4QXxvtjAtRl39Efvnah_IFKLt2uvEBd_4=.52e1d428-9cea-4a71-8d65-9ff45d081aca@github.com> > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/330e0368..37c78a4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From duke at openjdk.org Fri Aug 12 00:57:16 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Fri, 12 Aug 2022 00:57:16 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v3] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 23:54:23 GMT, Kevin Rushforth wrote: >> Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright year. > > modules/javafx.controls/src/main/java/javafx/scene/control/TableUtil.java line 2: > >> 1: /* >> 2: * Copyright (c) 2012, 2016, 2022 Oracle and/or its affiliates. All rights reserved. > > Not quite. There should be at most two years, and there must be a comma after each one. So: > > > * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved. @kevinrushforth Sorry that I am not aware of this standard. Is it that the two years is some thing like the first is the initial modification year and the second is the latest modification year? ------------- PR: https://git.openjdk.org/jfx/pull/848 From mhanl at openjdk.org Fri Aug 12 05:06:27 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Aug 2022 05:06:27 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Thu, 11 Aug 2022 23:14:39 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: >> >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8289397: added space >> - 8290844: skin.install >> - 8290844: whitespace >> - 8290844: validate input >> - 8290844: illegal argument exception >> - 8290844: illegal argument exception >> - ... and 3 more: https://git.openjdk.org/jfx/compare/e1057077...647ecd6c > > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 43: > >> 41: * It listens and responds to changes in state in a {@code Skinnable}. >> 42: *

>> 43: * There is typically a one-to-one relationship between a {@code Skinnable} and its > > When isn't it a 1-to-1 relationship? Is it just for the special case of `PopupControl`? Yes. All Skins derived by SkinBase must have a 1:1 relationship, while `getSkinnable()` for `PopupControl` is not really used. >From my other comment: It is a bit weird as Popups are not using the `getSkinnable` method it looks like. And also the `getSkinnable` method javadoc states: Gets the Skinnable to which this Skin is assigned. which is not true for the ComboBox Popup (as it sets the ComboBox as the skinnable) - while it makes sense that the ComboBox is set as styleable parent. And: So it is even more weird: `getSkinnable()` is always called in Control skins, `getNode()` is only called in `Control.getSkinNode()`, PaginationSkin and TableColumnHeader (so not very much). `getNode()` is always called for Popups (no `getSkinnable()` is called). The only exception is the internal class `InputFieldSkin`, where the node is an 'inner TextField' and the skinnable the control where it is installed on. ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Fri Aug 12 11:06:30 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 12 Aug 2022 11:06:30 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Thu, 11 Aug 2022 16:14:08 GMT, Andy Goryachev wrote: > > The tests were added to both TableViewSelectionModelImplTest and TreeTableViewSelectionModelImplTest. hmm .. in TreeTableViewSelectionModelImplTest, I don't see any of the testRowSelectionAfterSelectAndHideLastColumnXX nor testSelectRowWhenInSingleCellSelectionModeIsSelected, what am I missing? ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Fri Aug 12 11:51:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Aug 2022 11:51:03 GMT Subject: RFR: 8291630: Update attribution in webkit.md file Message-ID: We need to update the attribution in `webkit.md` to reflect the latest WebKit sources and a few missed items. ------------- Commit messages: - 8291630: Update attribution in webkit.md file Changes: https://git.openjdk.org/jfx/pull/868/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=868&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291630 Stats: 1152 lines in 1 file changed: 931 ins; 189 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/868.diff Fetch: git fetch https://git.openjdk.org/jfx pull/868/head:pull/868 PR: https://git.openjdk.org/jfx/pull/868 From kcr at openjdk.org Fri Aug 12 12:48:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Aug 2022 12:48:24 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v3] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 00:52:58 GMT, Sai Pradeep Dandem wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableUtil.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2012, 2016, 2022 Oracle and/or its affiliates. All rights reserved. >> >> Not quite. There should be at most two years, and there must be a comma after each one. So: >> >> >> * Copyright (c) 2012, 2022, Oracle and/or its affiliates. All rights reserved. > > @kevinrushforth Sorry that I am not aware of this standard. Is it that the two years is some thing like the first is the initial modification year and the second is the latest modification year? Yes, exactly. ------------- PR: https://git.openjdk.org/jfx/pull/848 From arapte at openjdk.org Fri Aug 12 12:48:27 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 Aug 2022 12:48:27 GMT Subject: RFR: 8291630: Update attribution in webkit.md file In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 11:44:49 GMT, Kevin Rushforth wrote: > We need to update the attribution in `webkit.md` to reflect the latest WebKit sources and a few missed items. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/868 From kcr at openjdk.org Fri Aug 12 12:54:52 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Aug 2022 12:54:52 GMT Subject: Integrated: 8291630: Update attribution in webkit.md file In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 11:44:49 GMT, Kevin Rushforth wrote: > We need to update the attribution in `webkit.md` to reflect the latest WebKit sources and a few missed items. This pull request has now been integrated. Changeset: 33534cb9 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/33534cb9e0524e91ed717b22fab667b284c52252 Stats: 1152 lines in 1 file changed: 931 ins; 189 del; 32 mod 8291630: Update attribution in webkit.md file Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/868 From fastegal at swingempire.de Fri Aug 12 14:13:09 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 12 Aug 2022 16:13:09 +0200 Subject: Proposal: Add Skin.install() method In-Reply-To: References: <20220721180356.Horde.Bvujqf0R8GWrWM-r9JGyZ9Y@webmail.df.eu> Message-ID: <20220812161309.Horde.el8Vf35K2G85hFZutfUzBh4@webmail.df.eu> Zitat von Andy Goryachev : > Dear Jeanette: > > Thank you for responding! > > You are right - some of the issues in > JDK-8241364 ? Cleanup > skin implementations to allow switching might be caused by other > factors. Still, from a pure design perspective, the fact that we > are altering control while the new skin is being constructed is not > right. > > I suspect there is a number of other Skins where we might have > memory leaks and other issues. For example, MenuButtonSkinBase:96 > tries to add an event handler based on the value of onMousePressed > property. Please correct me if I am wrong - should this event > handler also be removed in dispose()? Same in > MenuButtonSkinBase:105 (line numbers provided are for the latest > master branch). Same in MenuButtonSkin:108 exactly :) > > We may need to go through all the skins looking for places like this > as part of JDK-8241364 > ? Cleanup skin implementations. Well, we do - the cleanup is under way :) The umbrella issue is for keeping track. Have a look at SkinMemoryLeakTest: the 15 skins that are excluded from the test are not yet handled (most don't even have an issue yet). -- Jeanette > > Thank you so much for your comments! > > -andy > > > > From: openjfx-dev on behalf of > Jeanette Winzenburg > Date: Thursday, 2022/07/21 at 09:04 > To: openjfx-dev at openjdk.org > Subject: Re: Proposal: Add Skin.install() method > > Zitat von Andy Goryachev : > > Hi Andy, > > good idea to move our discussion from the issues to the mailling - > it's both easier and reaches a broader audience :) > > Will answer in about a week or so, for now just stumbled across > >> We can see the damage caused by looking at >> JDK-8241364 ? Cleanup >> skin implementations to allow switching, which refers a number of >> bugs: > > Hmm .. might be me, but looks like you are implying that with the > proposal in place (and used throughout our skins) those issues > wouldn't have existed? If that's not the case, could you please > clarify what you mean?. On the other hand, if yes, I disagree: the > majority of the issues (in particular those already fixed) are about > an incorrect/incomplete implementation of dispose - that's unrelated > to enhancing/cleaning up the install process. A subset (of the > unfixed) is indeed due to the parallel existence of two skins pointing > to the same control (and modifying its properties) > > Cheers, Jeanette > > >> Hi, >> >> I'd like to propose an API change in Skin interface (details below). >> Your feedback will be greatly appreciated! >> >> Thank you, >> -andy >> >> >> >> >> >> Summary >> ------- >> >> Introduce a new Skin.install() method with an empty default >> implementation. Modify Control.setSkin(Skin) implementation to >> invoke install() on the new skin after the old skin has been removed >> with dispose(). >> >> >> Problem >> ------- >> >> Presently, switching skins is a two-step process: first, a new skin >> is constructed against the target Control instance, and is attached >> (i.s. listeners added, child nodes added) to that instance in the >> constructor. Then, Control.setSkin() is invoked with a new skin - >> and inside, the old skin is detached via its dispose() method. >> >> This creates two problems: >> >> 1. if the new skin instance is discarded before setSkin(), it >> remains attached, leaving the control in a weird state with two >> skins attached, causing memory leaks and performance degradation. >> >> 2. if, in addition to adding listeners and child nodes, the skin >> sets a property, such as an event listener, or a handler, it >> overwrites the current value irreversibly. As a result, either the >> old skin would not be able to cleanly remove itself, or the new skin >> would not be able to set the new values, as it does not know whether >> it should overwrite or keep a handler installed earlier (possibly by >> design). Unsurprisingly, this also might cause memory leaks. >> >> We can see the damage caused by looking at >> JDK-8241364 ? Cleanup >> skin implementations to allow switching, which refers a number of >> bugs: >> >> JDK-8245145 Spinner: throws IllegalArgumentException when replacing skin >> JDK-8245303 InputMap: memory leak due to incomplete cleanup on >> remove mapping >> JDK-8268877 TextInputControlSkin: incorrect inputMethod event >> handler after switching skin >> JDK-8236840 Memory leak when switching ButtonSkin >> JDK-8240506 TextFieldSkin/Behavior: misbehavior on switching skin >> JDK-8242621 TabPane: Memory leak when switching skin >> JDK-8244657 ChoiceBox/ToolBarSkin: misbehavior on switching skin >> JDK-8245282 Button/Combo Behavior: memory leak on dispose >> JDK-8246195 ListViewSkin/Behavior: misbehavior on switching skin >> JDK-8246202 ChoiceBoxSkin: misbehavior on switching skin, part 2 >> JDK-8246745 ListCell/Skin: misbehavior on switching skin >> JDK-8247576 Labeled/SkinBase: misbehavior on switching skin >> JDK-8253634 TreeCell/Skin: misbehavior on switching skin >> JDK-8256821 TreeViewSkin/Behavior: misbehavior on switching skin >> JDK-8269081 Tree/ListViewSkin: must remove flow on dispose >> JDK-8273071 SeparatorSkin: must remove child on dispose >> JDK-8274061 Tree-/TableRowSkin: misbehavior on switching skin >> JDK-8244419 TextAreaSkin: throws UnsupportedOperation on dispose >> JDK-8244531 Tests: add support to identify recurring issues with >> controls et al >> >> >> Solution >> -------- >> >> This problem does not exist in e.g. Swing because the steps of >> instantiation, uninstalling the old ComponentUI ("skin"), and >> installing a new skin are cleanly separated. ComponentUI >> constructor does not alter the component itself, >> ComponentUI.uninstallUI(JComponent) cleanly removes the old skin, >> ComponentUI.installUI(JComponent) installs the new skin. We should >> follow the same model in javafx. >> >> Specifically, I'd like to propose the following changes: >> >> 1. Add Skin.install() with a default no-op implementation. >> 2. Clarify skin creation-attachment-detachment sequence in Skin and >> Skin.install() javadoc >> 3. Modify Control.setSkin(Skin) method (== invalidate listener in >> skin property) to call oldSkin.dispose() followed by newSkin.install() >> 4. Many existing skins that do not set properties in the >> corresponding control may remain unchanged. The skins that do, such >> as TextInputControlSkin (JDK-8268877), must be refactored to utilize >> the new install() method. I think the refactoring would simply move >> all the code that accesses its control instance away from the >> constructor to install(). >> >> >> Impact Analysis >> ------------- >> >> The changes should be fairly trivial. Only a subset of skins needs >> to be refactored, and the refactoring itself is trivial. >> >> The new API is backwards compatible with the existing code, the >> customer-developed skins can remain unchanged (thanks to default >> implementation). In case where customers could benefit from the new >> API, the change is trivial. >> >> The change will require CSR as it modifies a public API. From angorya at openjdk.org Fri Aug 12 14:21:30 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 14:21:30 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v5] In-Reply-To: <8-cmqM9aNt4QXxvtjAtRl39Efvnah_IFKLt2uvEBd_4=.52e1d428-9cea-4a71-8d65-9ff45d081aca@github.com> References: <8-cmqM9aNt4QXxvtjAtRl39Efvnah_IFKLt2uvEBd_4=.52e1d428-9cea-4a71-8d65-9ff45d081aca@github.com> Message-ID: On Fri, 12 Aug 2022 00:57:14 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. >> >> **Cause:** >> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. >> >> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). >> >> To confirm this behaviour, please find the below example that showcases the issue: >> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. >> >> >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.beans.property.StringProperty; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.geometry.Insets; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.control.*; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class ConstrainedResizePolicyIssueDemo extends Application { >> @Override >> public void start(Stage primaryStage) throws Exception { >> TableColumn fnCol = new TableColumn<>("First Name"); >> fnCol.setMinWidth(100); >> fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); >> >> TableColumn priceCol = new TableColumn<>("Price"); >> priceCol.setMinWidth(100); >> priceCol.setMaxWidth(150); >> priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); >> >> TableColumn totalCol = new TableColumn<>("Total"); >> totalCol.setMinWidth(100); >> totalCol.setMaxWidth(150); >> totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); >> >> ObservableList persons = FXCollections.observableArrayList(); >> persons.add(new Person("Harry", "200.00", "210.00")); >> persons.add(new Person("Jacob", "260.00", "260.00")); >> >> TableView tableView = new TableView<>(); >> tableView.getColumns().addAll(fnCol, priceCol, totalCol); >> tableView.setItems(persons); >> tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); >> tableView.setMinWidth(500); >> tableView.maxWidthProperty().bind(tableView.minWidthProperty()); >> >> Button button1 = new Button("Reduce 1px"); >> button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); >> Button button2 = new Button("Reduce 10px"); >> button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); >> Button button3 = new Button("Reset"); >> button3.setOnAction(e -> tableView.setMinWidth(500)); >> Button button4 = new Button("Increase 1px"); >> button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); >> Button button5 = new Button("Increase 10px"); >> button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); >> >> HBox row = new HBox(button1, button2, button3, button4, button5); >> row.setSpacing(10); >> TextArea output = new TextArea(); >> >> addWidthListeners(tableView, output); >> VBox root = new VBox(row, new Group(tableView), output); >> root.setSpacing(10); >> root.setPadding(new Insets(10)); >> >> Scene scene = new Scene(root); >> primaryStage.setScene(scene); >> primaryStage.setTitle("Constrained Resize Policy Issue TableView"); >> primaryStage.show(); >> } >> >> private void addWidthListeners(TableView tableView, TextArea output) { >> tableView.widthProperty().addListener((obs, old, val) -> { >> String str = "Table width changed :: " + val + "\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> tableView.getColumns().forEach(column -> { >> column.widthProperty().addListener((obs, old, width) -> { >> String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> }); >> } >> >> class Person { >> private StringProperty firstName = new SimpleStringProperty(); >> private StringProperty price = new SimpleStringProperty(); >> private StringProperty total = new SimpleStringProperty(); >> >> public Person(String fn, String price, String total) { >> setFirstName(fn); >> setPrice(price); >> setTotal(total); >> } >> >> public StringProperty firstNameProperty() { >> return firstName; >> } >> >> public void setFirstName(String firstName) { >> this.firstName.set(firstName); >> } >> >> public StringProperty priceProperty() { >> return price; >> } >> >> public void setPrice(String price) { >> this.price.set(price); >> } >> >> public StringProperty totalProperty() { >> return total; >> } >> >> public void setTotal(String total) { >> this.total.set(total); >> } >> } >> } >> >> >> **Fix:** >> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. >> >> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 >> >> `if (Math.abs(colWidth - tableWidth) > 1) {` >> >> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright review comments Changes requested by angorya (Author). modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5798: > 5796: assertEquals(column, anchor.getTableColumn()); > 5797: } > 5798: please update the copyright year in TableViewTest as well, since it's been modified: * Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jfx/pull/848 From fastegal at openjdk.org Fri Aug 12 14:48:27 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 12 Aug 2022 14:48:27 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: <_7Nvguz3QTYy64Vn9PmRucog4eTDK2uvhJTc-PADtLs=.bb4e25df-b782-4518-b865-9b6b09770716@github.com> References: <_7Nvguz3QTYy64Vn9PmRucog4eTDK2uvhJTc-PADtLs=.bb4e25df-b782-4518-b865-9b6b09770716@github.com> Message-ID: On Thu, 11 Aug 2022 23:24:11 GMT, Kevin Rushforth wrote: > > How common do you think this sort of thing is in practice? can't do more than guessing (knowing that companies I worked for had done so before I got my hands onto their code) - so would say it's common enough to cause .. well, some distress ;) > This does suggest that we ought to take a cautious approach, only overriding and implementing `Skin::install` for those built-in controls where it is needed to fix bugs. It also suggests that this possible incompatibility ought to be highlighted in a release note (in addition to updating the CSR, which Andy has indicated that he will do). Agreed. The part open to discussion is "needed to fix bugs". So far, we have identified (Andy, correct me if I'm wrong - you are nearer to the current state than I am :) only one [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877) that can't be handled without some kind of api change (which in that particular case might be a marker interface like UIResource in Swing to allow skins to differentiate between control- and skin installed handlers :). There probably are more in skins that are not yet cleaned. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 14:57:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 14:57:32 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: <_7Nvguz3QTYy64Vn9PmRucog4eTDK2uvhJTc-PADtLs=.bb4e25df-b782-4518-b865-9b6b09770716@github.com> Message-ID: On Fri, 12 Aug 2022 14:45:13 GMT, Jeanette Winzenburg wrote: > only one [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877) that can't be handled without some kind of api change There might be more, for example MenuButtonSkinBase:96, MenuButtonSkinBase:105, MenuButtonSkin:108. I don't think we have a bug filed for those (yet) - I was planning to go over core skins after we get this PR integrated. Any time a singleton is being set, or conditionally set, we have this problem. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 15:04:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 15:04:22 GMT Subject: RFR: 8290844: Add Skin.install() method [v2] In-Reply-To: References: <_7Nvguz3QTYy64Vn9PmRucog4eTDK2uvhJTc-PADtLs=.bb4e25df-b782-4518-b865-9b6b09770716@github.com> Message-ID: On Fri, 12 Aug 2022 14:45:13 GMT, Jeanette Winzenburg wrote: > only overriding and implementing `Skin::install` for those built-in controls where it is needed to fix bugs. It also suggests that this possible incompatibility ought to be highlighted in a release note (in addition to updating the CSR, which Andy has indicated that he will do). Umbrella ticket JDK-8241364 provides a list which might be incomplete (I think there are issues in MenuBaseSkin/Base as well). ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 15:12:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 15:12:33 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> On Fri, 12 Aug 2022 11:02:35 GMT, Jeanette Winzenburg wrote: > hmm .. in TreeTableViewSelectionModelImplTest, I don't see any of the testRowSelectionAfterSelectAndHideLastColumnXX nor testSelectRowWhenInSingleCellSelectionModeIsSelected, what am I missing? you are right... I am so sorry. missed this one while cherry picking from another branch. will fix it soon. would it be possible to review https://github.com/openjdk/jfx/pull/858 so there is no need to cherry pick, please? ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Fri Aug 12 17:03:44 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Fri, 12 Aug 2022 17:03:44 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Thu, 11 Aug 2022 22:19:39 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > 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 13 additional commits since the last revision: > > - 8290844: review comments > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8290844: javadoc > - Merge remote-tracking branch 'origin/master' into 8290844.skin.install > - 8289397: added space > - 8290844: skin.install > - 8290844: whitespace > - 8290844: validate input > - 8290844: illegal argument exception > - 8290844: illegal argument exception > - ... and 3 more: https://git.openjdk.org/jfx/compare/7839c8cd...647ecd6c did a bit of experimenting, trying to eat and keep the cake at the same time :) Or in terms of the new skin api: have a nice new life-cycle without breaking existing skins The idea: - let skin have another new method `supportsInstall` with a default to false - let our concrete skins implement that to test against their exact class - let constructors of concrete skins call install if supportsInstall returns false - custom skins will see the completely installed super if not refactored, or have moved their own installation code into install and overridden supportsInstall to return true A quick PoC is in [my fork off Andy's PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) - obviously very raw :) - for TextFieldSkin, tested in SkinCleanupTest: note the uncommented ignores for [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877) which pass due to Andy's work on install. Directly below those is a test against a custom text skin which expects super to be fully installed at the end of the constructor. Have a nice weekend, everybody, whenever it begins in your timezone! ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 17:21:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 17:21:24 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v11] In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8235491: added tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/839/files - new: https://git.openjdk.org/jfx/pull/839/files/35247bc6..9ad93526 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=839&range=09-10 Stats: 112 lines in 2 files changed: 99 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/839.diff Fetch: git fetch https://git.openjdk.org/jfx pull/839/head:pull/839 PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Fri Aug 12 17:36:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 17:36:36 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Thu, 11 Aug 2022 22:47:28 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 13 additional commits since the last revision: >> >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8289397: added space >> - 8290844: skin.install >> - 8290844: whitespace >> - 8290844: validate input >> - 8290844: illegal argument exception >> - 8290844: illegal argument exception >> - ... and 3 more: https://git.openjdk.org/jfx/compare/45c8c4bc...647ecd6c > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 245: > >> 243: if (skin != null) { >> 244: if (skin.getSkinnable() != Control.this) { >> 245: throw new IllegalArgumentException("There must be 1:1 relationship between Skin and Skinnable"); > > I wonder an error message like "Skin was not created for this Skinnable" or "Skin does not correspond to this Skinnable" would be clearer? > > For the implementation, you should also unbind, if needed, before throwing the exception (we really should have made this a read-only property so it couldn't be bound, since a Skin is a "use once" object). > > > if (isBound()) { > unbind(); > } Good point! Actually, unbind() is sufficient, as it does the required check. From javadoc: _If the Property is not bound, calling this method has no effect._ Is there another reason to call isBound(), perhaps for clarity? > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 36: > >> 34: *

>> 35: * A Skin implementation should generally avoid modifying its control outside of >> 36: * {@link #install()} method. The recommended life cycle of a Skin implementation > > The life-cycle is what the Control (Skinnable) does regardless of the implementation of the Skin, so I would drop the word "recommended" (the recommendation for the Skin implementation is the previous sentence to avoid modifying the control outside the install method). ok > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 78: > >> 76: /** >> 77: * Called by {@link Skinnable#setSkin(Skin)} on a pristine control, or after the >> 78: * previous skin has been uninstalled via its {@link #dispose()} method. > > Suggestion: You might be able to simplify this a bit by saying: "Called by {@link Skinnable#setSkin(Skin)}, after the previous skin, if any, has been uninstalled." I don't have a strong opinion on this. thank you ------------- PR: https://git.openjdk.org/jfx/pull/845 From kcr at openjdk.org Fri Aug 12 17:53:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Aug 2022 17:53:22 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Fri, 12 Aug 2022 17:30:20 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 245: >> >>> 243: if (skin != null) { >>> 244: if (skin.getSkinnable() != Control.this) { >>> 245: throw new IllegalArgumentException("There must be 1:1 relationship between Skin and Skinnable"); >> >> I wonder an error message like "Skin was not created for this Skinnable" or "Skin does not correspond to this Skinnable" would be clearer? >> >> For the implementation, you should also unbind, if needed, before throwing the exception (we really should have made this a read-only property so it couldn't be bound, since a Skin is a "use once" object). >> >> >> if (isBound()) { >> unbind(); >> } > > Good point! > Actually, unbind() is sufficient, as it does the required check. From javadoc: _If the Property is not bound, calling this method has no effect._ > Is there another reason to call isBound(), perhaps for clarity? Good question. I do see the check in other places where an exception is thrown from invalidated, such as TextField, TextArea, TableColumnHeader. More importantly, those properties also restore their previous value (irrespective of binding), which we might want to consider here. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 17:53:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 17:53:33 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: <4e0CXICdrqox7rR1RzRzitJdpPcNyDmZYbe6C-oGSp0=.94d3b817-2190-4987-966c-8222aad3c4d7@github.com> On Thu, 11 Aug 2022 23:03:49 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 13 additional commits since the last revision: >> >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8289397: added space >> - 8290844: skin.install >> - 8290844: whitespace >> - 8290844: validate input >> - 8290844: illegal argument exception >> - 8290844: illegal argument exception >> - ... and 3 more: https://git.openjdk.org/jfx/compare/1c437875...647ecd6c > > modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 80: > >> 78: * previous skin has been uninstalled via its {@link #dispose()} method. >> 79: * This method allows a Skin to register listeners, add child nodes, set >> 80: * required properties and/or event handlers. > > It might be good to add a sentence at the end saying: "The default implementation of this method does nothing". thank you. > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 59: > >> 57: * {@code Skin}, this method may check the return value of >> 58: * {@link Skin#getSkinnable()} against this Skinnable, >> 59: * and may throw an {@code IllegalArgumentException} if it is not the same. > > Since most implementations of `Skinnable` will do this check, we probably want to strengthen this statement. I like the language you added to the `@throws` tag, which says that it will throw an exception if the Skin does not "correspond to" this Skinnable. Is there a way to work this in, by defining what we mean to "correspond to"? @throws IllegalArgumentException if {@link Skin#getSkinnable()} returns a different {@code Skinnable} is this better? ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 18:00:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 18:00:36 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: On Thu, 11 Aug 2022 23:11:45 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 13 additional commits since the last revision: >> >> - 8290844: review comments >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8290844: javadoc >> - Merge remote-tracking branch 'origin/master' into 8290844.skin.install >> - 8289397: added space >> - 8290844: skin.install >> - 8290844: whitespace >> - 8290844: validate input >> - 8290844: illegal argument exception >> - 8290844: illegal argument exception >> - ... and 3 more: https://git.openjdk.org/jfx/compare/98cafacd...647ecd6c > > modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 64: > >> 62: * @throws IllegalArgumentException if {@code Skin} does not correspond to this {@code Skinnable} >> 63: */ >> 64: public void setSkin(Skin value); > > Generally docs for properties should go on just the property and not the setter or getter. The docs will be copied and cross linked by the javadoc tool. Can you try that, and generate a javadoc, and see if that holds in this case (we don't have many cases where a property is in an interface). So javadoc tool ignores the interface, resulting in Control.setSkin(skin) method inheriting the property's description. Curiously, eclipse does show the interface's version, which I think helps more than having three identical descriptions for the property, its getter and setter. What would you recommend we do here? ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 18:04:23 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 18:04:23 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: <_kRVPX-6CweZOHG-Uz7le1KgEZC8agFA2lnmsCn4mi8=.557f8222-2612-4305-8352-d55ff317a4a3@github.com> On Fri, 12 Aug 2022 17:51:20 GMT, Kevin Rushforth wrote: >> Good point! >> Actually, unbind() is sufficient, as it does the required check. From javadoc: _If the Property is not bound, calling this method has no effect._ >> Is there another reason to call isBound(), perhaps for clarity? > > Good question. I do see the check in other places where an exception is thrown from invalidated, such as TextField, TextArea, TableColumnHeader. More importantly, those properties also restore their previous value (irrespective of binding), which we might want to consider here. will unbind and restore the old value. thanks! ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 18:15:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 18:15:37 GMT Subject: RFR: 8290844: Add Skin.install() method [v4] In-Reply-To: References: Message-ID: > - added Skin.install() > - javadoc changes for Skinnable.setSkin(Skin) > > no code changes for Skinnable.setSkin(Skin) yet. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290844: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/845/files - new: https://git.openjdk.org/jfx/pull/845/files/647ecd6c..108efb89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=845&range=02-03 Stats: 9 lines in 3 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/845.diff Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845 PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Fri Aug 12 18:44:17 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 18:44:17 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> Message-ID: <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> On Fri, 12 Aug 2022 17:00:07 GMT, Jeanette Winzenburg wrote: > A quick PoC is in [my fork off Andy's PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) @kleopatra : Thank you so much for your effort to research the alternatives. The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. The others, which only add listeners and children nodes, can remain unchanged. ------------- PR: https://git.openjdk.org/jfx/pull/845 From nlisker at gmail.com Fri Aug 12 21:12:27 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 13 Aug 2022 00:12:27 +0300 Subject: Missing 'vcruntime.h' Message-ID: Hi, I have just run gradle clean and gradle build, and I'm getting an error: C:/Program Files (x86)/Windows Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error C1083: Cannot open include file: 'vcruntime.h': No such file or directory Indeed, vcruntime.h is not in that folder. Do I need to update something, like VS? - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Aug 12 22:30:28 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Aug 2022 15:30:28 -0700 Subject: Missing 'vcruntime.h' In-Reply-To: References: Message-ID: vcruntime.h is included with the Visual Studio compiler and has been for ages. I can't think of anything recently that would have changed relative to that. -- Kevin On 8/12/2022 2:12 PM, Nir Lisker wrote: > Hi, > > I have just run gradle clean and gradle build, and I'm getting an error: > > C:/Program Files (x86)/Windows > Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error C1083: > Cannot open include file: 'vcruntime.h': No such file or directory > > Indeed, vcruntime.h is not in that folder. Do I need to update > something, like VS? > > - Nir From nlisker at gmail.com Fri Aug 12 23:06:48 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 13 Aug 2022 02:06:48 +0300 Subject: Missing 'vcruntime.h' In-Reply-To: References: Message-ID: I see the file under \VC\Tools\MSVC\14.33.31629\include\vcruntime.h of the VS installation. The file calling it is under C:/Program Files (x86)/Windows Kits/10/include/10.0.17763.0/ucrt\corecrt.h. Is it supposed to look for some env variable to find it? I have MSVC_VER, VSINSTALLDIR and VS150COMNTOOLS all set. I don't remember needing anything else. On Sat, Aug 13, 2022 at 1:30 AM Kevin Rushforth wrote: > vcruntime.h is included with the Visual Studio compiler and has been for > ages. I can't think of anything recently that would have changed > relative to that. > > -- Kevin > > > On 8/12/2022 2:12 PM, Nir Lisker wrote: > > Hi, > > > > I have just run gradle clean and gradle build, and I'm getting an error: > > > > C:/Program Files (x86)/Windows > > Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error C1083: > > Cannot open include file: 'vcruntime.h': No such file or directory > > > > Indeed, vcruntime.h is not in that folder. Do I need to update > > something, like VS? > > > > - Nir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Aug 12 23:23:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Aug 2022 23:23:46 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v9] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: removed empty src sir ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/791552c0..2a9fb3b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From nlisker at gmail.com Sat Aug 13 03:06:06 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 13 Aug 2022 06:06:06 +0300 Subject: Missing 'vcruntime.h' In-Reply-To: References: Message-ID: Kevin, can you update the windows_tools.properties file for the build page on the wiki [1] for VS 2022 since I see that we updated to use that version? [1] https://wiki.openjdk.org/pages/viewpage.action?pageId=66650334 On Sat, Aug 13, 2022 at 2:06 AM Nir Lisker wrote: > I see the file under \VC\Tools\MSVC\14.33.31629\include\vcruntime.h of the > VS installation. The file calling it is under C:/Program Files > (x86)/Windows Kits/10/include/10.0.17763.0/ucrt\corecrt.h. > Is it supposed to look for some env variable to find it? I have MSVC_VER, > VSINSTALLDIR and VS150COMNTOOLS all set. I don't remember needing anything > else. > > On Sat, Aug 13, 2022 at 1:30 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> vcruntime.h is included with the Visual Studio compiler and has been for >> ages. I can't think of anything recently that would have changed >> relative to that. >> >> -- Kevin >> >> >> On 8/12/2022 2:12 PM, Nir Lisker wrote: >> > Hi, >> > >> > I have just run gradle clean and gradle build, and I'm getting an error: >> > >> > C:/Program Files (x86)/Windows >> > Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error C1083: >> > Cannot open include file: 'vcruntime.h': No such file or directory >> > >> > Indeed, vcruntime.h is not in that folder. Do I need to update >> > something, like VS? >> > >> > - Nir >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Aug 13 06:58:13 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Sat, 13 Aug 2022 06:58:13 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v6] In-Reply-To: References: Message-ID: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/37c78a4b..b066026a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From jbhaskar at openjdk.org Sat Aug 13 11:51:08 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 13 Aug 2022 11:51:08 GMT Subject: RFR: 8285878: [TestBug] LocalStorageTest does not cleanup post execution Message-ID: Issue: test Bug LocalStorageTest does not cleanup post execution Solution: Path for LocalStorageDir changed to modules/javafx.web/build/. Now the LocalStorageDir is deleted after post execution. ------------- Commit messages: - 8285878: [TestBug] LocalStorageTest does not cleanup post execution Changes: https://git.openjdk.org/jfx/pull/869/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285878 Stats: 26 lines in 2 files changed: 0 ins; 25 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/869.diff Fetch: git fetch https://git.openjdk.org/jfx pull/869/head:pull/869 PR: https://git.openjdk.org/jfx/pull/869 From kevin.rushforth at oracle.com Sat Aug 13 12:22:52 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 13 Aug 2022 05:22:52 -0700 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: References: Message-ID: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> Sure, I'll do that when I get a chance. As long as you set VS150COMNTOOLS, you shouldn't ever need to edit them, but it might be useful as a sanity check to compare with yours. Our GHA builds only set that one variable (and do not set MSVC_VER or VSINSTALLDIR). ??? VS150COMNTOOLS: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Auxiliary\\Build" -- Kevin On 8/12/2022 8:06 PM, Nir Lisker wrote: > Kevin, can you update the windows_tools.properties file for the build > page on the wiki [1] for VS 2022 since I see that we updated to use > that version? > > [1] https://wiki.openjdk.org/pages/viewpage.action?pageId=66650334 > > On Sat, Aug 13, 2022 at 2:06 AM Nir Lisker wrote: > > I see the file > under?\VC\Tools\MSVC\14.33.31629\include\vcruntime.h of the VS > installation. The file calling it is under C:/Program Files > (x86)/Windows Kits/10/include/10.0.17763.0/ucrt\corecrt.h. > Is it supposed to look for some env variable to find it? I > have?MSVC_VER, VSINSTALLDIR and?VS150COMNTOOLS all set. I don't > remember needing anything else. > > On Sat, Aug 13, 2022 at 1:30 AM Kevin Rushforth > wrote: > > vcruntime.h is included with the Visual Studio compiler and > has been for > ages. I can't think of anything recently that would have changed > relative to that. > > -- Kevin > > > On 8/12/2022 2:12 PM, Nir Lisker wrote: > > Hi, > > > > I have just run gradle clean and gradle build, and I'm > getting an error: > > > > C:/Program Files (x86)/Windows > > Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error > C1083: > > Cannot open include file: 'vcruntime.h': No such file or > directory > > > > Indeed, vcruntime.h is not in that folder. Do I need to update > > something, like VS? > > > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Aug 13 12:39:21 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 13 Aug 2022 12:39:21 GMT Subject: RFR: 8285878: [TestBug] LocalStorageTest does not cleanup post execution In-Reply-To: References: Message-ID: On Sat, 13 Aug 2022 11:45:00 GMT, Jay Bhaskar wrote: > Issue: test Bug LocalStorageTest does not cleanup post execution > Solution: Path for LocalStorageDir changed to modules/javafx.web/build/. Now the LocalStorageDir is deleted after post execution. Moving `LocalStorageDir` to be under `build/` is good, and makes this less of an issue, but I still see the directory present after running the test. So either `deleteRecursively` is not being called or it doesn't always work. Btw, you need to revert the inadvertent deletion of `.idea/modules.xml` ------------- PR: https://git.openjdk.org/jfx/pull/869 From lbourges at openjdk.org Sat Aug 13 13:24:30 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 13 Aug 2022 13:24:30 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v6] In-Reply-To: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: > Changelog for this MarlinFX 0.9.4.6 release: > > The Marlin-renderer 0.9.4.6 release provides one bug fix in Stroker: skip repeated endpoint to preserve mitter orientation: see JDK-8264999, https://bugs.openjdk.org/browse/JDK-8264999 > > The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: > - improved Stroker to handle huge coordinates, up to 1E15 > - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 > See JDK-8274066, https://bugs.openjdk.org/browse/JDK-8274066 > > > This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: > - Update DPQS to latest OpenJDK 14 patch > - Improve cubic curve offset computation > > > The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: > - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. > > > Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: > - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. > > > This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. > > Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: > see https://github.com/bourgesl/nearly-optimal-mergesort-code Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed dpqs javadoc + tests (setupOnce) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/674/files - new: https://git.openjdk.org/jfx/pull/674/files/b348079b..0e739a9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=674&range=04-05 Stats: 73 lines in 6 files changed: 15 ins; 31 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/674.diff Fetch: git fetch https://git.openjdk.org/jfx pull/674/head:pull/674 PR: https://git.openjdk.org/jfx/pull/674 From lbourges at openjdk.org Sat Aug 13 13:29:08 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 13 Aug 2022 13:29:08 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v6] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: <4VFoQBy6i3j3nluCRbyvwAk9pBEcElu6i4qqF2q9PH0=.0622817a-094c-4661-abee-d2366509c03d@github.com> On Sat, 13 Aug 2022 13:24:30 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.6 release: >> >> The Marlin-renderer 0.9.4.6 release provides one bug fix in Stroker: skip repeated endpoint to preserve mitter orientation: see JDK-8264999, https://bugs.openjdk.org/browse/JDK-8264999 >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> See JDK-8274066, https://bugs.openjdk.org/browse/JDK-8274066 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed dpqs javadoc + tests (setupOnce) Last commit fixes both DPQS javadoc and tests (setupOnce) ------------- PR: https://git.openjdk.org/jfx/pull/674 From nlisker at gmail.com Sat Aug 13 14:29:30 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 13 Aug 2022 17:29:30 +0300 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> Message-ID: I figured out that that error (which appeared during compilation of native decora shaders) came from a missing entry in windows.tools.properties: WINDOWS_VS_INCLUDE=C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.33.31629/include (There were many other entries there, but all pointing at the Windowls Kit.) But then a different error appeared: LINK : fatal error LNK1104: cannot open file 'MSVCRT.lib' This file is located under \VC\Tools\MSVC\14.33.31629\lib\x64 I assume there's another path missing in my file, but couldn't find anything pointing directly to this path in the example file. In general, I wonder why creating the file fails. If I specify where VS is located, I would assume that all the subdirectories would be easily found. I hadn't seen a change in the dir structure between 2017 and 2022. On Sat, Aug 13, 2022 at 3:22 PM Kevin Rushforth wrote: > Sure, I'll do that when I get a chance. As long as you set VS150COMNTOOLS, > you shouldn't ever need to edit them, but it might be useful as a sanity > check to compare with yours. Our GHA builds only set that one variable (and > do not set MSVC_VER or VSINSTALLDIR). > > VS150COMNTOOLS: "C:\\Program Files\\Microsoft Visual > Studio\\2022\\Enterprise\\VC\\Auxiliary\\Build" > > -- Kevin > > > On 8/12/2022 8:06 PM, Nir Lisker wrote: > > Kevin, can you update the windows_tools.properties file for the build page > on the wiki [1] for VS 2022 since I see that we updated to use that version? > > [1] https://wiki.openjdk.org/pages/viewpage.action?pageId=66650334 > > On Sat, Aug 13, 2022 at 2:06 AM Nir Lisker wrote: > >> I see the file under \VC\Tools\MSVC\14.33.31629\include\vcruntime.h of >> the VS installation. The file calling it is under C:/Program Files >> (x86)/Windows Kits/10/include/10.0.17763.0/ucrt\corecrt.h. >> Is it supposed to look for some env variable to find it? I have MSVC_VER, >> VSINSTALLDIR and VS150COMNTOOLS all set. I don't remember needing anything >> else. >> >> On Sat, Aug 13, 2022 at 1:30 AM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> vcruntime.h is included with the Visual Studio compiler and has been for >>> ages. I can't think of anything recently that would have changed >>> relative to that. >>> >>> -- Kevin >>> >>> >>> On 8/12/2022 2:12 PM, Nir Lisker wrote: >>> > Hi, >>> > >>> > I have just run gradle clean and gradle build, and I'm getting an >>> error: >>> > >>> > C:/Program Files (x86)/Windows >>> > Kits/10/include/10.0.17763.0/ucrt\corecrt.h(10): fatal error C1083: >>> > Cannot open include file: 'vcruntime.h': No such file or directory >>> > >>> > Indeed, vcruntime.h is not in that folder. Do I need to update >>> > something, like VS? >>> > >>> > - Nir >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhaskar at openjdk.org Sun Aug 14 05:31:16 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 14 Aug 2022 05:31:16 GMT Subject: RFR: 8285878: [TestBug] LocalStorageTest does not cleanup post execution [v2] In-Reply-To: References: Message-ID: > Issue: test Bug LocalStorageTest does not cleanup post execution > Solution: Path for LocalStorageDir changed to modules/javafx.web/build/. Now the LocalStorageDir is deleted after post execution. Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8285878' of github.com:jaybhaskar/jfx into JDK-8285878 - clean patch ------------- Changes: - all: https://git.openjdk.org/jfx/pull/869/files - new: https://git.openjdk.org/jfx/pull/869/files/41f80fe9..eb2fd2fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=869&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=869&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/869.diff Fetch: git fetch https://git.openjdk.org/jfx pull/869/head:pull/869 PR: https://git.openjdk.org/jfx/pull/869 From jbhaskar at openjdk.org Sun Aug 14 05:37:05 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 14 Aug 2022 05:37:05 GMT Subject: Withdrawn: 8285878: [TestBug] LocalStorageTest does not cleanup post execution In-Reply-To: References: Message-ID: On Sat, 13 Aug 2022 11:45:00 GMT, Jay Bhaskar wrote: > Issue: test Bug LocalStorageTest does not cleanup post execution > Solution: Path for LocalStorageDir changed to modules/javafx.web/build/. Now the LocalStorageDir is deleted after post execution. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/869 From mhanl at openjdk.org Sun Aug 14 11:51:22 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 14 Aug 2022 11:51:22 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v6] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Thu, 11 Aug 2022 22:12:09 GMT, Andy Goryachev wrote: >>> On a side note, we could have used Unicode here >>> >>> private static final double ? = .0000001; >> >> But let's not. > > you are right, we should not use non-ascii identifiers. > it was a joke, sorry. > So, plugging a 100 columns of 200 px wide we get something to the order of 1e-12 .. 1e-11. Thanks for the explaination and links. The remaining question is: Should we then use a smaller epsilon value or does it not matter at all? ------------- PR: https://git.openjdk.org/jfx/pull/848 From mstrauss at openjdk.org Sun Aug 14 12:58:07 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 14 Aug 2022 12:58:07 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v6] In-Reply-To: References: <4MbyCCX_GvSxzDTqvF7IOGUq6fZDdpBQS_CFIzrqzN8=.7f90249b-e565-4bf1-8f6c-6eb030ea21ed@github.com> Message-ID: On Sun, 14 Aug 2022 11:47:53 GMT, Marius Hanl wrote: >> you are right, we should not use non-ascii identifiers. >> it was a joke, sorry. > >> So, plugging a 100 columns of 200 px wide we get something to the order of 1e-12 .. 1e-11. > > Thanks for the explaination and links. > The remaining question is: Should we then use a smaller epsilon value or does it not matter at all? In general, the smallest epsilon depends on the magnitude of the floating-point number. There?s `Math.ulp(double)`, which for a given double value, returns the distance to the next representable value. ------------- PR: https://git.openjdk.org/jfx/pull/848 From john at status6.com Sun Aug 14 17:13:12 2022 From: john at status6.com (John Neffenger) Date: Sun, 14 Aug 2022 10:13:12 -0700 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> Message-ID: On 8/13/22 7:29 AM, Nir Lisker wrote: > I figured out that that error (which appeared during compilation?of > native decora shaders) came from a missing entry in > windows.tools.properties: While working on pull request openjdk/jfx#488, I found the sample 'windows_tools.properties' file in the Wiki to be unhelpful. You don't need it, and it was only a source of additional errors and confusion for me. I think we should delete that section from the Wiki. It was over a year ago when I ran into problems with the Windows build, but if I remember correctly, you need to do just the following: 1. Define the environment variables correctly. 2. When encountering errors, delete the entire 'build' directory after each run. That will force the build to regenerate the correct 'windows_tools.properties' file (and not use the old incorrect one). Step 1 is found below. The very important parts are to (a) include '/cygdrive/c/Windows/System32' in your PATH, and (b) define the 'VS150COMNTOOLS' environment variable: https://github.com/jgneff/jfxbuild/blob/main/win10/bin/jfxbuild.env Step 2 is: $ rm -r build More details are in the following pull request comment and my response: https://github.com/openjdk/jfx/pull/488#pullrequestreview-671683654 John From nlisker at gmail.com Mon Aug 15 07:32:01 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 15 Aug 2022 10:32:01 +0300 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> Message-ID: Thanks John. I managed to fix my issue by replacing the paths in the wiki's 'windows_tools.properties' file. As for your fix, I did delete the build folder and had the VS150COMNTOOLS variable defined, but didn't know about '/cygdrive/c/Windows/System32' (I have '%SystemRoot%\system32' which is exported to Cygwin correctly). The properties file was still wrong and caused errors. I also run gradle builds from Eclipse, so Cygwin isn't always used. On Sun, Aug 14, 2022 at 8:13 PM John Neffenger wrote: > On 8/13/22 7:29 AM, Nir Lisker wrote: > > I figured out that that error (which appeared during compilation of > > native decora shaders) came from a missing entry in > > windows.tools.properties: > > While working on pull request openjdk/jfx#488, I found the sample > 'windows_tools.properties' file in the Wiki to be unhelpful. You don't > need it, and it was only a source of additional errors and confusion for > me. I think we should delete that section from the Wiki. > > It was over a year ago when I ran into problems with the Windows build, > but if I remember correctly, you need to do just the following: > > 1. Define the environment variables correctly. > > 2. When encountering errors, delete the entire 'build' directory after > each run. That will force the build to regenerate the correct > 'windows_tools.properties' file (and not use the old incorrect one). > > Step 1 is found below. The very important parts are to (a) include > '/cygdrive/c/Windows/System32' in your PATH, and (b) define the > 'VS150COMNTOOLS' environment variable: > > https://github.com/jgneff/jfxbuild/blob/main/win10/bin/jfxbuild.env > > Step 2 is: > > $ rm -r build > > More details are in the following pull request comment and my response: > > https://github.com/openjdk/jfx/pull/488#pullrequestreview-671683654 > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Mon Aug 15 10:08:34 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 15 Aug 2022 10:08:34 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: <0okvvkrjS89IXbBAtr_N2OqaXgXjg2gRW_wggc7pzHQ=.65c7501d-b1e5-4abd-8d57-9b30114841de@github.com> References: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com> <0okvvkrjS89IXbBAtr_N2OqaXgXjg2gRW_wggc7pzHQ=.65c7501d-b1e5-4abd-8d57-9b30114841de@github.com> Message-ID: On Tue, 2 Aug 2022 10:57:25 GMT, Ambarish Rapte wrote: >> I'll have a look. What command did you run this test with? >> >> Can you also test the point light attenuation under `tests\system\src\test\java\test\javafx\scene\lighting3D\PointLightAttenuationTest.java`? (I think there's a bit of a mess in the tests folders.) > > Command to run the system test: > `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test --tests test.robot.test3d.PointLightIlluminationTest` > > I ran all the tests, only above test failed: > Command to run all the system tests: `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test` First of all, I found that the mistake was in the shortcut branch of the shader: it was using the light direction instead of the vector to the light (incident ray), so in the code I need to replace `dot(n, -lightDir)` with `dot(n, -l)`, like is done in the full computation branch. Then the test passes with the `0` input for no-attenuation. Thanks. Then I looked at the computation some more and I found something in the computation of the specular component. According to the theory, both in online sources and in the `PhongMaterial` class doc, the computation should be: `R . V` where `V` is the vector to the eye/cam and `R` is the reflection vector computed by `R = 2(N . L)N - L`, or using the [reflect](https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-reflect) HLSL function, `R = -reflect(N, L)`. So the shader files should look something like this: float3 refl = reflect(l, n); s = ... dot(-refl, e); // e is the vector to the eye, like V However, looking at the shader files, [already from legacy](https://github.com/openjdk/jfx/blob/c420248b9b459efcfbd3657170d9be0b96b5fb38/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h), the vectors are switched: float3 refl = reflect(e, n); s = ... dot(-refl, l); It looks like the specular computation was wrong from the start. I tested the visuals on the `master` branch before and after swapping the `l` and `e` vectors and I see no difference in the specular reflection. Rather odd. Will need to look into this more. The same mistakes are coded into the glsl shaders too, so I should fix the one you found at the very least. ------------- PR: https://git.openjdk.org/jfx/pull/789 From fastegal at openjdk.org Mon Aug 15 10:25:22 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 10:25:22 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> Message-ID: On Fri, 12 Aug 2022 15:08:27 GMT, Andy Goryachev wrote: > > you are right... I am so sorry. missed this one while cherry picking from another branch. will fix it soon. no problem, shit happens :) ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Mon Aug 15 10:31:26 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 10:31:26 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v10] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Thu, 11 Aug 2022 17:56:58 GMT, Andy Goryachev wrote: > unnecessary in the case of TableRow. that is .. why exactly? > the change in TreeTableRow was necessary because otherwise selecting a cell by mouse selected the whole row. it still does (if all cells are selected) see me in grinning - my first guess was exactly the same as yours, but the moment I was about answering your comment (with "should behave the same and _they do_") some memory neuron fired and made me curious enough the check. The outcome is [JDK-8292353](https://bugs.openjdk.org/browse/JDK-8292353) as that is unrelated to this fix (same before/after), we are fine here ------------- PR: https://git.openjdk.org/jfx/pull/839 From fastegal at openjdk.org Mon Aug 15 10:41:32 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 10:41:32 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v11] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Fri, 12 Aug 2022 17:21:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. change selectRowWhenInSingleCellSelectionMode() and selectRowWhenInSingleCellSelectionMode2() in TableViewSelectionModelImplTest to reflect new reality. >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: added tests long journey with a good end :) Looks fine, verified tests: - some assertions needed to be adjusted to the fix, so they were passing before and still passing after the fix - some where failing/passing before/after the fix ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.org/jfx/pull/839 From fastegal at swingempire.de Mon Aug 15 10:53:37 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 12:53:37 +0200 Subject: Merge master into fix branch during review Message-ID: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> .. is something I _personally_ don't like: have to mentally sort the related from the unrelated commits in the history. The contributing guidelines do allow intermediate merges (bolding by me) "If you __need__ to pick up changes from master, you can merge master into your branch" my interpretation would be: don't without good reason. To merge or not to merge, that is the quesion :) -- Jeanette From fastegal at openjdk.org Mon Aug 15 11:11:31 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 11:11:31 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v9] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 23:23:46 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: removed empty src sir no review, just a confirmation for part of this fix: with the change of .classpath in graphics (essentially a reversion of [JDK-8289255](https://bugs.openjdk.org/browse/JDK-8289255)) , applications in Eclipse projects that depend on the project graphics are now running again without errors ------------- PR: https://git.openjdk.org/jfx/pull/858 From kevin.rushforth at oracle.com Mon Aug 15 13:11:36 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Aug 2022 06:11:36 -0700 Subject: Merge master into fix branch during review In-Reply-To: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> References: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> Message-ID: <348cf399-c1f2-0b8b-c7e8-a40713599bd1@oracle.com> It depends on how out of date the PR branch gets from the upstream master. For long-running PRs it is important to periodically merge master, or at least to do it as the PR is winding down and before integration. See JDK-8289751 [1], which was caused by PR #741 [2] being integrated without having done this merge, for an example of what can happen if you don't. For shorter running PRs it is optional, as long as you are reasonably certain that there is no adverse interaction between your PR and any commits in the upstream master that have gone in since your merge base. I typically don't merge in such cases if I know that my PR is touching an area that has been unmodified by any other integrated PRs. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8289751 [2] https://github.com/openjdk/jfx/pull/741 On 8/15/2022 3:53 AM, Jeanette Winzenburg wrote: > > .. is something I _personally_ don't like: have to mentally sort the > related from the unrelated commits in the history. > > The contributing guidelines do allow intermediate merges (bolding by me) > > "If you __need__ to pick up changes from master, you can merge master > into your branch" > > my interpretation would be: don't without good reason. > > To merge or not to merge, that is the quesion :) > > -- Jeanette > From angorya at openjdk.org Mon Aug 15 15:19:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Aug 2022 15:19:38 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v10] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ 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 12 additional commits since the last revision: - Merge branch 'openjdk:master' into 8290473.apps - 8290473: removed empty src sir - 8290473: whitespace - 8290473: init shader dirs - 8290473: junit 5 - Merge remote-tracking branch 'origin/master' into 8290473.apps - 8290473: removed eclipse project in buildSrc - 8290473: whitespace - 8290473: added initDirs task - Merge remote-tracking branch 'origin/master' into 8290473.apps - ... and 2 more: https://git.openjdk.org/jfx/compare/ab2c3638...f3fa2068 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/2a9fb3b7..f3fa2068 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=08-09 Stats: 1193 lines in 4 files changed: 964 ins; 189 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From fastegal at openjdk.org Mon Aug 15 15:27:27 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 15:27:27 GMT Subject: RFR: 8290844: Add Skin.install() method [v4] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 18:15:37 GMT, Andy Goryachev wrote: >> - added Skin.install() >> - javadoc changes for Skinnable.setSkin(Skin) >> >> no code changes for Skinnable.setSkin(Skin) yet. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290844: review comments hmm .. with the singleton handler problem (f.i. [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877)) out off the way (a skin must not set such a handler), it seems we are very near to a solution without a problem: none of our skins would want to really implement install (due to the high risk of breaking existing custom skins). Nevertheless, the idea is good and a step into the right direction. But would be a bit weird not implementing it ourselfves .. what about refactor all our skins (move the complete installation into install, including listeners, children, mutations) and - circling back to the supportsInstall :) - implement the concrete subclasses to self-install in the constructor? All our skins extend from SkinBase, so the method might reside there (could be protected) if Skin should remain skinny .. ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Mon Aug 15 15:41:33 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Mon, 15 Aug 2022 15:41:33 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> Message-ID: <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> On Fri, 12 Aug 2022 18:42:16 GMT, Andy Goryachev wrote: > > @kleopatra : Thank you so much for your effort to research the alternatives. > thinking about alternatives is our job, isn't it :) > The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. There might be such code, but I doubt that there is anything (at least nothing validly installed) in our skins. Haven't looked into the install children that are defined in the control itself (like f.i. editors in the combo/spinner et al). > > Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. As long as custom classes play by the rules (aka: don't violate the spec) we'll have a hard time imposing code changes onto custom classes. Or if we do, we might see us in the middle of many pointed fingers. Like (from [kinds of compatibilty](https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility)) > While an end-user may not care why a program does not work with a newer version of a library, what contracts are being followed or broken should determine which party has the onus for fixing the problem ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 15 15:55:28 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Aug 2022 15:55:28 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> Message-ID: On Mon, 15 Aug 2022 15:37:15 GMT, Jeanette Winzenburg wrote: >>> A quick PoC is in [my fork off Andy's PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) >> >> @kleopatra : >> Thank you so much for your effort to research the alternatives. >> >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. The others, which only add listeners and children nodes, can remain unchanged. > >> >> @kleopatra : Thank you so much for your effort to research the alternatives. >> > > thinking about alternatives is our job, isn't it :) > >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. > > There might be such code, but I doubt that there is anything (at least nothing validly installed) in our skins. Haven't looked into the install children that are defined in the control itself (like f.i. editors in the combo/spinner et al). > >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. > > As long as custom classes play by the rules (aka: don't violate the spec) we'll have a hard time imposing code changes onto custom classes. Or if we do, we might see us in the middle of many pointed fingers. Like (from [kinds of compatibilty](https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility)) > >> While an end-user may not care why a program does not work with a newer version of a library, what contracts are being followed or broken should determine which party has the onus for fixing the problem @kleopatra : Please take a look at MenubuttonSkin:108 In there, we are setting an onAction handler, but only if it's not null. This particular code cannot distinguish between onAction handler set by the user prior to any skin installed, and the handler installed by a previous skin in the case of replacing an existing skin. How do you propose to fix it? Even if we invent some kind of inner class to be able to do instanceOf, there is still a possibility of replacing a user-defined skin, where the old skin would set and remove its handler and we'll end up without a handler once new skin is installed. No amount of hacks can fix a bad design, it seems. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Mon Aug 15 16:09:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Aug 2022 16:09:22 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v6] In-Reply-To: References: Message-ID: On Sat, 13 Aug 2022 06:58:13 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. >> >> **Cause:** >> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. >> >> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). >> >> To confirm this behaviour, please find the below example that showcases the issue: >> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. >> >> >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.beans.property.StringProperty; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.geometry.Insets; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.control.*; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class ConstrainedResizePolicyIssueDemo extends Application { >> @Override >> public void start(Stage primaryStage) throws Exception { >> TableColumn fnCol = new TableColumn<>("First Name"); >> fnCol.setMinWidth(100); >> fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); >> >> TableColumn priceCol = new TableColumn<>("Price"); >> priceCol.setMinWidth(100); >> priceCol.setMaxWidth(150); >> priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); >> >> TableColumn totalCol = new TableColumn<>("Total"); >> totalCol.setMinWidth(100); >> totalCol.setMaxWidth(150); >> totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); >> >> ObservableList persons = FXCollections.observableArrayList(); >> persons.add(new Person("Harry", "200.00", "210.00")); >> persons.add(new Person("Jacob", "260.00", "260.00")); >> >> TableView tableView = new TableView<>(); >> tableView.getColumns().addAll(fnCol, priceCol, totalCol); >> tableView.setItems(persons); >> tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); >> tableView.setMinWidth(500); >> tableView.maxWidthProperty().bind(tableView.minWidthProperty()); >> >> Button button1 = new Button("Reduce 1px"); >> button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); >> Button button2 = new Button("Reduce 10px"); >> button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); >> Button button3 = new Button("Reset"); >> button3.setOnAction(e -> tableView.setMinWidth(500)); >> Button button4 = new Button("Increase 1px"); >> button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); >> Button button5 = new Button("Increase 10px"); >> button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); >> >> HBox row = new HBox(button1, button2, button3, button4, button5); >> row.setSpacing(10); >> TextArea output = new TextArea(); >> >> addWidthListeners(tableView, output); >> VBox root = new VBox(row, new Group(tableView), output); >> root.setSpacing(10); >> root.setPadding(new Insets(10)); >> >> Scene scene = new Scene(root); >> primaryStage.setScene(scene); >> primaryStage.setTitle("Constrained Resize Policy Issue TableView"); >> primaryStage.show(); >> } >> >> private void addWidthListeners(TableView tableView, TextArea output) { >> tableView.widthProperty().addListener((obs, old, val) -> { >> String str = "Table width changed :: " + val + "\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> tableView.getColumns().forEach(column -> { >> column.widthProperty().addListener((obs, old, width) -> { >> String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> }); >> } >> >> class Person { >> private StringProperty firstName = new SimpleStringProperty(); >> private StringProperty price = new SimpleStringProperty(); >> private StringProperty total = new SimpleStringProperty(); >> >> public Person(String fn, String price, String total) { >> setFirstName(fn); >> setPrice(price); >> setTotal(total); >> } >> >> public StringProperty firstNameProperty() { >> return firstName; >> } >> >> public void setFirstName(String firstName) { >> this.firstName.set(firstName); >> } >> >> public StringProperty priceProperty() { >> return price; >> } >> >> public void setPrice(String price) { >> this.price.set(price); >> } >> >> public StringProperty totalProperty() { >> return total; >> } >> >> public void setTotal(String total) { >> this.total.set(total); >> } >> } >> } >> >> >> **Fix:** >> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. >> >> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 >> >> `if (Math.abs(colWidth - tableWidth) > 1) {` >> >> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright review comments looks good (I am not a Reviewer/Committer, so you may need to ask a real one to approve) ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/848 From angorya at openjdk.org Mon Aug 15 16:47:27 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Aug 2022 16:47:27 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v10] In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 15:19:38 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > 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 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290473.apps > - 8290473: removed empty src sir > - 8290473: whitespace > - 8290473: init shader dirs > - 8290473: junit 5 > - Merge remote-tracking branch 'origin/master' into 8290473.apps > - 8290473: removed eclipse project in buildSrc > - 8290473: whitespace > - 8290473: added initDirs task > - Merge remote-tracking branch 'origin/master' into 8290473.apps > - ... and 2 more: https://git.openjdk.org/jfx/compare/2c6d3232...f3fa2068 Could someone please, please review this PR? Thank you! ------------- PR: https://git.openjdk.org/jfx/pull/858 From mhanl at openjdk.org Mon Aug 15 17:02:36 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 15 Aug 2022 17:02:36 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: > This PR fixes an issue which is probably in JavaFX since VirtualFlow exists. > While horizontal scrolling any VirtualFlow control the left blue border sometimes disappear/gets smaller. (see also image below) > > This can be fixed by **snapping** the scroll bar value (similar like e.g. a **ScrollPane** does). > The same needs to be done on the table header as otherwise the column lines might be 1 px off to the cell lines. > As a side effect this also fixes that the column lines sometimes get's blurry when horizontal scrolling (see second image). > > While testing with **-Dglass.win.uiScale** I found out that the problem is not fixed for a scale like 1.25 or 1.5, while it is fixed for 1 or 2. The border sometimes disappears only when the snapped value is a decimal number (which obviously does not happen on a scale of 1 or 2), e.g. something like 12.6 but it will never disappear when it's a normal number, so e.g. just 12. > > That's why something like **Math.round(..)** or just a **cast** to an **int** instead of snapping fixes this problem for all scales. I also didn't notice any side effect. But not sure if this the right fix then. > How does JavaFX render a **node** when e.g. the x is a decimal number? And does a decimal number make sense (Why we e.g. don't round the value)? > > Another explanation could also be that there is an issue somewhere deep inside the node layout/snapping/Clip/Group/pixel rendering and to simply round/cast the value just fixes the symptom here. > > In any case I'm open for any feedback, help or explaination. > I'm also glad for anything which might help identify the root cause here, if any. > > --- > 1. > ![image](https://user-images.githubusercontent.com/66004280/134562508-bea6ab9d-d3d0-4dbb-b0ce-dc6570a94ed7.png) > --- > 2. > ![image](https://user-images.githubusercontent.com/66004280/134563377-970b4e48-8528-4dad-95fb-fb93780413e8.png) Marius Hanl 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 branch 'master' of https://github.com/openjdk/jfx into 8218745-snapping-x-y-tableview-scroll  Conflicts:  modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java - 8218745: Snapping X/Y when scrolling ------------- Changes: https://git.openjdk.org/jfx/pull/630/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=630&range=01 Stats: 60 lines in 6 files changed: 56 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/630.diff Fetch: git fetch https://git.openjdk.org/jfx pull/630/head:pull/630 PR: https://git.openjdk.org/jfx/pull/630 From john.hendrikx at gmail.com Mon Aug 15 20:33:55 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 15 Aug 2022 22:33:55 +0200 Subject: Merge master into fix branch during review In-Reply-To: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> References: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> Message-ID: <7610365c-0af4-f2b9-45f2-f7001370ca53@gmail.com> Normally pulling in changes from master is done by rebasing the branch on master, while putting in changes from a feature branch into master is a merge. This avoids making it seem the commits on master are part of your branch, and even avoids accidentally including something from master when your branch is merged but the change on master was reverted before that happened. Is there a reason openjfx uses a merge to bring a branch up-to-date with master? As long as the commits on the branch are not squashed or altered it should not make reviewing any harder. --John On 15/08/2022 12:53, Jeanette Winzenburg wrote: > > .. is something I _personally_ don't like: have to mentally sort the > related from the unrelated commits in the history. > > The contributing guidelines do allow intermediate merges (bolding by me) > > "If you __need__ to pick up changes from master, you can merge master > into your branch" > > my interpretation would be: don't without good reason. > > To merge or not to merge, that is the quesion :) > > -- Jeanette > From john at status6.com Mon Aug 15 22:26:33 2022 From: john at status6.com (John Neffenger) Date: Mon, 15 Aug 2022 15:26:33 -0700 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> Message-ID: <9e3f4a85-caaa-ca64-b262-93f1679cefdc@status6.com> On 8/15/22 12:32 AM, Nir Lisker wrote: > (I have '%SystemRoot%\system32' which is exported to Cygwin correctly). That works, too. I have to admit, my troubles on Windows at the time were self-inflicted. I was trying to reduce my PATH to its minimum (shown formatted below), but I left off 'Windows/System32', which causes difficult and hidden errors in the JavaFX build. $ echo $PATH /home/john/opt/apache-ant-1.10.12/bin :/home/john/opt/jdk-18.0.1.1/bin :/home/john/opt/cmake-3.23.1-windows-x86_64/bin :/usr/sbin:/usr/bin:/sbin:/bin :/cygdrive/c/Windows/System32 > I managed to fix my issue by replacing the paths in the wiki's 'windows_tools.properties' file. I tried editing that file, too, but I couldn't get it working. It also has almost 80 program and SDK directory entries on its paths that aren't on my system at all, so I was reluctant even to start with it. In any case, the JavaFX build on Windows is supposed to generate a properties file that works for your system, so something's wrong -- likely in the build script -- if it doesn't. I certainly understand, though, if a developer decides to move on and save that battle for another day. :-) John From kevin.rushforth at oracle.com Mon Aug 15 23:37:57 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Aug 2022 16:37:57 -0700 Subject: Merge master into fix branch during review In-Reply-To: <7610365c-0af4-f2b9-45f2-f7001370ca53@gmail.com> References: <20220815125337.Horde.SiBGar0mBo2auX-1VH6w0zN@webmail.df.eu> <7610365c-0af4-f2b9-45f2-f7001370ca53@gmail.com> Message-ID: <5fa26544-cd56-c44b-bc97-11bd62ccb06c@oracle.com> When you *initially* create the PR you can (and are encouraged to) rebase your branch on master. Subsequent updates to bring your branch up-to-date with master should be done with a "git merge". The contributing guidelines strongly recommend that you do not rebase your branch once you publish it (which, in this context, means once you first make a PR using that branch "rfr"). Skara now also warns you not to do that. The main reason is that rebasing an in-progress PR makes it hard for people who have been following along as the review progresses to see incremental changes or go back and make sure that earlier comments have been addressed. I agree that it isn't quite as much of a problem if you don't squash or alter commits, but the tooling doesn't always make that easy to see. -- Kevin On 8/15/2022 1:33 PM, John Hendrikx wrote: > Normally pulling in changes from master is done by rebasing the branch > on master, while putting in changes from a feature branch into master > is a merge. This avoids making it seem the commits on master are part > of your branch, and even avoids accidentally including something from > master when your branch is merged but the change on master was > reverted before that happened. > > Is there a reason openjfx uses a merge to bring a branch up-to-date > with master? As long as the commits on the branch are not squashed or > altered it should not make reviewing any harder. > > --John > > On 15/08/2022 12:53, Jeanette Winzenburg wrote: >> >> .. is something I _personally_ don't like: have to mentally sort the >> related from the unrelated commits in the history. >> >> The contributing guidelines do allow intermediate merges (bolding by me) >> >> "If you __need__ to pick up changes from master, you can merge master >> into your branch" >> >> my interpretation would be: don't without good reason. >> >> To merge or not to merge, that is the quesion :) >> >> -- Jeanette >> From michaelstrau2 at gmail.com Tue Aug 16 03:09:19 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 16 Aug 2022 05:09:19 +0200 Subject: CSS Transitions Message-ID: JavaFX supports animations using the tools in the `javafx.animation` package, but it lacks an easy way of defining animations in stylesheets. This feature has often been requested, but is still missing [0] [1] [2]. While there are several ways to tackle this problem (an alternative notation is presented in [2]), I think the best approach is to implement CSS Transitions [3] for JavaFX. CSS Transitions is an established and stable specification, and it is ubiquitous all over the web. I've prepared a PR that illustrates how that feature can look like in JavaFX: https://github.com/openjdk/jfx/pull/870 With this PR, JavaFX would support animated transitions for all numeric and `Interpolatable` styleable properties. However, in order to support transitions for CSS sub-properties like `-fx-background-color`, several background-related types must be made interpolatable as well (the same is true for border-related types). If this proposal goes forward, I plan to deliver the feature in two installments: 1. CSS Transitions (the above PR) 2. Interpolation support for `Background`, `BackgroundFill`, `CornerRadii`, `Insets`, `Border`, `BorderWidths` and `Margins` I'm looking foward for comments and feedback. [0] https://bugs.openjdk.org/browse/JDK-8283676 [1] https://bugs.openjdk.org/browse/JDK-8092084 [2] https://bugs.openjdk.org/browse/JDK-8090892 [3] https://www.w3.org/TR/css-transitions-1/ From nlisker at gmail.com Tue Aug 16 05:18:49 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 16 Aug 2022 08:18:49 +0300 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: <9e3f4a85-caaa-ca64-b262-93f1679cefdc@status6.com> References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> <9e3f4a85-caaa-ca64-b262-93f1679cefdc@status6.com> Message-ID: > > I tried editing that file, too, but I couldn't get it working. It also > has almost 80 program and SDK directory entries on its paths that aren't > on my system at all, so I was reluctant even to start with it. > I also have entries there that don't exist. I suspect they have to do with building WebKit. Turns out they don't hurt. > In any case, the JavaFX build on Windows is supposed to generate a > properties file that works for your system, so something's wrong -- > likely in the build script -- if it doesn't. I certainly understand, > though, if a developer decides to move on and save that battle for > another day. :-) > Well, it didn't generate one that worked for me, which is odd because it did so in the past. I don't know enough about the build and the script, so I can't debug it myself, otherwise I would have. On Tue, Aug 16, 2022 at 1:26 AM John Neffenger wrote: > On 8/15/22 12:32 AM, Nir Lisker wrote: > > (I have '%SystemRoot%\system32' which is exported to Cygwin correctly). > > That works, too. I have to admit, my troubles on Windows at the time > were self-inflicted. I was trying to reduce my PATH to its minimum > (shown formatted below), but I left off 'Windows/System32', which causes > difficult and hidden errors in the JavaFX build. > > $ echo $PATH > /home/john/opt/apache-ant-1.10.12/bin > :/home/john/opt/jdk-18.0.1.1/bin > :/home/john/opt/cmake-3.23.1-windows-x86_64/bin > :/usr/sbin:/usr/bin:/sbin:/bin > :/cygdrive/c/Windows/System32 > > > I managed to fix my issue by replacing the paths in the wiki's > 'windows_tools.properties' file. > > I tried editing that file, too, but I couldn't get it working. It also > has almost 80 program and SDK directory entries on its paths that aren't > on my system at all, so I was reluctant even to start with it. > > In any case, the JavaFX build on Windows is supposed to generate a > properties file that works for your system, so something's wrong -- > likely in the build script -- if it doesn't. I certainly understand, > though, if a developer decides to move on and save that battle for > another day. :-) > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Tue Aug 16 10:47:24 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 16 Aug 2022 10:47:24 GMT Subject: RFR: 8291908: VirtualFlow creates unneeded empty cells In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 14:30:40 GMT, Johan Vos wrote: > When calculating the viewportOffset, we now already take into account that cells will have to shift. > > This prevents the creation of temporary empty cells in the layout phase. > One test needed to be fixed, since the number of invocations to updateItem() was hardcoded (and it > is decreased by this commit). Fix looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/863 From aghaisas at openjdk.org Tue Aug 16 11:05:40 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 16 Aug 2022 11:05:40 GMT Subject: RFR: 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane In-Reply-To: References: Message-ID: <_xKjlThwVOOB2prpmQq5LKsWOUwpoV2Vg-Tmlm_3vQ0=.ca0bf024-f4d9-4dcc-881c-e97ab649e728@github.com> On Tue, 2 Aug 2022 10:45:54 GMT, Jose Pereda wrote: > This PR fixes an issue when there is a DialogPane that has no header and no graphic is set, by adding the `graphic-container` styleclass only when there is a non-null graphic applied, preventing the padding that otherwise the graphic container will keep. > > Two tests have been added, to verify that the padding is 0 when there is no graphic (this test fails without this PR) and to verify that the padding is correct when there is a graphic to the left of the content area. > > As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area. Fix looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/859 From aghaisas at openjdk.org Tue Aug 16 12:01:28 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 16 Aug 2022 12:01:28 GMT Subject: RFR: 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 10:45:54 GMT, Jose Pereda wrote: > As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area. We can discuss this in a separate JBS issue. ------------- PR: https://git.openjdk.org/jfx/pull/859 From jvos at openjdk.org Tue Aug 16 12:31:45 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Aug 2022 12:31:45 GMT Subject: Integrated: 8291908: VirtualFlow creates unneeded empty cells In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 14:30:40 GMT, Johan Vos wrote: > When calculating the viewportOffset, we now already take into account that cells will have to shift. > > This prevents the creation of temporary empty cells in the layout phase. > One test needed to be fixed, since the number of invocations to updateItem() was hardcoded (and it > is decreased by this commit). This pull request has now been integrated. Changeset: eaddb0fb Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/eaddb0fbeeb99900636f9704758f6c004860ff9a Stats: 40 lines in 3 files changed: 38 ins; 0 del; 2 mod 8291908: VirtualFlow creates unneeded empty cells Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/863 From john at status6.com Tue Aug 16 15:24:55 2022 From: john at status6.com (John Neffenger) Date: Tue, 16 Aug 2022 08:24:55 -0700 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> <9e3f4a85-caaa-ca64-b262-93f1679cefdc@status6.com> Message-ID: <56e9fa0e-4768-6ca8-0d70-507f3e23e54a@status6.com> On 8/15/22 10:18 PM, Nir Lisker wrote: > I also have entries there that don't exist. I suspect they have to do > with building WebKit. Turns out they don't hurt. Right, they don't hurt. They're not for WebKit, though, and I found they over-complicate the sample as a starting-point for editing. It has almost every piece of software and programming language a developer might install (listed below). I'll post a minimal working 'windows_tools.properties' file to the mailing list when I upgrade Visual Studio, in case Kevin wants to consider using it instead of the current sample for the Wiki. It has 82 less entries in its various paths. John ================================================== Unnecessary entries in the 'windows_tools.properties' Wiki sample not needed for building JavaFX: NETFXSDK 4.8 NETFX 4.8 Tools HTML Help Workshop Microsoft FSharp and all of the following: C:/aliyun-cli; C:/cf-cli; C:/hostedtoolcache/windows/go/1.15.8/x64/bin; C:/hostedtoolcache/windows/Python/3.7.9/x64; C:/hostedtoolcache/windows/Python/3.7.9/x64/Scripts; C:/hostedtoolcache/windows/Ruby/2.5.8/x64/bin; C:/hostedtoolcache/windows/stack/2.5.1/x64; C:/mysql-5.7.21-winx64/bin; C:/npm/prefix; C:/ProgramData/Chocolatey/bin; C:/ProgramData/chocolatey/lib/maven/apache-maven-3.6.3/bin; C:/ProgramData/chocolatey/lib/pulumi/tools/Pulumi/bin; C:/ProgramData/kind; C:/Program Files/Amazon/AWSCLIV2/; C:/Program Files/Amazon/AWSSAMCLI/bin/; C:/Program Files/Amazon/SessionManagerPlugin/bin/; C:/Program Files/CMake/bin; C:/Program Files/Docker; C:/Program Files/dotnet/; C:/Program Files/dotnet; C:/Program Files/Git/bin; C:/Program Files/Git/cmd; C:/Program Files/Git/mingw64/bin; C:/Program Files/Git/usr/bin; C:/Program Files/Java/jdk8u282-b08/bin; C:/Program Files/Mercurial/; C:/Program Files/Microsoft SDKs/Azure/Azure Dev Spaces CLI/; C:/Program Files/Microsoft SDKs/Azure/Azure Dev Spaces CLI; C:/Program Files/Microsoft SDKs/Service Fabric/Tools/ServiceFabricLocalClusterManager; C:/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code; C:/Program Files/Microsoft SQL Server/130/Tools/Binn/; C:/Program Files/Microsoft SQL Server/Client SDK/ODBC/170/Tools/Binn/; C:/Program Files/Microsoft/Web Platform Installer/; C:/Program Files/MongoDB/Server/4.4/bin; C:/Program Files/nodejs/; C:/Program Files/OpenSSL/bin; C:/Program Files/PowerShell/7/; C:/Program Files/PowerShell/7; C:/Program Files/R/R-4.0.4/bin/x64; C:/Program Files/TortoiseSVN/bin; C:/Program Files (x86)/GitHub CLI; C:/Program Files (x86)/Google/Cloud SDK/google-cloud-sdk/bin; C:/Program Files (x86)/Microsoft BizTalk Server/; C:/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin; C:/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn/; C:/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn/; C:/Program Files (x86)/Microsoft SQL Server/130/DTS/Binn/; C:/Program Files (x86)/Microsoft SQL Server/140/DTS/Binn/; C:/Program Files (x86)/Microsoft SQL Server/150/DTS/Binn/; C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin; C:/Program Files (x86)/NSIS/; C:/Program Files (x86)/pipx_bin; C:/Program Files (x86)/sbt/bin; C:/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/; C:/Rust/.cargo/bin; C:/SeleniumWebDrivers/ChromeDriver/; C:/SeleniumWebDrivers/EdgeDriver/; C:/SeleniumWebDrivers/GeckoDriver; C:/Strawberry/c/bin; C:/Strawberry/perl/bin; C:/Strawberry/perl/site/bin; C:/tools/ghc-9.0.1/bin; c:/tools/php; C:/Users/runneradmin/AppData/Local/Microsoft/WindowsApps; C:/Users/runneradmin/bootjdk/jdk-15.0.2/bin; C:/Users/runneradmin/build-tools/apache-ant-1.10.5/bin; C:/Users/runneradmin/cygwin/cygwin64/bin; C:/Users/runneradmin/.dotnet/tools; C:/vcpkg; C:/windows; C:/windows/system32; C:/windows/System32/OpenSSH/; C:/windows/System32/Wbem; C:/windows/System32/WindowsPowerShell/v1.0/; From angorya at openjdk.org Tue Aug 16 15:58:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Aug 2022 15:58:38 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ 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 13 additional commits since the last revision: - Merge branch 'openjdk:master' into 8290473.apps - Merge branch 'openjdk:master' into 8290473.apps - 8290473: removed empty src sir - 8290473: whitespace - 8290473: init shader dirs - 8290473: junit 5 - Merge remote-tracking branch 'origin/master' into 8290473.apps - 8290473: removed eclipse project in buildSrc - 8290473: whitespace - 8290473: added initDirs task - ... and 3 more: https://git.openjdk.org/jfx/compare/07fca35b...e86cb390 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/f3fa2068..e86cb390 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=09-10 Stats: 40 lines in 3 files changed: 38 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From nlisker at gmail.com Tue Aug 16 19:33:42 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 16 Aug 2022 22:33:42 +0300 Subject: [External] : Re: Missing 'vcruntime.h' In-Reply-To: <56e9fa0e-4768-6ca8-0d70-507f3e23e54a@status6.com> References: <31c4ea12-f7f9-70cf-5dbf-f8ede9060169@oracle.com> <9e3f4a85-caaa-ca64-b262-93f1679cefdc@status6.com> <56e9fa0e-4768-6ca8-0d70-507f3e23e54a@status6.com> Message-ID: Nodejs, Rust, F sharp, Selenium... those are indeed some questionable entries for JavaFX. On Tue, Aug 16, 2022 at 6:25 PM John Neffenger wrote: > On 8/15/22 10:18 PM, Nir Lisker wrote: > > I also have entries there that don't exist. I suspect they have to do > > with building WebKit. Turns out they don't hurt. > > Right, they don't hurt. They're not for WebKit, though, and I found they > over-complicate the sample as a starting-point for editing. It has > almost every piece of software and programming language a developer > might install (listed below). > > I'll post a minimal working 'windows_tools.properties' file to the > mailing list when I upgrade Visual Studio, in case Kevin wants to > consider using it instead of the current sample for the Wiki. It has 82 > less entries in its various paths. > > John > > ================================================== > Unnecessary entries in the 'windows_tools.properties' Wiki sample not > needed for building JavaFX: > > NETFXSDK 4.8 > NETFX 4.8 Tools > HTML Help Workshop > Microsoft FSharp > > and all of the following: > > C:/aliyun-cli; > C:/cf-cli; > C:/hostedtoolcache/windows/go/1.15.8/x64/bin; > C:/hostedtoolcache/windows/Python/3.7.9/x64; > C:/hostedtoolcache/windows/Python/3.7.9/x64/Scripts; > C:/hostedtoolcache/windows/Ruby/2.5.8/x64/bin; > C:/hostedtoolcache/windows/stack/2.5.1/x64; > C:/mysql-5.7.21-winx64/bin; > C:/npm/prefix; > C:/ProgramData/Chocolatey/bin; > C:/ProgramData/chocolatey/lib/maven/apache-maven-3.6.3/bin; > C:/ProgramData/chocolatey/lib/pulumi/tools/Pulumi/bin; > C:/ProgramData/kind; > C:/Program Files/Amazon/AWSCLIV2/; > C:/Program Files/Amazon/AWSSAMCLI/bin/; > C:/Program Files/Amazon/SessionManagerPlugin/bin/; > C:/Program Files/CMake/bin; > C:/Program Files/Docker; > C:/Program Files/dotnet/; > C:/Program Files/dotnet; > C:/Program Files/Git/bin; > C:/Program Files/Git/cmd; > C:/Program Files/Git/mingw64/bin; > C:/Program Files/Git/usr/bin; > C:/Program Files/Java/jdk8u282-b08/bin; > C:/Program Files/Mercurial/; > C:/Program Files/Microsoft SDKs/Azure/Azure Dev Spaces CLI/; > C:/Program Files/Microsoft SDKs/Azure/Azure Dev Spaces CLI; > C:/Program Files/Microsoft SDKs/Service > Fabric/Tools/ServiceFabricLocalClusterManager; > C:/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code; > C:/Program Files/Microsoft SQL Server/130/Tools/Binn/; > C:/Program Files/Microsoft SQL Server/Client SDK/ODBC/170/Tools/Binn/; > C:/Program Files/Microsoft/Web Platform Installer/; > C:/Program Files/MongoDB/Server/4.4/bin; > C:/Program Files/nodejs/; > C:/Program Files/OpenSSL/bin; > C:/Program Files/PowerShell/7/; > C:/Program Files/PowerShell/7; > C:/Program Files/R/R-4.0.4/bin/x64; > C:/Program Files/TortoiseSVN/bin; > C:/Program Files (x86)/GitHub CLI; > C:/Program Files (x86)/Google/Cloud SDK/google-cloud-sdk/bin; > C:/Program Files (x86)/Microsoft BizTalk Server/; > C:/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin; > C:/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn/; > C:/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn/; > C:/Program Files (x86)/Microsoft SQL Server/130/DTS/Binn/; > C:/Program Files (x86)/Microsoft SQL Server/140/DTS/Binn/; > C:/Program Files (x86)/Microsoft SQL Server/150/DTS/Binn/; > C:/Program Files (x86)/Microsoft Visual > Studio/2019/Community/VC/Tools/Llvm/bin; > C:/Program Files (x86)/NSIS/; > C:/Program Files (x86)/pipx_bin; > C:/Program Files (x86)/sbt/bin; > C:/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/; > C:/Rust/.cargo/bin; > C:/SeleniumWebDrivers/ChromeDriver/; > C:/SeleniumWebDrivers/EdgeDriver/; > C:/SeleniumWebDrivers/GeckoDriver; > C:/Strawberry/c/bin; > C:/Strawberry/perl/bin; > C:/Strawberry/perl/site/bin; > C:/tools/ghc-9.0.1/bin; > c:/tools/php; > C:/Users/runneradmin/AppData/Local/Microsoft/WindowsApps; > C:/Users/runneradmin/bootjdk/jdk-15.0.2/bin; > C:/Users/runneradmin/build-tools/apache-ant-1.10.5/bin; > C:/Users/runneradmin/cygwin/cygwin64/bin; > C:/Users/runneradmin/.dotnet/tools; > C:/vcpkg; > C:/windows; > C:/windows/system32; > C:/windows/System32/OpenSSH/; > C:/windows/System32/Wbem; > C:/windows/System32/WindowsPowerShell/v1.0/; > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Aug 16 21:22:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Aug 2022 21:22:00 GMT Subject: RFR: 8292391: Add support for optional signing of native libraries Message-ID: This PR enables an optional signing step inserted into the build right after the step to strip binaries that was added by [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260). As is the case with the `strip` step, the optional signing is only ever enabled for production builds when running with `gradle -PCONF=Release`. This is an optional step, meaning that `codeSignCmd` and `codeSignArgs` need to be provided by scripts external to the repo in order to enable it. By default, they are not defined, so the additional logic added by this PR will do nothing. NOTE: as with the fix for [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260), this PR adds three copies of the build logic. I filed [JDK-8292506](https://bugs.openjdk.org/browse/JDK-8292506) to refactor both of them (strip and sign), and to look for other duplication as well. ------------- Commit messages: - 8292391: Add support for optional signing of native libraries Changes: https://git.openjdk.org/jfx/pull/871/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=871&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292391 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/871.diff Fetch: git fetch https://git.openjdk.org/jfx pull/871/head:pull/871 PR: https://git.openjdk.org/jfx/pull/871 From kcr at openjdk.org Tue Aug 16 21:56:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Aug 2022 21:56:48 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v6] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Sat, 13 Aug 2022 13:24:30 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.6 release: >> >> The Marlin-renderer 0.9.4.6 release provides one bug fix in Stroker: skip repeated endpoint to preserve mitter orientation: see JDK-8264999, https://bugs.openjdk.org/browse/JDK-8264999 >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> See JDK-8274066, https://bugs.openjdk.org/browse/JDK-8274066 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > fixed dpqs javadoc + tests (setupOnce) Looks good. I did leave one question and a (minor) comment. modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 52: > 50: public final class DualPivotQuicksort20191112Ext { > 51: > 52: private static final boolean FAST_ISORT = true; How much testing have you done with this flag set to true? modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 784: > 782: * @param srcB the source array for the secondary array to be ordered (b) > 783: * @param offset the start index in the source, inclusive > 784: * @param dstB the temporary buffer used in merging (b) Minor: this should probably be moved before `offset` ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/674 From kcr at openjdk.org Tue Aug 16 22:00:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Aug 2022 22:00:28 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v5] In-Reply-To: References: <6L5lKtJQoYNoo0FjHo4xyha5dXhmjU03BBzENNCBAdg=.15313546-706c-4109-b051-ec150399fef3@github.com> <5i0ztOzetIFtHCpKLpStDQEmfpGSJ32hwZZbKamNlw4=.e95f63da-24e3-40ad-b2b3-6ece70803401@github.com> Message-ID: On Thu, 4 Aug 2022 08:22:29 GMT, Paul wrote: >> @gargoyle To clarify my inline comments, the minimal change you need to make is: >> >> 1. Change the tests of the four `jField` variables to remove the `> 0` (so it becomes a boolean test for non-null). >> 2. Change the tests of `width` and `height` to be `> 0` (rather than `> 1`) >> >> My other suggestions are optional. > > Thanks @kevinrushforth. Thinking about it, is there merit in changing the `scalex` and `scaley` checks to be `!= 0`, as The main reason for checking at all is to prevent a division by zero. Although unlikely, could fractional values < 1 reach this code? @gargoyle have you decided whether to change the scale tests to be `> 0`? Other than that pending question, the only required changes are the two I listed above. ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Tue Aug 16 22:32:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Aug 2022 22:32:29 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v6] In-Reply-To: References: Message-ID: On Sat, 13 Aug 2022 06:58:13 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. >> >> **Cause:** >> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. >> >> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). >> >> To confirm this behaviour, please find the below example that showcases the issue: >> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. >> >> >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.beans.property.StringProperty; >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import javafx.geometry.Insets; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.control.*; >> import javafx.scene.layout.HBox; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class ConstrainedResizePolicyIssueDemo extends Application { >> @Override >> public void start(Stage primaryStage) throws Exception { >> TableColumn fnCol = new TableColumn<>("First Name"); >> fnCol.setMinWidth(100); >> fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); >> >> TableColumn priceCol = new TableColumn<>("Price"); >> priceCol.setMinWidth(100); >> priceCol.setMaxWidth(150); >> priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); >> >> TableColumn totalCol = new TableColumn<>("Total"); >> totalCol.setMinWidth(100); >> totalCol.setMaxWidth(150); >> totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); >> >> ObservableList persons = FXCollections.observableArrayList(); >> persons.add(new Person("Harry", "200.00", "210.00")); >> persons.add(new Person("Jacob", "260.00", "260.00")); >> >> TableView tableView = new TableView<>(); >> tableView.getColumns().addAll(fnCol, priceCol, totalCol); >> tableView.setItems(persons); >> tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); >> tableView.setMinWidth(500); >> tableView.maxWidthProperty().bind(tableView.minWidthProperty()); >> >> Button button1 = new Button("Reduce 1px"); >> button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); >> Button button2 = new Button("Reduce 10px"); >> button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); >> Button button3 = new Button("Reset"); >> button3.setOnAction(e -> tableView.setMinWidth(500)); >> Button button4 = new Button("Increase 1px"); >> button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); >> Button button5 = new Button("Increase 10px"); >> button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); >> >> HBox row = new HBox(button1, button2, button3, button4, button5); >> row.setSpacing(10); >> TextArea output = new TextArea(); >> >> addWidthListeners(tableView, output); >> VBox root = new VBox(row, new Group(tableView), output); >> root.setSpacing(10); >> root.setPadding(new Insets(10)); >> >> Scene scene = new Scene(root); >> primaryStage.setScene(scene); >> primaryStage.setTitle("Constrained Resize Policy Issue TableView"); >> primaryStage.show(); >> } >> >> private void addWidthListeners(TableView tableView, TextArea output) { >> tableView.widthProperty().addListener((obs, old, val) -> { >> String str = "Table width changed :: " + val + "\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> tableView.getColumns().forEach(column -> { >> column.widthProperty().addListener((obs, old, width) -> { >> String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; >> output.setText(output.getText() + str); >> output.positionCaret(output.getText().length()); >> }); >> }); >> } >> >> class Person { >> private StringProperty firstName = new SimpleStringProperty(); >> private StringProperty price = new SimpleStringProperty(); >> private StringProperty total = new SimpleStringProperty(); >> >> public Person(String fn, String price, String total) { >> setFirstName(fn); >> setPrice(price); >> setTotal(total); >> } >> >> public StringProperty firstNameProperty() { >> return firstName; >> } >> >> public void setFirstName(String firstName) { >> this.firstName.set(firstName); >> } >> >> public StringProperty priceProperty() { >> return price; >> } >> >> public void setPrice(String price) { >> this.price.set(price); >> } >> >> public StringProperty totalProperty() { >> return total; >> } >> >> public void setTotal(String total) { >> this.total.set(total); >> } >> } >> } >> >> >> **Fix:** >> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. >> >> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 >> >> `if (Math.abs(colWidth - tableWidth) > 1) {` >> >> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright review comments The fix looks good. I tested it with the manual demo as well as verified that the new unit test fails without the fix and passes with the fix. I left a few (relatively minor) comments on the test. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5822: > 5820: ScrollBar horizontalBar = VirtualFlowTestUtils.getVirtualFlowHorizontalScrollbar(table); > 5821: assertNotNull(horizontalBar); > 5822: assertEquals(false, horizontalBar.isVisible()); Since you are testing against a constant, `assertFalse` would be clearer than `assertEquals(false` modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5823: > 5821: assertNotNull(horizontalBar); > 5822: assertEquals(false, horizontalBar.isVisible()); > 5823: assertTrue(table.getWidth() == initialWidth); We typically use `assertEquals` in this case, which provides a better error message if it fails. You can use a delta of 0 if you are sure they will compare exactly, or else a small delta value (e.g., 0.0001). assertEquals(initialWidth, table.getWidth(), 0); modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5826: > 5824: > 5825: // Reduce table width by 10px > 5826: table.setMinWidth(initialWidth-10); Minor: we usually put a space around binary operators. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5829: > 5827: Toolkit.getToolkit().firePulse(); > 5828: assertTrue(table.getWidth() == initialWidth-10); > 5829: assertEquals(false, horizontalBar.isVisible()); Same two comments here. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5835: > 5833: Toolkit.getToolkit().firePulse(); > 5834: assertTrue(table.getWidth() == initialWidth); > 5835: assertEquals(false, horizontalBar.isVisible()); And here. modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5841: > 5839: Toolkit.getToolkit().firePulse(); > 5840: assertTrue(table.getWidth() == initialWidth-1); > 5841: assertEquals(false, horizontalBar.isVisible()); And here. ------------- PR: https://git.openjdk.org/jfx/pull/848 From duke at openjdk.org Wed Aug 17 02:21:30 2022 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Wed, 17 Aug 2022 02:21:30 GMT Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. [v7] In-Reply-To: References: Message-ID: > **Issue:** > When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced. > > **Cause:** > The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. > > Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging). > > To confirm this behaviour, please find the below example that showcases the issue: > When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly. > > > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.beans.property.StringProperty; > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import javafx.geometry.Insets; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.control.*; > import javafx.scene.layout.HBox; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class ConstrainedResizePolicyIssueDemo extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > TableColumn fnCol = new TableColumn<>("First Name"); > fnCol.setMinWidth(100); > fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty()); > > TableColumn priceCol = new TableColumn<>("Price"); > priceCol.setMinWidth(100); > priceCol.setMaxWidth(150); > priceCol.setCellValueFactory(param -> param.getValue().priceProperty()); > > TableColumn totalCol = new TableColumn<>("Total"); > totalCol.setMinWidth(100); > totalCol.setMaxWidth(150); > totalCol.setCellValueFactory(param -> param.getValue().totalProperty()); > > ObservableList persons = FXCollections.observableArrayList(); > persons.add(new Person("Harry", "200.00", "210.00")); > persons.add(new Person("Jacob", "260.00", "260.00")); > > TableView tableView = new TableView<>(); > tableView.getColumns().addAll(fnCol, priceCol, totalCol); > tableView.setItems(persons); > tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); > tableView.setMinWidth(500); > tableView.maxWidthProperty().bind(tableView.minWidthProperty()); > > Button button1 = new Button("Reduce 1px"); > button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1)); > Button button2 = new Button("Reduce 10px"); > button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10)); > Button button3 = new Button("Reset"); > button3.setOnAction(e -> tableView.setMinWidth(500)); > Button button4 = new Button("Increase 1px"); > button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1)); > Button button5 = new Button("Increase 10px"); > button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10)); > > HBox row = new HBox(button1, button2, button3, button4, button5); > row.setSpacing(10); > TextArea output = new TextArea(); > > addWidthListeners(tableView, output); > VBox root = new VBox(row, new Group(tableView), output); > root.setSpacing(10); > root.setPadding(new Insets(10)); > > Scene scene = new Scene(root); > primaryStage.setScene(scene); > primaryStage.setTitle("Constrained Resize Policy Issue TableView"); > primaryStage.show(); > } > > private void addWidthListeners(TableView tableView, TextArea output) { > tableView.widthProperty().addListener((obs, old, val) -> { > String str = "Table width changed :: " + val + "\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > tableView.getColumns().forEach(column -> { > column.widthProperty().addListener((obs, old, width) -> { > String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n"; > output.setText(output.getText() + str); > output.positionCaret(output.getText().length()); > }); > }); > } > > class Person { > private StringProperty firstName = new SimpleStringProperty(); > private StringProperty price = new SimpleStringProperty(); > private StringProperty total = new SimpleStringProperty(); > > public Person(String fn, String price, String total) { > setFirstName(fn); > setPrice(price); > setTotal(total); > } > > public StringProperty firstNameProperty() { > return firstName; > } > > public void setFirstName(String firstName) { > this.firstName.set(firstName); > } > > public StringProperty priceProperty() { > return price; > } > > public void setPrice(String price) { > this.price.set(price); > } > > public StringProperty totalProperty() { > return total; > } > > public void setTotal(String total) { > this.total.set(total); > } > } > } > > > **Fix:** > On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px. > > The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226 > > `if (Math.abs(colWidth - tableWidth) > 1) {` > > If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly. Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: Fixed test review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/848/files - new: https://git.openjdk.org/jfx/pull/848/files/b066026a..a9a689e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=848&range=05-06 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/848.diff Fetch: git fetch https://git.openjdk.org/jfx pull/848/head:pull/848 PR: https://git.openjdk.org/jfx/pull/848 From aghaisas at openjdk.org Wed Aug 17 06:39:29 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 17 Aug 2022 06:39:29 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> Message-ID: On Fri, 12 Aug 2022 15:08:27 GMT, Andy Goryachev wrote: >>> >>> The tests were added to both TableViewSelectionModelImplTest and TreeTableViewSelectionModelImplTest. >> >> hmm .. in TreeTableViewSelectionModelImplTest, I don't see any of the testRowSelectionAfterSelectAndHideLastColumnXX nor testSelectRowWhenInSingleCellSelectionModeIsSelected, what am I missing? > >> hmm .. in TreeTableViewSelectionModelImplTest, I don't see any of the testRowSelectionAfterSelectAndHideLastColumnXX nor testSelectRowWhenInSingleCellSelectionModeIsSelected, what am I missing? > > you are right... I am so sorry. missed this one while cherry picking from another branch. will fix it soon. > > would it be possible to review https://github.com/openjdk/jfx/pull/858 so there is no need to cherry pick, please? I see a very good progress on this PR. Thanks @andy-goryachev-oracle and @kleopatra ! Only thing that needs to be corrected is - the PR description has become out of date with all the review change fixes. ------------- PR: https://git.openjdk.org/jfx/pull/839 From duke at openjdk.org Wed Aug 17 07:29:55 2022 From: duke at openjdk.org (Paul) Date: Wed, 17 Aug 2022 07:29:55 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v9] In-Reply-To: References: Message-ID: <489U1floHLzWMbk0DXral59Ul0MO7QPXC71zp5rWR18=.4a0d83cf-bc94-4e48-aae6-5a404755217b@github.com> > I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. > > Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. > > Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- > > > if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { > NSSize imgSize = {width / sx, height / sy}; > [image setSize: imgSize]; > } > > > The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. > > Before this fix:- > > Screenshot 2022-02-26 at 22 16 30 > > After this fix:- > > Screenshot 2022-02-26 at 22 18 17 Paul has updated the pull request incrementally with one additional commit since the last revision: Code improvements based on review feedback. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/743/files - new: https://git.openjdk.org/jfx/pull/743/files/2e4fe747..e9671f82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=743&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=743&range=07-08 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/743.diff Fetch: git fetch https://git.openjdk.org/jfx pull/743/head:pull/743 PR: https://git.openjdk.org/jfx/pull/743 From duke at openjdk.org Wed Aug 17 07:29:56 2022 From: duke at openjdk.org (Paul) Date: Wed, 17 Aug 2022 07:29:56 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v8] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 09:15:36 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul has updated the pull request incrementally with one additional commit since the last revision: > > A few more minor code cleanups I'll leave the scalex/y checks as they are, otherwise it will require two more if checks in the block for a situation which is almost certainly not going to happen. I've made the other changes you suggested. ------------- PR: https://git.openjdk.org/jfx/pull/743 From arapte at openjdk.org Wed Aug 17 08:33:09 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 08:33:09 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader Message-ID: Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. With this fix: 1. Windows narrator reads the dialog correctly 2. JAWS fails to read the header text. : This will be handled separately 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. Verification: 1. Run HelloAlert toy app, with fix. 2. Start Windows Narrator 3. Click on the different buttons to show different Dialogs => Observe that Narrator reads all the content correctly. ------------- Commit messages: - unit test - Add DIALOG role Changes: https://git.openjdk.org/jfx/pull/873/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=873&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8087557 Stats: 36 lines in 5 files changed: 34 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/873.diff Fetch: git fetch https://git.openjdk.org/jfx pull/873/head:pull/873 PR: https://git.openjdk.org/jfx/pull/873 From lbourges at openjdk.org Wed Aug 17 09:12:38 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 17 Aug 2022 09:12:38 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Thu, 13 Jan 2022 08:35:08 GMT, Johan Vos wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> added test for huge polygon coords > > Building and testing works, I am looking into the diffs as well now. > The DualPivotQuicksort20191112Ext seems to be an improved version of what is in java.util. Ideally, we can somehow extend or leverage the version in java.util without duplicating the original code. > For testing: one of the tests I would like to do is to see if the complexity increases as expected when increasing coordinates. Since the original Dual-Pivot quicksort has O(n log(n)) time complexity, it should be possible to have an upper bound on the number of invocations. @johanvos do you approve this patch too? ------------- PR: https://git.openjdk.org/jfx/pull/674 From lbourges at openjdk.org Wed Aug 17 09:12:42 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 17 Aug 2022 09:12:42 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.6 [v6] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Tue, 16 Aug 2022 21:48:37 GMT, Kevin Rushforth wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed dpqs javadoc + tests (setupOnce) > > modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 52: > >> 50: public final class DualPivotQuicksort20191112Ext { >> 51: >> 52: private static final boolean FAST_ISORT = true; > > How much testing have you done with this flag set to true? This is a validated shortcut as dpqs main loop also uses insertionsort on small arrays too, functionally equivalent. > modules/javafx.graphics/src/main/java/com/sun/marlin/DualPivotQuicksort20191112Ext.java line 784: > >> 782: * @param srcB the source array for the secondary array to be ordered (b) >> 783: * @param offset the start index in the source, inclusive >> 784: * @param dstB the temporary buffer used in merging (b) > > Minor: this should probably be moved before `offset` Sure, will fix this line before integration ------------- PR: https://git.openjdk.org/jfx/pull/674 From arapte at openjdk.org Wed Aug 17 12:10:08 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 12:10:08 GMT Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e Message-ID: Update libjpeg to current version release [9e](http://www.ijg.org/) of 16-Jan-2022 reference: https://jpegclub.org/reference/reference-sources/ Verified all test run on Windows and MacOS ------------- Commit messages: - Merge branch 'master' into jpeg-9e - lib jpeg 9e Changes: https://git.openjdk.org/jfx/pull/874/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289542 Stats: 525 lines in 25 files changed: 154 ins; 132 del; 239 mod Patch: https://git.openjdk.org/jfx/pull/874.diff Fetch: git fetch https://git.openjdk.org/jfx pull/874/head:pull/874 PR: https://git.openjdk.org/jfx/pull/874 From kcr at openjdk.org Wed Aug 17 12:57:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 12:57:35 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v9] In-Reply-To: <489U1floHLzWMbk0DXral59Ul0MO7QPXC71zp5rWR18=.4a0d83cf-bc94-4e48-aae6-5a404755217b@github.com> References: <489U1floHLzWMbk0DXral59Ul0MO7QPXC71zp5rWR18=.4a0d83cf-bc94-4e48-aae6-5a404755217b@github.com> Message-ID: On Wed, 17 Aug 2022 07:29:55 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul has updated the pull request incrementally with one additional commit since the last revision: > > Code improvements based on review feedback. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Wed Aug 17 12:57:36 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 12:57:36 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v8] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 09:46:26 GMT, Jose Pereda wrote: >> Paul has updated the pull request incrementally with one additional commit since the last revision: >> >> A few more minor code cleanups > > Looks good @jperedadnr can you re-review (only minor change since you last approved it)? ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Wed Aug 17 13:13:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 13:13:35 GMT Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e In-Reply-To: References: Message-ID: <7ABWLRvcfARWYH15ZDJEqobTOAkq0B4dOeUxBgN7wG4=.a185e2dd-e79f-4a9d-90b5-f7f8eac47b7e@github.com> On Wed, 17 Aug 2022 12:02:04 GMT, Ambarish Rapte wrote: > Update libjpeg to current version release [9e](http://www.ijg.org/) of 16-Jan-2022 > > reference: https://jpegclub.org/reference/reference-sources/ > > Verified all test run on Windows and MacOS Can you rerun the macOS GHA job? It timed out downloading `ant`. Btw, we've seen this a lot more lately, so I filed [JDK-8292549](https://bugs.openjdk.org/browse/JDK-8292549) to track it. ------------- PR: https://git.openjdk.org/jfx/pull/874 From jpereda at openjdk.org Wed Aug 17 13:19:32 2022 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 17 Aug 2022 13:19:32 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v9] In-Reply-To: <489U1floHLzWMbk0DXral59Ul0MO7QPXC71zp5rWR18=.4a0d83cf-bc94-4e48-aae6-5a404755217b@github.com> References: <489U1floHLzWMbk0DXral59Ul0MO7QPXC71zp5rWR18=.4a0d83cf-bc94-4e48-aae6-5a404755217b@github.com> Message-ID: <4WBUjAwhw77JdzfuddVZd4iotRBtRCIyCBZRJAXOs5o=.e0792192-ab2f-442b-8b21-9391b21c42d9@github.com> On Wed, 17 Aug 2022 07:29:55 GMT, Paul wrote: >> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. >> >> Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. >> >> Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- >> >> >> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { >> NSSize imgSize = {width / sx, height / sy}; >> [image setSize: imgSize]; >> } >> >> >> The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. >> >> Before this fix:- >> >> Screenshot 2022-02-26 at 22 16 30 >> >> After this fix:- >> >> Screenshot 2022-02-26 at 22 18 17 > > Paul has updated the pull request incrementally with one additional commit since the last revision: > > Code improvements based on review feedback. Looks good ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Wed Aug 17 13:35:21 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 13:35:21 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 08:26:48 GMT, Ambarish Rapte wrote: > Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. > Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. > With this fix: > 1. Windows narrator reads the dialog correctly > 2. JAWS fails to read the header text. : This will be handled separately > 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. > > Verification: > 1. Run HelloAlert toy app, with fix. > 2. Start Windows Narrator > 3. Click on the different buttons to show different Dialogs > => Observe that Narrator reads all the content correctly. This will need a CSR since you are adding a new enum value to `AccessibleRole`. ------------- PR: https://git.openjdk.org/jfx/pull/873 From arapte at openjdk.org Wed Aug 17 13:36:59 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:36:59 GMT Subject: [jfx11u] RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Message-ID: Not a clean backport. Following two files are not present in jfx11. 1. .github/workflows/submit.yml 2. gradle/verification-metadata.xml ------------- Commit messages: - 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Changes: https://git.openjdk.org/jfx11u/pull/104/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283786 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx11u/pull/104.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/104/head:pull/104 PR: https://git.openjdk.org/jfx11u/pull/104 From arapte at openjdk.org Wed Aug 17 13:41:33 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:41:33 GMT Subject: [jfx11u] RFR: 8088420: JavaFX WebView memory leak via EventListener Message-ID: Clean backport to jfx11u. ------------- Commit messages: - 8088420: JavaFX WebView memory leak via EventListener Changes: https://git.openjdk.org/jfx11u/pull/105/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8088420 Stats: 1509 lines in 11 files changed: 1503 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jfx11u/pull/105.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/105/head:pull/105 PR: https://git.openjdk.org/jfx11u/pull/105 From arapte at openjdk.org Wed Aug 17 13:41:39 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:41:39 GMT Subject: [jfx11u] RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:30:54 GMT, Ambarish Rapte wrote: > Not a clean backport. > Following two files are not present in jfx11. > > 1. .github/workflows/submit.yml > 2. gradle/verification-metadata.xml @kevinrushforth Please take a look, this is not a clean backport. ------------- PR: https://git.openjdk.org/jfx11u/pull/104 From arapte at openjdk.org Wed Aug 17 13:42:22 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:42:22 GMT Subject: [jfx11u] RFR: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Message-ID: Clean backport to jfx11u. ------------- Commit messages: - 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Changes: https://git.openjdk.org/jfx11u/pull/106/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289587 Stats: 180 lines in 3 files changed: 174 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx11u/pull/106.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/106/head:pull/106 PR: https://git.openjdk.org/jfx11u/pull/106 From arapte at openjdk.org Wed Aug 17 13:42:37 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:42:37 GMT Subject: [jfx11u] RFR: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Message-ID: Clean backport to jfx11u. ------------- Commit messages: - 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Changes: https://git.openjdk.org/jfx11u/pull/107/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289952 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx11u/pull/107.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/107/head:pull/107 PR: https://git.openjdk.org/jfx11u/pull/107 From arapte at openjdk.org Wed Aug 17 13:47:41 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 13:47:41 GMT Subject: [jfx11u] RFR: 8284676: TreeTableView loses sort ordering when applied on empty table Message-ID: Clean backport to jfx11u ------------- Commit messages: - 8284676: TreeTableView loses sort ordering when applied on empty table Changes: https://git.openjdk.org/jfx11u/pull/108/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=108&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284676 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx11u/pull/108.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/108/head:pull/108 PR: https://git.openjdk.org/jfx11u/pull/108 From kcr at openjdk.org Wed Aug 17 13:48:35 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 13:48:35 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 08:26:48 GMT, Ambarish Rapte wrote: > Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. > Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. > With this fix: > 1. Windows narrator reads the dialog correctly > 2. JAWS fails to read the header text. : This will be handled separately > 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. > > Verification: > 1. Run HelloAlert toy app, with fix. > 2. Start Windows Narrator > 3. Click on the different buttons to show different Dialogs > => Observe that Narrator reads all the content correctly. I left some comments on the `AccessibleRole.DIALOG` docs. Also, I get the following exception on macOS with VoiceOver when opening any dialog: Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot read field "ptr" because "macRole" is null at javafx.graphics at 20-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValue(MacAccessible.java:1305) at javafx.graphics at 20-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method) at javafx.graphics at 20-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(MacApplication.java:168) at javafx.graphics at 20-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:515) at javafx.graphics at 20-internal/com.sun.glass.ui.EventLoop.enter(EventLoop.java:107) at javafx.graphics at 20-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:631) at javafx.graphics at 20-internal/javafx.stage.Stage.showAndWait(Stage.java:469) at javafx.controls at 20-internal/javafx.scene.control.HeavyweightDialog.showAndWait(HeavyweightDialog.java:162) at javafx.controls at 20-internal/javafx.scene.control.Dialog.showAndWait(Dialog.java:345) at hello.HelloAlert.lambda$start$0(HelloAlert.java:79) ... You will need to at least implement a stub on macOS. modules/javafx.graphics/src/main/java/javafx/scene/AccessibleRole.java line 832: > 830: *

    > 831: *
  • {@link AccessibleAttribute#TEXT}
  • > 832: *
  • {@link AccessibleAttribute#ROLE_DESCRIPTION}
  • What is the purpose of adding `ROLE_DESCRIPTION` here? It isn't listed anywhere else except as an optional `Node` attribute. modules/javafx.graphics/src/main/java/javafx/scene/AccessibleRole.java line 836: > 834: *
> 835: */ > 836: DIALOG You need to add a `@since 20` tag. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/873 From kcr at openjdk.org Wed Aug 17 13:51:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 13:51:22 GMT Subject: [jfx11u] RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:30:54 GMT, Ambarish Rapte wrote: > Not a clean backport. > Following two files are not present in jfx11. > > 1. .github/workflows/submit.yml > 2. gradle/verification-metadata.xml LGTM ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx11u/pull/104 From arapte at openjdk.org Wed Aug 17 14:17:24 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 14:17:24 GMT Subject: [jfx11u] Integrated: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:30:54 GMT, Ambarish Rapte wrote: > Not a clean backport. > Following two files are not present in jfx11. > > 1. .github/workflows/submit.yml > 2. gradle/verification-metadata.xml This pull request has now been integrated. Changeset: dd358152 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/dd35815245d0d43ef9aa720fcc5a60dd556664a9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Reviewed-by: kcr Backport-of: 6d126382ddd59757081a866517c36ff09ba20125 ------------- PR: https://git.openjdk.org/jfx11u/pull/104 From arapte at openjdk.org Wed Aug 17 14:19:27 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 14:19:27 GMT Subject: [jfx11u] Integrated: 8088420: JavaFX WebView memory leak via EventListener In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:33:12 GMT, Ambarish Rapte wrote: > Clean backport to jfx11u. This pull request has now been integrated. Changeset: 24e053bb Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/24e053bb62faf2a99c16f528e9030c416418edc2 Stats: 1509 lines in 11 files changed: 1503 ins; 3 del; 3 mod 8088420: JavaFX WebView memory leak via EventListener Backport-of: f5348503143e8d08f09b4cd48b6a3864bd09c336 ------------- PR: https://git.openjdk.org/jfx11u/pull/105 From arapte at openjdk.org Wed Aug 17 14:20:32 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 14:20:32 GMT Subject: [jfx11u] Integrated: 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:34:42 GMT, Ambarish Rapte wrote: > Clean backport to jfx11u. This pull request has now been integrated. Changeset: d3e8fe12 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/d3e8fe126591d7df04601ff3661eaf6d8151de13 Stats: 180 lines in 3 files changed: 174 ins; 0 del; 6 mod 8289587: IllegalArgumentException: Color.rgb's red parameter (-16776961) expects color values 0-255 Backport-of: fc6a60234b0feec80b05257cc93407f651805303 ------------- PR: https://git.openjdk.org/jfx11u/pull/106 From arapte at openjdk.org Wed Aug 17 14:20:41 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 14:20:41 GMT Subject: [jfx11u] Integrated: 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:35:47 GMT, Ambarish Rapte wrote: > Clean backport to jfx11u. This pull request has now been integrated. Changeset: 19268eb0 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/19268eb01c0686b143bbb8bfc34c05a09c13931b Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod 8289952: Visual Studio libs msvcp140_1.dll and msvcp140_2.dll missing from build Backport-of: cbb53b22fc87e880d59ac3e217a86a4733d2b0f3 ------------- PR: https://git.openjdk.org/jfx11u/pull/107 From arapte at openjdk.org Wed Aug 17 14:24:26 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 14:24:26 GMT Subject: [jfx11u] Integrated: 8284676: TreeTableView loses sort ordering when applied on empty table In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:36:52 GMT, Ambarish Rapte wrote: > Clean backport to jfx11u This pull request has now been integrated. Changeset: 190dddfb Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/190dddfbac436be26ad9e1f99eeeb7b9ae7990a6 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod 8284676: TreeTableView loses sort ordering when applied on empty table Backport-of: 0132ac89033334ec9d9ec6149d116e8c352f89ec ------------- PR: https://git.openjdk.org/jfx11u/pull/108 From kcr at openjdk.org Wed Aug 17 14:47:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 14:47:11 GMT Subject: [jfx17u] RFR: 8291051: Update boot JDK to 17.0.4 Message-ID: This bumps the boot JDK used to build jfx17u to JDK 17.0.4. The minimum JDK that can run JavaFX 17.0.x is unchanged and remains at JDK 11. ------------- Commit messages: - 8291051: Update boot JDK to 17.0.4 Changes: https://git.openjdk.org/jfx17u/pull/78/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=78&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291051 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx17u/pull/78.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/78/head:pull/78 PR: https://git.openjdk.org/jfx17u/pull/78 From kcr at openjdk.org Wed Aug 17 14:47:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 14:47:12 GMT Subject: [jfx17u] RFR: 8291051: Update boot JDK to 17.0.4 In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:28:16 GMT, Kevin Rushforth wrote: > This bumps the boot JDK used to build jfx17u to JDK 17.0.4. The minimum JDK that can run JavaFX 17.0.x is unchanged and remains at JDK 11. Reviewer: @arapte ------------- PR: https://git.openjdk.org/jfx17u/pull/78 From angorya at openjdk.org Wed Aug 17 15:16:52 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 15:16:52 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v7] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> <_ZfFleEWEGrtlvRlQHW5mw3-UhzGArfMrXHfwObn7Rs=.3221fafa-7fb7-4c35-9673-5304fc03f079@github.com> Message-ID: On Wed, 17 Aug 2022 06:35:38 GMT, Ajit Ghaisas wrote: >>> hmm .. in TreeTableViewSelectionModelImplTest, I don't see any of the testRowSelectionAfterSelectAndHideLastColumnXX nor testSelectRowWhenInSingleCellSelectionModeIsSelected, what am I missing? >> >> you are right... I am so sorry. missed this one while cherry picking from another branch. will fix it soon. >> >> would it be possible to review https://github.com/openjdk/jfx/pull/858 so there is no need to cherry pick, please? > > I see a very good progress on this PR. Thanks @andy-goryachev-oracle and @kleopatra ! > Only thing that needs to be corrected is - the PR description has become out of date with all the review change fixes. updated PR description. thank you, @aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/839 From arapte at openjdk.org Wed Aug 17 15:23:00 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 15:23:00 GMT Subject: [jfx11u] RFR: 8285881: Update WebKit to 614.1 Message-ID: This is almost a clean backport, except a small conflict in a test file `LoadTest.java`. The conflict was because [fix](https://github.com/openjdk/jfx/commit/15e52d8f) for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696) is not backported to jfx11u. A test `testLoadLocalCSS()` was added as part of fix for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696), which is not present in jfx11u. No other conflict were observed. ------------- Commit messages: - 8285881: Update WebKit to 614.1 Changes: https://git.openjdk.org/jfx11u/pull/109/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285881 Stats: 447028 lines in 7345 files changed: 300706 ins; 103521 del; 42801 mod Patch: https://git.openjdk.org/jfx11u/pull/109.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/109/head:pull/109 PR: https://git.openjdk.org/jfx11u/pull/109 From arapte at openjdk.org Wed Aug 17 15:23:02 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 15:23:02 GMT Subject: [jfx11u] RFR: 8285881: Update WebKit to 614.1 In-Reply-To: References: Message-ID: <-reurp2WSRYI27Yel1V-TwEOOQH5PmUkXSbUr-ROsWk=.598975de-b0fa-4688-8adc-c027688d7005@github.com> On Wed, 17 Aug 2022 14:35:27 GMT, Ambarish Rapte wrote: > This is almost a clean backport, except a small conflict in a test file `LoadTest.java`. > > The conflict was because [fix](https://github.com/openjdk/jfx/commit/15e52d8f) for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696) is not backported to jfx11u. > A test `testLoadLocalCSS()` was added as part of fix for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696), which is not present in jfx11u. > > No other conflict were observed. @kevinrushforth Please take a look, there was minor conflict as explained in the description. ------------- PR: https://git.openjdk.org/jfx11u/pull/109 From kcr at openjdk.org Wed Aug 17 15:24:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 15:24:26 GMT Subject: [jfx11u] RFR: 8285881: Update WebKit to 614.1 In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:35:27 GMT, Ambarish Rapte wrote: > This is almost a clean backport, except a small conflict in a test file `LoadTest.java`. > > The conflict was because [fix](https://github.com/openjdk/jfx/commit/15e52d8f) for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696) is not backported to jfx11u. > A test `testLoadLocalCSS()` was added as part of fix for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696), which is not present in jfx11u. > > No other conflict were observed. Odd that Skara marked this as clean given that there was a (trivial) merge conflict that had to be resolved. I plan to file a bug against Skara. ------------- PR: https://git.openjdk.org/jfx11u/pull/109 From arapte at openjdk.org Wed Aug 17 15:24:29 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 15:24:29 GMT Subject: [jfx11u] Integrated: 8285881: Update WebKit to 614.1 In-Reply-To: References: Message-ID: <8t1nKTIruNjDOvLN8V10YEWb3e0G_BHNOxWz3M0wvJg=.c9e5ac29-0246-41f2-b86f-e642f21084c9@github.com> On Wed, 17 Aug 2022 14:35:27 GMT, Ambarish Rapte wrote: > This is almost a clean backport, except a small conflict in a test file `LoadTest.java`. > > The conflict was because [fix](https://github.com/openjdk/jfx/commit/15e52d8f) for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696) is not backported to jfx11u. > A test `testLoadLocalCSS()` was added as part of fix for [JDK-8253696](https://bugs.openjdk.org/browse/JDK-8253696), which is not present in jfx11u. > > No other conflict were observed. This pull request has now been integrated. Changeset: 4bd6877d Author: Ambarish Rapte URL: https://git.openjdk.org/jfx11u/commit/4bd6877dbd46e37f6774c50dcdc98a8a1ab41214 Stats: 447028 lines in 7345 files changed: 300706 ins; 103521 del; 42801 mod 8285881: Update WebKit to 614.1 Backport-of: 7e48413eb0f9eb3dcbd9d3a1572fc311036092c8 ------------- PR: https://git.openjdk.org/jfx11u/pull/109 From angorya at openjdk.org Wed Aug 17 15:27:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 15:27:34 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v10] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Mon, 15 Aug 2022 10:29:17 GMT, Jeanette Winzenburg wrote: >> unnecessary in the case of TableRow. >> the change in TreeTableRow was necessary because otherwise selecting a cell by mouse selected the whole row. > >> unnecessary in the case of TableRow. > > that is .. why exactly? > >> the change in TreeTableRow was necessary because otherwise selecting a cell by mouse selected the whole row. > > it still does (if all cells are selected) > > see me in grinning - my first guess was exactly the same as yours, but the moment I was about answering your comment (with "should behave the same and _they do_") some memory neuron fired and made me curious enough the check. The outcome is [JDK-8292353](https://bugs.openjdk.org/browse/JDK-8292353) > > as that is unrelated to this fix (same before/after), we are fine here [JDK-8292353](https://bugs.openjdk.org/browse/JDK-8292353) can be trivially fixed (PR to be filed). ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Wed Aug 17 15:29:41 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 15:29:41 GMT Subject: RFR: 8290274: DRT 27 tests fail due to xml not well formed error on window In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 10:06:21 GMT, Jay Bhaskar wrote: > Issue: xml not well-formed error occurs at XML document parser. > Issue: doEnd() call not needed for JAVA platform, as it is making XMLDocumentParserLibxml2 xml not well-formed error. Additional testing reveals a test failure on macOS that needs to be evaluated. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/866 From arapte at openjdk.org Wed Aug 17 16:18:33 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 16:18:33 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v2] In-Reply-To: References: Message-ID: > Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. > Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. > With this fix: > 1. Windows narrator reads the dialog correctly > 2. JAWS fails to read the header text. : This will be handled separately > 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. > > Verification: > 1. Run HelloAlert toy app, with fix. > 2. Start Windows Narrator > 3. Click on the different buttons to show different Dialogs > => Observe that Narrator reads all the content correctly. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review comment : mac NPE ------------- Changes: - all: https://git.openjdk.org/jfx/pull/873/files - new: https://git.openjdk.org/jfx/pull/873/files/408561b4..39d18967 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=873&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=873&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/873.diff Fetch: git fetch https://git.openjdk.org/jfx pull/873/head:pull/873 PR: https://git.openjdk.org/jfx/pull/873 From arapte at openjdk.org Wed Aug 17 16:22:23 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 16:22:23 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:33:47 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment : mac NPE > > modules/javafx.graphics/src/main/java/javafx/scene/AccessibleRole.java line 832: > >> 830: *
    >> 831: *
  • {@link AccessibleAttribute#TEXT}
  • >> 832: *
  • {@link AccessibleAttribute#ROLE_DESCRIPTION}
  • > > What is the purpose of adding `ROLE_DESCRIPTION` here? It isn't listed anywhere else except as an optional `Node` attribute. Reason to include `ROLE_DESCRIPTION` explicitly is that role description is fetched and read by the accessibility client application. The change in MacAccessible.java line 1302 and in WinAccessible line 799, are specifically for ROLE_DESCRIPTION. Windows Narrator appends this role description after dialog title. ------------- PR: https://git.openjdk.org/jfx/pull/873 From arapte at openjdk.org Wed Aug 17 16:36:24 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 16:36:24 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v3] In-Reply-To: References: Message-ID: > Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. > Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. > With this fix: > 1. Windows narrator reads the dialog correctly > 2. JAWS fails to read the header text. : This will be handled separately > 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. > > Verification: > 1. Run HelloAlert toy app, with fix. > 2. Start Windows Narrator > 3. Click on the different buttons to show different Dialogs > => Observe that Narrator reads all the content correctly. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review comment, add since 20 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/873/files - new: https://git.openjdk.org/jfx/pull/873/files/39d18967..28dc3900 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=873&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=873&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/873.diff Fetch: git fetch https://git.openjdk.org/jfx pull/873/head:pull/873 PR: https://git.openjdk.org/jfx/pull/873 From arapte at openjdk.org Wed Aug 17 16:36:27 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 Aug 2022 16:36:27 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v3] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 13:45:10 GMT, Kevin Rushforth wrote: > I get the following exception on macOS with VoiceOver when opening any dialog: It is fixed in next [commit](https://github.com/openjdk/jfx/pull/873/commits/39d1896751fe6709469ff79380ad15e7493f4879) It was caused when VoiceOver requested role description for DIALOG role. > modules/javafx.graphics/src/main/java/javafx/scene/AccessibleRole.java line 836: > >> 834: *
>> 835: */ >> 836: DIALOG > > You need to add a `@since 20` tag. Added the tag. ------------- PR: https://git.openjdk.org/jfx/pull/873 From nlisker at openjdk.org Wed Aug 17 17:42:25 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 17:42:25 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com> <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com> <0okvvkrjS89IXbBAtr_N2OqaXgXjg2gRW_wggc7pzHQ=.65c7501d-b1e5-4abd-8d57-9b30114841de@github.com> Message-ID: <1QIK7iTzZenVVbySu3sr63xOrtCTRkYb5fGBDZEA54g=.629dbc94-28e0-4128-b236-58dc2ccc43ab@github.com> On Mon, 15 Aug 2022 10:03:11 GMT, Nir Lisker wrote: >> Command to run the system test: >> `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test --tests test.robot.test3d.PointLightIlluminationTest` >> >> I ran all the tests, only above test failed: >> Command to run all the system tests: `gradle -PFULL_TEST=true -PUSE_ROBOT=true systemTests:test` > > First of all, I found that the mistake was in the shortcut branch of the shader: it was using the light direction instead of the vector to the light (incident ray), so in the code I need to replace `dot(n, -lightDir)` with `dot(n, -l)`, like is done in the full computation branch. Then the test passes with the `0` input for no-attenuation. Thanks. > > Then I looked at the computation some more and I found something in the computation of the specular component. According to the theory, both in online sources and in the `PhongMaterial` class doc, the computation should be: > `R . V` where `V` is the vector to the eye/cam and `R` is the reflection vector computed by `R = 2(N . L)N - L`, or using the [reflect](https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-reflect) HLSL function, `R = -reflect(N, L)`. So the shader files should look something like this: > > float3 refl = reflect(l, n); > s = ... dot(-refl, e); // e is the vector to the eye, like V > > However, looking at the shader files, [already from legacy](https://github.com/openjdk/jfx/blob/c420248b9b459efcfbd3657170d9be0b96b5fb38/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h), the vectors are switched: > > float3 refl = reflect(e, n); > s = ... dot(-refl, l); > > It looks like the specular computation was wrong from the start. > > I tested the visuals on the `master` branch before and after swapping the `l` and `e` vectors and I see no difference in the specular reflection. Rather odd. Will need to look into this more. > > The same mistakes are coded into the glsl shaders too, so I should fix the one you found at the very least. @kevinrushforth maybe you can take a look at this too. ------------- PR: https://git.openjdk.org/jfx/pull/789 From duke at openjdk.org Wed Aug 17 18:54:23 2022 From: duke at openjdk.org (Paul) Date: Wed, 17 Aug 2022 18:54:23 GMT Subject: Integrated: 8181084: JavaFX show big icons in system menu on macOS with Retina display In-Reply-To: References: Message-ID: On Sun, 27 Feb 2022 11:42:58 GMT, Paul wrote: > I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. > > Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. > > Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- > > > if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { > NSSize imgSize = {width / sx, height / sy}; > [image setSize: imgSize]; > } > > > The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. > > Before this fix:- > > Screenshot 2022-02-26 at 22 16 30 > > After this fix:- > > Screenshot 2022-02-26 at 22 18 17 This pull request has now been integrated. Changeset: 2618bf8a Author: Paul Court Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/2618bf8aeef3c9d9d923576e8a610f5e9b2123f1 Stats: 103 lines in 14 files changed: 97 ins; 3 del; 3 mod 8181084: JavaFX show big icons in system menu on macOS with Retina display Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.org/jfx/pull/743 From kcr at openjdk.org Wed Aug 17 18:58:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 18:58:25 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v3] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:36:24 GMT, Ambarish Rapte wrote: >> Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. >> Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. >> With this fix: >> 1. Windows narrator reads the dialog correctly >> 2. JAWS fails to read the header text. : This will be handled separately >> 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. >> >> Verification: >> 1. Run HelloAlert toy app, with fix. >> 2. Start Windows Narrator >> 3. Click on the different buttons to show different Dialogs >> => Observe that Narrator reads all the content correctly. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review comment, add since 20 Looks good now. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/873 From angorya at openjdk.org Wed Aug 17 20:20:57 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 20:20:57 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode Message-ID: The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. Changes: - modified TreeTableRow.updateSelection() ------------- Commit messages: - 8292353: update selection Changes: https://git.openjdk.org/jfx/pull/875/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292353 Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/875.diff Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875 PR: https://git.openjdk.org/jfx/pull/875 From kcr at openjdk.org Wed Aug 17 20:48:31 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 20:48:31 GMT Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 12:02:04 GMT, Ambarish Rapte wrote: > Update libjpeg to current version release [9e](http://www.ijg.org/) of 16-Jan-2022 > > reference: https://jpegclub.org/reference/reference-sources/ > > Verified all test run on Windows and MacOS Looks good. I tested on all three platforms. I left a couple comments on questionable-looking indentation. modules/javafx.graphics/src/main/native-iio/libjpeg/jdcolor.c line 446: > 444: ci++, compptr++) { > 445: if (! compptr->component_needed) > 446: continue; /* skip uninteresting component */ The indentation looks off here. modules/javafx.graphics/src/main/native-iio/libjpeg/jdcolor.c line 882: > 880: for (ci = 0; ci < cinfo->num_components; ci++) > 881: if (cinfo->comp_info[ci].component_needed) > 882: i++; /* count output color components */ Indentation? modules/javafx.graphics/src/main/native-iio/libjpeg/jdmaster.c line 181: > 179: ci++, compptr++) > 180: if (compptr->component_needed) > 181: i++; /* count output color components */ intendation? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/874 From nlisker at openjdk.org Wed Aug 17 22:02:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:02:36 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 15:58:38 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > 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 13 additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8290473.apps > - Merge branch 'openjdk:master' into 8290473.apps > - 8290473: removed empty src sir > - 8290473: whitespace > - 8290473: init shader dirs > - 8290473: junit 5 > - Merge remote-tracking branch 'origin/master' into 8290473.apps > - 8290473: removed eclipse project in buildSrc > - 8290473: whitespace > - 8290473: added initDirs task > - ... and 3 more: https://git.openjdk.org/jfx/compare/900277ad...e86cb390 I also noticed that the `jfx` project is still named `rt` in its project file. Please fix that on the way. While it's possible to run apps, the project structure is wrong in that the source folders are projects and the folders are packages. ColorCube has the right configuration. A follow up for apps and test is needed. apps/samples/.classpath line 21: > 19: > 20: > 21: I'm getting the following errors on Samples: Description Resource Path Location Type Project 'samples' is missing required library: 'Ensemble8/lib/lucene-core-7.7.3.jar' samples Build path Build Path Problem Project 'samples' is missing required library: 'Ensemble8/lib/lucene-grouping-7.7.3.jar' samples Build path Build Path Problem Project 'samples' is missing required library: 'Ensemble8/lib/lucene-queryparser-7.7.3.jar' samples Build path Build Path Problem Project 'samples' is missing required source folder: '3DViewer/src/test/java' samples Build path Build Path Problem Project 'samples' is missing required source folder: '3DViewer/src/test/resources' samples Build path Build Path Problem Indeed, there is no `3DViewer/src/test` folder. How do you not get errors? apps/toys/.classpath line 9: > 7: > 8: > 9: Why are these the only 2 sources? build.gradle line 2508: > 2506: // Create empty hlsl dirs on all platforms for IDE support > 2507: file("$project.buildDir/hlsl/Decora").mkdirs() > 2508: file("$project.buildDir/hlsl/Prism").mkdirs() You need to create `build/gensrc/jsl-decora` and `build/gensrc/jsl-prism` too if they are not declared as optional sources in the classpath. buildSrc/.settings/org.eclipse.core.resources.prefs line 2: > 1: eclipse.preferences.version=1 > 2: encoding/=UTF-8 This file can be removed too since buildSrc is not a project. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Wed Aug 17 22:02:37 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:02:37 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v8] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 21:43:04 GMT, Andy Goryachev wrote: > Thank you all! If there are no more objections, I'd like to get this integrated, as it will save me from duplicate branches and continuous cherry-picking. You don't need to do that. Unless 2 branches work on the same code, there will be no conflicts, and this only happens for very long PRs. Skara will check conflicts and merge for you when integrating. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 17 22:07:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 22:07:25 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 20:30:10 GMT, Nir Lisker 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 13 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290473.apps >> - Merge branch 'openjdk:master' into 8290473.apps >> - 8290473: removed empty src sir >> - 8290473: whitespace >> - 8290473: init shader dirs >> - 8290473: junit 5 >> - Merge remote-tracking branch 'origin/master' into 8290473.apps >> - 8290473: removed eclipse project in buildSrc >> - 8290473: whitespace >> - 8290473: added initDirs task >> - ... and 3 more: https://git.openjdk.org/jfx/compare/65c861c0...e86cb390 > > apps/samples/.classpath line 21: > >> 19: >> 20: >> 21: > > I'm getting the following errors on Samples: > > Description Resource Path Location Type > Project 'samples' is missing required library: 'Ensemble8/lib/lucene-core-7.7.3.jar' samples Build path Build Path Problem > Project 'samples' is missing required library: 'Ensemble8/lib/lucene-grouping-7.7.3.jar' samples Build path Build Path Problem > Project 'samples' is missing required library: 'Ensemble8/lib/lucene-queryparser-7.7.3.jar' samples Build path Build Path Problem > Project 'samples' is missing required source folder: '3DViewer/src/test/java' samples Build path Build Path Problem > Project 'samples' is missing required source folder: '3DViewer/src/test/resources' samples Build path Build Path Problem > > Indeed, there is no `3DViewer/src/test` folder. How do you not get errors? For lucene, you'd need to run ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 17 22:13:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 22:13:37 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 20:26:12 GMT, Nir Lisker 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 13 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8290473.apps >> - Merge branch 'openjdk:master' into 8290473.apps >> - 8290473: removed empty src sir >> - 8290473: whitespace >> - 8290473: init shader dirs >> - 8290473: junit 5 >> - Merge remote-tracking branch 'origin/master' into 8290473.apps >> - 8290473: removed eclipse project in buildSrc >> - 8290473: whitespace >> - 8290473: added initDirs task >> - ... and 3 more: https://git.openjdk.org/jfx/compare/f4048f6d...e86cb390 > > apps/toys/.classpath line 9: > >> 7: >> 8: >> 9: > > Why are these the only 2 sources? the goal of this PR is to make a workable configuration. We have a separate ticket JDK-8221708 for apps and toys. > build.gradle line 2508: > >> 2506: // Create empty hlsl dirs on all platforms for IDE support >> 2507: file("$project.buildDir/hlsl/Decora").mkdirs() >> 2508: file("$project.buildDir/hlsl/Prism").mkdirs() > > You need to create `build/gensrc/jsl-decora` and `build/gensrc/jsl-prism` too if they are not declared as optional sources in the classpath. ok > buildSrc/.settings/org.eclipse.core.resources.prefs line 2: > >> 1: eclipse.preferences.version=1 >> 2: encoding/=UTF-8 > > This file can be removed too since buildSrc is not a project. ok ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 17 22:22:02 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 22:22:02 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v12] In-Reply-To: References: Message-ID: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8290473: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/858/files - new: https://git.openjdk.org/jfx/pull/858/files/e86cb390..ed13176e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=858&range=10-11 Stats: 6 lines in 3 files changed: 2 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/858.diff Fetch: git fetch https://git.openjdk.org/jfx pull/858/head:pull/858 PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Wed Aug 17 22:22:05 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 22:22:05 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: Message-ID: <5mwXDYyhRa0cvJDKtYjJMLMRLDalFMiD_aVraJ1NBT4=.b027c9b3-850c-4823-ac1a-3d5b113099a4@github.com> On Wed, 17 Aug 2022 22:05:24 GMT, Andy Goryachev wrote: >> apps/samples/.classpath line 21: >> >>> 19: >>> 20: >>> 21: >> >> I'm getting the following errors on Samples: >> >> Description Resource Path Location Type >> Project 'samples' is missing required library: 'Ensemble8/lib/lucene-core-7.7.3.jar' samples Build path Build Path Problem >> Project 'samples' is missing required library: 'Ensemble8/lib/lucene-grouping-7.7.3.jar' samples Build path Build Path Problem >> Project 'samples' is missing required library: 'Ensemble8/lib/lucene-queryparser-7.7.3.jar' samples Build path Build Path Problem >> Project 'samples' is missing required source folder: '3DViewer/src/test/java' samples Build path Build Path Problem >> Project 'samples' is missing required source folder: '3DViewer/src/test/resources' samples Build path Build Path Problem >> >> Indeed, there is no `3DViewer/src/test` folder. How do you not get errors? > > For lucene, you'd need to run > For lucene, you'd need to run > > ``` > /bin/sh gradlew getLucene > ``` > > to bring in the dependencies which are not a part of the repository. Btw, `gradle apps` will also work. ------------- PR: https://git.openjdk.org/jfx/pull/858 From kcr at openjdk.org Wed Aug 17 22:25:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Aug 2022 22:25:22 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v11] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Fri, 12 Aug 2022 17:21:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. modified TreeTableRow.updateSelection() to use the right isSelected() method >> 4. updated tests for Tree/TableView >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: added tests This all looks good to me now. I left one comment on the CSR, and I'll review that once that is done. This will give @aghaisas a chance to review as well. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/839 From nlisker at openjdk.org Wed Aug 17 22:34:26 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:34:26 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: <5mwXDYyhRa0cvJDKtYjJMLMRLDalFMiD_aVraJ1NBT4=.b027c9b3-850c-4823-ac1a-3d5b113099a4@github.com> References: <5mwXDYyhRa0cvJDKtYjJMLMRLDalFMiD_aVraJ1NBT4=.b027c9b3-850c-4823-ac1a-3d5b113099a4@github.com> Message-ID: <1Bu6zQ2vZd9RDdeiQwZzX012pQeDvtI6aNENgv9N97A=.6302c6b5-25a9-4582-b84d-0c0f18c5ea72@github.com> On Wed, 17 Aug 2022 22:17:30 GMT, Kevin Rushforth wrote: >> For lucene, you'd need to run > >> For lucene, you'd need to run >> >> ``` >> /bin/sh gradlew getLucene >> ``` >> >> to bring in the dependencies which are not a part of the repository. > > Btw, `gradle apps` will also work. If there are folders that aren't generated by the build task, we should note it in the build page of the wiki. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Wed Aug 17 22:37:38 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:37:38 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v12] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 22:22:02 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: review comments Changes look good. The only remaining issue is that the project file under the root directory is named "rt" while in Eclipse it's named "jfx". I'm not sure where Gradle is taking the name from. The problem is that you can import the "rt" project and get a duplicate project. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 17 22:37:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 22:37:39 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: <1Bu6zQ2vZd9RDdeiQwZzX012pQeDvtI6aNENgv9N97A=.6302c6b5-25a9-4582-b84d-0c0f18c5ea72@github.com> References: <5mwXDYyhRa0cvJDKtYjJMLMRLDalFMiD_aVraJ1NBT4=.b027c9b3-850c-4823-ac1a-3d5b113099a4@github.com> <1Bu6zQ2vZd9RDdeiQwZzX012pQeDvtI6aNENgv9N97A=.6302c6b5-25a9-4582-b84d-0c0f18c5ea72@github.com> Message-ID: On Wed, 17 Aug 2022 22:31:05 GMT, Nir Lisker wrote: >>> For lucene, you'd need to run >>> >>> ``` >>> /bin/sh gradlew getLucene >>> ``` >>> >>> to bring in the dependencies which are not a part of the repository. >> >> Btw, `gradle apps` will also work. > > If there are folders that aren't generated by the build task, we should note it in the build page of the wiki. not sure what you are referring to - getLucene task does not create any folders. no wiki changes are needed. ------------- PR: https://git.openjdk.org/jfx/pull/858 From angorya at openjdk.org Wed Aug 17 22:40:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Aug 2022 22:40:40 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v12] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 22:22:02 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: review comments rt -> jfx change is not in scope for this PR. eclipse seems to have no issues if one imports the project as a gradle project. ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Wed Aug 17 22:46:31 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:46:31 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v12] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 22:22:02 GMT, Andy Goryachev wrote: >> The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. >> >> - updated .classpath entries in apps/ >> - added utf-8 prefs in .settings/ > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8290473: review comments Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/858 From nlisker at openjdk.org Wed Aug 17 22:46:33 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 17 Aug 2022 22:46:33 GMT Subject: RFR: 8290473: update Eclipse .classpath in apps, buildSrc [v11] In-Reply-To: References: <5mwXDYyhRa0cvJDKtYjJMLMRLDalFMiD_aVraJ1NBT4=.b027c9b3-850c-4823-ac1a-3d5b113099a4@github.com> <1Bu6zQ2vZd9RDdeiQwZzX012pQeDvtI6aNENgv9N97A=.6302c6b5-25a9-4582-b84d-0c0f18c5ea72@github.com> Message-ID: On Wed, 17 Aug 2022 22:35:37 GMT, Andy Goryachev wrote: >> If there are folders that aren't generated by the build task, we should note it in the build page of the wiki. > > not sure what you are referring to - getLucene task does not create any folders. no wiki changes are needed. It creates the `\apps\samples\Ensemble8\lib` directory with the jars inside. The project will not compile in Eclipse before this (or the `apps`) task is run. That's what I have just observed. ------------- PR: https://git.openjdk.org/jfx/pull/858 From aghaisas at openjdk.org Thu Aug 18 04:55:20 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 18 Aug 2022 04:55:20 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v11] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Fri, 12 Aug 2022 17:21:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. modified TreeTableRow.updateSelection() to use the right isSelected() method >> 4. updated tests for Tree/TableView >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: added tests Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/839 From angorya at openjdk.org Thu Aug 18 07:17:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Aug 2022 07:17:36 GMT Subject: Integrated: 8290473: update Eclipse .classpath in apps, buildSrc In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 16:53:29 GMT, Andy Goryachev wrote: > The goal of this change is to make sure jfx repo can be imported as a gradle project in eclipse and all nested projects in the workspace compile with no errors. > > - updated .classpath entries in apps/ > - added utf-8 prefs in .settings/ This pull request has now been integrated. Changeset: 5c47295c Author: Andy Goryachev Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/5c47295cf7ff9404b3bddaa2c30772fa2eff461c Stats: 130 lines in 14 files changed: 64 ins; 31 del; 35 mod 8290473: update Eclipse .classpath in apps, buildSrc Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/858 From aghaisas at openjdk.org Thu Aug 18 09:32:23 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 18 Aug 2022 09:32:23 GMT Subject: RFR: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader [v3] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 16:36:24 GMT, Ambarish Rapte wrote: >> Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. >> Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. >> With this fix: >> 1. Windows narrator reads the dialog correctly >> 2. JAWS fails to read the header text. : This will be handled separately >> 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. >> >> Verification: >> 1. Run HelloAlert toy app, with fix. >> 2. Start Windows Narrator >> 3. Click on the different buttons to show different Dialogs >> => Observe that Narrator reads all the content correctly. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review comment, add since 20 Looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/873 From fastegal at openjdk.org Thu Aug 18 09:54:35 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Thu, 18 Aug 2022 09:54:35 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode In-Reply-To: References: Message-ID: <3qKG_9IhxoxCJ36sokSoXC1_ShABIQIxw_RVn3dwNJs=.ad1e80d8-3554-465e-9cec-92b63a692ae7@github.com> On Wed, 17 Aug 2022 19:40:21 GMT, Andy Goryachev wrote: > The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. > > Changes: > - modified TreeTableRow.updateSelection() Changes requested by fastegal (Reviewer). modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 448: > 446: } > 447: > 448: boolean isSelected = !sm.isCellSelectionEnabled() && sm.isSelected(index, null); this is different from TableRow (which uses isSelected(index)) - why? And we don't seem to have complete test coverage for row selection (otherwise this issue would have shown somewhere :) - please add test/s that fail/pass before/after the fix, respectively ------------- PR: https://git.openjdk.org/jfx/pull/875 From arapte at openjdk.org Thu Aug 18 14:09:29 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 18 Aug 2022 14:09:29 GMT Subject: [jfx17u] RFR: 8291051: Update boot JDK to 17.0.4 In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:28:16 GMT, Kevin Rushforth wrote: > This bumps the boot JDK used to build jfx17u to JDK 17.0.4. The minimum JDK that can run JavaFX 17.0.x is unchanged and remains at JDK 11. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx17u/pull/78 From angorya at openjdk.org Thu Aug 18 18:17:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Aug 2022 18:17:11 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting Message-ID: Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. Setting a null selection model is a valid way to disable selection in a (tree)table. There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). changes: - added check for null selection model where it was missing - clearing focused row index on setting null selection model in TreeTableView ------------- Commit messages: - 8187145: whitespace - 8187145: clear focus - 8187145: tree table view - 8187145: fall through - 8187145: check for null selection model Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8187145 Stats: 182 lines in 11 files changed: 89 ins; 10 del; 83 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From nlisker at openjdk.org Thu Aug 18 21:53:16 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 21:53:16 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs Message-ID: Fixes the mistakes in the JBS ticket and some additional minor corrections. ------------- Commit messages: - Initial commit - 8290473: update Eclipse .classpath in apps, buildSrc - 8181084: JavaFX show big icons in system menu on macOS with Retina display - 8291908: VirtualFlow creates unneeded empty cells - 8291630: Update attribution in webkit.md file - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 - 8218826: TableRowSkinBase: horizontal layout broken if row has padding - Merge - Merge - 8289605: Robot capture tests fail intermittently on Mac M1 - ... and 14 more: https://git.openjdk.org/jfx/compare/dd30402a...c4b2bcd4 Changes: https://git.openjdk.org/jfx/pull/877/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=877&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286678 Stats: 456392 lines in 7434 files changed: 302779 ins; 110416 del; 43197 mod Patch: https://git.openjdk.org/jfx/pull/877.diff Fetch: git fetch https://git.openjdk.org/jfx pull/877/head:pull/877 PR: https://git.openjdk.org/jfx/pull/877 From angorya at openjdk.org Thu Aug 18 22:01:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Aug 2022 22:01:59 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir, have you sync'ed your branch with the latest master? There are 5000+ files changed listed. ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 22:35:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 22:35:13 GMT Subject: RFR: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Message-ID: Use the system version of `ant` on macOS platforms rather than downloading it from apache.org. As noted in the bug report, we are seeing frequent GitHub Actions (GHA) failures on macOS due to a timeout while attempting to download apache ant 1.10.5. The JavaFX build uses `ant` to build the apps (so `gradle apps` requires it). The installed version of ant on the macOS 11 systems that we use is ant 1.10.12, which works fine to build the apps. Given that the GHA builds are just a sanity test used as a help to reviewers and contributors, and that we already relax the requirement to specify the exact versions for a few other platform tools, there is no real downside to doing this. This PR only touches the GHA build script for the macOS job, so the GHA test run is sufficient to test it. ------------- Commit messages: - 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Changes: https://git.openjdk.org/jfx/pull/879/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=879&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292549 Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/879.diff Fetch: git fetch https://git.openjdk.org/jfx pull/879/head:pull/879 PR: https://git.openjdk.org/jfx/pull/879 From angorya at openjdk.org Thu Aug 18 22:35:13 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Aug 2022 22:35:13 GMT Subject: RFR: 8292549: GitHub actions: intermittent build failure on macOS while downloading ant In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 22:22:36 GMT, Kevin Rushforth wrote: > Use the system version of `ant` on macOS platforms rather than downloading it from apache.org. > > As noted in the bug report, we are seeing frequent GitHub Actions (GHA) failures on macOS due to a timeout while attempting to download apache ant 1.10.5. > > The JavaFX build uses `ant` to build the apps (so `gradle apps` requires it). The installed version of ant on the macOS 11 systems that we use is ant 1.10.12, which works fine to build the apps. Given that the GHA builds are just a sanity test used as a help to reviewers and contributors, and that we already relax the requirement to specify the exact versions for a few other platform tools, there is no real downside to doing this. > > This PR only touches the GHA build script for the macOS job, so the GHA test run is sufficient to test it. looks good to me. thank you, Kevin! ------------- Marked as reviewed by angorya (Author). PR: https://git.openjdk.org/jfx/pull/879 From nlisker at openjdk.org Thu Aug 18 22:43:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 22:43:36 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. It's a PR against the javafx19 branch. I think I forked the master branch though, which is why it is showing all the commits. I might need to rebase, but if the changes are approved it should integrate without issues. ------------- PR: https://git.openjdk.org/jfx/pull/877 From angorya at openjdk.org Thu Aug 18 22:49:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Aug 2022 22:49:45 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. you probably need to rebase. impossible to review. ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 22:49:46 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 22:49:46 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <0Sh_VQa-qvySmAY5I86BDOIq8BXuvU46aX4EZg-ROBo=.7b6df268-8f2f-455f-a159-9e83176df078@github.com> On Thu, 18 Aug 2022 22:40:09 GMT, Nir Lisker wrote: > It's a PR against the javafx19 branch. I think I forked the master branch though, which is why it is showing all the commits. Yeah, this is a fairly easy mistake to make. It's also very obvious when it happens. > I might need to rebase, but if the changes are approved it should integrate without issues. You will definitely need to rebase and force push before this can be reviewed. No, it otherwise won't integrate without issues. ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 22:53:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 22:53:12 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. I'll review it. @arapte or @aghaisas Can one of you be the second reviewer? ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 23:10:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 23:10:38 GMT Subject: [jfx17u] Integrated: 8291051: Update boot JDK to 17.0.4 In-Reply-To: References: Message-ID: <2klBtqnsGFHqTzwMvZk69_lS8NfeFoHKOEqnV7_EZ7k=.06c01146-709c-4705-861b-d22a5f715ebd@github.com> On Wed, 17 Aug 2022 14:28:16 GMT, Kevin Rushforth wrote: > This bumps the boot JDK used to build jfx17u to JDK 17.0.4. The minimum JDK that can run JavaFX 17.0.x is unchanged and remains at JDK 11. This pull request has now been integrated. Changeset: 9947198c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx17u/commit/9947198cfab960f0453cf97ba537ec54f0a7bf4b Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8291051: Update boot JDK to 17.0.4 Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx17u/pull/78 From nlisker at openjdk.org Thu Aug 18 23:19:49 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:19:49 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 16 new commits since the last revision: - Initial commit - 8290473: update Eclipse .classpath in apps, buildSrc Reviewed-by: nlisker - 8181084: JavaFX show big icons in system menu on macOS with Retina display Reviewed-by: jpereda, kcr - 8291908: VirtualFlow creates unneeded empty cells Reviewed-by: kcr, aghaisas - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 Reviewed-by: aghaisas, arapte - 8218826: TableRowSkinBase: horizontal layout broken if row has padding Reviewed-by: aghaisas - 8289605: Robot capture tests fail intermittently on Mac M1 Reviewed-by: kcr - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment Reviewed-by: kcr - 8290990: Clear .root style class from a root node that is removed from a Scene/SubScene Reviewed-by: jhendrikx, aghaisas, mhanl - 8290527: Bump macOS GitHub actions to macOS 11 Reviewed-by: arapte - ... and 6 more: https://git.openjdk.org/jfx/compare/c4b2bcd4...263061e3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/877/files - new: https://git.openjdk.org/jfx/pull/877/files/c4b2bcd4..263061e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=877&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=877&range=00-01 Stats: 448344 lines in 7349 files changed: 103818 ins; 301779 del; 42747 mod Patch: https://git.openjdk.org/jfx/pull/877.diff Fetch: git fetch https://git.openjdk.org/jfx pull/877/head:pull/877 PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Thu Aug 18 23:21:02 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:21:02 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Looks like the rebase missed a few commits. Not sure why. ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 23:31:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 23:31:37 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 23:19:49 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 16 new commits since the last revision: > > - Initial commit > - 8290473: update Eclipse .classpath in apps, buildSrc > > Reviewed-by: nlisker > - 8181084: JavaFX show big icons in system menu on macOS with Retina display > > Reviewed-by: jpereda, kcr > - 8291908: VirtualFlow creates unneeded empty cells > > Reviewed-by: kcr, aghaisas > - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 > > Reviewed-by: aghaisas, arapte > - 8218826: TableRowSkinBase: horizontal layout broken if row has padding > > Reviewed-by: aghaisas > - 8289605: Robot capture tests fail intermittently on Mac M1 > > Reviewed-by: kcr > - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment > > Reviewed-by: kcr > - 8290990: Clear .root style class from a root node that is removed from a Scene/SubScene > > Reviewed-by: jhendrikx, aghaisas, mhanl > - 8290527: Bump macOS GitHub actions to macOS 11 > > Reviewed-by: arapte > - ... and 6 more: https://git.openjdk.org/jfx/compare/c4b2bcd4...263061e3 How did you do the rebase? It should be something like: git fetch upstream git rebase -i upstream/master Alternatively, you can `git reset --hard upstream/jfx19` to reset your branch, and then cherry pick all of the commits (or apply the aggregate diffs as one commit). ------------- PR: https://git.openjdk.org/jfx/pull/877 From kcr at openjdk.org Thu Aug 18 23:39:34 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Aug 2022 23:39:34 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 23:19:49 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 16 new commits since the last revision: > > - Initial commit > - 8290473: update Eclipse .classpath in apps, buildSrc > > Reviewed-by: nlisker > - 8181084: JavaFX show big icons in system menu on macOS with Retina display > > Reviewed-by: jpereda, kcr > - 8291908: VirtualFlow creates unneeded empty cells > > Reviewed-by: kcr, aghaisas > - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 > > Reviewed-by: aghaisas, arapte > - 8218826: TableRowSkinBase: horizontal layout broken if row has padding > > Reviewed-by: aghaisas > - 8289605: Robot capture tests fail intermittently on Mac M1 > > Reviewed-by: kcr > - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment > > Reviewed-by: kcr > - 8290990: Clear .root style class from a root node that is removed from a Scene/SubScene > > Reviewed-by: jhendrikx, aghaisas, mhanl > - 8290527: Bump macOS GitHub actions to macOS 11 > > Reviewed-by: arapte > - ... and 6 more: https://git.openjdk.org/jfx/compare/c4b2bcd4...263061e3 Oh, there is only a single unique commit in your branch (or rather there was before you rebased some of the commits from master), so the following should work: git reset --hard upstream/jfx19 git cherry-pick 263061e366e5c7b4d0928b33d7bc4da90b9fa519 Check that there is only the one commit, and that the diffs look good: git log upstream/jfx19.. git diff upstream/jfx19.. then force push. ------------- PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Thu Aug 18 23:43:33 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:43:33 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Initial commit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/877/files - new: https://git.openjdk.org/jfx/pull/877/files/263061e3..5d0fbdea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=877&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=877&range=01-02 Stats: 7926 lines in 80 files changed: 6688 ins; 1116 del; 122 mod Patch: https://git.openjdk.org/jfx/pull/877.diff Fetch: git fetch https://git.openjdk.org/jfx pull/877/head:pull/877 PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Thu Aug 18 23:53:41 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:53:41 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 23:43:33 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. `git reset --hard upstream/jfx19` That gives an error fatal: ambiguous argument 'upstream/jfx19': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' I will close this PR and resubmit. ------------- PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Thu Aug 18 23:53:42 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:53:42 GMT Subject: [jfx19] Withdrawn: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:08:19 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Thu Aug 18 23:57:38 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 18 Aug 2022 23:57:38 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: <_nu82kUTYJbAfn1c_se5Jy-Fmi6JNbVeIRME6dr1AtI=.b2092e1a-a8ce-4aac-afc0-b3c72101f3e1@github.com> On Thu, 18 Aug 2022 23:43:33 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Initial commit #880 is the new PR. ------------- PR: https://git.openjdk.org/jfx/pull/877 From nlisker at openjdk.org Fri Aug 19 00:02:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 19 Aug 2022 00:02:24 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs Message-ID: Fixes the mistakes in the JBS ticket and some additional minor corrections. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jfx/pull/880/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286678 Stats: 30 lines in 7 files changed: 1 ins; 2 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/880.diff Fetch: git fetch https://git.openjdk.org/jfx pull/880/head:pull/880 PR: https://git.openjdk.org/jfx/pull/880 From nlisker at openjdk.org Fri Aug 19 00:07:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 19 Aug 2022 00:07:36 GMT Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect method docs Message-ID: Simple fixes for the inherited method docs. ------------- Commit messages: - Initial commit - 8290473: update Eclipse .classpath in apps, buildSrc - 8181084: JavaFX show big icons in system menu on macOS with Retina display - 8291908: VirtualFlow creates unneeded empty cells - 8291630: Update attribution in webkit.md file - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1 - 8218826: TableRowSkinBase: horizontal layout broken if row has padding - Merge - Merge - 8289605: Robot capture tests fail intermittently on Mac M1 - ... and 14 more: https://git.openjdk.org/jfx/compare/dd30402a...b99b1345 Changes: https://git.openjdk.org/jfx/pull/878/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=878&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291906 Stats: 456404 lines in 7428 files changed: 302820 ins; 110414 del; 43170 mod Patch: https://git.openjdk.org/jfx/pull/878.diff Fetch: git fetch https://git.openjdk.org/jfx pull/878/head:pull/878 PR: https://git.openjdk.org/jfx/pull/878 From mstrauss at openjdk.org Fri Aug 19 00:29:38 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 19 Aug 2022 00:29:38 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <_28-PhkNnOt43GovOYEyu7hbe6jynwpSTZsXDKQLqxg=.da601a30-5608-4db8-9564-16a0f33950f0@github.com> On Thu, 18 Aug 2022 23:52:48 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 102: > 100: * > 101: *
> 102:      *     property1.bindBicirectional(property2);

Almost, but not quite.

-------------

PR: https://git.openjdk.org/jfx/pull/880

From nlisker at openjdk.org  Fri Aug 19 00:33:24 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 00:33:24 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
Message-ID: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>

Added docs for inherited methods in `Bindings` subclasses.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jfx/pull/881/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291906
  Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/881.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/881/head:pull/881

PR: https://git.openjdk.org/jfx/pull/881

From nlisker at openjdk.org  Fri Aug 19 00:37:30 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 00:37:30 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs [v2]
In-Reply-To: 
References: 
Message-ID: 

> Simple fixes for the inherited method docs.

Nir Lisker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 19 new commits since the last revision:

 - Initial commit
 - 8290473: update Eclipse .classpath in apps, buildSrc
   
   Reviewed-by: nlisker
 - 8181084: JavaFX show big icons in system menu on macOS with Retina display
   
   Reviewed-by: jpereda, kcr
 - 8291908: VirtualFlow creates unneeded empty cells
   
   Reviewed-by: kcr, aghaisas
 - 8291630: Update attribution in webkit.md file
   
   Reviewed-by: arapte
 - 8291087: Wrong position of focus of screen reader on Windows with screen scale > 1
   
   Reviewed-by: aghaisas, arapte
 - 8218826: TableRowSkinBase: horizontal layout broken if row has padding
   
   Reviewed-by: aghaisas
 - 8289605: Robot capture tests fail intermittently on Mac M1
   
   Reviewed-by: kcr
 - 8289397: Fix warnings: Possible accidental assignment in place of a comparison. A condition expression should not be reduced to an assignment
   
   Reviewed-by: kcr
 - 8290530: Bump minimum JDK version for JavaFX to JDK 17
   
   Reviewed-by: prr, jvos
 - ... and 9 more: https://git.openjdk.org/jfx/compare/b99b1345...40b60ed1

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/878/files
  - new: https://git.openjdk.org/jfx/pull/878/files/b99b1345..40b60ed1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=878&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=878&range=00-01

  Stats: 59 lines in 3 files changed: 58 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/878.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/878/head:pull/878

PR: https://git.openjdk.org/jfx/pull/878

From nlisker at openjdk.org  Fri Aug 19 00:37:34 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 00:37:34 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fixes the mistakes in the JBS ticket and some additional minor corrections.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/880/files
  - new: https://git.openjdk.org/jfx/pull/880/files/6f2894de..d8ccb5ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/880.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/880/head:pull/880

PR: https://git.openjdk.org/jfx/pull/880

From nlisker at openjdk.org  Fri Aug 19 00:38:42 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 00:38:42 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Aug 2022 19:21:39 GMT, Nir Lisker  wrote:

> Simple fixes for the inherited method docs.

Closed in favor of #881.

-------------

PR: https://git.openjdk.org/jfx/pull/878

From nlisker at openjdk.org  Fri Aug 19 00:38:42 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 00:38:42 GMT
Subject: [jfx19] Withdrawn: 8291906: Bindings.createXxxBinding inherit
 incorrect method docs
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Aug 2022 19:21:39 GMT, Nir Lisker  wrote:

> Simple fixes for the inherited method docs.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx/pull/878

From arapte at openjdk.org  Fri Aug 19 04:51:39 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 19 Aug 2022 04:51:39 GMT
Subject: RFR: 8292549: GitHub actions: intermittent build failure on macOS
 while downloading ant
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Aug 2022 22:22:36 GMT, Kevin Rushforth  wrote:

> Use the system version of `ant` on macOS platforms rather than downloading it from apache.org.
> 
> As noted in the bug report, we are seeing frequent GitHub Actions (GHA) failures on macOS due to a timeout while attempting to download apache ant 1.10.5.
> 
> The JavaFX build uses `ant` to build the apps (so `gradle apps` requires it). The installed version of ant on the macOS 11 systems that we use is ant 1.10.12, which works fine to build the apps. Given that the GHA builds are just a sanity test used as a help to reviewers and contributors, and that we already relax the requirement to specify the exact versions for a few other platform tools, there is no real downside to doing this.
> 
> This PR only touches the GHA build script for the macOS job, so the GHA test run is sufficient to test it.

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.org/jfx/pull/879

From arapte at openjdk.org  Fri Aug 19 04:59:44 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 19 Aug 2022 04:59:44 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2]
In-Reply-To: <1QIK7iTzZenVVbySu3sr63xOrtCTRkYb5fGBDZEA54g=.629dbc94-28e0-4128-b236-58dc2ccc43ab@github.com>
References: 
 
 
 
 <11zXZpaT_LAn6lcBPWptufRySZFp2JYYAdzqWBn2ioA=.c3fe8097-6ded-4e4a-80b2-b2cd37195853@github.com>
 <3jBij94zLQ7_fUOwWZxymIWG-Xw27L_LyBYGFCdqdMI=.16b3a734-5042-4d09-a77c-dfa183484127@github.com>
 <0okvvkrjS89IXbBAtr_N2OqaXgXjg2gRW_wggc7pzHQ=.65c7501d-b1e5-4abd-8d57-9b30114841de@github.com>
 
 <1QIK7iTzZenVVbySu3sr63xOrtCTRkYb5fGBDZEA54g=.629dbc94-28e0-4128-b236-58dc2ccc43ab@github.com>
Message-ID: 

On Wed, 17 Aug 2022 17:38:31 GMT, Nir Lisker  wrote:

>> First of all, I found that the mistake was in the shortcut branch of the shader: it was using the light direction instead of the vector to the light (incident ray), so in the code I need to replace `dot(n, -lightDir)` with `dot(n, -l)`, like is done in the full computation branch. Then the test passes with the `0` input for no-attenuation. Thanks.
>> 
>> Then I looked at the computation some more and I found something in the computation of the specular component. According to the theory, both in online sources and in the `PhongMaterial` class doc, the computation should be:
>> `R . V` where `V` is the vector to the eye/cam and `R` is the reflection vector computed by `R = 2(N . L)N - L`, or using the [reflect](https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-reflect) HLSL function, `R = -reflect(N, L)`. So the shader files should look something like this:
>> 
>> float3 refl = reflect(l, n);
>> s = ... dot(-refl, e); // e is the vector to the eye, like V
>> 
>> However, looking at the shader files, [already from legacy](https://github.com/openjdk/jfx/blob/c420248b9b459efcfbd3657170d9be0b96b5fb38/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h), the vectors are switched:
>> 
>> float3 refl = reflect(e, n);
>> s = ... dot(-refl, l);
>> 
>> It looks like the specular computation was wrong from the start.
>> 
>> I tested the visuals on the `master` branch before and after swapping the `l` and `e` vectors and I see no difference in the specular reflection. Rather odd. Will need to look into this more.
>> 
>> The same mistakes are coded into the glsl shaders too, so I should fix the one you found at the very least.
>
> @kevinrushforth maybe you can take a look at this too.

I would recommend to make only cleanup changes in this PR. So keep `isAttenuated` as 1, and file separate issue to handle the corrections you found.

-------------

PR: https://git.openjdk.org/jfx/pull/789

From fkirmaier at openjdk.org  Fri Aug 19 07:36:12 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 07:36:12 GMT
Subject: RFR: 8271395: Crash during printing when disposing textures [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
> I'm open for better solutions on how to fix this Issue.
> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.

Florian Kirmaier 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master'
 - JDK-8271395
   changes based on codereview
   We now catch Throwable instead of Exception
 - JDK-8271395
   QuantumRenderer is no longer public
 - JDK-8271395 Fixing crash at printing
   Switching to the QuantumThread fixes the native crash when cleaning Textures.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/618/files
  - new: https://git.openjdk.org/jfx/pull/618/files/a41f41dd..27bf8836

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=618&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=618&range=02-03

  Stats: 999433 lines in 11556 files changed: 592004 ins; 268584 del; 138845 mod
  Patch: https://git.openjdk.org/jfx/pull/618.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/618/head:pull/618

PR: https://git.openjdk.org/jfx/pull/618

From arapte at openjdk.org  Fri Aug 19 07:51:50 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 19 Aug 2022 07:51:50 GMT
Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Aug 2022 20:44:52 GMT, Kevin Rushforth  wrote:

> I left a couple comments on questionable-looking indentation.

Hi Kevin, Looks like this is an existing issue, as we replace tabs with 4 spaces.
We have several such existing instances of incorrect layout.

1. https://github.com/openjdk/jfx/blob/5c47295cf7ff9404b3bddaa2c30772fa2eff461c/modules/javafx.graphics/src/main/native-iio/libjpeg/jdmaster.c#L142
2. https://github.com/openjdk/jfx/blob/5c47295cf7ff9404b3bddaa2c30772fa2eff461c/modules/javafx.graphics/src/main/native-iio/libjpeg/jdmaster.c#L439
3. https://github.com/openjdk/jfx/blob/5c47295cf7ff9404b3bddaa2c30772fa2eff461c/modules/javafx.graphics/src/main/native-iio/libjpeg/jdhuff.c#L438

-------------

PR: https://git.openjdk.org/jfx/pull/874

From fkirmaier at openjdk.org  Fri Aug 19 08:01:48 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 08:01:48 GMT
Subject: RFR: 8271395: Crash during printing when disposing textures [v2]
In-Reply-To: 
References: 
 
 <02K0ao_vWR0JEjBwNRu9wwG-Vbx-10Wl8Dw6V3UGoxA=.7ae7c2b4-b915-4940-866c-13dd94a5fcd0@github.com>
 
 
Message-ID: 

On Wed, 3 Aug 2022 15:22:13 GMT, Kevin Rushforth  wrote:

>> I've worked in the feedback, thank you @kevinrushforth 
>> Small note, this change is not used for a while and is therefore well tested.
>
> @FlorianKirmaier This PR is pending the following:
> 1. Merge upstream master into your PR branch (so we can get a clean test run on the latest + your changes)
> 2. Change this PR title to `8271395: Crash during printing when disposing textures`

@kevinrushforth 
I've just seen your comments.
I've just merged it and changed the title!

-------------

PR: https://git.openjdk.org/jfx/pull/618

From fkirmaier at openjdk.org  Fri Aug 19 09:00:44 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 09:00:44 GMT
Subject: RFR: 8271395: Crash during printing when disposing textures [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 07:36:12 GMT, Florian Kirmaier  wrote:

>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.
>
> Florian Kirmaier 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master'
>  - JDK-8271395
>    changes based on codereview
>    We now catch Throwable instead of Exception
>  - JDK-8271395
>    QuantumRenderer is no longer public
>  - JDK-8271395 Fixing crash at printing
>    Switching to the QuantumThread fixes the native crash when cleaning Textures.

The Mac build seems to be failing for some reason, unrelated to the PR.

-------------

PR: https://git.openjdk.org/jfx/pull/618

From fastegal at openjdk.org  Fri Aug 19 09:06:41 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Fri, 19 Aug 2022 09:06:41 GMT
Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE
 on sorting
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Aug 2022 16:24:11 GMT, Andy Goryachev  wrote:

> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. 
> 
> Setting a null selection model is a valid way to disable selection in a (tree)table.
> 
> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640).
> 
> changes:
> - added check for null selection model where it was missing
> - clearing focused row index on setting null selection model in TreeTableView

hmm ... where are the tests ;) The similar [PR 711](https://github.com/openjdk/jfx/pull/711) has examples that probably can be adapted for testing Tree/TableView as well (would expect that there might be more due to column navigation)

-------------

PR: https://git.openjdk.org/jfx/pull/876

From fkirmaier at openjdk.org  Fri Aug 19 09:23:47 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 09:23:47 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Jul 2022 11:51:10 GMT, Florian Kirmaier  wrote:

>> It's "a bit" complicated.
>> In some situations, getRuns get's called because listeners on bounds are set.
>> This causes TextFlow to layout to compute the runs.
>> Afterward, the bounds of the parents get updated. 
>> This triggers a call to compute bounds - which cascades up to the children.
>> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
>> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
>> 
>> In the case it happened - it didn't repair and the application kinda crashed.
>> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
>> It also can cause unpredictable performance issues.
>> 
>> Unit test and example stacktrace are in the ticket.
>> 
>> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
>> The Textflow should be layouting by the Parent.
>> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
>> 
>> Benefits:
>>  * Better Tooling Support For ScenicView etc.
>>  * Fixes complicated but reproducible crashes
>>  * Might fix some rare crashes, which are hard to reproduce
>>  * Likely improves performance - might fix some edge cases with unpredictable bad performance
>
> Florian Kirmaier 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8269921-textflow-bug
>  - JDK-8269921
>    Added a copyright header
>  - JDK-8269921
>    Fixing a crash related to Text and TextFlow with bounds listeners

I've just verified that the test is also green with the call to `parent.layout()`
So it might be an option, to change this PR to only contain the null check.

When I find some time, I will write a test to show how the parent.layout() call can cause issues.
Similar issues exist with Group - which sometimes has the effect, that applications stop working when scenic view is used. (or other tooling)

The exception in PrismTextLayout tends to happen when also the bug of this PR happens - but I don't really know how they relate.

-------------

PR: https://git.openjdk.org/jfx/pull/564

From aghaisas at openjdk.org  Fri Aug 19 10:14:50 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 19 Aug 2022 10:14:50 GMT
Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly
 displays a horizontal scroll bar. [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Aug 2022 02:21:30 GMT, Sai Pradeep Dandem  wrote:

>> **Issue:**
>> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced.
>> 
>> **Cause:**
>> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. 
>> 
>> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging).
>> 
>> To confirm this behaviour, please find the below example that showcases the issue:
>> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly.
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.beans.property.StringProperty;
>> import javafx.collections.FXCollections;
>> import javafx.collections.ObservableList;
>> import javafx.geometry.Insets;
>> import javafx.scene.Group;
>> import javafx.scene.Scene;
>> import javafx.scene.control.*;
>> import javafx.scene.layout.HBox;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>> 
>> public class ConstrainedResizePolicyIssueDemo extends Application {
>>     @Override
>>     public void start(Stage primaryStage) throws Exception {
>>         TableColumn fnCol = new TableColumn<>("First Name");
>>         fnCol.setMinWidth(100);
>>         fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty());
>> 
>>         TableColumn priceCol = new TableColumn<>("Price");
>>         priceCol.setMinWidth(100);
>>         priceCol.setMaxWidth(150);
>>         priceCol.setCellValueFactory(param -> param.getValue().priceProperty());
>> 
>>         TableColumn totalCol = new TableColumn<>("Total");
>>         totalCol.setMinWidth(100);
>>         totalCol.setMaxWidth(150);
>>         totalCol.setCellValueFactory(param -> param.getValue().totalProperty());
>> 
>>         ObservableList persons = FXCollections.observableArrayList();
>>         persons.add(new Person("Harry", "200.00", "210.00"));
>>         persons.add(new Person("Jacob", "260.00", "260.00"));
>> 
>>         TableView tableView = new TableView<>();
>>         tableView.getColumns().addAll(fnCol, priceCol, totalCol);
>>         tableView.setItems(persons);
>>         tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
>>         tableView.setMinWidth(500);
>>         tableView.maxWidthProperty().bind(tableView.minWidthProperty());
>> 
>>         Button button1 = new Button("Reduce 1px");
>>         button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1));
>>         Button button2 = new Button("Reduce 10px");
>>         button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10));
>>         Button button3 = new Button("Reset");
>>         button3.setOnAction(e -> tableView.setMinWidth(500));
>>         Button button4 = new Button("Increase 1px");
>>         button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1));
>>         Button button5 = new Button("Increase 10px");
>>         button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10));
>> 
>>         HBox row = new HBox(button1, button2, button3, button4, button5);
>>         row.setSpacing(10);
>>         TextArea output = new TextArea();
>> 
>>         addWidthListeners(tableView, output);
>>         VBox root = new VBox(row, new Group(tableView), output);
>>         root.setSpacing(10);
>>         root.setPadding(new Insets(10));
>> 
>>         Scene scene = new Scene(root);
>>         primaryStage.setScene(scene);
>>         primaryStage.setTitle("Constrained Resize Policy Issue TableView");
>>         primaryStage.show();
>>     }
>> 
>>     private void addWidthListeners(TableView tableView, TextArea output) {
>>         tableView.widthProperty().addListener((obs, old, val) -> {
>>             String str = "Table width changed :: " + val + "\n";
>>             output.setText(output.getText() + str);
>>             output.positionCaret(output.getText().length());
>>         });
>>         tableView.getColumns().forEach(column -> {
>>             column.widthProperty().addListener((obs, old, width) -> {
>>                 String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n";
>>                 output.setText(output.getText() + str);
>>                 output.positionCaret(output.getText().length());
>>             });
>>         });
>>     }
>> 
>>     class Person {
>>         private StringProperty firstName = new SimpleStringProperty();
>>         private StringProperty price = new SimpleStringProperty();
>>         private StringProperty total = new SimpleStringProperty();
>> 
>>         public Person(String fn, String price, String total) {
>>             setFirstName(fn);
>>             setPrice(price);
>>             setTotal(total);
>>         }
>> 
>>         public StringProperty firstNameProperty() {
>>             return firstName;
>>         }
>> 
>>         public void setFirstName(String firstName) {
>>             this.firstName.set(firstName);
>>         }
>> 
>>         public StringProperty priceProperty() {
>>             return price;
>>         }
>> 
>>         public void setPrice(String price) {
>>             this.price.set(price);
>>         }
>> 
>>         public StringProperty totalProperty() {
>>             return total;
>>         }
>> 
>>         public void setTotal(String total) {
>>             this.total.set(total);
>>         }
>>     }
>> }
>> 
>> 
>> **Fix:**
>> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px.
>> 
>> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226
>> 
>> `if (Math.abs(colWidth - tableWidth) > 1) {`
>> 
>> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly.
>
> Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test review comments

Fix looks good to me.

-------------

Marked as reviewed by aghaisas (Reviewer).

PR: https://git.openjdk.org/jfx/pull/848

From fkirmaier at openjdk.org  Fri Aug 19 10:34:18 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 10:34:18 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v6]
In-Reply-To: 
References: 
Message-ID: 

> After thinking about this issue for some time, I've now got a solution.
> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.

Florian Kirmaier 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master'
 - JDK-8269907
   Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary.
 - JDK-8269907
   Fixed rare bug, causing bounds to be out of sync.
 - JDK-8269907
   We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method.
 - JDK-8269907
   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.
 - JDK-8269907
   Fixing dirty nodes and parent removed, when a window is no longer showing.  This typically happens with context menus.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/584/files
  - new: https://git.openjdk.org/jfx/pull/584/files/22326ccf..580ba7d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=584&range=04-05

  Stats: 1013036 lines in 12130 files changed: 596342 ins; 275898 del; 140796 mod
  Patch: https://git.openjdk.org/jfx/pull/584.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/584/head:pull/584

PR: https://git.openjdk.org/jfx/pull/584

From fkirmaier at openjdk.org  Fri Aug 19 10:34:21 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 10:34:21 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 27 Jan 2022 14:50:16 GMT, Florian Kirmaier  wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary.

I've just merged it with master, to make it easier to review, if someone finds the time.

-------------

PR: https://git.openjdk.org/jfx/pull/584

From fkirmaier at openjdk.org  Fri Aug 19 10:40:01 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 10:40:01 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Making the initial listener of the ListProperty weak fixes the problem.
> The same is fixed for Set and Map.
> Due to a smart implementation, this is done without any performance drawback.
> (The trick is to have an object, which is both the WeakReference and the Changelistener)
> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.

Florian Kirmaier 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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
 - JDK-8277848
   Added tests to ensure no premature garbage collection is happening.
 - JDK-8277848
   Added 3 more tests to verify that a bug discussed in the PR does not appear.
 - JDK-8277848
   Added the 3 requests whitespaces
 - JDK-8277848
   Further optimization based code review.
   This Bugfix should now event improve the performance
 - JDK-8277848
   Added missing change
 - JDK-8277848
   Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/689/files
  - new: https://git.openjdk.org/jfx/pull/689/files/b744a098..917c1bf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=05-06

  Stats: 983127 lines in 11369 files changed: 578129 ins; 267400 del; 137598 mod
  Patch: https://git.openjdk.org/jfx/pull/689.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/689/head:pull/689

PR: https://git.openjdk.org/jfx/pull/689

From fkirmaier at openjdk.org  Fri Aug 19 10:49:43 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 19 Aug 2022 10:49:43 GMT
Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 10:40:01 GMT, Florian Kirmaier  wrote:

>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to have an object, which is both the WeakReference and the Changelistener)
>> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties.
>
> Florian Kirmaier 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 seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak
>  - JDK-8277848
>    Added tests to ensure no premature garbage collection is happening.
>  - JDK-8277848
>    Added 3 more tests to verify that a bug discussed in the PR does not appear.
>  - JDK-8277848
>    Added the 3 requests whitespaces
>  - JDK-8277848
>    Further optimization based code review.
>    This Bugfix should now event improve the performance
>  - JDK-8277848
>    Added missing change
>  - JDK-8277848
>    Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty.

I've just merged it with master for easier codereview.

-------------

PR: https://git.openjdk.org/jfx/pull/689

From kcr at openjdk.org  Fri Aug 19 11:44:43 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 11:44:43 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 18 Aug 2022 23:50:03 GMT, Nir Lisker  wrote:

> ```
> fatal: ambiguous argument 'upstream/jfx19': unknown revision or path not in the working tree.
> ```

I should have said "presuming you have a remote configured with the name `upstream`". Anyway, what you did was good.

-------------

PR: https://git.openjdk.org/jfx/pull/877

From kcr at openjdk.org  Fri Aug 19 11:55:44 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 11:55:44 GMT
Subject: RFR: 8271395: Crash during printing when disposing textures [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 07:36:12 GMT, Florian Kirmaier  wrote:

>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.
>
> Florian Kirmaier 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master'
>  - JDK-8271395
>    changes based on codereview
>    We now catch Throwable instead of Exception
>  - JDK-8271395
>    QuantumRenderer is no longer public
>  - JDK-8271395 Fixing crash at printing
>    Switching to the QuantumThread fixes the native crash when cleaning Textures.

Looks good.

Yes, that is due to JDK-8292549 which is fixed by the soon-to-be-integrated PR #879

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/618

From kcr at openjdk.org  Fri Aug 19 12:03:51 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 12:03:51 GMT
Subject: Integrated: 8292549: GitHub actions: intermittent build failure on
 macOS while downloading ant
In-Reply-To: 
References: 
Message-ID: 

On Thu, 18 Aug 2022 22:22:36 GMT, Kevin Rushforth  wrote:

> Use the system version of `ant` on macOS platforms rather than downloading it from apache.org.
> 
> As noted in the bug report, we are seeing frequent GitHub Actions (GHA) failures on macOS due to a timeout while attempting to download apache ant 1.10.5.
> 
> The JavaFX build uses `ant` to build the apps (so `gradle apps` requires it). The installed version of ant on the macOS 11 systems that we use is ant 1.10.12, which works fine to build the apps. Given that the GHA builds are just a sanity test used as a help to reviewers and contributors, and that we already relax the requirement to specify the exact versions for a few other platform tools, there is no real downside to doing this.
> 
> This PR only touches the GHA build script for the macOS job, so the GHA test run is sufficient to test it.

This pull request has now been integrated.

Changeset: cedc17cc
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/cedc17cc26bb0ad3e2d0693bd174f118ad5f0b82
Stats:     16 lines in 1 file changed: 5 ins; 0 del; 11 mod

8292549: GitHub actions: intermittent build failure on macOS while downloading ant

Reviewed-by: angorya, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/879

From kcr at openjdk.org  Fri Aug 19 13:36:49 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 13:36:49 GMT
Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 19 Aug 2022 07:48:18 GMT, Ambarish Rapte  wrote:

> Looks like this is an existing issue, as we replace tabs with 4 spaces.
> We have several such existing instances of incorrect layout.

Perhaps it would be better to replace TABS with 8 spaces for libjpeg since it looks like that is what their source base assumes? If we were to do that, it would need to be done separately and not part of this update, since we would want to do it consistently for all TABS and not just the ones on lines modified by this update. It may or may not be worth a follow-up cleanup issue.

-------------

PR: https://git.openjdk.org/jfx/pull/874

From kcr at openjdk.org  Fri Aug 19 13:43:41 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 13:43:41 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <-afVZb48sWOoK1Dv68Rdzg_oa3BzUrlrcyGaEfftp-U=.ed1a6287-53d8-4fd5-bc52-1b0707db73e7@github.com>

On Fri, 19 Aug 2022 09:19:59 GMT, Florian Kirmaier  wrote:

> So it might be an option, to change this PR to only contain the null check.

If that is the route you want to go, then filing a new issue / PR is better. A fix with a null check might be a good option as long as we understand why the null is happening (so we can know whether the null check is sufficient).

> When I find some time, I will write a test to show how the parent.layout() call can cause issues.
> Similar issues exist with Group - which sometimes has the effect, that applications stop working when scenic view is used. (or other tooling)

That would be helpful. As it is, this PR is not really ready for review for the reasons I mentioned (much) earlier.

-------------

PR: https://git.openjdk.org/jfx/pull/564

From kcr at openjdk.org  Fri Aug 19 13:57:53 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 13:57:53 GMT
Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly
 displays a horizontal scroll bar. [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Aug 2022 02:21:30 GMT, Sai Pradeep Dandem  wrote:

>> **Issue:**
>> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced.
>> 
>> **Cause:**
>> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. 
>> 
>> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging).
>> 
>> To confirm this behaviour, please find the below example that showcases the issue:
>> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly.
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.beans.property.StringProperty;
>> import javafx.collections.FXCollections;
>> import javafx.collections.ObservableList;
>> import javafx.geometry.Insets;
>> import javafx.scene.Group;
>> import javafx.scene.Scene;
>> import javafx.scene.control.*;
>> import javafx.scene.layout.HBox;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>> 
>> public class ConstrainedResizePolicyIssueDemo extends Application {
>>     @Override
>>     public void start(Stage primaryStage) throws Exception {
>>         TableColumn fnCol = new TableColumn<>("First Name");
>>         fnCol.setMinWidth(100);
>>         fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty());
>> 
>>         TableColumn priceCol = new TableColumn<>("Price");
>>         priceCol.setMinWidth(100);
>>         priceCol.setMaxWidth(150);
>>         priceCol.setCellValueFactory(param -> param.getValue().priceProperty());
>> 
>>         TableColumn totalCol = new TableColumn<>("Total");
>>         totalCol.setMinWidth(100);
>>         totalCol.setMaxWidth(150);
>>         totalCol.setCellValueFactory(param -> param.getValue().totalProperty());
>> 
>>         ObservableList persons = FXCollections.observableArrayList();
>>         persons.add(new Person("Harry", "200.00", "210.00"));
>>         persons.add(new Person("Jacob", "260.00", "260.00"));
>> 
>>         TableView tableView = new TableView<>();
>>         tableView.getColumns().addAll(fnCol, priceCol, totalCol);
>>         tableView.setItems(persons);
>>         tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
>>         tableView.setMinWidth(500);
>>         tableView.maxWidthProperty().bind(tableView.minWidthProperty());
>> 
>>         Button button1 = new Button("Reduce 1px");
>>         button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1));
>>         Button button2 = new Button("Reduce 10px");
>>         button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10));
>>         Button button3 = new Button("Reset");
>>         button3.setOnAction(e -> tableView.setMinWidth(500));
>>         Button button4 = new Button("Increase 1px");
>>         button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1));
>>         Button button5 = new Button("Increase 10px");
>>         button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10));
>> 
>>         HBox row = new HBox(button1, button2, button3, button4, button5);
>>         row.setSpacing(10);
>>         TextArea output = new TextArea();
>> 
>>         addWidthListeners(tableView, output);
>>         VBox root = new VBox(row, new Group(tableView), output);
>>         root.setSpacing(10);
>>         root.setPadding(new Insets(10));
>> 
>>         Scene scene = new Scene(root);
>>         primaryStage.setScene(scene);
>>         primaryStage.setTitle("Constrained Resize Policy Issue TableView");
>>         primaryStage.show();
>>     }
>> 
>>     private void addWidthListeners(TableView tableView, TextArea output) {
>>         tableView.widthProperty().addListener((obs, old, val) -> {
>>             String str = "Table width changed :: " + val + "\n";
>>             output.setText(output.getText() + str);
>>             output.positionCaret(output.getText().length());
>>         });
>>         tableView.getColumns().forEach(column -> {
>>             column.widthProperty().addListener((obs, old, width) -> {
>>                 String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n";
>>                 output.setText(output.getText() + str);
>>                 output.positionCaret(output.getText().length());
>>             });
>>         });
>>     }
>> 
>>     class Person {
>>         private StringProperty firstName = new SimpleStringProperty();
>>         private StringProperty price = new SimpleStringProperty();
>>         private StringProperty total = new SimpleStringProperty();
>> 
>>         public Person(String fn, String price, String total) {
>>             setFirstName(fn);
>>             setPrice(price);
>>             setTotal(total);
>>         }
>> 
>>         public StringProperty firstNameProperty() {
>>             return firstName;
>>         }
>> 
>>         public void setFirstName(String firstName) {
>>             this.firstName.set(firstName);
>>         }
>> 
>>         public StringProperty priceProperty() {
>>             return price;
>>         }
>> 
>>         public void setPrice(String price) {
>>             this.price.set(price);
>>         }
>> 
>>         public StringProperty totalProperty() {
>>             return total;
>>         }
>> 
>>         public void setTotal(String total) {
>>             this.total.set(total);
>>         }
>>     }
>> }
>> 
>> 
>> **Fix:**
>> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px.
>> 
>> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226
>> 
>> `if (Math.abs(colWidth - tableWidth) > 1) {`
>> 
>> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly.
>
> Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test review comments

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx/pull/848

From kcr at openjdk.org  Fri Aug 19 14:39:16 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 14:39:16 GMT
Subject: [jfx17u] RFR: 8288450: Update attribution in gstreamer.md file
Message-ID: 

Clean backport.

-------------

Commit messages:
 - 8288450: Update attribution in gstreamer.md file

Changes: https://git.openjdk.org/jfx17u/pull/79/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=79&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288450
  Stats: 6943 lines in 3 files changed: 293 ins; 6648 del; 2 mod
  Patch: https://git.openjdk.org/jfx17u/pull/79.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/79/head:pull/79

PR: https://git.openjdk.org/jfx17u/pull/79

From kcr at openjdk.org  Fri Aug 19 14:43:07 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 14:43:07 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
Message-ID: 

Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:


CONTRIBUTING.md
README.md
doc-files/release-notes-17.0.1.md
doc-files/release-notes-17.0.2.md

-------------

Commit messages:
 - 8286774: Replace openjdk.java.net with openjdk.org

Changes: https://git.openjdk.org/jfx17u/pull/80/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286774
  Stats: 570 lines in 31 files changed: 0 ins; 0 del; 570 mod
  Patch: https://git.openjdk.org/jfx17u/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/80/head:pull/80

PR: https://git.openjdk.org/jfx17u/pull/80

From kcr at openjdk.org  Fri Aug 19 14:43:07 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 14:43:07 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

Reviewer: @arapte or @johanvos

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From angorya at openjdk.org  Fri Aug 19 14:46:54 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 14:46:54 GMT
Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly
 displays a horizontal scroll bar. [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Aug 2022 02:21:30 GMT, Sai Pradeep Dandem  wrote:

>> **Issue:**
>> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced.
>> 
>> **Cause:**
>> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. 
>> 
>> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging).
>> 
>> To confirm this behaviour, please find the below example that showcases the issue:
>> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly.
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.beans.property.StringProperty;
>> import javafx.collections.FXCollections;
>> import javafx.collections.ObservableList;
>> import javafx.geometry.Insets;
>> import javafx.scene.Group;
>> import javafx.scene.Scene;
>> import javafx.scene.control.*;
>> import javafx.scene.layout.HBox;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>> 
>> public class ConstrainedResizePolicyIssueDemo extends Application {
>>     @Override
>>     public void start(Stage primaryStage) throws Exception {
>>         TableColumn fnCol = new TableColumn<>("First Name");
>>         fnCol.setMinWidth(100);
>>         fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty());
>> 
>>         TableColumn priceCol = new TableColumn<>("Price");
>>         priceCol.setMinWidth(100);
>>         priceCol.setMaxWidth(150);
>>         priceCol.setCellValueFactory(param -> param.getValue().priceProperty());
>> 
>>         TableColumn totalCol = new TableColumn<>("Total");
>>         totalCol.setMinWidth(100);
>>         totalCol.setMaxWidth(150);
>>         totalCol.setCellValueFactory(param -> param.getValue().totalProperty());
>> 
>>         ObservableList persons = FXCollections.observableArrayList();
>>         persons.add(new Person("Harry", "200.00", "210.00"));
>>         persons.add(new Person("Jacob", "260.00", "260.00"));
>> 
>>         TableView tableView = new TableView<>();
>>         tableView.getColumns().addAll(fnCol, priceCol, totalCol);
>>         tableView.setItems(persons);
>>         tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
>>         tableView.setMinWidth(500);
>>         tableView.maxWidthProperty().bind(tableView.minWidthProperty());
>> 
>>         Button button1 = new Button("Reduce 1px");
>>         button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1));
>>         Button button2 = new Button("Reduce 10px");
>>         button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10));
>>         Button button3 = new Button("Reset");
>>         button3.setOnAction(e -> tableView.setMinWidth(500));
>>         Button button4 = new Button("Increase 1px");
>>         button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1));
>>         Button button5 = new Button("Increase 10px");
>>         button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10));
>> 
>>         HBox row = new HBox(button1, button2, button3, button4, button5);
>>         row.setSpacing(10);
>>         TextArea output = new TextArea();
>> 
>>         addWidthListeners(tableView, output);
>>         VBox root = new VBox(row, new Group(tableView), output);
>>         root.setSpacing(10);
>>         root.setPadding(new Insets(10));
>> 
>>         Scene scene = new Scene(root);
>>         primaryStage.setScene(scene);
>>         primaryStage.setTitle("Constrained Resize Policy Issue TableView");
>>         primaryStage.show();
>>     }
>> 
>>     private void addWidthListeners(TableView tableView, TextArea output) {
>>         tableView.widthProperty().addListener((obs, old, val) -> {
>>             String str = "Table width changed :: " + val + "\n";
>>             output.setText(output.getText() + str);
>>             output.positionCaret(output.getText().length());
>>         });
>>         tableView.getColumns().forEach(column -> {
>>             column.widthProperty().addListener((obs, old, width) -> {
>>                 String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n";
>>                 output.setText(output.getText() + str);
>>                 output.positionCaret(output.getText().length());
>>             });
>>         });
>>     }
>> 
>>     class Person {
>>         private StringProperty firstName = new SimpleStringProperty();
>>         private StringProperty price = new SimpleStringProperty();
>>         private StringProperty total = new SimpleStringProperty();
>> 
>>         public Person(String fn, String price, String total) {
>>             setFirstName(fn);
>>             setPrice(price);
>>             setTotal(total);
>>         }
>> 
>>         public StringProperty firstNameProperty() {
>>             return firstName;
>>         }
>> 
>>         public void setFirstName(String firstName) {
>>             this.firstName.set(firstName);
>>         }
>> 
>>         public StringProperty priceProperty() {
>>             return price;
>>         }
>> 
>>         public void setPrice(String price) {
>>             this.price.set(price);
>>         }
>> 
>>         public StringProperty totalProperty() {
>>             return total;
>>         }
>> 
>>         public void setTotal(String total) {
>>             this.total.set(total);
>>         }
>>     }
>> }
>> 
>> 
>> **Fix:**
>> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px.
>> 
>> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226
>> 
>> `if (Math.abs(colWidth - tableWidth) > 1) {`
>> 
>> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly.
>
> Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test review comments

good job!

-------------

Marked as reviewed by angorya (Author).

PR: https://git.openjdk.org/jfx/pull/848

From angorya at openjdk.org  Fri Aug 19 14:57:39 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 14:57:39 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 00:37:34 GMT, Nir Lisker  wrote:

>> Fixes the mistakes in the JBS ticket and some additional minor corrections.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Would these changes require a CSR?  Or, since they are just corrections, the API did not really change?
Otherwise, looks good.  Thank you for cleaning up the docs!

-------------

Marked as reviewed by angorya (Author).

PR: https://git.openjdk.org/jfx/pull/880

From angorya at openjdk.org  Fri Aug 19 15:15:44 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 15:15:44 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

CookieManager.java - web/src/main/java/com/sun/webkit/network line 156 refers to 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7059532

would this be in scope of this PR?

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From angorya at openjdk.org  Fri Aug 19 15:20:42 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 15:20:42 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

Should we also, at some point, replace http -> https?
For example,
AccordionApp : 51

 * @docUrl http://www.oracle.com/pls/topic/lookup?ctx=javase80&id=JFXUI336 Using JavaFX UI Controls

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From angorya at openjdk.org  Fri Aug 19 15:24:45 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 15:24:45 GMT
Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE
 on sorting
In-Reply-To: 
References: 
 
Message-ID: <6ijZZrllZf_vSZnrcr1Fydlx9lSePdAr2qRU-TYqubM=.75d34f2b-055c-4d32-93c1-e22173138e8d@github.com>

On Fri, 19 Aug 2022 09:02:55 GMT, Jeanette Winzenburg  wrote:

> hmm ... where are the tests ;)

good point.  will do.

-------------

PR: https://git.openjdk.org/jfx/pull/876

From kcr at openjdk.org  Fri Aug 19 16:25:46 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 16:25:46 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

This is a backport of an existing jfx mainline fix, so all of these additional things are out of scope for this PR. They will be good to file as follow-up fixes for mainline jfx, though, so thanks for pointing them out.

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From angorya at openjdk.org  Fri Aug 19 16:30:35 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 16:30:35 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v3]
In-Reply-To: 
References: 
Message-ID: 

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8292353.visuals
 - 8292353: review comments
 - Merge remote-tracking branch 'origin/master' into 8292353.visuals
 - 8292353: update selection

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/0b9aadb7..51275937

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=01-02

  Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

PR: https://git.openjdk.org/jfx/pull/875

From prr at openjdk.org  Fri Aug 19 16:43:33 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Aug 2022 16:43:33 GMT
Subject: RFR: 8271395: Crash during printing when disposing textures [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 07:36:12 GMT, Florian Kirmaier  wrote:

>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.
>
> Florian Kirmaier 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master'
>  - JDK-8271395
>    changes based on codereview
>    We now catch Throwable instead of Exception
>  - JDK-8271395
>    QuantumRenderer is no longer public
>  - JDK-8271395 Fixing crash at printing
>    Switching to the QuantumThread fixes the native crash when cleaning Textures.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jfx/pull/618

From nlisker at openjdk.org  Fri Aug 19 16:50:07 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 19 Aug 2022 16:50:07 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <2wkOqibIqtpaBVkAT4JR_Jl2LQ9NoDkPNGs4J2HJWKE=.5181df84-8b59-4ea0-9dd7-5a4455bf79d7@github.com>

On Fri, 19 Aug 2022 14:54:11 GMT, Andy Goryachev  wrote:

> Would these changes require a CSR? Or, since they are just corrections, the API did not really change? Otherwise, looks good. Thank you for cleaning up the docs!

Usually they don't since there are no spec changes.

-------------

PR: https://git.openjdk.org/jfx/pull/880

From kcr at openjdk.org  Fri Aug 19 16:56:41 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 16:56:41 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 00:37:34 GMT, Nir Lisker  wrote:

>> Fixes the mistakes in the JBS ticket and some additional minor corrections.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I took a quick look and don't see anything that would warrant a CSR. I'll confirm when I review.

-------------

PR: https://git.openjdk.org/jfx/pull/880

From kcr at openjdk.org  Fri Aug 19 19:21:12 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 19:21:12 GMT
Subject: [jfx17u] Integrated: 8288450: Update attribution in gstreamer.md file
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:32:41 GMT, Kevin Rushforth  wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: edd83e3e
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/edd83e3eb7b57323dc91e1aa7ccffc4eb9943283
Stats:     6943 lines in 3 files changed: 293 ins; 6648 del; 2 mod

8288450: Update attribution in gstreamer.md file
8288449: Update attribution in glib.md file

Backport-of: 54e689ce639ee182113dab610d9ed82890493898

-------------

PR: https://git.openjdk.org/jfx17u/pull/79

From arapte at openjdk.org  Fri Aug 19 19:32:59 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 19 Aug 2022 19:32:59 GMT
Subject: [jfx17u] RFR: 8286774: Replace openjdk.java.net with openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From kcr at openjdk.org  Fri Aug 19 20:52:06 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 20:52:06 GMT
Subject: [jfx17u] Integrated: 8286774: Replace openjdk.java.net with
 openjdk.org
In-Reply-To: 
References: 
Message-ID: 

On Fri, 19 Aug 2022 14:34:19 GMT, Kevin Rushforth  wrote:

> Backport fix to substitute openjdk.java.net with openjdk.org. Most of the patch applied cleanly, but there were a few files modified in mainline that don't exist in jfx17u (so excluded from backport). Additionally, I had to manually update the following:
> 
> 
> CONTRIBUTING.md
> README.md
> doc-files/release-notes-17.0.1.md
> doc-files/release-notes-17.0.2.md

This pull request has now been integrated.

Changeset: e006ee78
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx17u/commit/e006ee78477e7925bc5de29bfa6b5908a37f5028
Stats:     570 lines in 31 files changed: 0 ins; 0 del; 570 mod

8286774: Replace openjdk.java.net with openjdk.org

Reviewed-by: arapte
Backport-of: c75928654581920867b5d6c655fb7917d43d1093

-------------

PR: https://git.openjdk.org/jfx17u/pull/80

From kcr at openjdk.org  Fri Aug 19 23:16:44 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Aug 2022 23:16:44 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
In-Reply-To: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
References: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
Message-ID: 

On Fri, 19 Aug 2022 00:18:37 GMT, Nir Lisker  wrote:

> Added docs for inherited methods in `Bindings` subclasses.

As far as I can tell, none of these are public API and so don't show up in the docs. (If they were, then the lack of an `@return` in a few places would generate a warning which we are not seeing. Are you building the docs with a setting that produces docs for non-public classes?

If that's the reason for doing this, then it probably doesn't need to go into 19 (although, since we are going to generate the docs again anyway., I won't object).

-------------

PR: https://git.openjdk.org/jfx/pull/881

From angorya at openjdk.org  Fri Aug 19 23:31:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 23:31:55 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v4]
In-Reply-To: 
References: 
Message-ID: 

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8292353: added tests

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/51275937..419e76c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=02-03

  Stats: 363 lines in 1 file changed: 363 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

PR: https://git.openjdk.org/jfx/pull/875

From angorya at openjdk.org  Fri Aug 19 23:33:11 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 23:33:11 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v4]
In-Reply-To: <3qKG_9IhxoxCJ36sokSoXC1_ShABIQIxw_RVn3dwNJs=.ad1e80d8-3554-465e-9cec-92b63a692ae7@github.com>
References: 
 <3qKG_9IhxoxCJ36sokSoXC1_ShABIQIxw_RVn3dwNJs=.ad1e80d8-3554-465e-9cec-92b63a692ae7@github.com>
Message-ID: 

On Thu, 18 Aug 2022 09:51:53 GMT, Jeanette Winzenburg  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292353: added tests
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 448:
> 
>> 446:         }
>> 447: 
>> 448:         boolean isSelected = !sm.isCellSelectionEnabled() && sm.isSelected(index, null);
> 
> this is different from TableRow (which uses isSelected(index)) - why?
> 
> And we don't seem to have complete test coverage for row selection (otherwise this issue would have shown somewhere :) - please add test/s that fail/pass before/after the fix, respectively

updated and added tests.

-------------

PR: https://git.openjdk.org/jfx/pull/875

From angorya at openjdk.org  Fri Aug 19 23:35:31 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Aug 2022 23:35:31 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v5]
In-Reply-To: 
References: 
Message-ID: 

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8292353: whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/419e76c1..326fcce4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

PR: https://git.openjdk.org/jfx/pull/875

From nlisker at openjdk.org  Sat Aug 20 00:11:39 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 20 Aug 2022 00:11:39 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
In-Reply-To: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
References: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
Message-ID: 

On Fri, 19 Aug 2022 00:18:37 GMT, Nir Lisker  wrote:

> Added docs for inherited methods in `Bindings` subclasses.

I don't mind either way. I initially bundled it with the issue for fixing API docs, but decoupled it later and just thought it would be fine to do them both. The changes are very straightforward.

> Are you building the docs with a setting that produces docs for non-public classes?

No, but Eclipse shows internal docs also. I suspect other IDEs do so as well.

-------------

PR: https://git.openjdk.org/jfx/pull/881

From kcr at openjdk.org  Sat Aug 20 00:33:32 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 20 Aug 2022 00:33:32 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
In-Reply-To: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
References: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
Message-ID: 

On Fri, 19 Aug 2022 00:18:37 GMT, Nir Lisker  wrote:

> Added docs for inherited methods in `Bindings` subclasses.

Looks fine. I left a question about the missing `@return` tags, but it might not matter here depending on whether the IDEs care.

modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 174:

> 172:             /**
> 173:              * Returns an immutable list of the dependencies of this binding.
> 174:              */

Does the missing `@return` tag matter here? It isn't public docs so might not matter. The same question applies to the other instances of this overridden method.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/881

From nlisker at openjdk.org  Sat Aug 20 00:33:33 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 20 Aug 2022 00:33:33 GMT
Subject: [jfx19] RFR: 8291906: Bindings.createXxxBinding inherit incorrect
 method docs
In-Reply-To: 
References: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
 
Message-ID: 

On Sat, 20 Aug 2022 00:27:32 GMT, Kevin Rushforth  wrote:

>> Added docs for inherited methods in `Bindings` subclasses.
>
> modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 174:
> 
>> 172:             /**
>> 173:              * Returns an immutable list of the dependencies of this binding.
>> 174:              */
> 
> Does the missing `@return` tag matter here? It isn't public docs so might not matter. The same question applies to the other instances of this overridden method.

I don't think it matters. The description is more important.

-------------

PR: https://git.openjdk.org/jfx/pull/881

From nlisker at openjdk.org  Sat Aug 20 00:43:50 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 20 Aug 2022 00:43:50 GMT
Subject: [jfx19] Integrated: 8291906: Bindings.createXxxBinding inherit
 incorrect method docs
In-Reply-To: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
References: <-uS-R9Zirzt434iOetqZDJFL3sAw4ui-vrhaQw62Abg=.cff4ef17-dc46-464d-8f6e-32965f7e8f3c@github.com>
Message-ID: 

On Fri, 19 Aug 2022 00:18:37 GMT, Nir Lisker  wrote:

> Added docs for inherited methods in `Bindings` subclasses.

This pull request has now been integrated.

Changeset: 5c007833
Author:    Nir Lisker 
URL:       https://git.openjdk.org/jfx/commit/5c00783352940b08f6254d2250524ef804984267
Stats:     42 lines in 1 file changed: 42 ins; 0 del; 0 mod

8291906: Bindings.createXxxBinding inherit incorrect method docs

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/881

From fkirmaier at openjdk.org  Sat Aug 20 12:44:35 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Sat, 20 Aug 2022 12:44:35 GMT
Subject: Integrated: 8271395: Crash during printing when disposing textures
In-Reply-To: 
References: 
Message-ID: <1KmpssTC8x9rS_GvTvntyHSVYpMt_W4PO43PXygtPJ0=.f4e5ca31-2469-49d6-8fef-8efe6d28bb47@github.com>

On Mon, 6 Sep 2021 10:33:28 GMT, Florian Kirmaier  wrote:

> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread.
> I'm open for better solutions on how to fix this Issue.
> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread.

This pull request has now been integrated.

Changeset: 88159811
Author:    Florian Kirmaier 
Committer: Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/88159811239b76399b8f90c6c648293b4a06528c
Stats:     23 lines in 2 files changed: 23 ins; 0 del; 0 mod

8271395: Crash during printing when disposing textures

Reviewed-by: kcr, prr

-------------

PR: https://git.openjdk.org/jfx/pull/618

From kcr at openjdk.org  Sat Aug 20 12:49:35 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 20 Aug 2022 12:49:35 GMT
Subject: RFR: 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly
 displays a horizontal scroll bar.
In-Reply-To: 
References: 
 <4C73S8_ounnwZr9uyD2_yAcGdXJTN88Pe2b2w9gxQak=.43e7a3e5-8320-4468-9475-5b177208a665@github.com>
 <2RoB4gyvso6w6weufIwYGxoB3OSVqr_FmZB1f5EqxjQ=.05f87e44-07f4-43a9-84c2-07142d21ed80@github.com>
 <0L1CdX6lO070NqzFhslfwY91LIJsUX9h8OvLArbggmc=.20eafde0-c855-42ed-a201-14998fa0e358@github.com>
 
Message-ID: 

On Tue, 26 Jul 2022 22:59:03 GMT, Sai Pradeep Dandem  wrote:

>>> I am not sure about setting TableView.CONSTRAINED_RESIZE_POLICY means to always hide the horizontal scroll bar. The most common use case with the CONSTRAINED_RESIZE_POLICY, is to auto stretch the columns if there is enough space, and set to the minimum widths and show horizontal scroll bar if there is not enough space. I included an example in this stackoverflow [question](https://stackoverflow.com/questions/73060277/horizontal-scrollbar-is-visible-in-tableview-with-constrained-resize-policy) and the gif show-casing the requirement (2nd gif). And the current code already handles this very well.
>> 
>> Quite the opposite.  As an app developer, I've used unrestrained policy (in swing) exactly once, all other cases used fit-to-width.
>> 
>> Even if you look at stackoverflow and even [JDK-8089280](https://bugs.openjdk.org/browse/JDK-8089280) it is clear that the app developers do not want to see the horizontal scroll bar with the constrained policy set, ever.  This was one of the pain points with javafx coming from swing.  
>> 
>> In swing, JTable offers a rich set of possibilities:
>> 
>> `    /** Do not adjust column widths automatically; use a horizontal scrollbar instead. */
>>     public static final int     AUTO_RESIZE_OFF = 0;
>> 
>>     /** When a column is adjusted in the UI, adjust the next column the opposite way. */
>>     public static final int     AUTO_RESIZE_NEXT_COLUMN = 1;
>> 
>>     /** During UI adjustment, change subsequent columns to preserve the total width;
>>       * this is the default behavior. */
>>     public static final int     AUTO_RESIZE_SUBSEQUENT_COLUMNS = 2;
>> 
>>     /** During all resize operations, apply adjustments to the last column only. */
>>     public static final int     AUTO_RESIZE_LAST_COLUMN = 3;
>> 
>>     /** During all resize operations, proportionately resize all columns. */
>>     public static final int     AUTO_RESIZE_ALL_COLUMNS = 4;`
>> 
>> In javafx, behavior of TableView.CONSTRAINED_RESIZE_POLICY is, permit me to say, simply incorrect.  The scope of this discussion may go beyond the scope of this PR, but the fact that we have a number of JDK bugs logged against it is an indication.
>
> @andy-goryachev-oracle Thanks for providing the info about constrained resize policy in Swing. Unfornately I didn't get a chance to work with Swing, so I am not fully aware of this functionality that existed in Swing. At this stage in JavaFX,the need with scroll bar visibility comes into picture when working with resizable windows. May be as mentioned in one of the comments in [JDK-8089280](https://bugs.openjdk.org/browse/JDK-8089280), when constrained resize policy is set, it needs to set/override the minWidth of the table view to total minWidths of all columns. And as you said, this might be beyond the scope of this PR.

@SaiPradeepDandem This is now ready to be integrated. The next step is for you to issue the `/integrate` command, and then Ajit or I will sponsor it.

-------------

PR: https://git.openjdk.org/jfx/pull/848

From fastegal at openjdk.org  Sun Aug 21 12:00:40 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Sun, 21 Aug 2022 12:00:40 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl  wrote:

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

Fix and tests look rather complete, NPEs are fixed

There is still one unguarded access to the selectionModel in ListViewSkin.queryAccessibleAttributes: don't know if that's ever reached without actually having a selectionModel?

As we have similar NPEs in all our behaviors (of virtualized controls), we might decided here which behavior we want to support and then apply that decision everywhere. In particular what should happen if we have a null selection and a not-null focusModel with

- activate/edit: that happens on the focusedIndex/Cell with selection only an after-thought
- focus navigation (often ctrl-somekey): is inconsistently either supported (ctrl-end) or not (ctrl-pageDown)

Personally, I think that we should support both - we have a separate focusModel so should use it independently of the selectionModel where possible. A good starter for this issue might be to implement the activate such that it doesn't back out on null selection (just leave out the select statement). The consistent support of navigation might be done in a follow-up issue.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewMouseInputTest.java line 397:

> 395: 
> 396:         loader.dispose();
> 397:     }

the stageloader is not disposed if the test fails - so a safer route is to keep it in a field which is then disposed in  @ after (which we decided to do years ago, but tend to forget occasionally :), see f.i. ListViewKeyInputTest

BTW: good to explicitely create the stageloader and __not__ rely on the one implicitly created by the flowUtils!

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2196:

> 2194: 
> 2195:         StageLoader stageLoader = new StageLoader(listView);
> 2196: 

just to not forget: stageloader again

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2208:

> 2206: 
> 2207:         StageLoader stageLoader = new StageLoader(listView);
> 2208: 

just to not forget: stageloader again

-------------

Changes requested by fastegal (Reviewer).

PR: https://git.openjdk.org/jfx/pull/711

From duke at openjdk.org  Mon Aug 22 04:25:46 2022
From: duke at openjdk.org (Sai Pradeep Dandem)
Date: Mon, 22 Aug 2022 04:25:46 GMT
Subject: Integrated: 8089009: TableView with CONSTRAINED_RESIZE_POLICY
 incorrectly displays a horizontal scroll bar.
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Jul 2022 09:25:57 GMT, Sai Pradeep Dandem  wrote:

> **Issue:**
> When the `TableView` is set with built-in `CONSTRAINED_RESIZE_POLICY`, the horizontal scroll bar keeps flickering when the `TableView` width is reduced.
> 
> **Cause:**
> The table columns widths are recalculated only if the difference of the `TableView` width and the total columns width is greater than 1px. Because of this improper calculations, if the `TableView` width is reduced by 1px, the columns widths are not updated. Which results to computing for horizontal scroll bar visibility in `VirtualFlow` to improper results and let the horizontal scroll bar to be visible. 
> 
> Where as if the `TableView` width is reduced by more than 1px, the calculations are done correctly and the horizontal scroll bar visibility is turned off. Because of this behaviour, it looks like the horizontal scroll bar is flickering when the `TableView` width is reduced (let?s say by dragging).
> 
> To confirm this behaviour, please find the below example that showcases the issue:
> When the tableView width is reduced/increased by 1px, the column widths are recalculated only after every alternate 1px change. Whereas if the tableView width is reduced/increased by more than 1px (say 10px), the column widths are calculated correctly.
> 
> 
> import javafx.application.Application;
> import javafx.beans.property.SimpleStringProperty;
> import javafx.beans.property.StringProperty;
> import javafx.collections.FXCollections;
> import javafx.collections.ObservableList;
> import javafx.geometry.Insets;
> import javafx.scene.Group;
> import javafx.scene.Scene;
> import javafx.scene.control.*;
> import javafx.scene.layout.HBox;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
> 
> public class ConstrainedResizePolicyIssueDemo extends Application {
>     @Override
>     public void start(Stage primaryStage) throws Exception {
>         TableColumn fnCol = new TableColumn<>("First Name");
>         fnCol.setMinWidth(100);
>         fnCol.setCellValueFactory(param -> param.getValue().firstNameProperty());
> 
>         TableColumn priceCol = new TableColumn<>("Price");
>         priceCol.setMinWidth(100);
>         priceCol.setMaxWidth(150);
>         priceCol.setCellValueFactory(param -> param.getValue().priceProperty());
> 
>         TableColumn totalCol = new TableColumn<>("Total");
>         totalCol.setMinWidth(100);
>         totalCol.setMaxWidth(150);
>         totalCol.setCellValueFactory(param -> param.getValue().totalProperty());
> 
>         ObservableList persons = FXCollections.observableArrayList();
>         persons.add(new Person("Harry", "200.00", "210.00"));
>         persons.add(new Person("Jacob", "260.00", "260.00"));
> 
>         TableView tableView = new TableView<>();
>         tableView.getColumns().addAll(fnCol, priceCol, totalCol);
>         tableView.setItems(persons);
>         tableView.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY);
>         tableView.setMinWidth(500);
>         tableView.maxWidthProperty().bind(tableView.minWidthProperty());
> 
>         Button button1 = new Button("Reduce 1px");
>         button1.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 1));
>         Button button2 = new Button("Reduce 10px");
>         button2.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() - 10));
>         Button button3 = new Button("Reset");
>         button3.setOnAction(e -> tableView.setMinWidth(500));
>         Button button4 = new Button("Increase 1px");
>         button4.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 1));
>         Button button5 = new Button("Increase 10px");
>         button5.setOnAction(e -> tableView.setMinWidth(tableView.getMinWidth() + 10));
> 
>         HBox row = new HBox(button1, button2, button3, button4, button5);
>         row.setSpacing(10);
>         TextArea output = new TextArea();
> 
>         addWidthListeners(tableView, output);
>         VBox root = new VBox(row, new Group(tableView), output);
>         root.setSpacing(10);
>         root.setPadding(new Insets(10));
> 
>         Scene scene = new Scene(root);
>         primaryStage.setScene(scene);
>         primaryStage.setTitle("Constrained Resize Policy Issue TableView");
>         primaryStage.show();
>     }
> 
>     private void addWidthListeners(TableView tableView, TextArea output) {
>         tableView.widthProperty().addListener((obs, old, val) -> {
>             String str = "Table width changed :: " + val + "\n";
>             output.setText(output.getText() + str);
>             output.positionCaret(output.getText().length());
>         });
>         tableView.getColumns().forEach(column -> {
>             column.widthProperty().addListener((obs, old, width) -> {
>                 String str = " ---> " + column.getText() + " : width changed to : " + column.getWidth()+"\n";
>                 output.setText(output.getText() + str);
>                 output.positionCaret(output.getText().length());
>             });
>         });
>     }
> 
>     class Person {
>         private StringProperty firstName = new SimpleStringProperty();
>         private StringProperty price = new SimpleStringProperty();
>         private StringProperty total = new SimpleStringProperty();
> 
>         public Person(String fn, String price, String total) {
>             setFirstName(fn);
>             setPrice(price);
>             setTotal(total);
>         }
> 
>         public StringProperty firstNameProperty() {
>             return firstName;
>         }
> 
>         public void setFirstName(String firstName) {
>             this.firstName.set(firstName);
>         }
> 
>         public StringProperty priceProperty() {
>             return price;
>         }
> 
>         public void setPrice(String price) {
>             this.price.set(price);
>         }
> 
>         public StringProperty totalProperty() {
>             return total;
>         }
> 
>         public void setTotal(String total) {
>             this.total.set(total);
>         }
>     }
> }
> 
> 
> **Fix:**
> On investigating the code, it is noticed that there is an explicit line of code to check if the difference in widths is greater than 1px. I think this should be greater than 0px. Because we need to recompute the columns widths even if the width is increased by 1px.
> 
> The part of the code that need to be updated is in TableUtil.java -> constrainedResize(..) method -> line 226
> 
> `if (Math.abs(colWidth - tableWidth) > 1) {`
> 
> If I update the value 1 to 0, the issue is fixed and the horizontal scroll bar visibility is computed correctly.

This pull request has now been integrated.

Changeset: d4ff45af
Author:    Dandem, Sai Pradeep 
Committer: Ajit Ghaisas 
URL:       https://git.openjdk.org/jfx/commit/d4ff45af9fbde29f96d80681c7fc3af3ec580d1a
Stats:     56 lines in 2 files changed: 53 ins; 0 del; 3 mod

8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar.

Reviewed-by: kcr, angorya, aghaisas

-------------

PR: https://git.openjdk.org/jfx/pull/848

From fkirmaier at openjdk.org  Mon Aug 22 09:46:24 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 22 Aug 2022 09:46:24 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v4]
In-Reply-To: 
References: 
Message-ID: 

> It's "a bit" complicated.
> In some situations, getRuns get's called because listeners on bounds are set.
> This causes TextFlow to layout to compute the runs.
> Afterward, the bounds of the parents get updated. 
> This triggers a call to compute bounds - which cascades up to the children.
> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
> 
> In the case it happened - it didn't repair and the application kinda crashed.
> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
> It also can cause unpredictable performance issues.
> 
> Unit test and example stacktrace are in the ticket.
> 
> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
> The Textflow should be layouting by the Parent.
> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
> 
> Benefits:
>  * Better Tooling Support For ScenicView etc.
>  * Fixes complicated but reproducible crashes
>  * Might fix some rare crashes, which are hard to reproduce
>  * Likely improves performance - might fix some edge cases with unpredictable bad performance

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8269921
  Reverted the change to the layout, so we can fix the main-bug without further discussions.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/564/files
  - new: https://git.openjdk.org/jfx/pull/564/files/a9516f3d..404f7103

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=564&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=564&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/564.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/564/head:pull/564

PR: https://git.openjdk.org/jfx/pull/564

From fkirmaier at openjdk.org  Mon Aug 22 09:50:05 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 22 Aug 2022 09:50:05 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v3]
In-Reply-To: 
References: 
 
Message-ID: <8Qiw2XRQ5qsVHnWiyjIY8BhDnlnjBvxwkRlsuxnxh0E=.2b66b19a-c474-4892-9eb0-e2405519fe95@github.com>

On Tue, 26 Jul 2022 11:51:10 GMT, Florian Kirmaier  wrote:

>> It's "a bit" complicated.
>> In some situations, getRuns get's called because listeners on bounds are set.
>> This causes TextFlow to layout to compute the runs.
>> Afterward, the bounds of the parents get updated. 
>> This triggers a call to compute bounds - which cascades up to the children.
>> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
>> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
>> 
>> In the case it happened - it didn't repair and the application kinda crashed.
>> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
>> It also can cause unpredictable performance issues.
>> 
>> Unit test and example stacktrace are in the ticket.
>> 
>> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
>> The Textflow should be layouting by the Parent.
>> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
>> 
>> Benefits:
>>  * Better Tooling Support For ScenicView etc.
>>  * Fixes complicated but reproducible crashes
>>  * Might fix some rare crashes, which are hard to reproduce
>>  * Likely improves performance - might fix some edge cases with unpredictable bad performance
>
> Florian Kirmaier 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8269921-textflow-bug
>  - JDK-8269921
>    Added a copyright header
>  - JDK-8269921
>    Fixing a crash related to Text and TextFlow with bounds listeners

I've just removed the change in the layouting.
So I guess the PR should be good now.

-------------

PR: https://git.openjdk.org/jfx/pull/564

From angorya at openjdk.org  Mon Aug 22 15:31:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 15:31:51 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl  wrote:

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876

I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.

-------------

PR: https://git.openjdk.org/jfx/pull/711

From fastegal at openjdk.org  Mon Aug 22 15:45:44 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Mon, 22 Aug 2022 15:45:44 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Aug 2022 15:29:29 GMT, Andy Goryachev  wrote:

> There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876
> 
> I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.

@andy-goryachev-oracle  hmm .. are those methods reached if selectionModel == null? On skimming across its code, it looks like all callers back out (that is not call it) without selectionModel. Might be wrong, though - hard to tell without documented preconditions, and without tests ?

-------------

PR: https://git.openjdk.org/jfx/pull/711

From angorya at openjdk.org  Mon Aug 22 16:42:00 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 16:42:00 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 22 Aug 2022 15:43:28 GMT, Jeanette Winzenburg  wrote:

>> There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876
>> 
>> I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.
>
>> There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876
>> 
>> I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.
> 
> @andy-goryachev-oracle  hmm .. are those methods reached if selectionModel == null? On skimming across its code, it looks like all callers back out (that is not call it) without selectionModel. Might be wrong, though - hard to tell without documented preconditions, and without tests ?

@kleopatra : 
simpleSelect and selectRows are being called from CellBehaviorBase.mousePressed and mouseReleased, so probably yes.
in any way, they are updated in #876 ; fixing them here would likely create a merge conflict.

-------------

PR: https://git.openjdk.org/jfx/pull/711

From angorya at openjdk.org  Mon Aug 22 16:42:00 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 16:42:00 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
Message-ID: 

On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl  wrote:

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

Screen Shot 2022-08-22 at 09 37 36

-------------

PR: https://git.openjdk.org/jfx/pull/711

From jpereda at openjdk.org  Mon Aug 22 16:52:45 2022
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 22 Aug 2022 16:52:45 GMT
Subject: Integrated: 8291625: DialogPane without header nor headerText nor
 graphic node adds padding to the left of the content pane
In-Reply-To: 
References: 
Message-ID: <9D9rpiy3T10t-pHwUP91o_f8gOwcREOF3oP0Uc-FFUc=.dcec909d-a979-47a2-b9fa-5272fd9e1893@github.com>

On Tue, 2 Aug 2022 10:45:54 GMT, Jose Pereda  wrote:

> This PR fixes an issue when there is a DialogPane that has no header and no graphic is set, by adding the `graphic-container` styleclass only when there is a non-null graphic applied, preventing the padding that otherwise the graphic container will keep.
> 
> Two tests have been added, to verify that the padding is 0 when there is no graphic (this test fails without this PR) and to verify that the padding is correct when there is a graphic to the left of the content area.
> 
> As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area.

This pull request has now been integrated.

Changeset: bee2dfb8
Author:    Jose Pereda 
URL:       https://git.openjdk.org/jfx/commit/bee2dfb848c908c62764a1fa9c071d2cfcf9c1f4
Stats:     47 lines in 2 files changed: 40 ins; 3 del; 4 mod

8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane

Reviewed-by: aghaisas

-------------

PR: https://git.openjdk.org/jfx/pull/859

From fastegal at openjdk.org  Mon Aug 22 17:30:07 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Mon, 22 Aug 2022 17:30:07 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 22 Aug 2022 15:43:28 GMT, Jeanette Winzenburg  wrote:

>> There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876
>> 
>> I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.
>
>> There is also an unguarded access in CellBehaviorBase.selectRows(int,int) : 312 and CellBehaviorBase.sompleSelect(MouseButton,int,boolean) : 274, which are being fixed by #876
>> 
>> I'd suggest to integrate #876 first, followed by this PR, in order to avoid merge conflicts.
> 
> @andy-goryachev-oracle  hmm .. are those methods reached if selectionModel == null? On skimming across its code, it looks like all callers back out (that is not call it) without selectionModel. Might be wrong, though - hard to tell without documented preconditions, and without tests ?

> @kleopatra : simpleSelect and selectRows are being called from CellBehaviorBase.mousePressed and mouseReleased, so probably yes. in any way, they are updated in #876 ; fixing them here would likely create a merge conflict.

@andy-goryachev-oracle, to be precise: the mouse methods call doSelect which backs out if focus- or selectionModel is null - so doesn't look like we should touch simpleSelect/selectRows. Except maybe by adding a precondition that the selection/focusModel must not be null. But we'll see in review, you might convince me with tests :) 

Here at least cell behavior is not changed, so changes in the other PR wouldn't cause a conflict.

-------------

PR: https://git.openjdk.org/jfx/pull/711

From angorya at openjdk.org  Mon Aug 22 17:51:41 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 17:51:41 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: 
References: 
Message-ID: <_RYmhV_lrstbXUeSswFtZt9AF5o2eR3STqAqX829b28=.7e2be545-1909-498e-91d1-dfb7402527bc@github.com>

On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl  wrote:

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

you are right!  unless, of course, someone writes code to invoke these methods directly.  For example, simpleSelect() is protected, so any Behavior that extends CellBehaviorBase might encounter an NPE.

but again, these are being addressed in another PR.

-------------

PR: https://git.openjdk.org/jfx/pull/711

From jpereda at openjdk.org  Mon Aug 22 18:47:53 2022
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 22 Aug 2022 18:47:53 GMT
Subject: RFR: 8291625: DialogPane without header nor headerText nor graphic
 node adds padding to the left of the content pane
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 16 Aug 2022 11:57:45 GMT, Ajit Ghaisas  wrote:

>> This PR fixes an issue when there is a DialogPane that has no header and no graphic is set, by adding the `graphic-container` styleclass only when there is a non-null graphic applied, preventing the padding that otherwise the graphic container will keep.
>> 
>> Two tests have been added, to verify that the padding is 0 when there is no graphic (this test fails without this PR) and to verify that the padding is correct when there is a graphic to the left of the content area.
>> 
>> As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area.
>
>> As part of this PR or as possible follow-up, it could be also discussed that the right/bottom padding of the graphic container shouldn't be 0 when there is no header and the graphic is laid out to the left of the content area.
> 
> We can discuss this in a separate JBS issue.

@aghaisas I've just filed https://bugs.openjdk.org/browse/JDK-8292740 to track the follow-up issue.

-------------

PR: https://git.openjdk.org/jfx/pull/859

From angorya at openjdk.org  Mon Aug 22 19:31:50 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 19:31:50 GMT
Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE
 on sorting [v2]
In-Reply-To: 
References: 
Message-ID: 

> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. 
> 
> Setting a null selection model is a valid way to disable selection in a (tree)table.
> 
> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640).
> 
> changes:
> - added check for null selection model where it was missing
> - clearing focused row index on setting null selection model in TreeTableView

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:

 - 8187145: clear selection when setting selection model
 - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
 - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model
 - 8187145: whitespace
 - 8187145: clear focus
 - 8187145: tree table view
 - 8187145: fall through
 - 8187145: check for null selection model

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/876/files
  - new: https://git.openjdk.org/jfx/pull/876/files/df5a2402..d6d185fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=00-01

  Stats: 144 lines in 9 files changed: 123 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/876.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876

PR: https://git.openjdk.org/jfx/pull/876

From angorya at openjdk.org  Mon Aug 22 21:07:31 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 21:07:31 GMT
Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE
 on sorting [v3]
In-Reply-To: 
References: 
Message-ID: 

> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. 
> 
> Setting a null selection model is a valid way to disable selection in a (tree)table.
> 
> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640).
> 
> changes:
> - added check for null selection model where it was missing
> - clear focused row index on setting null selection model in TreeTableView
> - clear selected cells on setting a new selection model

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8187145: clear selected tree table row when setting null selection model

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/876/files
  - new: https://git.openjdk.org/jfx/pull/876/files/d6d185fc..5f37fe6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=01-02

  Stats: 13 lines in 1 file changed: 8 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/876.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876

PR: https://git.openjdk.org/jfx/pull/876

From angorya at openjdk.org  Mon Aug 22 21:08:39 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Aug 2022 21:08:39 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v6]
In-Reply-To: 
References: 
Message-ID: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com>

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - 8292353: typo
 - 8292353: typo

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/326fcce4..3ced43d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

PR: https://git.openjdk.org/jfx/pull/875

From kcr at openjdk.org  Mon Aug 22 22:32:41 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Aug 2022 22:32:41 GMT
Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 Aug 2022 00:37:34 GMT, Nir Lisker  wrote:

>> Fixes the mistakes in the JBS ticket and some additional minor corrections.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

A few comments inline.

modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 47:

> 45:  * 
> 46:  * 

> 47: * It's possible to have a formatter with just filter or value converter. If value converter is not provided however, The "however" in the middle of the sentence is a bit awkward, and not really needed here. I suggest dropping it. modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 48: > 46: *

> 47: * It's possible to have a formatter with just filter or value converter. If value converter is not provided however, > 48: * setting a value will result in an {@code IllegalStateException} and the value is always {#code null}. That should be `{@code null}` modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java line 130: > 128: * will treat that duration as if it were Duration.ZERO. Likewise, any Duration which answers true > 129: * to {@link javafx.util.Duration#isIndefinite()} will be treated as if it were a duration of Double.MAX_VALUE > 130: * milliseconds. Any {@code null} Duration is treated as Duration.ZERO. Any custom implementation of a backoff strategy Since you changed `null` to use code style, maybe also do it for `Duration.ZERO`? modules/javafx.graphics/src/main/java/javafx/concurrent/Service.java line 102: > 100: * Because a Service is intended to simplify declarative use cases, subclasses > 101: * should expose as properties the input parameters to the work to be done. > 102: * For example, suppose I wanted to write a Service that reads the first line As long as you are changing this sentence, can you also change `I` to `you`? The unintended use of first person here is a bit jarring. modules/javafx.graphics/src/main/java/javafx/concurrent/package.html line 36: > 34: > 35: > 36:

Provides the set of classes for javafx.concurrent.

Can you make this same change to the page title? ------------- PR: https://git.openjdk.org/jfx/pull/880 From arapte at openjdk.org Mon Aug 22 23:36:36 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 22 Aug 2022 23:36:36 GMT Subject: Integrated: 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 08:26:48 GMT, Ambarish Rapte wrote: > Accessibility is not implemented for JavaFX dialogs. This change is to implement the accessibility on windows platform. > Without this fix : On Windows platform, content of Dialog are not read by Windows Narrator or JAWS. > With this fix: > 1. Windows narrator reads the dialog correctly > 2. JAWS fails to read the header text. : This will be handled separately > 3. Behavior of VoiceOver on MacOS remains unchanged : This will be handled separately. > > Verification: > 1. Run HelloAlert toy app, with fix. > 2. Start Windows Narrator > 3. Click on the different buttons to show different Dialogs > => Observe that Narrator reads all the content correctly. This pull request has now been integrated. Changeset: b9515031 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/b951503134bdbc607cfa7a5ff05937f70a1a13dd Stats: 39 lines in 6 files changed: 37 ins; 1 del; 1 mod 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/873 From duke at openjdk.org Tue Aug 23 08:12:27 2022 From: duke at openjdk.org (danielpeintner) Date: Tue, 23 Aug 2022 08:12:27 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Mon, 22 Aug 2022 21:08:39 GMT, Andy Goryachev wrote: >> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. >> >> Changes: >> - modified TreeTableRow.updateSelection() > > Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: > > - 8292353: typo > - 8292353: typo modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 56: > 54: /** > 55: * Tests for: > 56: * - cell seleciton logic JDK-8292353. Nit: seleciton -> selection ------------- PR: https://git.openjdk.org/jfx/pull/875 From craigraw at gmail.com Tue Aug 23 08:31:45 2022 From: craigraw at gmail.com (Craig Raw) Date: Tue, 23 Aug 2022 10:31:45 +0200 Subject: Draggable TabPane introduces unwanted tab movement on selection Message-ID: When setting the tab drag policy on a TabPane to REORDER, undesirable behaviour is introduced where a tab occasionally "jumps" or slides to the right on selection, by about 20px. I cannot determine what causes this, but it seems to occur more often when clicking rapidly between tabs. After sliding to the right, the tab jumps back to its original position. The best way to demonstrate this is visually through this animated GIF: https://user-images.githubusercontent.com/862166/159428470-1bdf9761-e8df-453a-9a8c-18686ceae4f6.gif This is sufficiently disconcerting that it makes draggable tabs unusable for me. Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Aug 23 09:38:41 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 23 Aug 2022 09:38:41 GMT Subject: RFR: 8292391: Add support for optional signing of native libraries In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 21:14:42 GMT, Kevin Rushforth wrote: > This PR enables an optional signing step inserted into the build right after the step to strip binaries that was added by [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260). As is the case with the `strip` step, the optional signing is only ever enabled for production builds when running with `gradle -PCONF=Release`. > > This is an optional step, meaning that `codeSignCmd` and `codeSignArgs` need to be provided by scripts external to the repo in order to enable it. By default, they are not defined, so the additional logic added by this PR will do nothing. > > NOTE: as with the fix for [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260), this PR adds three copies of the build logic. I filed [JDK-8292506](https://bugs.openjdk.org/browse/JDK-8292506) to refactor both of them (strip and sign), and to look for other duplication as well. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/871 From fastegal at openjdk.org Tue Aug 23 10:42:29 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 23 Aug 2022 10:42:29 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Mon, 22 Aug 2022 21:08:39 GMT, Andy Goryachev wrote: >> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. >> >> Changes: >> - modified TreeTableRow.updateSelection() > > Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: > > - 8292353: typo > - 8292353: typo Fix looks good (left a minor inline comment which you might follow or not :) The tests, though, ... need some love: As a general rule, it's preferred to assert a single state per test method instead of changing the state repeatedly inside the same method. We can see that something is wrong when having code comments like: line 240: assertFalse(row.isSelected()); // JDK-8292353 failure line 249: assertFalse(row.isSelected()); // JDK-8292353 failure running the test before the fix and the second failure is never reached. We _want_ to see the failures, all of them :) Write a test as near to the cause as possible: here the cause is an incorrect selection state of the TreeTableRow under certain conditions. That's unrelated to any user interaction, so a setup faking such an interaction is a detour which might (or not) bring in their own trouble (aside: I do see the css parser warnings when running TreeAndTableViewTest inside Eclipse - that is [JDK-8291853](https://bugs.openjdk.org/browse/JDK-8291853) which we don't yet understand, except that something fishy might be going on ;) Best to use the most simple setup to test that exact state, here that would be an isolated Tree/TableRow thats configured with a Tree/TableView at some index and setup the view's selection state as needed, for examples see TreeTableRowTest or something like the following @Test public void testRowSelectionStateOnCellSelectionEnabledMultiple() { // configure view addColumns(); tree.getSelectionModel().setCellSelectionEnabled(true); tree.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); // configure tableRow int selected = 1; cell.updateTreeTableView(tree); cell.updateIndex(selected); // select all columns if possible tree.getSelectionModel().select(selected, null); assertEquals("sanity: all columns selected", tree.getColumns().size(), tree.getSelectionModel().getSelectedCells().size()); assertFalse("row must not be selected in cell selection mode", cell.isSelected()); } and one for the second failure before the fix plus (for coverage) the other combinations of cell selection enablement/selection mode :) These should reside in TreeTableRowTest, IMO, to be "near" the other row state tests. For coverage, we should also have the corresponding tests for TableRow (also isolated, not wrapped into faked user interaction). They should reside in TableRowTest. Which we don't have yet, time to add it :) My suggestions: - convert the monolithic test methods into separate tests, each without changing the state you want to test - configure and test the selection state of an isolated row (without faking user interaction, similar to the example above) - for TreeTableRow, add the tests to TreeTableRowTest - for TableRow, add TableRowTest and add analogue methods as those you added for TreeTableRow - remove TreeAndTableViewTest modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableRow.java line 450: > 448: boolean isSelected = !sm.isCellSelectionEnabled() && sm.isSelected(index); > 449: if (isSelected() != isSelected) { > 450: updateSelected(isSelected); looks good now - we might consider to copy the code comment from TableRow updateSelection for emphasis of the implementation intention. But then, it might be considered clutter, with tests in place. Leaving it to you to decide :) ------------- Changes requested by fastegal (Reviewer). PR: https://git.openjdk.org/jfx/pull/875 From fastegal at openjdk.org Tue Aug 23 10:52:30 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Tue, 23 Aug 2022 10:52:30 GMT Subject: RFR: 8235491: Tree/TableView: implementation of isSelected(int) violates contract [v11] In-Reply-To: References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: On Fri, 12 Aug 2022 17:21:24 GMT, Andy Goryachev wrote: >> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." >> 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) >> 3. modified TreeTableRow.updateSelection() to use the right isSelected() method >> 4. updated tests for Tree/TableView >> >> NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8235491: added tests hmm .. isn't this ready for integration? CSR being approved was the last step, or not? ------------- PR: https://git.openjdk.org/jfx/pull/839 From kcr at openjdk.org Tue Aug 23 11:04:50 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 11:04:50 GMT Subject: Integrated: 8292391: Add support for optional signing of native libraries In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 21:14:42 GMT, Kevin Rushforth wrote: > This PR enables an optional signing step inserted into the build right after the step to strip binaries that was added by [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260). As is the case with the `strip` step, the optional signing is only ever enabled for production builds when running with `gradle -PCONF=Release`. > > This is an optional step, meaning that `codeSignCmd` and `codeSignArgs` need to be provided by scripts external to the repo in order to enable it. By default, they are not defined, so the additional logic added by this PR will do nothing. > > NOTE: as with the fix for [JDK-8278260](https://bugs.openjdk.org/browse/JDK-8278260), this PR adds three copies of the build logic. I filed [JDK-8292506](https://bugs.openjdk.org/browse/JDK-8292506) to refactor both of them (strip and sign), and to look for other duplication as well. This pull request has now been integrated. Changeset: dee34b42 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/dee34b42d3443466d81fc4e2a9a2994338b680c0 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod 8292391: Add support for optional signing of native libraries Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/871 From nlisker at openjdk.org Tue Aug 23 11:46:47 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 11:46:47 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/880/files - new: https://git.openjdk.org/jfx/pull/880/files/d8ccb5ae..6e9eda88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=01-02 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/880.diff Fetch: git fetch https://git.openjdk.org/jfx pull/880/head:pull/880 PR: https://git.openjdk.org/jfx/pull/880 From nlisker at openjdk.org Tue Aug 23 11:46:48 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 11:46:48 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 22:21:29 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java line 130: > >> 128: * will treat that duration as if it were Duration.ZERO. Likewise, any Duration which answers true >> 129: * to {@link javafx.util.Duration#isIndefinite()} will be treated as if it were a duration of Double.MAX_VALUE >> 130: * milliseconds. Any {@code null} Duration is treated as Duration.ZERO. Any custom implementation of a backoff strategy > > Since you changed `null` to use code style, maybe also do it for `Duration.ZERO`? There are many places that are missing it in this class. Should I do them all while here? > modules/javafx.graphics/src/main/java/javafx/concurrent/Service.java line 102: > >> 100: * Because a Service is intended to simplify declarative use cases, subclasses >> 101: * should expose as properties the input parameters to the work to be done. >> 102: * For example, suppose I wanted to write a Service that reads the first line > > As long as you are changing this sentence, can you also change `I` to `you`? The unintended use of first person here is a bit jarring. I rephrased the sentence. ------------- PR: https://git.openjdk.org/jfx/pull/880 From kcr at openjdk.org Tue Aug 23 12:02:36 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 12:02:36 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 11:37:38 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/concurrent/ScheduledService.java line 130: >> >>> 128: * will treat that duration as if it were Duration.ZERO. Likewise, any Duration which answers true >>> 129: * to {@link javafx.util.Duration#isIndefinite()} will be treated as if it were a duration of Double.MAX_VALUE >>> 130: * milliseconds. Any {@code null} Duration is treated as Duration.ZERO. Any custom implementation of a backoff strategy >> >> Since you changed `null` to use code style, maybe also do it for `Duration.ZERO`? > > There are many places that are missing it in this class. Should I do them all while here? I'll leave that up to you. ------------- PR: https://git.openjdk.org/jfx/pull/880 From kcr at openjdk.org Tue Aug 23 12:02:38 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 12:02:38 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 11:46:47 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments modules/javafx.graphics/src/main/java/javafx/concurrent/Service.java line 104: > 102: * For example, to write a Service that reads the first line > 103: * from any URL and returned it as a String, it might be defined > 104: * such that it had a single property, {@code url}, and might be implemented I like the rewrite, although a couple of the verb tenses are now mismatched: "returned" --> "returns" "had" --> "has" (or replace "such that it had" by "with") ------------- PR: https://git.openjdk.org/jfx/pull/880 From angorya at openjdk.org Tue Aug 23 15:25:38 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 15:25:38 GMT Subject: Integrated: 8235491: Tree/TableView: implementation of isSelected(int) violates contract In-Reply-To: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> References: <8FltcHbiZfP9OSY8KnMyi6YiDE5nFc-g2CMwt9tkP2U=.cfc49717-cce5-4b96-bb59-93007d6cf5a1@github.com> Message-ID: <0rUTjFXI54WReOKOL-rft-3M07Hv35bPtZ3qU3BlAPo=.411e20be-f220-42c2-9c8a-87de0031d2f7@github.com> On Tue, 19 Jul 2022 22:08:19 GMT, Andy Goryachev wrote: > 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement "Is functionally equivalent to calling getSelectedIndices().contains(index)." > 2. reimplement TableView.TableViewSelectionModel.isSelected(int) method to return true when at least one cell in *any* column is selected on the given row (was: *all* columns) > 3. modified TreeTableRow.updateSelection() to use the right isSelected() method > 4. updated tests for Tree/TableView > > NOTE: proposed change alters semantics of isSelected(int) method (in the right direction, in my opinion). This pull request has now been integrated. Changeset: 7cb8d679 Author: Andy Goryachev Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7cb8d679dc2aa96b7c9a2bd60983ab74aa275967 Stats: 325 lines in 8 files changed: 285 ins; 9 del; 31 mod 8235491: Tree/TableView: implementation of isSelected(int) violates contract Reviewed-by: aghaisas, fastegal, kcr ------------- PR: https://git.openjdk.org/jfx/pull/839 From nlisker at openjdk.org Tue Aug 23 15:36:35 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 15:36:35 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/880/files - new: https://git.openjdk.org/jfx/pull/880/files/6e9eda88..e9df3a27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=02-03 Stats: 20 lines in 1 file changed: 0 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/880.diff Fetch: git fetch https://git.openjdk.org/jfx pull/880/head:pull/880 PR: https://git.openjdk.org/jfx/pull/880 From nlisker at openjdk.org Tue Aug 23 15:41:29 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 15:41:29 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:36:35 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments When looking at `Service` I noticed that in `Worker` the property docs are on the `get` methods instead of on the `property` methods: https://openjfx.io/javadoc/18/javafx.graphics/javafx/concurrent/Worker.html#getState() This causes `Service` to inherit these as well. Docs should only appear on the property (except in special circumstances), but I didn't want to touch all of this here. Should I create a new issue for this or is it not worth it? ------------- PR: https://git.openjdk.org/jfx/pull/880 From angorya at openjdk.org Tue Aug 23 15:42:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 15:42:41 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v7] In-Reply-To: References: Message-ID: > The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. > > Changes: > - modified TreeTableRow.updateSelection() Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8292353: spelling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/875/files - new: https://git.openjdk.org/jfx/pull/875/files/3ced43d0..d785e3d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/875.diff Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875 PR: https://git.openjdk.org/jfx/pull/875 From kcr at openjdk.org Tue Aug 23 16:02:39 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 16:02:39 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:36:35 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments > When looking at `Service` I noticed that in `Worker` the property docs are on the `get` methods instead of on the `property` methods ... > > This causes `Service` to inherit these as well. Docs should only appear on the property (except in special circumstances), but I didn't want to touch all of this here. Should I create a new issue for this or is it not worth it? I recommend to file a new issue. We can target it for JavaFX 20. ------------- PR: https://git.openjdk.org/jfx/pull/880 From angorya at openjdk.org Tue Aug 23 16:06:22 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 16:06:22 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v8] In-Reply-To: References: Message-ID: > The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled. > > Changes: > - modified TreeTableRow.updateSelection() Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge remote-tracking branch 'origin/master' into 8292353.visuals - 8292353: spelling - 8292353: typo - 8292353: typo - 8292353: whitespace - 8292353: added tests - Merge remote-tracking branch 'origin/master' into 8292353.visuals - 8292353: review comments - Merge remote-tracking branch 'origin/master' into 8292353.visuals - 8292353: update selection ------------- Changes: https://git.openjdk.org/jfx/pull/875/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=07 Stats: 373 lines in 2 files changed: 369 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/875.diff Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875 PR: https://git.openjdk.org/jfx/pull/875 From nlisker at openjdk.org Tue Aug 23 16:34:59 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 16:34:59 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v5] In-Reply-To: References: Message-ID: <0hq2pncOOJVmJchJxM9atoDAQ-_oxvVk5X38nm_Q8gg=.cf60b7e0-b2a5-41b8-bc58-ede5bdd1ec49@github.com> > Fixes the mistakes in the JBS ticket and some additional minor corrections. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/880/files - new: https://git.openjdk.org/jfx/pull/880/files/e9df3a27..c537fa93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=880&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/880.diff Fetch: git fetch https://git.openjdk.org/jfx pull/880/head:pull/880 PR: https://git.openjdk.org/jfx/pull/880 From kcr at openjdk.org Tue Aug 23 16:35:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 16:35:00 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v4] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:36:35 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Looks good with one optional suggestion. modules/javafx.controls/src/main/java/javafx/scene/control/TextFormatter.java line 50: > 48: * setting a value will result in an {@code IllegalStateException} and the value is always {@code null}. > 49: *

> 50: * Since {@code Formatter} contains a value which represents the state of the {@code TextInputControl} to which it is One more thing I noticed: "contains a value which" could be changed to "contains a value that" ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/880 From kcr at openjdk.org Tue Aug 23 16:59:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 16:59:26 GMT Subject: [jfx19] RFR: 8286678: Fix mistakes in FX API docs [v5] In-Reply-To: <0hq2pncOOJVmJchJxM9atoDAQ-_oxvVk5X38nm_Q8gg=.cf60b7e0-b2a5-41b8-bc58-ede5bdd1ec49@github.com> References: <0hq2pncOOJVmJchJxM9atoDAQ-_oxvVk5X38nm_Q8gg=.cf60b7e0-b2a5-41b8-bc58-ede5bdd1ec49@github.com> Message-ID: On Tue, 23 Aug 2022 16:34:59 GMT, Nir Lisker wrote: >> Fixes the mistakes in the JBS ticket and some additional minor corrections. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/880 From nlisker at openjdk.org Tue Aug 23 17:03:05 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 17:03:05 GMT Subject: [jfx19] Integrated: 8286678: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 23:52:48 GMT, Nir Lisker wrote: > Fixes the mistakes in the JBS ticket and some additional minor corrections. This pull request has now been integrated. Changeset: 8b967765 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/8b96776510908c14a860680ad99404c339faa48f Stats: 49 lines in 7 files changed: 1 ins; 3 del; 45 mod 8286678: Fix mistakes in FX API docs Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/880 From kcr at openjdk.org Tue Aug 23 17:44:15 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 17:44:15 GMT Subject: [jfx11u] RFR: 8286774: Replace openjdk.java.net with openjdk.org Message-ID: The patch from `jfx17u` applied partially cleanly, but I had to skip several files that don't exist in `jfx11u`, and there were a few trivial merge conflicts. Additionally, the following two files had to be fixed up manually: doc-files/release-notes-11.0.1.md doc-files/release-notes-11.0.2.md ------------- Commit messages: - 8286774: Replace openjdk.java.net with openjdk.org Changes: https://git.openjdk.org/jfx11u/pull/110/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286774 Stats: 130 lines in 12 files changed: 0 ins; 0 del; 130 mod Patch: https://git.openjdk.org/jfx11u/pull/110.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/110/head:pull/110 PR: https://git.openjdk.org/jfx11u/pull/110 From kcr at openjdk.org Tue Aug 23 17:44:15 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 17:44:15 GMT Subject: [jfx11u] RFR: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:36:24 GMT, Kevin Rushforth wrote: > The patch from `jfx17u` applied partially cleanly, but I had to skip several files that don't exist in `jfx11u`, and there were a few trivial merge conflicts. Additionally, the following two files had to be fixed up manually: > > > doc-files/release-notes-11.0.1.md > doc-files/release-notes-11.0.2.md Reviewer: @arapte ------------- PR: https://git.openjdk.org/jfx11u/pull/110 From kcr at openjdk.org Tue Aug 23 17:46:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 17:46:11 GMT Subject: [jfx11u] RFR: 8288450: Update attribution in gstreamer.md file Message-ID: Clean backport. ------------- Commit messages: - 8288450: Update attribution in gstreamer.md file Changes: https://git.openjdk.org/jfx11u/pull/111/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288450 Stats: 6943 lines in 3 files changed: 293 ins; 6648 del; 2 mod Patch: https://git.openjdk.org/jfx11u/pull/111.diff Fetch: git fetch https://git.openjdk.org/jfx11u pull/111/head:pull/111 PR: https://git.openjdk.org/jfx11u/pull/111 From kcr at openjdk.org Tue Aug 23 18:10:42 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 18:10:42 GMT Subject: [jfx11u] Integrated: 8288450: Update attribution in gstreamer.md file In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:37:08 GMT, Kevin Rushforth wrote: > Clean backport. This pull request has now been integrated. Changeset: 53d18fc5 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx11u/commit/53d18fc535d4426ec604c0e0d1b5138b5f36dde5 Stats: 6943 lines in 3 files changed: 293 ins; 6648 del; 2 mod 8288450: Update attribution in gstreamer.md file 8288449: Update attribution in glib.md file Backport-of: 54e689ce639ee182113dab610d9ed82890493898 ------------- PR: https://git.openjdk.org/jfx11u/pull/111 From kcr at openjdk.org Tue Aug 23 18:14:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 18:14:33 GMT Subject: RFR: Merge jfx19 Message-ID: Merge `jfx19` branch into `master`. ------------- Commit messages: - Merge jfx19 - 8286678: Fix mistakes in FX API docs - 8291906: Bindings.createXxxBinding inherit incorrect method docs The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/882/files Stats: 91 lines in 8 files changed: 43 ins; 3 del; 45 mod Patch: https://git.openjdk.org/jfx/pull/882.diff Fetch: git fetch https://git.openjdk.org/jfx pull/882/head:pull/882 PR: https://git.openjdk.org/jfx/pull/882 From kcr at openjdk.org Tue Aug 23 18:24:16 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 18:24:16 GMT Subject: RFR: Merge jfx19 [v2] In-Reply-To: References: Message-ID: > Merge `jfx19` branch into `master`. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge jfx19 - 8235491: Tree/TableView: implementation of isSelected(int) violates contract Reviewed-by: aghaisas, fastegal, kcr - 8292391: Add support for optional signing of native libraries Reviewed-by: arapte - 8087557: [Win] [Accessibility, Dialogs] Alert Dialog content is not fully read by Screen Reader Reviewed-by: kcr, aghaisas - 8291625: DialogPane without header nor headerText nor graphic node adds padding to the left of the content pane Reviewed-by: aghaisas - 8089009: TableView with CONSTRAINED_RESIZE_POLICY incorrectly displays a horizontal scroll bar. Reviewed-by: kcr, angorya, aghaisas - 8271395: Crash during printing when disposing textures Reviewed-by: kcr, prr - 8292549: GitHub actions: intermittent build failure on macOS while downloading ant Reviewed-by: angorya, arapte - 8290473: update Eclipse .classpath in apps, buildSrc Reviewed-by: nlisker - 8181084: JavaFX show big icons in system menu on macOS with Retina display Reviewed-by: jpereda, kcr - ... and 21 more: https://git.openjdk.org/jfx/compare/8b967765...e30d0839 ------------- Changes: https://git.openjdk.org/jfx/pull/882/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=882&range=01 Stats: 456922 lines in 7443 files changed: 303275 ins; 110427 del; 43220 mod Patch: https://git.openjdk.org/jfx/pull/882.diff Fetch: git fetch https://git.openjdk.org/jfx pull/882/head:pull/882 PR: https://git.openjdk.org/jfx/pull/882 From kcr at openjdk.org Tue Aug 23 18:24:18 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 18:24:18 GMT Subject: Integrated: Merge jfx19 In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 18:07:57 GMT, Kevin Rushforth wrote: > Merge `jfx19` branch into `master`. This pull request has now been integrated. Changeset: 6d6726c3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/6d6726c3d69379559c4d66681726adc4e794899c Stats: 91 lines in 8 files changed: 43 ins; 3 del; 45 mod Merge ------------- PR: https://git.openjdk.org/jfx/pull/882 From angorya at openjdk.org Tue Aug 23 18:45:04 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 18:45:04 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) Message-ID: This change affects eclipse projects only - all eclipse projects are configured to use JUnit5. ------------- Commit messages: - 8292678 junit5 in all eclipse projects Changes: https://git.openjdk.org/jfx/pull/883/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=883&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292678 Stats: 21 lines in 9 files changed: 0 ins; 15 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/883.diff Fetch: git fetch https://git.openjdk.org/jfx pull/883/head:pull/883 PR: https://git.openjdk.org/jfx/pull/883 From angorya at openjdk.org Tue Aug 23 18:45:04 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 18:45:04 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: References: Message-ID: <0bS_7-qr6olbdbQZf6rXgP8jwxVYkWboZGX-WpX1FIo=.b86ee597-0fb0-4f4e-9ded-9d1b02d460a8@github.com> On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are configured to use JUnit5. @kleopatra or @nlisker - please review if you can. thanks! ------------- PR: https://git.openjdk.org/jfx/pull/883 From angorya at openjdk.org Tue Aug 23 18:49:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 18:49:39 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> Message-ID: <7yHT6HXISNj1YgFmGW0H0x4CsZtMfYhCrLpuYxgOTtk=.b62edc84-a44c-4114-b2f8-8d11f32f8a97@github.com> On Mon, 15 Aug 2022 15:37:15 GMT, Jeanette Winzenburg wrote: >>> A quick PoC is in [my fork off Andy's PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) >> >> @kleopatra : >> Thank you so much for your effort to research the alternatives. >> >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. The others, which only add listeners and children nodes, can remain unchanged. > >> >> @kleopatra : Thank you so much for your effort to research the alternatives. >> > > thinking about alternatives is our job, isn't it :) > >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. > > There might be such code, but I doubt that there is anything (at least nothing validly installed) in our skins. Haven't looked into the install children that are defined in the control itself (like f.i. editors in the combo/spinner et al). > >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. > > As long as custom classes play by the rules (aka: don't violate the spec) we'll have a hard time imposing code changes onto custom classes. Or if we do, we might see us in the middle of many pointed fingers. Like (from [kinds of compatibilty](https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility)) > >> While an end-user may not care why a program does not work with a newer version of a library, what contracts are being followed or broken should determine which party has the onus for fixing the problem I'd like to move forward with this PR. Despite many insightful suggestions from @kleopatra , I don't think there is a way around this problem except to create a new method. Thank you. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Tue Aug 23 18:52:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 18:52:42 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Tue, 23 Aug 2022 08:09:10 GMT, danielpeintner wrote: >> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8292353: typo >> - 8292353: typo > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 56: > >> 54: /** >> 55: * Tests for: >> 56: * - cell seleciton logic JDK-8292353. > > Nit: seleciton -> selection fixed, thanks! ------------- PR: https://git.openjdk.org/jfx/pull/875 From nlisker at openjdk.org Tue Aug 23 19:49:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 19:49:36 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 15:10:50 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed method > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1VS.hlsl line 32: > >> 30: //float2 transformTexture(float2 t) { return t; } >> 31: >> 32: VsOutput main(VsInput vsInput) { > > The input struct name was earlier passed from build.gradle, https://github.com/openjdk/jfx/blob/08ec9c8781a57b49a13a2b7febbe33172ebc1a5a/build.gradle#L2344 > > This change needs to be reflected in build.gradle. so, > either > 1. Remove `"/DVertexType=ObjVertex",` in build.gradle > OR > 2. Change `"/DVertexType=ObjVertex",` in build.gradle to `"/DVertexType=VsInput",` and revert the type function parameter here. > > I would recommend option 2, as it would remind us to use this approach in future if we needed multiple types of vs input structs. But I leave it to you. What do you mean by "revert the type function parameter here"? Doesn't the type parameter match after a change to the gradle file? ------------- PR: https://git.openjdk.org/jfx/pull/789 From angorya at openjdk.org Tue Aug 23 20:01:23 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 20:01:23 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Tue, 23 Aug 2022 10:39:24 GMT, Jeanette Winzenburg wrote: >> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8292353: typo >> - 8292353: typo > > Fix looks good (left a minor inline comment which you might follow or not :) > > The tests, though, ... need some love: > > As a general rule, it's preferred to assert a single state per test method instead of changing the state repeatedly inside the same method. We can see that something is wrong when having code comments like: > > line 240: assertFalse(row.isSelected()); // JDK-8292353 failure > > line 249: assertFalse(row.isSelected()); // JDK-8292353 failure > > running the test before the fix and the second failure is never reached. We _want_ to see the failures, all of them :) > > Write a test as near to the cause as possible: here the cause is an incorrect selection state of the TreeTableRow under certain conditions. That's unrelated to any user interaction, so a setup faking such an interaction is a detour which might (or not) bring in their own trouble (aside: I do see the css parser warnings when running TreeAndTableViewTest inside Eclipse - that is [JDK-8291853](https://bugs.openjdk.org/browse/JDK-8291853) which we don't yet understand, except that something fishy might be going on ;) Best to use the most simple setup to test that exact state, here that would be an isolated Tree/TableRow thats configured with a Tree/TableView at some index and setup the view's selection state as needed, for examples see TreeTableRowTest or something like the following > > @Test > public void testRowSelectionStateOnCellSelectionEnabledMultiple() { > // configure view > addColumns(); > tree.getSelectionModel().setCellSelectionEnabled(true); > tree.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // configure tableRow > int selected = 1; > cell.updateTreeTableView(tree); > cell.updateIndex(selected); > > // select all columns if possible > tree.getSelectionModel().select(selected, null); > assertEquals("sanity: all columns selected", tree.getColumns().size(), > tree.getSelectionModel().getSelectedCells().size()); > assertFalse("row must not be selected in cell selection mode", cell.isSelected()); > } > > and one for the second failure before the fix plus (for coverage) the other combinations of cell selection enablement/selection mode :) These should reside in TreeTableRowTest, IMO, to be "near" the other row state tests. > > For coverage, we should also have the corresponding tests for TableRow (also isolated, not wrapped into faked user interaction). They should reside in TableRowTest. Which we don't have yet, time to add it :) > > My suggestions: > > - convert the monolithic test methods into separate tests, each without changing the state you want to test > - configure and test the selection state of an isolated row (without faking user interaction, similar to the example above) > - for TreeTableRow, add the tests to TreeTableRowTest > - for TableRow, add TableRowTest and add analogue methods as those you added for TreeTableRow > - remove TreeAndTableViewTest Dear @kleopatra : thank you for insightful comments and suggestions! I do agree that, in general, it might be beneficial to have one test case per condition or failure, but it should not be a requirement. I believe it is perfectly fine to have a test that executes a complex scenario. In this particular case, the failure is known, it is described in JDK-8292353, and the fact that there are multiple places where test fails (before the fix) is not important. What is important is that the failing paths are exercised and pass as a result of the fix. I do disagree with the requirement to write a highly artificial tests like testRowSelectionStateOnCellSelectionEnabledMultiple() because it makes too many assumptions on the internal structure of the code being tested. I would rather have a test that simulates as much as possible the actual user interaction. I am not saying we have to forbid simple tests, but rather we need both. After all, we have all these tests and yet plenty of bugs avoided detection for years. It took me 10 minutes to write and test a simple example and identify a number of issues (though many of them already in JBS) with Tree/TableView. I'd say let's allow some diversity in our testing approaches. Unless there is a *very* good reason to refactor, I'd rather leave TreeAndTableViewTest as is and not touch other files, as they are too big and I don't want to replicate code. What do you think? ------------- PR: https://git.openjdk.org/jfx/pull/875 From angorya at openjdk.org Tue Aug 23 20:12:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 20:12:32 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v4] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: added tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/5f37fe6d..bf8a0b37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=02-03 Stats: 236 lines in 1 file changed: 236 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Tue Aug 23 20:20:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 23 Aug 2022 20:20:11 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v5] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: added tests - 8187145: clear selected tree table row when setting null selection model - 8187145: clear selection when setting selection model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: whitespace - 8187145: clear focus - 8187145: tree table view - 8187145: fall through - ... and 1 more: https://git.openjdk.org/jfx/compare/7cb8d679...fed5dfdb ------------- Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=04 Stats: 432 lines in 13 files changed: 335 ins; 11 del; 86 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From nlisker at openjdk.org Tue Aug 23 21:01:47 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 21:01:47 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v6] In-Reply-To: References: Message-ID: > Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. > > Since there are many small changes, I'm giving a full list here: > > **Java** > > * `NGShape3D.java` > * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. > * Normalized the direction here instead of in the native code. > * Ambient light is now only set when it exists (and is not black). > * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). > * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. > > **Native C++** > > * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). > * `D3DLight` > * Commented out unused methods. Were they supposed to be used at some point? > * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. > * `D3DPhongShader.h` > * Renamed some of the register constants for more clarity. > * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. > * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. > * `D3DMeshView.cc` > * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. > * Removed the direction normalization as stated in the change for `NGShape3D.java`. > * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. > > **Native shaders** > * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). > * Commented out many unused functions. I don't know what they are for, so I didn't remove them. > * `vsConstants` > * Removed the light color from here since it's unused, only the position is. > * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. > * `vs2ps` > * Removed the ambient color interpolation, which frees a register (no change in performance). > * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). > * `Mtl1PS` and `psMath` > * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. > * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. > > No changes in performance were measured and the behavior stayed the same. Nir Lisker 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: - Addressed review comments - undo debugging - Merge remote-tracking branch 'origin/master' into 8217853_Cleanup_in_the_D3D_native_pipeline - debugging - Address review comments and fix attempt for attenuation - Renamed method - Missed review comment - Addressed review comments - Remove unused comments, clean constructor - Initial commit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/789/files - new: https://git.openjdk.org/jfx/pull/789/files/689497a0..72305b30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=04-05 Stats: 529110 lines in 8139 files changed: 340356 ins; 120729 del; 68025 mod Patch: https://git.openjdk.org/jfx/pull/789.diff Fetch: git fetch https://git.openjdk.org/jfx pull/789/head:pull/789 PR: https://git.openjdk.org/jfx/pull/789 From nlisker at openjdk.org Tue Aug 23 21:06:43 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 23 Aug 2022 21:06:43 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 17:38:06 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed method > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vs2ps.h line 26: > >> 24: */ >> 25: >> 26: struct PsInput { > > The `struct VsOutput` is the actual input to pixel shader. Naming this struct as `PsInput` may not be correct. > I would recommend to have only one struct that is `PsInput` and move member variable texD of `VsOutput` to `PsInput`. > In vertex and pixel shaders, use correct names for the variables of `PsInput`. > In vertex shader, the variable would be names as output, and in pixel shader as input. > For example: https://github.com/caioteixeira/GameEngines/blob/master/lab5/Assets/Shaders/Phong.hlsl I opted to alias the names and use `VsOutput` in the vertex shader and `PsInput` in the pixel shader. See if that works for you. ------------- PR: https://git.openjdk.org/jfx/pull/789 From arapte at openjdk.org Tue Aug 23 23:18:36 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 23 Aug 2022 23:18:36 GMT Subject: [jfx11u] RFR: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: <_g-JqBAyHx6y6YFA8STMf-JjsO-El0pS-FbOTGL-1ag=.c7fdf9ef-f4bc-4eb5-b299-0a498d6fdd7d@github.com> On Tue, 23 Aug 2022 17:36:24 GMT, Kevin Rushforth wrote: > The patch from `jfx17u` applied partially cleanly, but I had to skip several files that don't exist in `jfx11u`, and there were a few trivial merge conflicts. Additionally, the following two files had to be fixed up manually: > > > doc-files/release-notes-11.0.1.md > doc-files/release-notes-11.0.2.md Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx11u/pull/110 From kcr at openjdk.org Tue Aug 23 23:40:30 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 23 Aug 2022 23:40:30 GMT Subject: [jfx11u] Integrated: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 17:36:24 GMT, Kevin Rushforth wrote: > The patch from `jfx17u` applied partially cleanly, but I had to skip several files that don't exist in `jfx11u`, and there were a few trivial merge conflicts. Additionally, the following two files had to be fixed up manually: > > > doc-files/release-notes-11.0.1.md > doc-files/release-notes-11.0.2.md This pull request has now been integrated. Changeset: c7fe7896 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx11u/commit/c7fe78965e5cc85bb5961a80086d699f9e493373 Stats: 130 lines in 12 files changed: 0 ins; 0 del; 130 mod 8286774: Replace openjdk.java.net with openjdk.org Reviewed-by: arapte Backport-of: c75928654581920867b5d6c655fb7917d43d1093 ------------- PR: https://git.openjdk.org/jfx11u/pull/110 From nlisker at openjdk.org Wed Aug 24 01:41:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 24 Aug 2022 01:41:24 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are configured to use JUnit5. I don't see why the base project needs a `.classpath` file at all considering that it doesn't contain sources. ------------- PR: https://git.openjdk.org/jfx/pull/883 From andrea.vacondio at gmail.com Wed Aug 24 08:52:07 2022 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Wed, 24 Aug 2022 10:52:07 +0200 Subject: Drag and drop of Outlook attachments In-Reply-To: References: Message-ID: Hi, thanks for pointing me there but it doesn't seem to work for me. I want to drop attachments from Outlook into my application. I tried to stream all the DataFormats returned by getContentTypes() and used them to get content either from e.getDragboard() and Clipboard.getSystemClipboard() and I couldn't find anything useful. This is quite a pain for me because I have users still using the 10 years old Swing version of my application writing to me "hey, I upgraded and I can't drag and drop Outlook attachments anymore". Does anyone have an idea of how to do it or if it's even possible in JavaFX? Il giorno ven 29 lug 2022 alle ore 14:27 Dean Wookey ha scritto: > Hi Andrea, > > You can have a look at this post to see if it helps you. > > https://stackoverflow.com/a/73166666/4489577 > > Dean > > On Tue, Jul 12, 2022 at 10:59 AM Andrea Vacondio < > andrea.vacondio at gmail.com> wrote: > >> Hello, >> can anyone point me or tell me the current support regarding JavaFX drag >> and drop of Outlook attachments? This is the only bug report I found >> https://bugs.openjdk.org/browse/JDK-8133342 >> Also, is there a searchable version of the mailing list? https:// >> mail.openjdk.org/pipermail/open >> Thanks >> Andrea >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Wed Aug 24 09:54:39 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 24 Aug 2022 09:54:39 GMT Subject: RFR: 8289542: Update JPEG Image Decoding Software to 9e In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 12:02:04 GMT, Ambarish Rapte wrote: > Update libjpeg to current version release [9e](http://www.ijg.org/) of 16-Jan-2022 > > reference: https://jpegclub.org/reference/reference-sources/ > > Verified all test run on Windows and MacOS Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/874 From arapte at openjdk.org Wed Aug 24 13:59:21 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 24 Aug 2022 13:59:21 GMT Subject: RFR: 8284281: [Accessibility] [Win] [Narrator] Exceptions with TextArea & TextField when deleted last char Message-ID: <7jSOau5jDM5j91e0QcgsnJ9-AqZA31H_5x2Izz99jSU=.40fe4b40-a586-4bd3-9ee5-911a776271ab@github.com> Issue: When Narrator is running, 1. Deleting last character from `TextField` throws `IllegalArgumentException`, and 2. Deleting last character from `TextArea` throws `NPE`. Fix: When character is deleted, we receive an offset larger by one than the current text length. This scenario needs to be handled correctly. The change in `Text.java` fixes the NPE with TextArea, and, The change in `WinTextRangeProvider.java` fixes the IllegalArgumentException with TextField. To observe the issue. 1. Run any program with TextField and/or TextArea 3. Launch Windows Narrator 4. Delete the last character from TextField / TextArea 5. Observe the related Exception ------------- Commit messages: - TextField and TextArea last char del fix for a11y Changes: https://git.openjdk.org/jfx/pull/884/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284281 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/884.diff Fetch: git fetch https://git.openjdk.org/jfx pull/884/head:pull/884 PR: https://git.openjdk.org/jfx/pull/884 From kcr at openjdk.org Wed Aug 24 14:28:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 24 Aug 2022 14:28:01 GMT Subject: RFR: 8284281: [Accessibility] [Win] [Narrator] Exceptions with TextArea & TextField when deleted last char In-Reply-To: <7jSOau5jDM5j91e0QcgsnJ9-AqZA31H_5x2Izz99jSU=.40fe4b40-a586-4bd3-9ee5-911a776271ab@github.com> References: <7jSOau5jDM5j91e0QcgsnJ9-AqZA31H_5x2Izz99jSU=.40fe4b40-a586-4bd3-9ee5-911a776271ab@github.com> Message-ID: On Wed, 24 Aug 2022 13:50:32 GMT, Ambarish Rapte wrote: > Issue: > When Narrator is running, > 1. Deleting last character from `TextField` throws `IllegalArgumentException`, and > 2. Deleting last character from `TextArea` throws `NPE`. > > Fix: > When character is deleted, we receive an offset larger by one than the current text length. This scenario needs to be handled correctly. > The change in `Text.java` fixes the NPE with TextArea, and, > The change in `WinTextRangeProvider.java` fixes the IllegalArgumentException with TextField. > > To observe the issue. > 1. Run any program with TextField and/or TextArea > 3. Launch Windows Narrator > 4. Delete the last character from TextField / TextArea > 5. Observe the related Exception I'll test this before finishing my review. I left 2 question inline. I'll review this, but it would be helpful for someone else to as well. Maybe @aghaisas can also review? modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1990: > 1988: int offset = (Integer)parameters[0]; > 1989: TextLine[] lines = getTextLayout().getLines(); > 1990: if (offset > getTextInternal().length()) return lines.length; A couple questions: 1. This will return an offset that represents the position just past the end of the list of lines. I presume this is OK? 2. The `LINE_START` and `LINE_END` cases also can return null. Should a similar fix be applied for those cases? ------------- PR: https://git.openjdk.org/jfx/pull/884 From fastegal at openjdk.org Wed Aug 24 14:54:35 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 24 Aug 2022 14:54:35 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Tue, 23 Aug 2022 19:58:24 GMT, Andy Goryachev wrote: > > I do agree that, in general, it might be beneficial to have one test case per condition or failure, but it should not be a requirement. well, this project follows (should, at least, there are legacy areas ;) established best practices for unit testing. If you want that changed, the best place to discuss such a change in strategy is the mailinglist. > I believe it is perfectly fine to have a test that executes a complex scenario. we certainly can have tests for complex scenarios - but only if testing such a complex scenario. That's not the case here. > > I do disagree with the requirement to write a highly artificial tests like testRowSelectionStateOnCellSelectionEnabledMultiple() because it makes too many assumptions on the internal structure of the code being tested. with all due respect: that sentence is completely wrong. - there is nothing artificial to test a class in the most minimal context possible, in fact that's the whole point of unit testing - the amount of assumptions on internal structure is zero, they use public api to follow the three A (Arrange: create the cell, configure it at a fixed location inside a virtualized control) A (Act: change the selection of the control) A (Assert: verify the cell has updated its own state accordingly) > After all, we have all these tests and yet plenty of bugs avoided detection for years. that's mostly because the coverage is .. suboptimal ;) As this issue demonstrates: there are no simple tests to guarantee a treeTableRow updates itself reliably. > I would rather have a test that simulates as much as possible the actual user interaction. grabbing a tableRow from a temporary scenegraph (note: its scene is null once you get it), adding its tableCells to a different scenegraph (note: after mouseFirer constructor tableCell.getParent() != tableRow) and fire a mouseEvent onto that isolated tableCell is _near .. actual user interaction_? That's not case ;) > Unless there is a very good reason The very good reason is that your test setup is suboptimal (apart from changing the recommended Attach-Act-Assert into Attach-Act-Assert-ActAgain-AssertAgain-... ) for the issue here ;) We have a very clear functional path to test: a fully configured TableRow must sync its own selection state to the TableView's selection state at the location of the row. So all we need is a TableView (with columns, as we want cell selection) and a TableRow configured to represent a location in that TableView. Changing table's selection at the location of the row must change (or not, depending on selection context) the selection state of the row. The most simple means to change table's selection is programatically using public api on the table's selectionModel with a direct mapping of selectionModel.select -> tableRow.updateSelection With yours: stageloaderA -> createAndConfigure tableRows/Cells -> tableRow = lookup row at index -> stageloaderA.dispose // at this point we are already far from any"real" context - no user interaction possible tableCell = lookup column for tableColumn // nevertheless with rather normal micro-cosmos: assertEquals(tableCell.getParent(), tableCell.getTableRow()); mouseFirer -> stageLoaderB -> insert targetNode into its own root // at this point we have an isolated tableCell in a slightly weird state, now failing the above assert: assertEquals(tableCell.getParent(), tableCell.getTableRow()); // now fire a mouseEvent onto that isolated tableCell // (which nevertheless is fully configured with its tableView and location) mouseFirer.doFirer -> tableCell.behaviour -> __selectionModel.select -> tableRow.updateSelection__ and here at the very end we are again testing the same as in the simple case, after going on a detour which might (or not) have side-effects or bugs of their own. We might go that tour if we are specifically interested in that path, that is when we are really want to test the behaviour (mouse and keyboard input) - and then we must be certain that this very last expectation is fulfilled. > > What do you think? Same as yesterday: - missing direct tests - unrelated, overly complex (and potentially testing the wrong thingy) TreeAndTableViewTest ------------- PR: https://git.openjdk.org/jfx/pull/875 From angorya at openjdk.org Wed Aug 24 14:58:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 24 Aug 2022 14:58:43 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 01:37:49 GMT, Nir Lisker wrote: > I don't see why the base project needs a `.classpath` file at all considering that it doesn't contain sources. 'base' project does contain shims, other sources, generated sources. I think we should keep it. are the other changes ok? ------------- PR: https://git.openjdk.org/jfx/pull/883 From angorya at openjdk.org Wed Aug 24 15:08:44 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 24 Aug 2022 15:08:44 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: <9eDhEXaQBQsplHMrHBqzBhDbMSg743F376lJOTELDcQ=.a86d862f-646d-4a5b-8be2-db4f1d6ca032@github.com> References: <9eDhEXaQBQsplHMrHBqzBhDbMSg743F376lJOTELDcQ=.a86d862f-646d-4a5b-8be2-db4f1d6ca032@github.com> Message-ID: <-fIA_jJVlTmuY9DrfiLKpHUeckErupOIiIipcS8Xt_c=.d295667a-20d7-4465-99b0-9df32c226a64@github.com> On Wed, 24 Aug 2022 14:59:57 GMT, Nir Lisker wrote: > the root one, called "jfx" or "rt". I don't know, the file was created in 2013 by a certain Kevin Rushforth for RT-30490. Who am I to criticize the wisdom of the elders? Besides, this question is beyond the scope of this PR. ------------- PR: https://git.openjdk.org/jfx/pull/883 From nlisker at openjdk.org Wed Aug 24 15:03:40 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 24 Aug 2022 15:03:40 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: References: Message-ID: <9eDhEXaQBQsplHMrHBqzBhDbMSg743F376lJOTELDcQ=.a86d862f-646d-4a5b-8be2-db4f1d6ca032@github.com> On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are configured to use JUnit5. Not the `base` module, the root one, called "jfx" or "rt". ------------- PR: https://git.openjdk.org/jfx/pull/883 From kcr at openjdk.org Wed Aug 24 15:19:44 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 24 Aug 2022 15:19:44 GMT Subject: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse) In-Reply-To: <-fIA_jJVlTmuY9DrfiLKpHUeckErupOIiIipcS8Xt_c=.d295667a-20d7-4465-99b0-9df32c226a64@github.com> References: <9eDhEXaQBQsplHMrHBqzBhDbMSg743F376lJOTELDcQ=.a86d862f-646d-4a5b-8be2-db4f1d6ca032@github.com> <-fIA_jJVlTmuY9DrfiLKpHUeckErupOIiIipcS8Xt_c=.d295667a-20d7-4465-99b0-9df32c226a64@github.com> Message-ID: On Wed, 24 Aug 2022 15:04:58 GMT, Andy Goryachev wrote: > I don't know, the file was created in 2013 by a certain Kevin Rushforth for RT-30490. Who am I to criticize the wisdom of the elders? It was actually added a couple years earlier, by this commit: commit bc3b2da484c5c957f557623261b279b36cc7a40d Author: Steve Northover Date: Wed Nov 30 15:57:21 2011 -0500 Fix .classpath I do agree that removing it would best be done in a follow-up. ------------- PR: https://git.openjdk.org/jfx/pull/883 From angorya at openjdk.org Wed Aug 24 15:23:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 24 Aug 2022 15:23:33 GMT Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode [v6] In-Reply-To: References: <3gyXuv4BWo1ePaM9mu3wgNaVBchfDtYvHTlaSAWc-G8=.004bc156-d3d1-42bd-b62b-072131275919@github.com> Message-ID: On Wed, 24 Aug 2022 14:49:47 GMT, Jeanette Winzenburg wrote: >> Dear @kleopatra : thank you for insightful comments and suggestions! >> >> I do agree that, in general, it might be beneficial to have one test case per condition or failure, but it should not be a requirement. I believe it is perfectly fine to have a test that executes a complex scenario. In this particular case, the failure is known, it is described in JDK-8292353, and the fact that there are multiple places where test fails (before the fix) is not important. What is important is that the failing paths are exercised and pass as a result of the fix. >> >> I do disagree with the requirement to write a highly artificial tests like testRowSelectionStateOnCellSelectionEnabledMultiple() because it makes too many assumptions on the internal structure of the code being tested. I would rather have a test that simulates as much as possible the actual user interaction. I am not saying we have to forbid simple tests, but rather we need both. After all, we have all these tests and yet plenty of bugs avoided detection for years. It took me 10 minutes to write and test a simple example and identify a number of issues (though many of them already in JBS) with Tree/TableView. >> >> I'd say let's allow some diversity in our testing approaches. Unless there is a *very* good reason to refactor, I'd rather leave TreeAndTableViewTest as is and not touch other files, as they are too big and I don't want to replicate code. >> >> What do you think? > >> >> I do agree that, in general, it might be beneficial to have one test case per condition or failure, but it should not be a requirement. > > well, this project follows (should, at least, there are legacy areas ;) established best practices for unit testing. If you want that changed, the best place to discuss such a change in strategy is the mailinglist. > >> I believe it is perfectly fine to have a test that executes a complex scenario. > > we certainly can have tests for complex scenarios - but only if testing such a complex scenario. That's not the case here. > >> >> I do disagree with the requirement to write a highly artificial tests like testRowSelectionStateOnCellSelectionEnabledMultiple() because it makes too many assumptions on the internal structure of the code being tested. > > with all due respect: that sentence is completely wrong. > > - there is nothing artificial to test a class in the most minimal context possible, in fact that's the whole point of unit testing > - the amount of assumptions on internal structure is zero, they use public api to follow the three A (Arrange: create the cell, configure it at a fixed location inside a virtualized control) A (Act: change the selection of the control) A (Assert: verify the cell has updated its own state accordingly) > >> After all, we have all these tests and yet plenty of bugs avoided detection for years. > > that's mostly because the coverage is .. suboptimal ;) As this issue demonstrates: there are no simple tests to guarantee a treeTableRow updates itself reliably. > >> I would rather have a test that simulates as much as possible the actual user interaction. > > grabbing a tableRow from a temporary scenegraph (note: its scene is null once you get it), adding its tableCells to a different scenegraph (note: after mouseFirer constructor tableCell.getParent() != tableRow) and fire a mouseEvent onto that isolated tableCell is _near .. actual user interaction_? That's not case ;) > >> Unless there is a very good reason > > The very good reason is that your test setup is suboptimal (apart from changing the recommended Attach-Act-Assert into Attach-Act-Assert-ActAgain-AssertAgain-... ) for the issue here ;) > > We have a very clear functional path to test: a fully configured TableRow must sync its own selection state to the TableView's selection state at the location of the row. > > So all we need is a TableView (with columns, as we want cell selection) and a TableRow configured to represent a location in that TableView. Changing table's selection at the location of the row must change (or not, depending on selection context) the selection state of the row. The most simple means to change table's selection is programatically using public api on the table's selectionModel with a direct mapping of > > selectionModel.select -> tableRow.updateSelection > > With yours: > > stageloaderA -> createAndConfigure tableRows/Cells > -> tableRow = lookup row at index > -> stageloaderA.dispose > // at this point we are already far from any"real" context - no user interaction possible > tableCell = lookup column for tableColumn > // nevertheless with rather normal micro-cosmos: > assertEquals(tableCell.getParent(), tableCell.getTableRow()); > mouseFirer -> stageLoaderB -> insert targetNode into its own root > // at this point we have an isolated tableCell in a slightly weird state, now failing the above assert: > assertEquals(tableCell.getParent(), tableCell.getTableRow()); > // now fire a mouseEvent onto that isolated tableCell > // (which nevertheless is fully configured with its tableView and location) > mouseFirer.doFirer -> tableCell.behaviour -> > __selectionModel.select -> tableRow.updateSelection__ > > and here at the very end we are again testing the same as in the simple case, after going on a detour which might (or not) have side-effects or bugs of their own. We might go that tour if we are specifically interested in that path, that is when we are really want to test the behaviour (mouse and keyboard input) - and then we must be certain that this very last expectation is fulfilled. > >> >> What do you think? > > Same as yesterday: > > - missing direct tests > - unrelated, overly complex (and potentially testing the wrong thingy) TreeAndTableViewTest Dear @kleopatra : Thank you so much for the wisdom. Let me try to refactor the test cases. A few questions: 1. StageLoader - since it is being disposed of by MouseFirer, would it make sense to explain how to use it properly in its javadoc? Perhaps a StageLoader needs to be created and explicitly disposed of at the beginning and end of each test? 2. I noticed that despite MouseFirer's firing MOUSE_PRESSED followed by MOUSE_RELEASED, the cell's pseudostyles contain "pressed" which seems to be incorrect. Perhaps it is due to multiple stages being created? 3. Why do I need to call VirtualFlowTestUtils.getCell(table, 0) for the cells to be created? Do you know what is missing here? thank you. ------------- PR: https://git.openjdk.org/jfx/pull/875 From fastegal at openjdk.org Wed Aug 24 15:23:45 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 24 Aug 2022 15:23:45 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> Message-ID: <3k3YMS_bjxdIGCyolaV_6uKh5FtlE5m7Ej3Y8w7i5Xg=.76e7a709-8632-40b2-bbb4-77bad8f6d840@github.com> On Mon, 15 Aug 2022 15:37:15 GMT, Jeanette Winzenburg wrote: >>> A quick PoC is in [my fork off Andy's PR](https://github.com/kleopatra/jfx/tree/exp-skin-install-supportsInstall) >> >> @kleopatra : >> Thank you so much for your effort to research the alternatives. >> >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. The others, which only add listeners and children nodes, can remain unchanged. > >> >> @kleopatra : Thank you so much for your effort to research the alternatives. >> > > thinking about alternatives is our job, isn't it :) > >> The main issue that necessitates creation of install() and moving it outside of the skin's constructor is the fact that certain code just cannot be inside of the skin's constructor - because the old skin is still attached. So it must be called after the old skin has been removed in setSkin(). I don't think there is a way around it. > > There might be such code, but I doubt that there is anything (at least nothing validly installed) in our skins. Haven't looked into the install children that are defined in the control itself (like f.i. editors in the combo/spinner et al). > >> >> Those user-defined skins (and the affected core skins) that modify singletons or rely on internals of the superclass - must be refactored. > > As long as custom classes play by the rules (aka: don't violate the spec) we'll have a hard time imposing code changes onto custom classes. Or if we do, we might see us in the middle of many pointed fingers. Like (from [kinds of compatibilty](https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility)) > >> While an end-user may not care why a program does not work with a newer version of a library, what contracts are being followed or broken should determine which party has the onus for fixing the problem > I'd like to move forward with this PR. Despite many insightful suggestions from @kleopatra , I don't think there is a way around this problem except to create a new method. Not at the end of my insight - in particular, since you seem to circle back to your very first assumption, despite out lengthy debate in [JDK-8268877](https://bugs.openjdk.org/browse/JDK-8268877) ;) Fact is that not one of our current skins will have an install different from the empty default implementation. So I agree - there is no reason for any bridging api (as f.i. supportsInstall), and retract that suggestion. But that also means, that there is _no_ problem in our _current_ skin that _requires_ such new api. We identified a single pattern that will, though: given a skin wants to set a default value to a control's property only if that value is __not__ set by the control itself, that is something like if (control.getXX() == null) { control.setXX(myDefault); } then it's not possible to safely install and cleanup that value with the current api. But: turned out that we currently don't have such a case :) We have 1. XX being a singleton event handler: it's a bug of the skin to set the singleton handler, instead it should add a handler 2. for all other XX, the value is set unconditionally, no matter its current value If we want to change 2. to doing so conditionally (only if not set by the control/client code) - which we both consider sane behavior - then we _require_ some new API. ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Wed Aug 24 15:32:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 24 Aug 2022 15:32:40 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: <3k3YMS_bjxdIGCyolaV_6uKh5FtlE5m7Ej3Y8w7i5Xg=.76e7a709-8632-40b2-bbb4-77bad8f6d840@github.com> References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> <3k3YMS_bjxdIGCyolaV_6uKh5FtlE5m7Ej3Y8w7i5Xg=.76e7a709-8632-40b2-bbb4-77bad8f6d840@github.com> Message-ID: On Wed, 24 Aug 2022 15:20:15 GMT, Jeanette Winzenburg wrote: > But: turned out that we currently don't have such a case :) But we do! (I this one of my earlier comments did not got lost by Jira, sorry). In TextInputControlSkin : 334, we have control.setInputMethodRequests(new ExtendedInputMethodRequests() this sets a property with a complex object (not a listener). the constructor cannot distinguish between this property set by the user, or by the still attached skin. So if the user wants to set a custom input method requests it will get overwritten. There is no way around it. ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Wed Aug 24 15:40:49 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 24 Aug 2022 15:40:49 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> <3k3YMS_bjxdIGCyolaV_6uKh5FtlE5m7Ej3Y8w7i5Xg=.76e7a709-8632-40b2-bbb4-77bad8f6d840@github.com> Message-ID: On Wed, 24 Aug 2022 15:29:01 GMT, Andy Goryachev wrote: > the constructor cannot distinguish between this property set by the user true, but currently it doesn't even _try_ to. So IMO that's __not__ a problematic pattern (as already pointed out in our recent debate): the install sets whatever property __unconditionally__ - to safely cleanup behind itself, the old skin will simply check if the current value is the one it installed itself, if not leave it alone (which it currently doesn't but that's a bug that can be solved without new api). ------------- PR: https://git.openjdk.org/jfx/pull/845 From angorya at openjdk.org Wed Aug 24 15:44:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 24 Aug 2022 15:44:45 GMT Subject: RFR: 8290844: Add Skin.install() method [v3] In-Reply-To: References: <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com> <_L51s1s_NuZyXVwXsrxrrkPKdB4i5udViVR_gbUm3NY=.3bf48a82-cc0e-49da-9080-bad47bc61111@github.com> <3WASiHm9C4f-ToTo3WnIPAbcz0YAGXp3XVXju88d8yQ=.b854c9aa-918f-49f8-97b3-b0a2f6f92042@github.com> <3k3YMS_bjxdIGCyolaV_6uKh5FtlE5m7Ej3Y8w7i5Xg=.76e7a709-8632-40b2-bbb4-77bad8f6d840@github.com> Message-ID: On Wed, 24 Aug 2022 15:36:17 GMT, Jeanette Winzenburg wrote: >>> But: turned out that we currently don't have such a case :) >> >> But we do! (I this one of my earlier comments did not got lost by Jira, sorry). >> >> In TextInputControlSkin : 334, we have >> >> control.setInputMethodRequests(new ExtendedInputMethodRequests() >> >> this sets a property with a complex object (not a listener). the constructor cannot distinguish between this property set by the user, or by the still attached skin. So if the user wants to set a custom input method requests it will get overwritten. >> >> There is no way around it. > >> the constructor cannot distinguish between this property set by the user > > true, but currently it doesn't even _try_ to. > > So IMO that's __not__ a problematic pattern (as already pointed out in our recent debate): the install sets whatever property __unconditionally__ - to safely cleanup behind itself, the old skin will simply check if the current value is the one it installed itself, if not leave it alone (which it currently doesn't but that's a bug that can be solved without new api). @kleopatra , this will fail in the case of changing skins - 0. user sets the property (U) 1. skinA() sets the property (A) 2. skinB() sets the property (B) 3. skinA.dispose() does not reset property to U because it's now == B 4. skinB.dispose() fails to set the property to U because it does not know the initial value ------------- PR: https://git.openjdk.org/jfx/pull/845 From fastegal at openjdk.org Wed Aug 24 16:02:43 2022 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 24 Aug 2022 16:02:43 GMT Subject: RFR: 8290844: Add Skin.install() method [v4] In-Reply-To: