From lkostyra at openjdk.org Mon May 1 12:43:59 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 1 May 2023 12:43:59 GMT Subject: RFR: 8307076: gradle test should always run tests In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 13:48:28 GMT, Kevin Rushforth wrote: > "gradle test" won't rerun a test that has already passed. This is surprising behavior, especially for UI toolkit tests where there might be many reasons to want to run the tests again, even if none of that tests "inputs" have changed. This is especially bothersome when debugging an intermittent test failure. Unlike rebuilding the JavaFX runtime or the docs, where there is no need to rerun a task that was successful if none of the inputs to that task have changed, I expect gradle to run my test when I tell it to. > > This PR will make test tasks always run when specified. FYI Gradle 7.6 introduced `--rerun` command which kind of solves that problem. There used to be a `--rerun-tasks` option which invalidates all tasks (including dependencies), but now the process is improved - if you run for example `gradle --info :web:test --rerun` it's going to qualify only the `:web:test` target as out of date, but all dependent tasks will remain up-to-date and will be skipped. I do, however, agree that the behavior introduced by this change might be more intuitive when it comes to running tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1120#issuecomment-1529672716 From lkostyra at openjdk.org Mon May 1 12:44:26 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 1 May 2023 12:44:26 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v6] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 23:35:14 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 46 additional commits since the last revision: > > - Review changes > - Merge branch 'master' into change_scene_fix > - Change call to requestFocus > - Revert "The window could start iconified." > > This reverts commit f92e25cbcc24fd772b9d6bb25a92386ec0561313. > - The window could start iconified. > - Request Focus on setVisible > - fix mistake > - Scene not rendered initially when changing scenes after fix for JDK-8296621 > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 36 more: https://git.openjdk.org/jfx/compare/4733565a...2649d15c I verified the changes, in general the `testSecondSetScene` test is now passing on all platforms. However, on Windows and macOS I observed two tests from controls test suite failing: * MouseEventFirerTest. testAnchorRight[0] * ComboBoxTest. test_rt28245 When I change branches to before all these changes - 48b5fea374 - or even before the most recent master that's merged to these tests - 559ad1139b - these tests pass. Seems like these two failures were introduced by this PR. ------------- PR Review: https://git.openjdk.org/jfx/pull/1110#pullrequestreview-1407560199 From kcr at openjdk.org Mon May 1 13:06:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 13:06:26 GMT Subject: RFR: 8307076: gradle test should always run tests In-Reply-To: <7DDRVR1mHOzBpfhodzNeNunFUzTBicfxSyPjcYIvrBU=.522ddc39-f0df-4d6a-b620-980d81125d67@github.com> References: <7DDRVR1mHOzBpfhodzNeNunFUzTBicfxSyPjcYIvrBU=.522ddc39-f0df-4d6a-b620-980d81125d67@github.com> Message-ID: On Sat, 29 Apr 2023 19:55:40 GMT, Johan Vos wrote: > This is a major enhancement. The non-rerunning tests have been extremely annoying I wanted to do this 10 years ago, but was talked out of it. It recently came up as a source of much wasted time for a developer when tracking down another test bug, so I figured it's past time to reconsider it. > FYI Gradle 7.6 introduced --rerun command which kind of solves that problem For rerunning tests, that's not appreciably better than the currently recommended approach of adding the `cleanTest` target: in both cases you have to remember to do it, and can be surprised if you don't. This RFE has a closed-side part to it, so I'll wait to integrate this PR until the other half is ready (which should be soon). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1120#issuecomment-1529682544 From lkostyra at openjdk.org Mon May 1 15:00:53 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 1 May 2023 15:00:53 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility Message-ID: Verified these changes on all platforms and saw no abnormalities in test execution. This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. ------------- Commit messages: - Use JMemoryBuddy in Web leak tests - Use JMemoryBuddy in tests currently using System.gc() Changes: https://git.openjdk.org/jfx/pull/1121/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296919 Stats: 179 lines in 9 files changed: 24 ins; 118 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From kcr at openjdk.org Mon May 1 15:40:55 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 15:40:55 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility In-Reply-To: References: Message-ID: On Mon, 1 May 2023 14:48:32 GMT, Lukasz Kostyra wrote: > EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. In addition to the manual test, the `javafx.web` module also has an automated [EventListenerLeakTest](https://github.com/openjdk/jfx/blob/fbee1d2201270e7b3beb054ecb9fdf65ae11c43d/modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java) that could benefit from using JMemoryBuddy, but it would not be a trivial change, so it might be better to file a follow-on bug for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1529842965 From angorya at openjdk.org Mon May 1 16:25:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 16:25:52 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility In-Reply-To: References: Message-ID: <_oDXmhiRDCN9xMkwF2CT4EYApkyfN11_DZ4Osw8dAl4=.bff446bd-85d9-4232-bdfb-fcc320f6a56d@github.com> On Mon, 1 May 2023 14:48:32 GMT, Lukasz Kostyra wrote: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. LG, with minor suggestions. What do you think? build.gradle line 3468: > 3466: implementation project(":controls") > 3467: implementation project(":media") > 3468: testImplementation project(":base").sourceSets.test.output does the header year need to be changed? modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 50: > 48: import org.w3c.dom.NodeList; > 49: import static org.junit.Assert.*; > 50: import test.util.memory.JMemoryBuddy; same comment - year in the header? tests/system/src/test/java/test/javafx/embed/swing/SwingNodeDnDMemoryLeakTest.java line 74: > 72: }); > 73: > 74: for (WeakReference ref : weakRefArrSN) { I wonder if we should add a utility method to JMemoryBuddy to operate on an array/collection, so we don't have to repeat this code again and again? tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 82: > 80: SwingUtilities.invokeAndWait(() -> Util.sleep(500)); > 81: > 82: for (WeakReference ref : weakRefArrSN) { same comment as before about a new utility method tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java line 98: > 96: > 97: JMemoryBuddy.assertCollectable(tabWeakRef); > 98: JMemoryBuddy.assertCollectable(textFieldWeakRef); perhaps the utility method operating on an array should accept varargs, like so: `assertCollectable(WeakRef a, WeakRef ... b)` (to differentiate it from a single arg method, and to make sure there are 2+ args) ------------- PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1407777336 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1181683614 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1181683783 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1181685233 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1181686826 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1181687839 From angorya at openjdk.org Mon May 1 16:36:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 16:36:57 GMT Subject: RFR: 8307076: gradle test should always run tests In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 13:48:28 GMT, Kevin Rushforth wrote: > "gradle test" won't rerun a test that has already passed. This is surprising behavior, especially for UI toolkit tests where there might be many reasons to want to run the tests again, even if none of that tests "inputs" have changed. This is especially bothersome when debugging an intermittent test failure. Unlike rebuilding the JavaFX runtime or the docs, where there is no need to rerun a task that was successful if none of the inputs to that task have changed, I expect gradle to run my test when I tell it to. > > This PR will make test tasks always run when specified. build.gradle line 2011: > 2009: // Always run tests > 2010: outputs.upToDateWhen { false } > 2011: Should the 'testing' section of https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX be updated after this PR is integrated? Are there any other wiki pages that might be impacted? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1120#discussion_r1181697798 From angorya at openjdk.org Mon May 1 17:11:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 17:11:28 GMT Subject: RFR: 8306447: Adding an element to a long existing list may cause the first visible element to jump In-Reply-To: References: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> Message-ID: On Sat, 29 Apr 2023 19:49:48 GMT, Johan Vos wrote: > Not sure I understand this scenario The scenario is when ListView has items with variable heights, and scroll bar positioned to somewhere in the middle, adding a new item would unexpectedly scroll the content. It seems to have been fixed by the latest commit. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1099#issuecomment-1529949262 From angorya at openjdk.org Mon May 1 17:11:32 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 17:11:32 GMT Subject: RFR: 8306447: Adding an element to a long existing list may cause the first visible element to jump [v2] In-Reply-To: References: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> Message-ID: On Sat, 29 Apr 2023 20:05:52 GMT, Johan Vos wrote: >> Calculate position of first visible element before propagating changes. >> Make sure to restore the position of said element after the changes are done. >> >> Fix JDK-8306447 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Make sure not to change index and offset when the cell count change. > Use the old cellcount when doing initial calculations, as the estimated > cell size will otherwise be wrong. > > Extend the testcase for this, by adding 9 cells instead of just 1 It looks like there might be another case, but it might be unrelated to the current issue. When clicking on Jump w/VirtualFlow button in the Monkey Tester, the following action is performed: protected void jump() { int sz = control.getItems().size(); int ix = sz / 2; control.getSelectionModel().select(ix); VirtualFlow f = findVirtualFlow(control); f.scrollTo(ix); f.scrollPixels(-1.0); } It is expected that second and any subsequent click on the button should not have an impact, i.e. the scroll position would be the same, but it is not (the view scrolls by 1 pixel on each click). It is a very minor issue though. video: https://user-images.githubusercontent.com/107069028/235493278-dd07b56f-2078-4936-9a95-4c7a412177f1.mp4 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1099#issuecomment-1529955425 From angorya at openjdk.org Mon May 1 17:44:55 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 17:44:55 GMT Subject: RFR: 8306447: Adding an element to a long existing list may cause the first visible element to jump [v2] In-Reply-To: References: <97UrtekvLwi5BBpUCNUZZVFoo3H4oqaPwB8AzpXeZxA=.156a6529-5629-49cb-b95d-959d2a2b512d@github.com> Message-ID: On Sat, 29 Apr 2023 20:05:52 GMT, Johan Vos wrote: >> Calculate position of first visible element before propagating changes. >> Make sure to restore the position of said element after the changes are done. >> >> Fix JDK-8306447 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Make sure not to change index and offset when the cell count change. > Use the old cellcount when doing initial calculations, as the estimated > cell size will otherwise be wrong. > > Extend the testcase for this, by adding 9 cells instead of just 1 LG: fixes the specific issue. ------------- Marked as reviewed by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1099#pullrequestreview-1407872286 From kcr at openjdk.org Mon May 1 18:36:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 18:36:21 GMT Subject: RFR: 8307076: gradle test should always run tests In-Reply-To: References: Message-ID: On Mon, 1 May 2023 16:26:36 GMT, Andy Goryachev wrote: >> "gradle test" won't rerun a test that has already passed. This is surprising behavior, especially for UI toolkit tests where there might be many reasons to want to run the tests again, even if none of that tests "inputs" have changed. This is especially bothersome when debugging an intermittent test failure. Unlike rebuilding the JavaFX runtime or the docs, where there is no need to rerun a task that was successful if none of the inputs to that task have changed, I expect gradle to run my test when I tell it to. >> >> This PR will make test tasks always run when specified. > > build.gradle line 2011: > >> 2009: // Always run tests >> 2010: outputs.upToDateWhen { false } >> 2011: > > Should the 'testing' section of > https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX > > be updated after this PR is integrated? > > Are there any other wiki pages that might be impacted? Updating the testing section is a good idea. Thanks. I'll do that once I integrate. I am not aware of any other page that needs to be updated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1120#discussion_r1181769605 From kcr at openjdk.org Mon May 1 18:36:41 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 18:36:41 GMT Subject: Integrated: 8307076: gradle test should always run tests In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 13:48:28 GMT, Kevin Rushforth wrote: > "gradle test" won't rerun a test that has already passed. This is surprising behavior, especially for UI toolkit tests where there might be many reasons to want to run the tests again, even if none of that tests "inputs" have changed. This is especially bothersome when debugging an intermittent test failure. Unlike rebuilding the JavaFX runtime or the docs, where there is no need to rerun a task that was successful if none of the inputs to that task have changed, I expect gradle to run my test when I tell it to. > > This PR will make test tasks always run when specified. This pull request has now been integrated. Changeset: 97405de1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/97405de1f55ecd26b05cf470e72a2061b579e775 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8307076: gradle test should always run tests Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/1120 From angorya at openjdk.org Mon May 1 19:01:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 19:01:12 GMT Subject: RFR: 8299335: Monkey Tester Application [v16] In-Reply-To: References: Message-ID: <4nwmEvrOhqvrTiP-Y9MmAHMoGkiGRfSZmrkU2Oo8qRA=.0317876e-c09a-4927-a922-b0c5b8c8effa@github.com> On Sat, 29 Apr 2023 14:43:47 GMT, Johan Vos wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > I am not convinced this belongs in the OpenJFX repository. I clearly see the value of tools like this, and I highly encourage developers to use those -- they are fantastic. > However, for OpenJFX, I believe we should focus more on exact tests (which can be unit tests, for example). > For many applications, it can be useful if a user shows a visual artifact and explains that to a developer. But for developers talking about issues with other developers, I believe we should try to stick as much as possible to numbers. We describe the expected behavior and the actual behavior which are both, in the end, represented by numbers. > > I won't oppose this PR, but I am worried that this will not increase the number of regression tests. The regression tests we currently have are incredibly valuable, and they saved us from lots of regression. But I believe we need more regression tests. I think you are right on all points here, @johanvos , and thank you for the feedback! This tool is not a replacement for unit tests or manual tests, but rather to fill a certain gap by providing a relatively quick way for ad hoc testing of component behavior and bug fixes. Ideally, once a bug is found, there should be a SCCE pinpointing the issue. The harsh reality is that we don't live in an ideal world: we don't have unit tests that cover 100% of declared features (er, we don't even have a list of features for each component, so we can't even tell the percentage of coverage). The manual tests are still working off a fixed script. So the consensus in our team seems to be that this is a useful tool to test scenarios covered neither by the unit tests nor by manual tests, with added benefit of adding additional entropy to the process - everyone does things differently, and additional variation might uncover bugs that are specific to certain scenarios. We had some discussion as to where to put this tool, and again the consensus was to put it in openjfx repo (I actually wanted to put it into a separate repo). And again, thank you for the comments! > tests/manual/monkey/README.md line 20: > >> 18: (using absolute path, the script apparently does not understand ~ symbols): >> 19: ``` >> 20: ant -Djavafx.home= > > Try to be consistent when using parameters in code snippets. This line uses `` but on line 31 there is `/PATH` good point, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1097#issuecomment-1530072533 PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1181804282 From angorya at openjdk.org Mon May 1 19:01:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 19:01:14 GMT Subject: RFR: 8299335: Monkey Tester Application In-Reply-To: References: <03m9vwqGR1WBdkdRyXQLGJ7CgQ20SQQ2MGbYnZ7DkGU=.657ab803-fc7a-4956-b125-6aca437393dd@github.com> <8Gk76y8WH0rq0-afRD-1BImnhLM3x6AiUty-aKbfD-g=.8eb6ec9c-8192-4e3f-b374-03e541c631bf@github.com> Message-ID: On Sat, 29 Apr 2023 14:28:49 GMT, Johan Vos wrote: > Unfortunately, that doesn't work for Netbeans. If someone has working config files for Netbeans, I could add them to this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1097#issuecomment-1530073122 From angorya at openjdk.org Mon May 1 19:07:16 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 19:07:16 GMT Subject: RFR: 8299335: Monkey Tester Application [v14] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 20:24:18 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > tests/manual/monkey/README.md line 38: > >> 36: Applications stores the user preferences (window position, currently selected page, etc.) in `~/.MonkeyTester` directory. >> 37: >> 38: To use a different directory, redefine the `user.home` system property, `-Duser.home=`. > > I presume this is mainly so you can run multiple MonkeyTester instances without having them fight over the preferences, right? Maybe add a sentence to that effect? > > Possible future RFE: This might have other implications (e.g., it will change the location of the default WebView user data directory). Do you think it would it be better to have a custom property that, when set, will be used instead of asking users to change `user.home`? This could be done later if you think it's worth doing. good idea! with your permission, I'll change to a different property name in another PR (there is also a rather dubious usage of setId() for the purposes of storing the preferences that I'd like to change). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1181808492 From angorya at openjdk.org Mon May 1 19:16:31 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 19:16:31 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: > Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. > > Feedback and suggestions are always welcome. > > ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1097/files - new: https://git.openjdk.org/jfx/pull/1097/files/1998bdce..e22a6b32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1097&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1097&range=15-16 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1097.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1097/head:pull/1097 PR: https://git.openjdk.org/jfx/pull/1097 From angorya at openjdk.org Mon May 1 19:16:32 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 19:16:32 GMT Subject: RFR: 8299335: Monkey Tester Application [v14] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:04:19 GMT, Andy Goryachev wrote: >> tests/manual/monkey/README.md line 38: >> >>> 36: Applications stores the user preferences (window position, currently selected page, etc.) in `~/.MonkeyTester` directory. >>> 37: >>> 38: To use a different directory, redefine the `user.home` system property, `-Duser.home=`. >> >> I presume this is mainly so you can run multiple MonkeyTester instances without having them fight over the preferences, right? Maybe add a sentence to that effect? >> >> Possible future RFE: This might have other implications (e.g., it will change the location of the default WebView user data directory). Do you think it would it be better to have a custom property that, when set, will be used instead of asking users to change `user.home`? This could be done later if you think it's worth doing. > > good idea! with your permission, I'll change to a different property name in another PR (there is also a rather dubious usage of setId() for the purposes of storing the preferences that I'd like to change). Follow up RFE: [JDK-8307176](https://bugs.openjdk.org/browse/JDK-8307176) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1181813372 From andy.goryachev at oracle.com Mon May 1 19:44:12 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 May 2023 19:44:12 +0000 Subject: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: Nir, would you like to submit a pull request? Thank you -andy From: openjfx-dev on behalf of Nir Lisker Date: Sunday, April 30, 2023 at 10:04 To: openjfx-dev Subject: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars Hi, I took a quick jab at this issue [1]. Using the reproducer in the ticket, launch and resize the stage vertically so that the buttons at the bottom are only partially visible. The current behavior is as follows: When the scrollbar is not needed, toggling to the AS_NEEDED policy reallocates the scrollbar space for the buttons (they move up). When the scrollbar is needed, toggling to the AS_NEEDED policy still reallocates space, and the scrollbar takes away space from the content node. This is wrong. I modified the method 'computeHsbSizeHint' to private double computeHsbSizeHint(ScrollPane sp) { return determineHorizontalSBVisible() ? hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; } Now the policy toggling behavior is correct both when the scrollbar is needed and when it's not - the space is reallocated not at the expense of the content. However, enlarging the stage horizontally while AS_NEEDED is selected does not reallocate the space (you need to toggle the policies). I'm guessing there's a missing call to layoutChildren during this resizing. Does anyone have any input here? Thanks, Nir [1] https://bugs.openjdk.org/browse/JDK-8199934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Mon May 1 20:09:11 2023 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 1 May 2023 23:09:11 +0300 Subject: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: If I knew what the fix was I would have. Right now I'm not sure anymore what the correct behavior should be even. On Mon, May 1, 2023 at 10:44?PM Andy Goryachev wrote: > Nir, would you like to submit a pull request? > > > > Thank you > > -andy > > > > *From: *openjfx-dev on behalf of Nir > Lisker > *Date: *Sunday, April 30, 2023 at 10:04 > *To: *openjfx-dev > *Subject: *JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars > > Hi, > > > > I took a quick jab at this issue [1]. Using the reproducer in the ticket, > launch and resize the stage vertically so that the buttons at the bottom > are only partially visible. > > > > The current behavior is as follows: > > When the scrollbar is not needed, toggling to the AS_NEEDED policy > reallocates the scrollbar space for the buttons (they move up). > > When the scrollbar is needed, toggling to the AS_NEEDED policy still > reallocates space, and the scrollbar takes away space from the content > node. This is wrong. > > > > I modified the method 'computeHsbSizeHint' to > > > > private double computeHsbSizeHint(ScrollPane sp) { > return determineHorizontalSBVisible() ? > hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; > } > > > > Now the policy toggling behavior is correct both when the scrollbar is > needed and when it's not - the space is reallocated not at the expense of > the content. However, enlarging the stage horizontally while AS_NEEDED is > selected does not reallocate the space (you need to toggle the policies). > I'm guessing there's a missing call to layoutChildren during this resizing. > > > > Does anyone have any input here? > > > > Thanks, > > Nir > > > > [1] https://bugs.openjdk.org/browse/JDK-8199934 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon May 1 20:18:38 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 May 2023 20:18:38 +0000 Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: I think your diagnosis is right though: sometimes the layout is not triggered when a property is changed, the recent bug like that is JDK-8307117 TextArea: wrapText property ignored when changing font I wonder if some kind of a generic unit test could be developed to identify such cases. -andy From: Nir Lisker Date: Monday, May 1, 2023 at 13:09 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars If I knew what the fix was I would have. Right now I'm not sure anymore what the correct behavior should be even. On Mon, May 1, 2023 at 10:44?PM Andy Goryachev > wrote: Nir, would you like to submit a pull request? Thank you -andy From: openjfx-dev > on behalf of Nir Lisker > Date: Sunday, April 30, 2023 at 10:04 To: openjfx-dev > Subject: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars Hi, I took a quick jab at this issue [1]. Using the reproducer in the ticket, launch and resize the stage vertically so that the buttons at the bottom are only partially visible. The current behavior is as follows: When the scrollbar is not needed, toggling to the AS_NEEDED policy reallocates the scrollbar space for the buttons (they move up). When the scrollbar is needed, toggling to the AS_NEEDED policy still reallocates space, and the scrollbar takes away space from the content node. This is wrong. I modified the method 'computeHsbSizeHint' to private double computeHsbSizeHint(ScrollPane sp) { return determineHorizontalSBVisible() ? hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; } Now the policy toggling behavior is correct both when the scrollbar is needed and when it's not - the space is reallocated not at the expense of the content. However, enlarging the stage horizontally while AS_NEEDED is selected does not reallocate the space (you need to toggle the policies). I'm guessing there's a missing call to layoutChildren during this resizing. Does anyone have any input here? Thanks, Nir [1] https://bugs.openjdk.org/browse/JDK-8199934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From perini.davide at dpsoftware.org Mon May 1 20:45:59 2023 From: perini.davide at dpsoftware.org (Davide Perini) Date: Mon, 1 May 2023 22:45:59 +0200 Subject: Is there a way to easily change the window border color? In-Reply-To: References: Message-ID: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> Hi all, is there an easy way to change the window border color in JavaFX? I would not like to create a custom border since I like to use the "native window border" look n feel, but how can I match the color with the one used in the OS? I'm using Windows 11 here, as you can see from this image, Windows explorer uses a dark grey border, while my JavaFX app uses the light grey color. How can I change that color without creating a custom "window border"? Thanks Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XkvmWtJR6f3y8rZb.jpeg Type: image/jpeg Size: 125179 bytes Desc: not available URL: From andy.goryachev at oracle.com Mon May 1 21:02:50 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 May 2023 21:02:50 +0000 Subject: Is there a way to easily change the window border color? In-Reply-To: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> References: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> Message-ID: Dear Davide: There is currently a discussion on the mailing list around platform preferences API https://bugs.openjdk.org/browse/JDK-8301302 and also a draft PR (one of possibly many) https://github.com/openjdk/jfx/pull/1014 I am sure your feedback will be greatly appreciated by all the participants. -andy From: openjfx-dev on behalf of Davide Perini Date: Monday, May 1, 2023 at 13:46 To: openjfx-dev at openjdk.org Subject: Is there a way to easily change the window border color? Hi all, is there an easy way to change the window border color in JavaFX? I would not like to create a custom border since I like to use the "native window border" look n feel, but how can I match the color with the one used in the OS? I'm using Windows 11 here, [cid:part1.lQoqmFQP.Q0pClVoY at dpsoftware.org] as you can see from this image, Windows explorer uses a dark grey border, while my JavaFX app uses the light grey color. How can I change that color without creating a custom "window border"? Thanks Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XkvmWtJR6f3y8rZb.jpeg Type: image/jpeg Size: 125179 bytes Desc: XkvmWtJR6f3y8rZb.jpeg URL: From john.hendrikx at gmail.com Mon May 1 21:21:47 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 1 May 2023 23:21:47 +0200 Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: I think we need to be very careful in adjusting preferred size based on scrollbar visibility. ScrollPane's are used to avoid putting pressure on the surrounding layout.? It's preferred size will often be ignored in most layouts because its preferred size is the size of its content, which is likely too large too fit (otherwise why use a ScrollPane). When a ScrollPane's bounds become smaller, it must be careful not to change its minimum space requirements, as that would be counter to its purpose. However, even changing its preferred size when space is getting tighter may affect layouts in a way you really want to avoid. BorderPane is one of many layouts, and even though what we're seeing may seem like a bug, changing this behavior may have consequences.? What if the ScrollPane is in a VBox with two elements set to Priority.ALWAYS, one being the ScrollPane?? When space gets tighter, changing the preferred size to allow for a scroll bar is going to make the layout jump a bit, because it will take away a bit of extra space from the other element with Priority.ALWAYS.? VBox uses the preferred sizes of all children as a starting point, and shrinks them to be smaller to fit -- changing the starting point (the preferred size) suddenly to make room for a scroll bar is not going to be smooth. I suspect in a lot of layouts the values for viewport width/height will be set, as using the content as its preferred size for a ScrollPane seems like a bad choice to begin with.? In the VBox example, the preferred size would be so large when there is a lot of content that it would swallow most of the extra space from any other nodes set to Priority.ALWAYS.? Two ScrollPane's above each other would not be equal sized, as their preferred starting sizes would be based on their contents... it would look weird without setting viewport size hints. I could imagine that there could be a different scroll bar policy, one where room is always reserved for scrollbars, but they still display only when needed.? This way, the ScrollPane, if it can be displayed at its preferred size, would have sufficient room for a horizontal scrollbar, and when it's horizontal size gets squished, it can display it without needing to adjust its minimum or preferred sizes. If there isn't enough room, it would pretty much function as before, where the scrollbar overlays content when it does need to be displayed -- that's unavoidable. There's also a similar issue: https://bugs.openjdk.org/browse/JDK-8095135 --John On 01/05/2023 22:18, Andy Goryachev wrote: > > I think your diagnosis is right though: sometimes the layout is not > triggered when a property is changed, > > the recent bug like that is > > JDK-8307117 TextArea: > wrapText property ignored when changing font > > I wonder if some kind of a generic unit test could be developed to > identify such cases. > > -andy > > *From: *Nir Lisker > *Date: *Monday, May 1, 2023 at 13:09 > *To: *Andy Goryachev > *Cc: *openjfx-dev > *Subject: *[External] : Re: JDK-8199934: ScrollPaneSkin incorrectly > lays out its scrollbars > > If I knew what the fix was I would have. Right now I'm not sure > anymore what the correct behavior should be even. > > On Mon, May 1, 2023 at 10:44?PM Andy Goryachev > wrote: > > Nir, would you like to submit a pull request? > > Thank you > > -andy > > *From: *openjfx-dev on behalf of > Nir Lisker > *Date: *Sunday, April 30, 2023 at 10:04 > *To: *openjfx-dev > *Subject: *JDK-8199934: ScrollPaneSkin incorrectly lays out its > scrollbars > > Hi, > > I took a quick jab at this issue [1]. Using the reproducer in the > ticket, launch and resize the stage vertically so that the buttons > at the bottom are only partially?visible. > > The current behavior is as follows: > > When the scrollbar is not needed, toggling to the AS_NEEDED policy > reallocates the scrollbar space for the buttons (they move up). > > When the scrollbar is needed, toggling to the AS_NEEDED policy > still reallocates space, and the scrollbar takes away space from > the content node. This is wrong. > > I modified the method 'computeHsbSizeHint' to > > private double computeHsbSizeHint(ScrollPane sp) { > ? ? return determineHorizontalSBVisible() ? > hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; > } > > Now the policy toggling behavior is correct both when the > scrollbar is needed and when it's not - the space is reallocated > not at the expense of the content. However, enlarging the stage > horizontally while AS_NEEDED is selected does not reallocate the > space (you need to toggle the policies). I'm guessing there's a > missing call to layoutChildren during this resizing. > > Does anyone have any input here? > > Thanks, > > Nir > > [1] https://bugs.openjdk.org/browse/JDK-8199934 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Mon May 1 21:28:40 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 1 May 2023 23:28:40 +0200 Subject: Is there a way to easily change the window border color? In-Reply-To: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> References: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> Message-ID: <521108b8-5477-0e75-4427-8f867f819b51@gmail.com> No easy way as of yet, the border isn't created by JavaFX but by Windows, and I think JavaFX is not responding to the global LIGHT/DARK settings of the platform.? You could try use the StageStyle UNDECORATED or UNIFIED, but that would still involve rendering your own border. Other options may include getting the HWND handle and using Windows API directly to change the style.? Getting the HWND (using Windows API) is not too hard, but I'm not sure what you may need to do to change the Window border to use the dark theme. --John On 01/05/2023 22:45, Davide Perini wrote: > Hi all, > is there an easy way to change the window border color in JavaFX? > > I would not like to create a custom border since I like to use the > "native window border" look n feel, > but how can I match the color with the one used in the OS? > > I'm using Windows 11 here, > > > > as you can see from this image, Windows explorer uses a dark grey > border, while my JavaFX app uses the light grey color. > > How can I change that color without creating a custom "window border"? > > Thanks > Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XkvmWtJR6f3y8rZb.jpeg Type: image/jpeg Size: 125179 bytes Desc: not available URL: From john.hendrikx at gmail.com Mon May 1 21:43:27 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 1 May 2023 23:43:27 +0200 Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: One more thing, ScrollPane is also missing an often seen use case: Transparent scrollbars, or scrollbars that fade out after use. For one of my own panes, I've tweaked ScrollPane to have transparent scroll bars which overlaps the content always (ie. the content is visible below the scroll bar).? I do this with a new ScrollBarSkin that just puts the bar at a negative offset so it overlaps the content.? IntelliJ does this for example, as well as Visual Studio Code (for horizontal bar at least). I think it already do this for touch platforms (embedded), but doesn't offer it for other platforms.? Someone filed a ticket for this: https://bugs.openjdk.org/browse/JDK-8091365 --John On 01/05/2023 23:21, John Hendrikx wrote: > > I think we need to be very careful in adjusting preferred size based > on scrollbar visibility. > > ScrollPane's are used to avoid putting pressure on the surrounding > layout.? It's preferred size will often be ignored in most layouts > because its preferred size is the size of its content, which is likely > too large too fit (otherwise why use a ScrollPane). When a > ScrollPane's bounds become smaller, it must be careful not to change > its minimum space requirements, as that would be counter to its purpose. > > However, even changing its preferred size when space is getting > tighter may affect layouts in a way you really want to avoid. > BorderPane is one of many layouts, and even though what we're seeing > may seem like a bug, changing this behavior may have consequences.? > What if the ScrollPane is in a VBox with two elements set to > Priority.ALWAYS, one being the ScrollPane?? When space gets tighter, > changing the preferred size to allow for a scroll bar is going to make > the layout jump a bit, because it will take away a bit of extra space > from the other element with Priority.ALWAYS.? VBox uses the preferred > sizes of all children as a starting point, and shrinks them to be > smaller to fit -- changing the starting point (the preferred size) > suddenly to make room for a scroll bar is not going to be smooth. > > I suspect in a lot of layouts the values for viewport width/height > will be set, as using the content as its preferred size for a > ScrollPane seems like a bad choice to begin with.? In the VBox > example, the preferred size would be so large when there is a lot of > content that it would swallow most of the extra space from any other > nodes set to Priority.ALWAYS.? Two ScrollPane's above each other would > not be equal sized, as their preferred starting sizes would be based > on their contents... it would look weird without setting viewport size > hints. > > I could imagine that there could be a different scroll bar policy, one > where room is always reserved for scrollbars, but they still display > only when needed.? This way, the ScrollPane, if it can be displayed at > its preferred size, would have sufficient room for a horizontal > scrollbar, and when it's horizontal size gets squished, it can display > it without needing to adjust its minimum or preferred sizes. If there > isn't enough room, it would pretty much function as before, where the > scrollbar overlays content when it does need to be displayed -- that's > unavoidable. > > There's also a similar issue: https://bugs.openjdk.org/browse/JDK-8095135 > > --John > > On 01/05/2023 22:18, Andy Goryachev wrote: >> >> I think your diagnosis is right though: sometimes the layout is not >> triggered when a property is changed, >> >> the recent bug like that is >> >> JDK-8307117 TextArea: >> wrapText property ignored when changing font >> >> I wonder if some kind of a generic unit test could be developed to >> identify such cases. >> >> -andy >> >> *From: *Nir Lisker >> *Date: *Monday, May 1, 2023 at 13:09 >> *To: *Andy Goryachev >> *Cc: *openjfx-dev >> *Subject: *[External] : Re: JDK-8199934: ScrollPaneSkin incorrectly >> lays out its scrollbars >> >> If I knew what the fix was I would have. Right now I'm not sure >> anymore what the correct behavior should be even. >> >> On Mon, May 1, 2023 at 10:44?PM Andy Goryachev >> wrote: >> >> Nir, would you like to submit a pull request? >> >> Thank you >> >> -andy >> >> *From: *openjfx-dev on behalf of >> Nir Lisker >> *Date: *Sunday, April 30, 2023 at 10:04 >> *To: *openjfx-dev >> *Subject: *JDK-8199934: ScrollPaneSkin incorrectly lays out its >> scrollbars >> >> Hi, >> >> I took a quick jab at this issue [1]. Using the reproducer in the >> ticket, launch and resize the stage vertically so that the >> buttons at the bottom are only partially?visible. >> >> The current behavior is as follows: >> >> When the scrollbar is not needed, toggling to the AS_NEEDED >> policy reallocates the scrollbar space for the buttons (they move >> up). >> >> When the scrollbar is needed, toggling to the AS_NEEDED policy >> still reallocates space, and the scrollbar takes away space from >> the content node. This is wrong. >> >> I modified the method 'computeHsbSizeHint' to >> >> private double computeHsbSizeHint(ScrollPane sp) { >> ? ? return determineHorizontalSBVisible() ? >> hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; >> } >> >> Now the policy toggling behavior is correct both when the >> scrollbar is needed and when it's not - the space is reallocated >> not at the expense of the content. However, enlarging the stage >> horizontally while AS_NEEDED is selected does not reallocate the >> space (you need to toggle the policies). I'm guessing there's a >> missing call to layoutChildren during this resizing. >> >> Does anyone have any input here? >> >> Thanks, >> >> Nir >> >> [1] https://bugs.openjdk.org/browse/JDK-8199934 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon May 1 21:45:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 21:45:21 GMT Subject: RFR: 8299335: Monkey Tester Application [v16] In-Reply-To: <4nwmEvrOhqvrTiP-Y9MmAHMoGkiGRfSZmrkU2Oo8qRA=.0317876e-c09a-4927-a922-b0c5b8c8effa@github.com> References: <4nwmEvrOhqvrTiP-Y9MmAHMoGkiGRfSZmrkU2Oo8qRA=.0317876e-c09a-4927-a922-b0c5b8c8effa@github.com> Message-ID: <7lLLiAjTb8Jpok6p0lcXXtye0Yo_TzHU4W6Wk1QyX6Q=.1289481b-12e1-4b80-9f3a-2185f94b4660@github.com> On Mon, 1 May 2023 18:55:34 GMT, Andy Goryachev wrote: > This tool is not a replacement for unit tests or manual tests, but rather to fill a certain gap by providing a relatively quick way for ad hoc testing of component behavior and bug fixes. I agree with this. Regression tests and functional tests are best done as automated tests. When absolutely necessary, a manual test with a clear recipe is an acceptable, but less desirable fallback. This isn't the area MonkeyTester is targeting. Rather, it is a useful tool to help find bugs by making ad hoc testing easier. Hopefully it can be improved over time. > Ideally, once a bug is found, there should be a SCCE pinpointing the issue. Yep. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1097#issuecomment-1530346346 From andy.goryachev at oracle.com Mon May 1 21:51:10 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 May 2023 21:51:10 +0000 Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars In-Reply-To: References: Message-ID: This is a very interesting idea. iOS does something similar, but I always thought than discoverability should be a priority. Perhaps if it would not fade to a complete transparency, but remained slightly visible. Or it might depend on a (global) option. One thing you are right - it would require a different skin (skins, for all the components that use ScrollBars). -andy From: openjfx-dev on behalf of John Hendrikx Date: Monday, May 1, 2023 at 14:43 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars One more thing, ScrollPane is also missing an often seen use case: Transparent scrollbars, or scrollbars that fade out after use. For one of my own panes, I've tweaked ScrollPane to have transparent scroll bars which overlaps the content always (ie. the content is visible below the scroll bar). I do this with a new ScrollBarSkin that just puts the bar at a negative offset so it overlaps the content. IntelliJ does this for example, as well as Visual Studio Code (for horizontal bar at least). I think it already do this for touch platforms (embedded), but doesn't offer it for other platforms. Someone filed a ticket for this: https://bugs.openjdk.org/browse/JDK-8091365 --John On 01/05/2023 23:21, John Hendrikx wrote: I think we need to be very careful in adjusting preferred size based on scrollbar visibility. ScrollPane's are used to avoid putting pressure on the surrounding layout. It's preferred size will often be ignored in most layouts because its preferred size is the size of its content, which is likely too large too fit (otherwise why use a ScrollPane). When a ScrollPane's bounds become smaller, it must be careful not to change its minimum space requirements, as that would be counter to its purpose. However, even changing its preferred size when space is getting tighter may affect layouts in a way you really want to avoid. BorderPane is one of many layouts, and even though what we're seeing may seem like a bug, changing this behavior may have consequences. What if the ScrollPane is in a VBox with two elements set to Priority.ALWAYS, one being the ScrollPane? When space gets tighter, changing the preferred size to allow for a scroll bar is going to make the layout jump a bit, because it will take away a bit of extra space from the other element with Priority.ALWAYS. VBox uses the preferred sizes of all children as a starting point, and shrinks them to be smaller to fit -- changing the starting point (the preferred size) suddenly to make room for a scroll bar is not going to be smooth. I suspect in a lot of layouts the values for viewport width/height will be set, as using the content as its preferred size for a ScrollPane seems like a bad choice to begin with. In the VBox example, the preferred size would be so large when there is a lot of content that it would swallow most of the extra space from any other nodes set to Priority.ALWAYS. Two ScrollPane's above each other would not be equal sized, as their preferred starting sizes would be based on their contents... it would look weird without setting viewport size hints. I could imagine that there could be a different scroll bar policy, one where room is always reserved for scrollbars, but they still display only when needed. This way, the ScrollPane, if it can be displayed at its preferred size, would have sufficient room for a horizontal scrollbar, and when it's horizontal size gets squished, it can display it without needing to adjust its minimum or preferred sizes. If there isn't enough room, it would pretty much function as before, where the scrollbar overlays content when it does need to be displayed -- that's unavoidable. There's also a similar issue: https://bugs.openjdk.org/browse/JDK-8095135 --John On 01/05/2023 22:18, Andy Goryachev wrote: I think your diagnosis is right though: sometimes the layout is not triggered when a property is changed, the recent bug like that is JDK-8307117 TextArea: wrapText property ignored when changing font I wonder if some kind of a generic unit test could be developed to identify such cases. -andy From: Nir Lisker Date: Monday, May 1, 2023 at 13:09 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars If I knew what the fix was I would have. Right now I'm not sure anymore what the correct behavior should be even. On Mon, May 1, 2023 at 10:44?PM Andy Goryachev > wrote: Nir, would you like to submit a pull request? Thank you -andy From: openjfx-dev > on behalf of Nir Lisker > Date: Sunday, April 30, 2023 at 10:04 To: openjfx-dev > Subject: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars Hi, I took a quick jab at this issue [1]. Using the reproducer in the ticket, launch and resize the stage vertically so that the buttons at the bottom are only partially visible. The current behavior is as follows: When the scrollbar is not needed, toggling to the AS_NEEDED policy reallocates the scrollbar space for the buttons (they move up). When the scrollbar is needed, toggling to the AS_NEEDED policy still reallocates space, and the scrollbar takes away space from the content node. This is wrong. I modified the method 'computeHsbSizeHint' to private double computeHsbSizeHint(ScrollPane sp) { return determineHorizontalSBVisible() ? hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0; } Now the policy toggling behavior is correct both when the scrollbar is needed and when it's not - the space is reallocated not at the expense of the content. However, enlarging the stage horizontally while AS_NEEDED is selected does not reallocate the space (you need to toggle the policies). I'm guessing there's a missing call to layoutChildren during this resizing. Does anyone have any input here? Thanks, Nir [1] https://bugs.openjdk.org/browse/JDK-8199934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon May 1 21:55:29 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 May 2023 21:55:29 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:16:31 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments I ran through all of the panels and have three additional suggestions: 1. `ComboBox`: The current two buttons don't seem all that useful. I'm not even sure what, exactly, they do. What would be useful is a way to select the number of items in the list (like there is with ChoiceBox) 2. `ListView`: Changing the selection model or checking / unchecking the "null focus model" option clears the list, which is unexptected. Given that there is a separate "clear list" button, it doesn't seem needed either. 3. `TextField`: The default alignment of BASELINE_RIGHT is unexpected (unless there is a good reason, defaults for properties should match the API default to avoid surprises). Feel free to defer them to [JDK-8307176](https://bugs.openjdk.org/browse/JDK-8307176) if you prefer. If you fix any of them, I'll reapprove. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1097#pullrequestreview-1408158477 From angorya at openjdk.org Mon May 1 22:44:25 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 May 2023 22:44:25 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 21:52:31 GMT, Kevin Rushforth wrote: > three additional suggestions: Thank you. I'd rather defer them to the next iteration. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1097#issuecomment-1530471587 From martin at martinfox.com Tue May 2 00:38:30 2023 From: martin at martinfox.com (Martin Fox) Date: Mon, 1 May 2023 17:38:30 -0700 Subject: Is there a way to easily change the window border color? In-Reply-To: <521108b8-5477-0e75-4427-8f867f819b51@gmail.com> References: <0cf0fb54-5b63-8e94-e77d-14ff8e4bad8a@dpsoftware.org> <521108b8-5477-0e75-4427-8f867f819b51@gmail.com> Message-ID: The details on how to detect dark mode and alter the HWND?s title bar are laid out here: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes Martin > On May 1, 2023, at 2:28 PM, John Hendrikx wrote: > > No easy way as of yet, the border isn't created by JavaFX but by Windows, and I think JavaFX is not responding to the global LIGHT/DARK settings of the platform. You could try use the StageStyle UNDECORATED or UNIFIED, but that would still involve rendering your own border. > > Other options may include getting the HWND handle and using Windows API directly to change the style. Getting the HWND (using Windows API) is not too hard, but I'm not sure what you may need to do to change the Window border to use the dark theme. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue May 2 08:57:30 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 May 2023 08:57:30 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v4] In-Reply-To: References: Message-ID: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> > Add `TEST_ONLY` flag to gradle with default value as false. > Add new task named `shims`, This task depends on all shim tasks from all projects. Hence it will build all shim classes. > > If TEST_ONLY is set to true, the all non test tasks get disabled. When running a test task, this flag would reduce time in checking if all non test tasks are up to date. > How to use: > 1. Following command would fail in a clean repo, > > gradle -PTEST_ONLY=true :base:test > 2. The sdk and shims task must have been executed before running any test > > gradle sdk shims > > gradle -PTEST_ONLY=true :base:test > 3. Setting this flag to true with non test task would result in no task being run. > > gradle -PTEST_ONLY=true sdk -> It will not build sdk task > > TIP: use `--dry-run` option of gradle for speeding up testing the effect of this PR. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1117/files - new: https://git.openjdk.org/jfx/pull/1117/files/980000e7..908e8fcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1117&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1117&range=02-03 Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1117.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1117/head:pull/1117 PR: https://git.openjdk.org/jfx/pull/1117 From arapte at openjdk.org Tue May 2 08:57:32 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 May 2023 08:57:32 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 11:44:37 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> update submit.yml > > build.gradle line 55: > >> 53: * >> 54: * Adding a new project or task: >> 55: * - Fix for JDK-XXXXXXX, introduces a restriction on assigning name for project or task. > > Minor: replace with actual bug ID (8297071) Corrected. > build.gradle line 57: > >> 55: * - Fix for JDK-XXXXXXX, introduces a restriction on assigning name for project or task. >> 56: * - If the name of project or task contains word test/Test then it is considered as test task. >> 57: * - If the name of project or task contains word shim/Shim then it is considered as shims task. > > Minor: there is no project that contains the name `shim`, so I think you can remove the "project or" from this comment. Corrected. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1117#discussion_r1182265837 PR Review Comment: https://git.openjdk.org/jfx/pull/1117#discussion_r1182266003 From arapte at openjdk.org Tue May 2 08:57:34 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 May 2023 08:57:34 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v4] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 11:58:02 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > gradle.properties.template line 82: > >> 80: # Recommended to use TEST_ONLY instead of this property. >> 81: >> 82: #BUILD_SDK_FOR_TEST = false > > Suggestion: Maybe remove this, since it is only kept for compatibility? It's fine if you want to keep it. Removed `BUILD_SDK_FOR_TEST`. It seems safer and right to remove. It may be confusing to keep two flags for same action. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1117#discussion_r1182268657 From arapte at openjdk.org Tue May 2 09:00:23 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 May 2023 09:00:23 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 18:13:57 GMT, Kevin Rushforth wrote: > I get one failure when running the tests after first building the shims: As you pointed out, it failed because `webArchiveJar` task was getting disabled. Changing the task name to `testWebArchiveJar` solves the problem. That task is local to `:web` project and referred only by `:web:test` task, not elsewhere, so it looks safe to rename. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1117#issuecomment-1531119327 From lkostyra at openjdk.org Tue May 2 09:52:33 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 2 May 2023 09:52:33 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility In-Reply-To: <_oDXmhiRDCN9xMkwF2CT4EYApkyfN11_DZ4Osw8dAl4=.bff446bd-85d9-4232-bdfb-fcc320f6a56d@github.com> References: <_oDXmhiRDCN9xMkwF2CT4EYApkyfN11_DZ4Osw8dAl4=.bff446bd-85d9-4232-bdfb-fcc320f6a56d@github.com> Message-ID: On Mon, 1 May 2023 16:05:01 GMT, Andy Goryachev wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > build.gradle line 3468: > >> 3466: implementation project(":controls") >> 3467: implementation project(":media") >> 3468: testImplementation project(":base").sourceSets.test.output > > does the header year need to be changed? Done > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 50: > >> 48: import org.w3c.dom.NodeList; >> 49: import static org.junit.Assert.*; >> 50: import test.util.memory.JMemoryBuddy; > > same comment - year in the header? Done > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeDnDMemoryLeakTest.java line 74: > >> 72: }); >> 73: >> 74: for (WeakReference ref : weakRefArrSN) { > > I wonder if we should add a utility method to JMemoryBuddy to operate on an array/collection, so we don't have to repeat this code again and again? Done > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 82: > >> 80: SwingUtilities.invokeAndWait(() -> Util.sleep(500)); >> 81: >> 82: for (WeakReference ref : weakRefArrSN) { > > same comment as before about a new utility method Done > tests/system/src/test/java/test/javafx/scene/control/TabPaneHeaderLeakTest.java line 98: > >> 96: >> 97: JMemoryBuddy.assertCollectable(tabWeakRef); >> 98: JMemoryBuddy.assertCollectable(textFieldWeakRef); > > perhaps the utility method operating on an array should accept varargs, like so: > > `assertCollectable(WeakRef a, WeakRef ... b)` > > (to differentiate it from a single arg method, and to make sure there are 2+ args) Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182334803 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182334700 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182334626 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182334517 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182334449 From arapte at openjdk.org Tue May 2 10:25:25 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 2 May 2023 10:25:25 GMT Subject: RFR: 8302816: Refactor sorting-related classes [v3] In-Reply-To: <5ZjkCYYTjlgJ-trVrEowL9_eg2QGDQ_gxPOFZTF3f-8=.59a4dec3-7818-4e71-88e5-6abfe6ffc85f@github.com> References: <5ZjkCYYTjlgJ-trVrEowL9_eg2QGDQ_gxPOFZTF3f-8=.59a4dec3-7818-4e71-88e5-6abfe6ffc85f@github.com> Message-ID: On Fri, 28 Apr 2023 11:41:53 GMT, Nir Lisker wrote: >> Most of the changes revolve around unifying the sorting methods for a collection with `Comparable` elements with sorting methods that take an external `Comparator` by passing `Comparator.naturalOrder()` from the former to the latter. This eliminates method duplication and some warnings suppressions. >> >> Note that I get 1 failing test: VersionInfoTest.testMajorVersion. This PR is unrelated to this test. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Addressed review comments for SortableList > - Addressed review comments for FXCollections LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1041#pullrequestreview-1408822487 From lkostyra at openjdk.org Tue May 2 10:29:24 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 2 May 2023 10:29:24 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility In-Reply-To: References: Message-ID: <8DCvorsuEZO-MS8HcStDF8u29WUGOuOu5PqeCeDIVrs=.bd5e65fd-ba41-443b-ac88-e53473ba7942@github.com> On Mon, 1 May 2023 15:34:35 GMT, Kevin Rushforth wrote: > > EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > In addition to the manual test, the `javafx.web` module also has an automated [EventListenerLeakTest](https://github.com/openjdk/jfx/blob/fbee1d2201270e7b3beb054ecb9fdf65ae11c43d/modules/javafx.web/src/test/java/test/javafx/scene/web/EventListenerLeakTest.java) that could benefit from using JMemoryBuddy, but it would not be a trivial change, so it might be better to file a follow-on bug for that. I actually missed that. I looked briefly into it and I agree it is a larger change, I will file a follow-up bug for it after this PR is merged. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1531235468 From dwookey at openjdk.org Tue May 2 10:44:29 2023 From: dwookey at openjdk.org (Dean Wookey) Date: Tue, 2 May 2023 10:44:29 GMT Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes memory leak [v2] In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey wrote: >> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak. >> >> The first commit was more straightforward, but there are 2 things that might be of concern: >> >> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine. >> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. >> >> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit. >> >> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView). >> >> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added more comments and fixed IdentityWrapper hashcode. This fix is quite complicated for sure. This memory leak currently affects us, so we're using an internal build. We would like to see a fix for this get merged in, and there's also a follow-up PR I'd like to do as well. @arapte If the complexity is the issue, we are open to any suggestions for alternative (simpler) fixes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1037#issuecomment-1531251481 From lkostyra at openjdk.org Tue May 2 11:08:18 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 2 May 2023 11:08:18 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v2] In-Reply-To: References: Message-ID: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Address review issues * JMemoryBuddy now has helpers for arrays of WeakReference, ArrayList of WeakReference and vararg WeakReferences * Updated copyright years in some files which were missed in previous changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/fbee1d22..158ed40a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=00-01 Stats: 39 lines in 7 files changed: 20 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From nlisker at openjdk.org Tue May 2 11:22:26 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 2 May 2023 11:22:26 GMT Subject: Integrated: 8302816: Refactor sorting-related classes In-Reply-To: References: Message-ID: On Sat, 18 Feb 2023 17:59:12 GMT, Nir Lisker wrote: > Most of the changes revolve around unifying the sorting methods for a collection with `Comparable` elements with sorting methods that take an external `Comparator` by passing `Comparator.naturalOrder()` from the former to the latter. This eliminates method duplication and some warnings suppressions. > > Note that I get 1 failing test: VersionInfoTest.testMajorVersion. This PR is unrelated to this test. This pull request has now been integrated. Changeset: 50bafc21 Author: Nir Lisker URL: https://git.openjdk.org/jfx/commit/50bafc2120722f51dd5684899f40a40a6705297b Stats: 249 lines in 5 files changed: 28 ins; 125 del; 96 mod 8302816: Refactor sorting-related classes Reviewed-by: jhendrikx, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1041 From angorya at openjdk.org Tue May 2 15:17:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 May 2023 15:17:28 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v2] In-Reply-To: References: Message-ID: <4AmItVxP7ZvoN1KJb7lnj-E4sMPpDd5Zd3ge2_EGnxQ=.73e6b3e8-1f99-4656-b54c-7f17284ecb8e@github.com> On Thu, 27 Apr 2023 19:15:56 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx 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: > > - Print seed if test fails > - Merge branch 'master' into feature/ceil-fix > - Fix Region ceil/floor function guarantees to be more accurate > I'm not able to reproduce it. I am trying to run the code after a clean build, and can't - the MonkeyTester freezes going in an infinite loop in HBox.growOrShrinkAreaWidths() on line 517 when launching to an HBox page. And when launching to a different page, the layout all gets messed up: ![Screenshot 2023-05-01 132041](https://user-images.githubusercontent.com/107069028/235538707-2ac949d7-6257-4a66-8847-3dc73a5f1e64.png) also, looks like it's entering infinite loop when moving the window from primary monitor on windows 11 (scale=100%) to the secondary (scale=175%) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1531657744 From jhendrikx at openjdk.org Tue May 2 15:20:34 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 2 May 2023 15:20:34 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v2] In-Reply-To: <4AmItVxP7ZvoN1KJb7lnj-E4sMPpDd5Zd3ge2_EGnxQ=.73e6b3e8-1f99-4656-b54c-7f17284ecb8e@github.com> References: <4AmItVxP7ZvoN1KJb7lnj-E4sMPpDd5Zd3ge2_EGnxQ=.73e6b3e8-1f99-4656-b54c-7f17284ecb8e@github.com> Message-ID: On Tue, 2 May 2023 15:15:00 GMT, Andy Goryachev wrote: > > I'm not able to reproduce it. > > I am trying to run the code after a clean build, and can't - the MonkeyTester freezes going in an infinite loop in HBox.growOrShrinkAreaWidths() on line 517 when launching to an HBox page. > > And when launching to a different page, the layout all gets messed up: > > ![Screenshot 2023-05-01 132041](https://user-images.githubusercontent.com/107069028/235538707-2ac949d7-6257-4a66-8847-3dc73a5f1e64.png) > > also, looks like it's entering infinite loop when moving the window from primary monitor on windows 11 (scale=100%) to the secondary (scale=175%) Okay, I will investigate, I have an idea what this can be, just very surprised that the rounding fixes would cause any issues in this code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1531662136 From angorya at openjdk.org Tue May 2 15:40:25 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 May 2023 15:40:25 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v2] In-Reply-To: References: <4AmItVxP7ZvoN1KJb7lnj-E4sMPpDd5Zd3ge2_EGnxQ=.73e6b3e8-1f99-4656-b54c-7f17284ecb8e@github.com> Message-ID: On Tue, 2 May 2023 15:18:02 GMT, John Hendrikx wrote: > Okay, I will investigate, I have an idea what this can be, just very surprised that the rounding fixes would cause any issues in this code. Thank you. I wonder if other places might also exhibit a similar failure mode. `scaledCeil` is called by `snapSizeX/snapSizeY` as well as `layoutInArea()` which are ... everywhere. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1531692780 From jhendrikx at openjdk.org Tue May 2 15:43:27 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 2 May 2023 15:43:27 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v2] In-Reply-To: References: <4AmItVxP7ZvoN1KJb7lnj-E4sMPpDd5Zd3ge2_EGnxQ=.73e6b3e8-1f99-4656-b54c-7f17284ecb8e@github.com> Message-ID: On Tue, 2 May 2023 15:38:06 GMT, Andy Goryachev wrote: > > Okay, I will investigate, I have an idea what this can be, just very surprised that the rounding fixes would cause any issues in this code. > > Thank you. I wonder if other places might also exhibit a similar failure mode. `scaledCeil` is called by `snapSizeX/snapSizeY` as well as `layoutInArea()` which are ... everywhere. The problem is that the code you linked (L517 in HBox) is doing a few things that are incorrect (and which I fixed in #1111). First, it has this line: while (Math.abs(available) > 1 && adjustingNumber > 0) { Here it assumes that pixels have size == 1; the correct check should be `Math.abs(available) > 1 / renderScale`. Secondly, it uses `snapPortionX`, which are package private methods (luckily) which have an interesting side effect. They don't just round "down" (floor for positive, ceiling for negative) but they also have a minimum value (1 or -1) -- this is incorrect for two reasons: a round down function can also round to 0 (which I corrected), and secondly, using the constant 1 is incorrect because that should be `1 / renderScale`. >From what it looks like, these `snapPortion` functions are only used by HBox/VBox, and I think it would be best to correct the callers here to not rely on the behavior that the smallest values that can be returned are 1 or -1 (also because those are simply incorrect). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1531696750 From angorya at openjdk.org Tue May 2 15:48:27 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 May 2023 15:48:27 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 19:15:56 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx 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: > > - Print seed if test fails > - Merge branch 'master' into feature/ceil-fix > - Fix Region ceil/floor function guarantees to be more accurate I'll comment about snapPortionX/Y in https://github.com/openjdk/jfx/pull/1111 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1531704605 From angorya at openjdk.org Tue May 2 15:54:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 May 2023 15:54:28 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v2] In-Reply-To: References: Message-ID: <7G1Fl6owRSZw6WF7WLsfeRA0L_E2To4pVsX45D8bZX0=.71e50f11-7dd8-4da6-9b47-30f8df36415e@github.com> On Tue, 2 May 2023 11:08:18 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Address review issues > > * JMemoryBuddy now has helpers for arrays of WeakReference, ArrayList > of WeakReference and vararg WeakReferences > * Updated copyright years in some files which were missed in previous > changes modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 101: > 99: } > 100: > 101: public static void assertCollectable(ArrayList> weakReferences) { Could we change the argument to Collection<...>? modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 95: > 93: > 94: for (WeakReference ref : willGC) { > 95: JMemoryBuddy.assertCollectable(ref); should we use newly added methods here? modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 122: > 120: > 121: for (WeakReference ref : willGC) { > 122: JMemoryBuddy.assertCollectable(ref); ditto, new methods? modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 224: > 222: Thread.sleep(SLEEP_TIME); > 223: for (WeakReference ref : willGC) { > 224: JMemoryBuddy.assertCollectable(ref); and here ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182737400 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182738142 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182738501 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1182738706 From jhendrikx at openjdk.org Tue May 2 16:11:18 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 2 May 2023 16:11:18 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v3] In-Reply-To: References: Message-ID: > Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: > > ceil(x) = ceil(ceil(x)) > > However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. > > The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). > > The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. > > Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix for using constant 1 in HBox/VBox instead of 1 / renderScale ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1118/files - new: https://git.openjdk.org/jfx/pull/1118/files/65e1475a..9c9e6391 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=01-02 Stats: 30 lines in 3 files changed: 20 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1118.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1118/head:pull/1118 PR: https://git.openjdk.org/jfx/pull/1118 From martin at martinfox.com Tue May 2 16:35:56 2023 From: martin at martinfox.com (Martin Fox) Date: Tue, 2 May 2023 09:35:56 -0700 Subject: Supporting "+" and "-" accelerators on the numeric keypad Message-ID: One of the most common keyboard accelerators involving a symbol is Shortcut+'+' (plus sign). It?s often assigned to a menu item like Zoom In or Bigger. To target + in a way that works regardless of keyboard layout this has to be specified using a KeyCharacterCombination. Using a KeyCharacter combo also ensures the user can invoke the accelerator without using the Shift key on layouts where + is a shifted character. On Windows and Linux KeyCharacter combos only work on the main keyboard and not the numeric keypad. This surprises users and developers and there?s a bug entered against it (see JDK-8089373). The work-around is to add an accelerator to the scene that performs the same action and targets KeyCode.ADD. Since a menu item can only have one accelerator this would have to be managed in code outside the menu system. I?m not familiar enough with JavaFX app development to comment on how much effort that would involve. On the Mac a KeyCharacter combo targeting + will work on both the main keyboard and the numeric keypad (in fact it works more reliably from the keypad). So there?s also platform discrepancy that needs to be resolved. I?m inclined to fix JDK-8089373 and make KeyCharacterCombinations work on the numeric keypad on all platforms. I?ve got the necessary changes queued up for Windows but wanted to get some buy-in before submitting the PR. The same PR would fix some other problems related to + char combos (they don?t work on German layouts) but I can easily drop the changes that enable the keypad. https://bugs.openjdk.org/browse/JDK-8089373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue May 2 16:47:02 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 2 May 2023 16:47:02 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v4] In-Reply-To: References: Message-ID: > Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: > > ceil(x) = ceil(ceil(x)) > > However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. > > The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). > > The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. > > Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix bad commit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1118/files - new: https://git.openjdk.org/jfx/pull/1118/files/9c9e6391..2cfbb8a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1118.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1118/head:pull/1118 PR: https://git.openjdk.org/jfx/pull/1118 From john at status6.com Tue May 2 18:29:22 2023 From: john at status6.com (John Neffenger) Date: Tue, 2 May 2023 11:29:22 -0700 Subject: Bug using binary stylesheets: Loading relative @font-face paths are converted to absolute ones In-Reply-To: <3a1a49b8-e467-9c93-9cbd-108e2c24450a@skymatic.de> References: <3a1a49b8-e467-9c93-9cbd-108e2c24450a@skymatic.de> Message-ID: On 3/30/23 2:01 AM, Armin Schrenk wrote: > binary stylesheets is a more hidden feature of javafx, so before filing > a bug ticket i'm writing to this mailing list. Just a note that I've opened the following bug report for the problem: JDK-8307082 Build path is recorded in JavaFX Controls module https://bugs.openjdk.org/browse/JDK-8307082 John From kcr at openjdk.org Tue May 2 21:52:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 May 2023 21:52:20 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v4] In-Reply-To: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> References: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> Message-ID: On Tue, 2 May 2023 08:57:30 GMT, Ambarish Rapte wrote: >> Add `TEST_ONLY` flag to gradle with default value as false. >> Add new task named `shims`, This task depends on all shim tasks from all projects. Hence it will build all shim classes. >> >> If TEST_ONLY is set to true, the all non test tasks get disabled. When running a test task, this flag would reduce time in checking if all non test tasks are up to date. >> How to use: >> 1. Following command would fail in a clean repo, >> > gradle -PTEST_ONLY=true :base:test >> 2. The sdk and shims task must have been executed before running any test >> > gradle sdk shims >> > gradle -PTEST_ONLY=true :base:test >> 3. Setting this flag to true with non test task would result in no task being run. >> > gradle -PTEST_ONLY=true sdk -> It will not build sdk task >> >> TIP: use `--dry-run` option of gradle for speeding up testing the effect of this PR. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1117#pullrequestreview-1409937087 From kcr at openjdk.org Tue May 2 21:52:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 May 2023 21:52:21 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v3] In-Reply-To: References: Message-ID: <9rF6dGgikJOlgQkjescuhr7CzZ2nnuHBeHA8PdAMzxo=.b6f2d385-561f-4da6-af85-c6466954a6f6@github.com> On Tue, 2 May 2023 08:57:13 GMT, Ambarish Rapte wrote: > As you pointed out, it failed because `webArchiveJar` task was getting disabled. Changing the task name to `testWebArchiveJar` solves the problem. That seems like a good solution, and makes it clear that this is a test task. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1117#issuecomment-1532198359 From john at status6.com Wed May 3 04:54:19 2023 From: john at status6.com (John Neffenger) Date: Tue, 2 May 2023 21:54:19 -0700 Subject: Allow OpenJFX to be built on unknown architectures In-Reply-To: References: Message-ID: I opened the following bug report for this issue: JDK-8307316 : Let JavaFX be built on unknown architectures John On 3/30/23 10:34 AM, Glavo wrote: > Did I successfully send this email to the mailing list? > > On Wed, Mar 29, 2023 at 10:18?PM Glavo wrote: > > Hi everyone, > > Currently OpenJFX's build script asserts the CPU architecture and > does not allow building on unknown architectures. > But in fact OpenJFX is cross-platform, it can actually be built > and run on almost all architectures. > The only hurdle was the asserts in the build scripts, and John > made it compile on the s390x and ppc64el platforms with a simple > patch[1]. > > I'm working on some niche architectures (such as MIPS64el and > RISC-V) and I need to compile OpenJFX for them. > I understand the need to warn users that there may be unknown > issues building on these architectures, > and I don't have time to do regular testing to ensure that OpenJFX > works on these architectures. > But I wish it was simpler to build OpenJFX on these architectures. > So can we add a gradle property to have the build script skip the > assertion on the architecture, > thus allowing us to build OpenJFX on unknown architectures without > modifying any files? > > Glavo > > [1]: > https://github.com/jgneff/openjfx/blob/candidate/snap/local/allow-armhf-i386-ppc64el-s390x.patch > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Wed May 3 09:20:14 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 3 May 2023 09:20:14 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v3] In-Reply-To: References: Message-ID: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Minor review updates * Changed ArrayList<> to Collection<> in one of assertCollectable-s * Updated LeakTest to use new assertCollectable helpers ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/158ed40a..0b8b058f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=01-02 Stats: 13 lines in 2 files changed: 0 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From lkostyra at openjdk.org Wed May 3 09:20:19 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 3 May 2023 09:20:19 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v2] In-Reply-To: <7G1Fl6owRSZw6WF7WLsfeRA0L_E2To4pVsX45D8bZX0=.71e50f11-7dd8-4da6-9b47-30f8df36415e@github.com> References: <7G1Fl6owRSZw6WF7WLsfeRA0L_E2To4pVsX45D8bZX0=.71e50f11-7dd8-4da6-9b47-30f8df36415e@github.com> Message-ID: On Tue, 2 May 2023 15:49:41 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review issues >> >> * JMemoryBuddy now has helpers for arrays of WeakReference, ArrayList >> of WeakReference and vararg WeakReferences >> * Updated copyright years in some files which were missed in previous >> changes > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 101: > >> 99: } >> 100: >> 101: public static void assertCollectable(ArrayList> weakReferences) { > > Could we change the argument to Collection<...>? Done > modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 95: > >> 93: >> 94: for (WeakReference ref : willGC) { >> 95: JMemoryBuddy.assertCollectable(ref); > > should we use newly added methods here? Done + others. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1183435309 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1183435289 From kizune at openjdk.org Wed May 3 18:14:30 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 3 May 2023 18:14:30 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: On Mon, 1 May 2023 19:16:31 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/AccordionPage.java line 61: > 59: > 60: protected void addPane() { > 61: String name = "" + System.currentTimeMillis(); Here and in other demos - can we use some sort of pronounceable generated names for new controls instead of hashes or timestamps? Especially testing accessibility for system to voice the numbers soup takes a long time because it spells it out digit by digit and it is hard to check if we get reading from the correct component because names are like 99% the same. Even "Pane 1".."Pane 99" would be more acceptable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184087037 From angorya at openjdk.org Wed May 3 18:18:22 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 18:18:22 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v3] In-Reply-To: References: Message-ID: <0izA_ihL0kd6T4fp4jfMyamD93t9icK-NM30SuyfLC4=.479e99fb-141c-473c-80c7-4a9e1c9efdc3@github.com> On Wed, 3 May 2023 09:20:14 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Minor review updates > > * Changed ArrayList<> to Collection<> in one of assertCollectable-s > * Updated LeakTest to use new assertCollectable helpers The changes look good! Unfortunately, the project won't build in Eclipse due to `The type test.util.memory.JMemoryBuddy is not accessible LeakTest.java /web/src/test/java/test/javafx/scene/web` To fix that, could you please modify line 45 of modules/web/.classpath file to this (er, better include the whole file): ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1533497773 From angorya at openjdk.org Wed May 3 19:08:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 19:08:28 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v3] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 09:20:14 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Minor review updates > > * Changed ArrayList<> to Collection<> in one of assertCollectable-s > * Updated LeakTest to use new assertCollectable helpers looks good, one .classpath file change is requested. ------------- Changes requested by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1411606552 From kizune at openjdk.org Wed May 3 19:10:30 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 3 May 2023 19:10:30 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: <__IF-baAfkZt_7Tbm6cBjezxf0eGnPL8S730u56u2K8=.957f862b-54b8-4b55-ab0d-3bab8cfd39e6@github.com> On Mon, 1 May 2023 19:16:31 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/ComboBoxPage.java line 71: > 69: new Timeline( > 70: new KeyFrame(Duration.seconds(1.0), (ev) -> { > 71: System.out.println("2"); Why do we need that debug output in this particular place? May be add some label or text field that shows the currently assumed number of items instead of relying on the system output stream? Also it would be great if there is a text somewhere which at least describes what is the purpose of the button and what is supposed to happen when you press it. If not in some designated area then at least as a tooltip on the button? I mean "Change item count" - to what? No mention of the delay so user has to either guess of why does it not change immediately or look the source code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184138655 From angorya at openjdk.org Wed May 3 19:24:27 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 19:24:27 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: <__IF-baAfkZt_7Tbm6cBjezxf0eGnPL8S730u56u2K8=.957f862b-54b8-4b55-ab0d-3bab8cfd39e6@github.com> References: <__IF-baAfkZt_7Tbm6cBjezxf0eGnPL8S730u56u2K8=.957f862b-54b8-4b55-ab0d-3bab8cfd39e6@github.com> Message-ID: <53EbVu4UcIbEbG6NTbjvLjlAtTDmyNNdBDMDjsMGZgY=.0415a532-341c-4e39-84a8-c302ee81e395@github.com> On Wed, 3 May 2023 19:08:06 GMT, Alexander Zuev wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/ComboBoxPage.java line 71: > >> 69: new Timeline( >> 70: new KeyFrame(Duration.seconds(1.0), (ev) -> { >> 71: System.out.println("2"); > > Why do we need that debug output in this particular place? May be add some label or text field that shows the currently assumed number of items instead of relying on the system output stream? Also it would be great if there is a text somewhere which at least describes what is the purpose of the button and what is supposed to happen when you press it. If not in some designated area then at least as a tooltip on the button? I mean "Change item count" - to what? No mention of the delay so user has to either guess of why does it not change immediately or look the source code. good point, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184152929 From angorya at openjdk.org Wed May 3 19:40:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 19:40:28 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v4] In-Reply-To: References: Message-ID: <_iieA18bdVsyqyY_TxKluycBhpyn5KdBQGsRvrqxZcM=.c760eaeb-c1c3-4f8b-ac42-75a6a6820f79@github.com> On Tue, 2 May 2023 16:47:02 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bad commit The latest commit still completely breaks Monkey Tester layout when a scale other than 100% is used: The Monkey Tester uses SplitPanes, BorderPanes and VBox: ![Screenshot 2023-05-03 123236](https://user-images.githubusercontent.com/107069028/236027123-0184010e-3773-4f8a-9aca-715dd76af160.png) (a mirror as a standalone project has been moved to https://github.com/andy-goryachev-oracle/MonkeyTest ) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1533613792 From angorya at openjdk.org Wed May 3 19:45:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 19:45:21 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v4] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 16:47:02 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix bad commit even 200% breaks the layout. I wonder if this change requires HBox/VBox changes as well and therefore cannot be made separately from https://github.com/openjdk/jfx/pull/1111 as we expected earlier... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1533621856 PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1533627108 From mhanl at openjdk.org Wed May 3 20:18:35 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 20:18:35 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values Message-ID: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. ------------- Commit messages: - JDK-8307208: Add GridPane constructor that accepts hGap and vGap values Changes: https://git.openjdk.org/jfx/pull/1125/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307208 Stats: 25 lines in 2 files changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1125.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1125/head:pull/1125 PR: https://git.openjdk.org/jfx/pull/1125 From angorya at openjdk.org Wed May 3 20:26:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:26:28 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:13:42 GMT, Marius Hanl wrote: > This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. > As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. > In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. > > This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. minor change requested, otherwise looks good! modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 737: > 735: } > 736: > 737: /** we probably need to update the year `2011, 2023,` in the header ------------- Changes requested by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1411745023 PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184220421 From angorya at openjdk.org Wed May 3 20:26:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:26:29 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:22:57 GMT, Andy Goryachev wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 737: > >> 735: } >> 736: >> 737: /** > > we probably need to update the year `2011, 2023,` in the header also in the test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184220807 From angorya at openjdk.org Wed May 3 20:33:30 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:33:30 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: > Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. > > Feedback and suggestions are always welcome. > > ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1097/files - new: https://git.openjdk.org/jfx/pull/1097/files/e22a6b32..d9d6f2e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1097&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1097&range=16-17 Stats: 91 lines in 6 files changed: 67 ins; 14 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1097.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1097/head:pull/1097 PR: https://git.openjdk.org/jfx/pull/1097 From angorya at openjdk.org Wed May 3 20:33:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:33:33 GMT Subject: RFR: 8299335: Monkey Tester Application [v17] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:11:29 GMT, Alexander Zuev wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/AccordionPage.java line 61: > >> 59: >> 60: protected void addPane() { >> 61: String name = "" + System.currentTimeMillis(); > > Here and in other demos - can we use some sort of pronounceable generated names for new controls instead of hashes or timestamps? Especially testing accessibility for system to voice the numbers soup takes a long time because it spells it out digit by digit and it is hard to check if we get reading from the correct component because names are like 99% the same. Even "Pane 1".."Pane 99" would be more acceptable. changed to a global sequence number ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184225400 From nlisker at openjdk.org Wed May 3 20:37:28 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 May 2023 20:37:28 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:13:42 GMT, Marius Hanl wrote: > This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. > As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. > In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. > > This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. Look simple enough. `FlowPane` and `TilePane` have this constructor as well. modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 738: > 736: > 737: /** > 738: * Creates a GridPane layout with the given {@link #hgapProperty() hgap} and {@link #vgapProperty() vgap}. "GridPane" should be in `{@code}`. modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 741: > 739: * > 740: * @param hgap the width of the horizontal gaps between columns > 741: * @param vgap the height of the vertical gaps between rows I think that either "the width of the gaps between columns" or "the size of the horizontal gaps between columns" otherwise it gives the illusion that there is a height for the horizontal gap. Still reads fine as it is. ------------- PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1411752213 PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184225022 PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184229229 From nlisker at openjdk.org Wed May 3 20:37:30 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 May 2023 20:37:30 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> On Wed, 3 May 2023 20:23:19 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 737: >> >>> 735: } >>> 736: >>> 737: /** >> >> we probably need to update the year `2011, 2023,` in the header > > also in the test. There is a script that does this automatically. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184231019 From kizune at openjdk.org Wed May 3 20:39:26 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 3 May 2023 20:39:26 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:33:30 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Overall looks useful and will definitely help to manually test some global changes like control revamp or underlaying renderer works (like metal pipeline or potentially Wayland integration). ------------- Marked as reviewed by kizune (no project role). PR Review: https://git.openjdk.org/jfx/pull/1097#pullrequestreview-1411773286 From duke at openjdk.org Wed May 3 20:40:10 2023 From: duke at openjdk.org (buedi) Date: Wed, 3 May 2023 20:40:10 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() Message-ID: A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. A null check is needed on the node before calling node.getScene(). The error occurs occasionally and causes the application to crash. ------------- Commit messages: - Add null check to synchronizeSceneNodes() Changes: https://git.openjdk.org/jfx/pull/1123/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298104 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1123.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1123/head:pull/1123 PR: https://git.openjdk.org/jfx/pull/1123 From angorya at openjdk.org Wed May 3 20:49:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:49:29 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:13:42 GMT, Marius Hanl wrote: > This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. > As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. > In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. > > This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. Not related to these changes specifically, but why does GridPane adds a listener in the constructor getChildren().addListener((Observable o) -> requestLayout()); and VBox/HBox do not? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1125#issuecomment-1533725376 From kcr at openjdk.org Wed May 3 20:49:31 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 May 2023 20:49:31 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:33:30 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1097#pullrequestreview-1411815237 From kizune at openjdk.org Wed May 3 20:49:32 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 3 May 2023 20:49:32 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:33:30 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by kizune (no project role). ------------- PR Review: https://git.openjdk.org/jfx/pull/1097#pullrequestreview-1411820439 From kcr at openjdk.org Wed May 3 20:57:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 May 2023 20:57:26 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:46:49 GMT, Alexander Zuev wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > Marked as reviewed by kizune (no project role). Since @azuev-java has also approved, this is good to go in. Skara doesn't recognize it, so I'll manually fix it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1097#issuecomment-1533733147 From kizune at openjdk.org Wed May 3 20:57:28 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 3 May 2023 20:57:28 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: References: Message-ID: <4K2UgcVLcdL2RObQDN_HESbhcgqAt8oYRuGPB-2ub6U=.10d7041f-19dc-4cc5-b8db-ea4bb81fd554@github.com> On Wed, 3 May 2023 20:33:30 GMT, Andy Goryachev wrote: >> Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. >> >> Feedback and suggestions are always welcome. >> >> ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > address review comments tests/manual/monkey/src/com/oracle/tools/fx/monkey/MonkeyTesterApp.java line 194: > 192: StringBuilder sb = new StringBuilder(); > 193: sb.append(" "); > 194: sb.append(System.getProperty("javafx.runtime.version")); I would love to see more information in the status bar - especially if users will submit screenshots as a proof of the fact for bugs having additional information would be super nice. Already love the scale output, would love to see the current window size in either logical or physical pixels and a version of JVM in addition to the version of the JFX runtime - i think it might be even more important if we would add the JFX/Swing interoperability tests to this tool. If not in a status bar may be some sort of about menu that reports all the details about the environment such as reported OS version, number of displays, reported graphics mode with insets and such. And i think that might be an RFE for later version of the tool. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184230970 From angorya at openjdk.org Wed May 3 20:57:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:57:29 GMT Subject: RFR: 8299335: Monkey Tester Application [v18] In-Reply-To: <4K2UgcVLcdL2RObQDN_HESbhcgqAt8oYRuGPB-2ub6U=.10d7041f-19dc-4cc5-b8db-ea4bb81fd554@github.com> References: <4K2UgcVLcdL2RObQDN_HESbhcgqAt8oYRuGPB-2ub6U=.10d7041f-19dc-4cc5-b8db-ea4bb81fd554@github.com> Message-ID: On Wed, 3 May 2023 20:34:46 GMT, Alexander Zuev wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > tests/manual/monkey/src/com/oracle/tools/fx/monkey/MonkeyTesterApp.java line 194: > >> 192: StringBuilder sb = new StringBuilder(); >> 193: sb.append(" "); >> 194: sb.append(System.getProperty("javafx.runtime.version")); > > I would love to see more information in the status bar - especially if users will submit screenshots as a proof of the fact for bugs having additional information would be super nice. Already love the scale output, would love to see the current window size in either logical or physical pixels and a version of JVM in addition to the version of the JFX runtime - i think it might be even more important if we would add the JFX/Swing interoperability tests to this tool. If not in a status bar may be some sort of about menu that reports all the details about the environment such as reported OS version, number of displays, reported graphics mode with insets and such. And i think that might be an RFE for later version of the tool. thank you for suggestions! added to https://bugs.openjdk.org/browse/JDK-8307176 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1097#discussion_r1184250294 From angorya at openjdk.org Wed May 3 20:57:30 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 20:57:30 GMT Subject: Integrated: 8299335: Monkey Tester Application In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 20:12:01 GMT, Andy Goryachev wrote: > Monkey Tester - a JavaFX application designed to support manual ad-hoc testing of individual JavaFX controls. Unlike Ensemble, the goal of this application is to facilitate manual testing rather than demonstrate the capabilities of JavaFX. > > Feedback and suggestions are always welcome. > > ![screenshot](https://user-images.githubusercontent.com/107069028/232911797-3d02da68-ce11-419e-8f16-c2661b778f9c.png) This pull request has now been integrated. Changeset: 0a1fd6e0 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/0a1fd6e0705ccced541b14afad68aea24faea8df Stats: 7223 lines in 51 files changed: 7223 ins; 0 del; 0 mod 8299335: Monkey Tester Application Reviewed-by: kcr, kizune ------------- PR: https://git.openjdk.org/jfx/pull/1097 From mhanl at openjdk.org Wed May 3 21:00:21 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 21:00:21 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> Message-ID: On Wed, 3 May 2023 20:34:49 GMT, Nir Lisker wrote: >> also in the test. > > There is a script that does this automatically. I will change them in my next commit. Completely forgot about them. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184273354 From mhanl at openjdk.org Wed May 3 21:00:25 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 21:00:25 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:32:55 GMT, Nir Lisker wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 741: > >> 739: * >> 740: * @param hgap the width of the horizontal gaps between columns >> 741: * @param vgap the height of the vertical gaps between rows > > I think that either > "the width of the gaps between columns" or > "the size of the horizontal gaps between columns" > otherwise it gives the illusion that there is a height for the horizontal gap. > > Still reads fine as it is. I copied that mostly from the javadoc of `hgapProperty` and `vgapProperty`. Tbh I like `the size of the horizontal gaps between columns` more as well. But then we are not consistent with the javadoc of the property. I'm fine either way, just that was my intention. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184271144 From angorya at openjdk.org Wed May 3 21:08:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 21:08:19 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> Message-ID: On Wed, 3 May 2023 20:57:53 GMT, Marius Hanl wrote: >> There is a script that does this automatically. > > I will change them in my next commit. Completely forgot about them. :) I thought it's only in jdk, not jfx. @kevinrushforth could you confirm that? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184280648 From nlisker at openjdk.org Wed May 3 21:08:20 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 May 2023 21:08:20 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> Message-ID: On Wed, 3 May 2023 21:03:57 GMT, Andy Goryachev wrote: >> I will change them in my next commit. Completely forgot about them. :) > > I thought it's only in jdk, not jfx. @kevinrushforth could you confirm that? We use the script every release. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184282026 From nlisker at openjdk.org Wed May 3 21:08:22 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 May 2023 21:08:22 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:55:42 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/GridPane.java line 741: >> >>> 739: * >>> 740: * @param hgap the width of the horizontal gaps between columns >>> 741: * @param vgap the height of the vertical gaps between rows >> >> I think that either >> "the width of the gaps between columns" or >> "the size of the horizontal gaps between columns" >> otherwise it gives the illusion that there is a height for the horizontal gap. >> >> Still reads fine as it is. > > I copied that mostly from the javadoc of `hgapProperty` and `vgapProperty`. > Tbh I like `the size of the horizontal gaps between columns` more as well. But then we are not consistent with the javadoc of the property. I'm fine either way, just that was my intention. :) I prefer the better phrasing over the consistent one :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184282904 From mhanl at openjdk.org Wed May 3 21:14:23 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 21:14:23 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:46:16 GMT, Andy Goryachev wrote: > Not related to these changes specifically, but why does GridPane adds a listener in the constructor > > ``` > getChildren().addListener((Observable o) -> requestLayout()); > ``` > > and VBox/HBox do not? I don't think it is necessary. If you actually look at the `children` list it already takes care about layouting stuff and more. So requesting it here for every change seems wrong. But this should be tested carefully. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1125#issuecomment-1533754981 From mhanl at openjdk.org Wed May 3 21:22:10 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 21:22:10 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: > This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. > As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. > In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. > > This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8307208: Improve javadoc and change copyright year ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1125/files - new: https://git.openjdk.org/jfx/pull/1125/files/76d5be3f..570061a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1125&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1125&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1125.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1125/head:pull/1125 PR: https://git.openjdk.org/jfx/pull/1125 From angorya at openjdk.org Wed May 3 21:22:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 21:22:12 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 21:18:10 GMT, Marius Hanl wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8307208: Improve javadoc and change copyright year looking good ? ------------- Marked as reviewed by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1411871111 From angorya at openjdk.org Wed May 3 21:22:15 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 21:22:15 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: <16NLy996Y8VrshQvHwTxt84estmeFOgFQY_U64AvnIU=.4757e359-1db9-4551-93f5-ba90b47145a7@github.com> On Wed, 3 May 2023 21:11:11 GMT, Marius Hanl wrote: > I don't think it is necessary. If you actually look at the `children` list it already takes care about layouting stuff and more. So requesting it here for every change seems wrong. But this should be tested carefully. that's what I thought too. just to clarify, that was a question, not a change request. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1125#issuecomment-1533759567 From mhanl at openjdk.org Wed May 3 21:22:15 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 May 2023 21:22:15 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <16NLy996Y8VrshQvHwTxt84estmeFOgFQY_U64AvnIU=.4757e359-1db9-4551-93f5-ba90b47145a7@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> <16NLy996Y8VrshQvHwTxt84estmeFOgFQY_U64AvnIU=.4757e359-1db9-4551-93f5-ba90b47145a7@github.com> Message-ID: On Wed, 3 May 2023 21:15:11 GMT, Andy Goryachev wrote: > that's what I thought too. just to clarify, that was a question, not a change request. no problem, I asked myself the same. ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1125#issuecomment-1533762671 From angorya at openjdk.org Wed May 3 21:30:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 May 2023 21:30:28 GMT Subject: RFR: 8284542: Missing attribute for state of CheckBox in CheckBoxTreeItem In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 15:13:25 GMT, Ambarish Rapte wrote: > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 357: > 355: * @since 21 > 356: */ > 357: TOGGLE_STATE(Integer.class), Would a dedicated enum be a better choice here? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1184308252 From kcr at openjdk.org Wed May 3 21:52:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 May 2023 21:52:19 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> <8s3JZ25AGKCT2VmFRxUBk1-Pk4qv5L4DFdIUFngoXKY=.46eadb09-b07c-4ff3-9e10-ae0a9b21b461@github.com> Message-ID: On Wed, 3 May 2023 21:05:15 GMT, Nir Lisker wrote: >> I thought it's only in jdk, not jfx. @kevinrushforth could you confirm that? > > We use the script every release. Yes, we run a copyright update script a couple times a release, so I don't bother updating the copyright year for existing files. It will get picked up soon enough. If you do want to update them, no one will object, but it's optional. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1125#discussion_r1184324982 From nlisker at openjdk.org Wed May 3 22:56:18 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 3 May 2023 22:56:18 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: <5Hfvnwz2fI5cL63J5G38qprh6u3GEJ4gCrKWWfKAHAc=.e8aae65f-ea70-4a30-ba65-b46280ba010f@github.com> On Wed, 3 May 2023 21:22:10 GMT, Marius Hanl wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8307208: Improve javadoc and change copyright year You can create a CSR, Kevin will need to review it. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1412014070 From almatvee at openjdk.org Wed May 3 23:25:20 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 May 2023 23:25:20 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 05:53:34 GMT, Michael Strau? wrote: >> - Added missing exception checks for JNI calls. >> - Improved JNI error checking by checking for both exception and return value. >> - Minor code clean up. > > modules/javafx.media/src/main/native/jfxmedia/jni/Logger.cpp line 130: > >> 128: // Get global reference >> 129: m_cls = (jclass)pEnv->NewWeakGlobalRef(local_cls); >> 130: pEnv->DeleteLocalRef(local_cls); > > What is this code attempting to do? After `local_cls` is deleted, `m_cls` refers to a potentially freed object and is thus not safe to use. In order to do anything meaningful with `m_cls`, a strong reference needs to be acquired with `NewLocalRef(m_cls)`. I think it should be fine to use `NewWeakGlobalRef`. `NewLocalRef` will make reference which is valid only for duration of `CLogger::init` and we using `m_cls` in `CLogger::logMsg` as well. I think you mean `NewGlobalRef`, but in this case there is no way to call `DeleteGlobalRef`, since CLogger instance is static global variable which gets deleted only when native media library gets unloaded and by this time JVM will be shutting down. Java Logger class referenced by m_cls should not be freed, since it contains only static methods and fields, until our native code unloads. So, using weak reference should be fine in this case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1184395328 From lkostyra at openjdk.org Thu May 4 08:21:15 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 4 May 2023 08:21:15 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4] In-Reply-To: References: Message-ID: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Update javafx.web classpath to include JMemoryBuddy ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/0b8b058f..5ea23cf9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From lkostyra at openjdk.org Thu May 4 08:21:17 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 4 May 2023 08:21:17 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v3] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 09:20:14 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Minor review updates > > * Changed ArrayList<> to Collection<> in one of assertCollectable-s > * Updated LeakTest to use new assertCollectable helpers Done, thanks for checking! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1534275671 From jhendrikx at openjdk.org Thu May 4 09:46:28 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 09:46:28 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: > Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: > > ceil(x) = ceil(ceil(x)) > > However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. > > The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). > > The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. > > Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix NaN returns when using Math.ulp ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1118/files - new: https://git.openjdk.org/jfx/pull/1118/files/2cfbb8a0..11e650b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=03-04 Stats: 288 lines in 5 files changed: 233 ins; 44 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1118.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1118/head:pull/1118 PR: https://git.openjdk.org/jfx/pull/1118 From jhendrikx at openjdk.org Thu May 4 09:49:31 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 09:49:31 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 09:46:28 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix NaN returns when using Math.ulp > I wonder if this change requires HBox/VBox changes as well and therefore cannot be made separately from #1111 as we expected earlier... @andy-goryachev-oracle thanks for testing this (again). I think it was important to track down the root cause here, so I put some time in tracking this down. Turns out it is a real bug introduced with this tiny code change. The problem was that `Math.ulp` will return infinity when given an infinity, and when you then use that in a subtraction, the result is `Double.NaN` -- this caused controls to go a bit crazy :) I've moved the math functions to a new class to make them easier to test, but also added an extra test case that uses `Region` directly, just in case. I've confirmed the Monkey Tester works now, so if you could take a look one more time :-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1534433754 From jhendrikx at openjdk.org Thu May 4 09:55:28 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 09:55:28 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: <2tNLTcMMx7iNr7bZh3dirkeNS77vRFjvTBp60_enipE=.a015dc4d-5ae8-4fda-9301-461c42a1e74a@github.com> On Thu, 27 Apr 2023 15:23:33 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix NaN returns when using Math.ulp > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 310: > >> 308: private static double scaledFloor(double value, double scale) { >> 309: double d = value * scale; >> 310: > > could we get rid of this newline - here and on lines 330, 413 please? It's the style I use, I tend to separate assignment, declaration and other code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1184800203 From jhendrikx at openjdk.org Thu May 4 10:01:25 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 10:01:25 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 21:22:10 GMT, Marius Hanl wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8307208: Improve javadoc and change copyright year Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1412758633 From lkostyra at openjdk.org Thu May 4 10:20:24 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 4 May 2023 10:20:24 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:17:52 GMT, John Hendrikx wrote: > Focused only on raw type problems, and removing casts that were no longer needed because of the changes. Patch seems okay for me, I also run it on Windows and macOS and tests are all good. I left a minor comment about some leftover imports which could be cleared. modules/javafx.graphics/src/main/java/com/sun/prism/es2/GLFactory.java line 32: > 30: import java.security.AccessController; > 31: import java.security.PrivilegedAction; > 32: import java.util.HashMap; I think this import can be removed now. Also check derivatives (aka. other `GLFactory`-ies extending this one) ------------- PR Review: https://git.openjdk.org/jfx/pull/1095#pullrequestreview-1412765069 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1184811230 From jhendrikx at openjdk.org Thu May 4 10:49:26 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 10:49:26 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: <-zD45dQ8V6CyUXEBfPR8HViGDVJIoMhQGQuvznfbmuY=.955de435-61d8-4d78-a9fa-b1c71258581e@github.com> On Wed, 3 May 2023 11:46:50 GMT, buedi wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. Hi @buedi, I've taken a look at this, but would like to know the root cause. I get the impression that this happens a lot for you, could you share when this happens so I can reproduce this as well? You could also try this code and report back if you get any of the exceptions I added: private void synchronizeSceneNodes() { Toolkit.getToolkit().checkFxUserThread(); Scene.inSynchronizer = true; // if dirtyNodes is null then that means this Scene has not yet been // synchronized, and so we will simply synchronize every node in the // scene and then create the dirty nodes array list if (Scene.this.dirtyNodes == null) { // must do this recursively syncAll(getRoot()); dirtyNodes = new Node[MIN_DIRTY_CAPACITY]; } else { if (peer == null) { throw new IllegalStateException("peer shouldn't be null here: " + dirtyNodesSize); } // This is not the first time this scene has been synchronized, // so we will only synchronize those nodes that need it for (int i = 0 ; i < dirtyNodesSize; ++i) { try { Node node = dirtyNodes[i]; dirtyNodes[i] = null; if (node.getScene() == Scene.this) { node.syncPeer(); } } catch (Throwable e) { throw new IllegalStateException("exception will break dirtyNodes!", e); } } dirtyNodesSize = 0; } if (!Scene.inSynchronizer) { throw new IllegalStateException("Synchronizer flag was reset, reentrant call?"); } Scene.inSynchronizer = false; } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1534538130 From duke at openjdk.org Thu May 4 12:14:23 2023 From: duke at openjdk.org (buedi) Date: Thu, 4 May 2023 12:14:23 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:46:50 GMT, buedi wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. Hello John, this issue occurs very rarely, approximately 1-2 times per month, on systems that run 24/7. However, when it does occur, the JavaFx application gets stuck in an endless loop (--> [logError-JavaFxScene.txt](https://github.com/openjdk/jfx/files/11397119/logError-JavaFxScene.txt)) and cannot recover from it. Currently, I am unable to replicate this phenomenon. I fully agree with you that it's essential to address the problem at its root cause. However, adding an additional check for a null value would at least solve a rare but blocking issue. ![sceneError_](https://user-images.githubusercontent.com/5691507/236197639-8c240ed2-d135-4abc-9a29-5d1cfa3e0984.png) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1534664290 From kcr at openjdk.org Thu May 4 12:20:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 May 2023 12:20:24 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4] In-Reply-To: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> References: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> Message-ID: On Thu, 4 May 2023 08:21:15 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Update javafx.web classpath to include JMemoryBuddy The changes generally look good, although I left a comment about sleeping on the EDT. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 95: > 93: } > 94: > 95: public static void assertCollectable(WeakReference[] weakReferences) { Can you add javadoc comments? tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: > 78: }); > 79: > 80: SwingUtilities.invokeAndWait(() -> Util.sleep(500)); Sleeping on either the JavaFX Application thread or the Swing EDT (as in this case) is not generally desirable. What is the sleep trying to achieve? Is there a better way, possibly sleeping on the test thread and then doing a `SwingUtilities.invokeAndWait` (maybe with a no-op runnable? not sure)?. ------------- PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1412937420 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1184918401 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1184923206 From duke at openjdk.org Thu May 4 14:55:29 2023 From: duke at openjdk.org (duke) Date: Thu, 4 May 2023 14:55:29 GMT Subject: Withdrawn: 8299348: Size-restricted window can be observed with incorrect dimensions In-Reply-To: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: On Mon, 26 Dec 2022 03:03:50 GMT, Michael Strau? wrote: > On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. > > Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/984 From jhendrikx at openjdk.org Thu May 4 15:17:24 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 4 May 2023 15:17:24 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 12:11:13 GMT, buedi wrote: > Hello John, this issue occurs very rarely, approximately 1-2 times per month, on systems that run 24/7. However, when it does occur, the JavaFx application gets stuck in an endless loop (--> [logError-JavaFxScene.txt](https://github.com/openjdk/jfx/files/11397119/logError-JavaFxScene.txt)) and cannot recover from it. Currently, I am unable to replicate this phenomenon. I fully agree with you that it's essential to address the problem at its root cause. However, adding an additional check for a null value would at least solve a rare but blocking issue. > > ![sceneError_](https://user-images.githubusercontent.com/5691507/236197639-8c240ed2-d135-4abc-9a29-5d1cfa3e0984.png) The problem is, this kind of fix is unlikely to be accepted as it hides the root cause of perhaps a much more serious issue. Skipping `null`s for example will mean that some nodes probably didn't get synced in the last run due to an exception or some other kind of bug in the code (I was looking at Node reuse as a possible cause for this problem). The NPE you show is probably not the first exception that is logged, but the one that is most visible because it keeps being repeated once the dirty nodes list gets into a bad state. You said you already fixed this yourself, would you be willing to add diagnostics to your build that you could share so the root cause can be tracked down? A few log lines when a bad state is detected that could give us insights into what went wrong could go a long way. I will take another look tonight to see if I can find how this list is getting corrupted; most likely it is an exception thrown by `syncPeer`; if that could be caught and logged it will probably tell us the rest of the story. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1534960245 From angorya at openjdk.org Thu May 4 15:28:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 May 2023 15:28:24 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 09:47:02 GMT, John Hendrikx wrote: > I think it was important to track down the root cause here You are so right! I'll try to take a look today. Without looking at the code, could we add a test (unless already done) which exercise all the possible corner cases with Double - NaN, Infinities, 0, ulp, 1, ...? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1118#issuecomment-1534980841 From angorya at openjdk.org Thu May 4 15:33:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 May 2023 15:33:29 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4] In-Reply-To: References: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> Message-ID: On Thu, 4 May 2023 12:05:45 GMT, Kevin Rushforth wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Update javafx.web classpath to include JMemoryBuddy > > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: > >> 78: }); >> 79: >> 80: SwingUtilities.invokeAndWait(() -> Util.sleep(500)); > > Sleeping on either the JavaFX Application thread or the Swing EDT (as in this case) is not generally desirable. What is the sleep trying to achieve? Is there a better way, possibly sleeping on the test thread and then doing a `SwingUtilities.invokeAndWait` (maybe with a no-op runnable? not sure)?. I can't believe I missed that! I wonder if we could use CountDownLatch instead here and use Util.await(CountDownLatch) or something like that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1185197255 From duke at openjdk.org Thu May 4 17:23:34 2023 From: duke at openjdk.org (Martin Fox) Date: Thu, 4 May 2023 17:23:34 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient Message-ID: Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. ------------- Commit messages: - Migrating Windows to new Toolkit.getKeyCanGenerateCharacter call Changes: https://git.openjdk.org/jfx/pull/1126/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8089373 Stats: 1120 lines in 18 files changed: 1061 ins; 4 del; 55 mod Patch: https://git.openjdk.org/jfx/pull/1126.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1126/head:pull/1126 PR: https://git.openjdk.org/jfx/pull/1126 From mstrauss at openjdk.org Thu May 4 18:35:22 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 4 May 2023 18:35:22 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 12:17:53 GMT, John Hendrikx wrote: >> Fix bug in CSS caching code that could reset values on unrelated nodes. >> >> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. > > John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug > - Fix typo > - Fix bug in CSS caching code that could reset values on unrelated nodes > > The bug occurs due to a cache entry being constructed incorrectly when > the initial node that triggered the cache entry creation has user set > values. The calculated values for properties with a user set value were > omitted in the cache entry, and other nodes that later share the same > entry would incorrectly assume the omitted property was unstyled and > were therefore reset to their default values. Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1072#pullrequestreview-1413695522 From angorya at openjdk.org Thu May 4 22:30:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 May 2023 22:30:21 GMT Subject: RFR: 8307363: TextFlow.underlineShape() Message-ID: Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using getRange(start, end, TextLayout.TYPE_UNDERLINE); which mirrors an existing method in Text with exactly the same signature. ------------- Commit messages: - use the same javadoc as in Text - whitespace - 8307363: text flow underline shape Changes: https://git.openjdk.org/jfx/pull/1127/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307363 Stats: 63 lines in 2 files changed: 52 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1127.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1127/head:pull/1127 PR: https://git.openjdk.org/jfx/pull/1127 From angorya at openjdk.org Thu May 4 23:41:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 4 May 2023 23:41:24 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 09:46:28 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix NaN returns when using Math.ulp This version does not seem to crash the Monkey Tester, both VBox and HBox continue to work. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 1: > 1: package com.sun.javafx.scene.layout; please add a standard header modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 18: > 16: * larger integers with exact precision beyond this limit. > 17: * > 18: * @param value The value that needs to be floored is this method only for positive values? modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 46: > 44: * @return value ceiled with scale > 45: */ > 46: public static double ceil(double value, double scale) { same comment about negative values modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest.java line 1356: > 1354: // test snapPortionX/snapPortionY methods > 1355: > 1356: random.setSeed(seed); I still think we need to remove setSeed() here and below. ------------- PR Review: https://git.openjdk.org/jfx/pull/1118#pullrequestreview-1414035195 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185593563 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185594018 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185594187 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185595181 From lkostyra at openjdk.org Fri May 5 06:33:24 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 06:33:24 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4] In-Reply-To: References: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> Message-ID: On Thu, 4 May 2023 15:30:20 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: >> >>> 78: }); >>> 79: >>> 80: SwingUtilities.invokeAndWait(() -> Util.sleep(500)); >> >> Sleeping on either the JavaFX Application thread or the Swing EDT (as in this case) is not generally desirable. What is the sleep trying to achieve? Is there a better way, possibly sleeping on the test thread and then doing a `SwingUtilities.invokeAndWait` (maybe with a no-op runnable? not sure)?. > > I can't believe I missed that! > I wonder if we could use CountDownLatch instead here and use Util.await(CountDownLatch) or something like that. This is something that came from the original patch - I'm no Swing expert so I originally figured I should leave it here. My only guess was that it (among other `Thread.sleep()`-s in this patch) is trying to let the other threads run for a bit and chew through the resources to make sure they're collectable. Upon closer inspection it looks like JMemoryBuddy is already doing those sleeps, so I'll remove them - tests should work fine without those. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1185739169 From jhendrikx at openjdk.org Fri May 5 07:57:25 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 07:57:25 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:46:50 GMT, buedi wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. I've looked a bit through the JavaFX bugs, and I noticed that many problems involving `synchronizeSceneNodes` are caused by modifying the SceneGraph outside the FX thread which would sometimes throw `ConcurrentModificationException`. As you see this problem only occasionally, it's a pretty good fit. It might be worthwhile to check your logs for such an exception (or similar, like `IndexOutOfBoundsException`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1535874797 From jhendrikx at openjdk.org Fri May 5 08:00:26 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 08:00:26 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 12:17:53 GMT, John Hendrikx wrote: >> Fix bug in CSS caching code that could reset values on unrelated nodes. >> >> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. > > John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug > - Fix typo > - Fix bug in CSS caching code that could reset values on unrelated nodes > > The bug occurs due to a cache entry being constructed incorrectly when > the initial node that triggered the cache entry creation has user set > values. The calculated values for properties with a user set value were > omitted in the cache entry, and other nodes that later share the same > entry would incorrectly assume the omitted property was unstyled and > were therefore reset to their default values. @arapte can you take a look, it's a bug fix ------------- PR Comment: https://git.openjdk.org/jfx/pull/1072#issuecomment-1535877796 From jhendrikx at openjdk.org Fri May 5 08:02:24 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 08:02:24 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v5] In-Reply-To: References: Message-ID: <2pu8LoF_8NjN5zIPIu02mMtar0yXoVY5qMgQHXGNI0c=.24f26fed-bce0-4feb-91f1-64d7927da3b7@github.com> On Thu, 4 May 2023 23:16:38 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix NaN returns when using Math.ulp > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 18: > >> 16: * larger integers with exact precision beyond this limit. >> 17: * >> 18: * @param value The value that needs to be floored > > is this method only for positive values? No, it can be used for any value. > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/ScaledMath.java line 46: > >> 44: * @return value ceiled with scale >> 45: */ >> 46: public static double ceil(double value, double scale) { > > same comment about negative values No, it can be used for any value. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185803401 PR Review Comment: https://git.openjdk.org/jfx/pull/1118#discussion_r1185803588 From jhendrikx at openjdk.org Fri May 5 08:08:30 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 08:08:30 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v6] In-Reply-To: References: Message-ID: <484iszAUIMqb6-eJomeXxVSuEQhw_bnd57fKoPqBCOg=.3714c74f-2e43-4759-b485-3db0c878b06c@github.com> > Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: > > ceil(x) = ceil(ceil(x)) > > However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. > > The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). > > The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. > > Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: - Remove seed - Add test cases for negative values - Add copyright headers ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1118/files - new: https://git.openjdk.org/jfx/pull/1118/files/11e650b5..d6c3a3a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1118&range=04-05 Stats: 77 lines in 3 files changed: 69 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1118.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1118/head:pull/1118 PR: https://git.openjdk.org/jfx/pull/1118 From duke at openjdk.org Fri May 5 08:48:35 2023 From: duke at openjdk.org (buedi) Date: Fri, 5 May 2023 08:48:35 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:46:50 GMT, buedi wrote: > A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. > A null check is needed on the node before calling node.getScene(). > > The error occurs occasionally and causes the application to crash. Hi John, thank you for this information. I couldn't find any instances of `ConcurrentModificationException`, but about an hour ago before the NPE, we did have an `IllegalStateException`. Could this be the cause of the issue? ![image](https://user-images.githubusercontent.com/5691507/236412428-2279c9ff-8918-4054-bbaa-a3ec292018c9.png) Two weeks ago, we fixed the issue by implementing a check to see if the dialog header was being called from a JavaFX thread. ![image](https://user-images.githubusercontent.com/5691507/236413193-a85133c6-273a-4fb4-9fd7-c9c651790697.png) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1535930576 From jhendrikx at openjdk.org Fri May 5 09:08:23 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 09:08:23 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Fri, 5 May 2023 08:46:03 GMT, Daniel wrote: > Hi John, thank you for this information. I couldn't find any instances of `ConcurrentModificationException`, but about an hour ago before the NPE, we did have an `IllegalStateException`. No, I don't think that is it. The check there prevented things from going wrong, and only alerted you that you were about to manipulate the SceneGraph on the wrong thread. These checks are not everywhere though, so there are many places where you can still change the SceneGraph without being alerted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-1535956787 From lkostyra at openjdk.org Fri May 5 10:37:23 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 10:37:23 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v5] In-Reply-To: References: Message-ID: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: - JMemoryBuddy: Add javadoc comments - Remove thread sleeps before JMemoryBuddy calls JMemoryBuddy performs sleeps to check if objects are collectable by itself, there is no reason to do those. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/5ea23cf9..492d670d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=03-04 Stats: 18 lines in 3 files changed: 13 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From lkostyra at openjdk.org Fri May 5 10:37:25 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 10:37:25 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v4] In-Reply-To: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> References: <4r0Vw3o-ZM3ev0SkB34RfYsFSJwHHAd9pSTDOz0yKw0=.f7005e84-3a02-461d-bea0-728a665e5d4f@github.com> Message-ID: <_RE6_0Th8szjtI237h47Ba2XHsPOzNCGcZSbrm29wQU=.0bcfd514-62a3-48c8-b716-6b4a85df3131@github.com> On Thu, 4 May 2023 08:21:15 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Update javafx.web classpath to include JMemoryBuddy I removed the sleeps, ran the test multiple times on all platforms and didn't notice any abnormalities. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1536056184 From kcr at openjdk.org Fri May 5 11:46:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 11:46:23 GMT Subject: RFR: 8307208: Add GridPane constructor that accepts hGap and vGap values [v2] In-Reply-To: References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 21:22:10 GMT, Marius Hanl wrote: >> This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. >> As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. >> In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. >> >> This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8307208: Improve javadoc and change copyright year Looks good. I reviewed the CSR, so you can Finalize it now. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1125#pullrequestreview-1414634331 From kcr at openjdk.org Fri May 5 12:30:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 12:30:21 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v5] In-Reply-To: References: Message-ID: <9-K1RnbXelDpVyhrN4qR2Rq-vbp9o1n8h5Fb1cLeL4A=.fce3d4f4-ef23-4ec9-bd56-c5935c3f6887@github.com> On Fri, 5 May 2023 10:37:23 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: > > - JMemoryBuddy: Add javadoc comments > - Remove thread sleeps before JMemoryBuddy calls > > JMemoryBuddy performs sleeps to check if objects are collectable by > itself, there is no reason to do those. I saw a one-time failure that suggests waiting for the EDT to run something, and possibly a sleep, might still be needed. tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: > 78: }); > 79: > 80: JMemoryBuddy.assertCollectable(weakRefArrSN); On my Mac (MacBook Pro x64 running macOS 13.2.1) I saw a one-time test failure here. So there might be a need to wait for the EDT to at least do something, possibly followed by a sleep (on the test thread, not on the EDT). ------------- PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1414685123 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186027809 From lkostyra at openjdk.org Fri May 5 12:43:30 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 12:43:30 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v5] In-Reply-To: <9-K1RnbXelDpVyhrN4qR2Rq-vbp9o1n8h5Fb1cLeL4A=.fce3d4f4-ef23-4ec9-bd56-c5935c3f6887@github.com> References: <9-K1RnbXelDpVyhrN4qR2Rq-vbp9o1n8h5Fb1cLeL4A=.fce3d4f4-ef23-4ec9-bd56-c5935c3f6887@github.com> Message-ID: <8ar79b3ZjEDXpo0ZIfODQ54WPEfMadza7EZh2p24IBg=.0951b2ce-813c-400e-9837-61029f4554a4@github.com> On Fri, 5 May 2023 12:22:03 GMT, Kevin Rushforth wrote: >> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: >> >> - JMemoryBuddy: Add javadoc comments >> - Remove thread sleeps before JMemoryBuddy calls >> >> JMemoryBuddy performs sleeps to check if objects are collectable by >> itself, there is no reason to do those. > > tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: > >> 78: }); >> 79: >> 80: JMemoryBuddy.assertCollectable(weakRefArrSN); > > On my Mac (MacBook Pro x64 running macOS 13.2.1) I saw a one-time test failure here. So there might be a need to wait for the EDT to at least do something, possibly followed by a sleep (on the test thread, not on the EDT). Interesting, I will add a `runAndWait()` noop and a test thread sleep then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186045625 From kcr at openjdk.org Fri May 5 13:06:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 13:06:28 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v5] In-Reply-To: <8ar79b3ZjEDXpo0ZIfODQ54WPEfMadza7EZh2p24IBg=.0951b2ce-813c-400e-9837-61029f4554a4@github.com> References: <9-K1RnbXelDpVyhrN4qR2Rq-vbp9o1n8h5Fb1cLeL4A=.fce3d4f4-ef23-4ec9-bd56-c5935c3f6887@github.com> <8ar79b3ZjEDXpo0ZIfODQ54WPEfMadza7EZh2p24IBg=.0951b2ce-813c-400e-9837-61029f4554a4@github.com> Message-ID: On Fri, 5 May 2023 12:41:03 GMT, Lukasz Kostyra wrote: >> tests/system/src/test/java/test/javafx/embed/swing/SwingNodeMemoryLeakTest.java line 80: >> >>> 78: }); >>> 79: >>> 80: JMemoryBuddy.assertCollectable(weakRefArrSN); >> >> On my Mac (MacBook Pro x64 running macOS 13.2.1) I saw a one-time test failure here. So there might be a need to wait for the EDT to at least do something, possibly followed by a sleep (on the test thread, not on the EDT). > > Interesting, I will add a `runAndWait()` noop and a test thread sleep then. I think you mean `SwingUtilities::invokeAndWait`, right? Btw, I also got a similar one-time failure in `SwingNodeDnDMemoryLeakTest`, so perhaps the same could be added there? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186070622 From lkostyra at openjdk.org Fri May 5 13:40:39 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 13:40:39 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v6] In-Reply-To: References: Message-ID: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Add an EDT no-op and sleep for a bit On some platforms Swing memory leak tests occasionally failed, this might help to mitigate this problem. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/492d670d..1230c8b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=04-05 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From lkostyra at openjdk.org Fri May 5 13:48:25 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 13:48:25 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v5] In-Reply-To: References: <9-K1RnbXelDpVyhrN4qR2Rq-vbp9o1n8h5Fb1cLeL4A=.fce3d4f4-ef23-4ec9-bd56-c5935c3f6887@github.com> <8ar79b3ZjEDXpo0ZIfODQ54WPEfMadza7EZh2p24IBg=.0951b2ce-813c-400e-9837-61029f4554a4@github.com> Message-ID: On Fri, 5 May 2023 13:03:35 GMT, Kevin Rushforth wrote: >> Interesting, I will add a `runAndWait()` noop and a test thread sleep then. > > I think you mean `SwingUtilities::invokeAndWait`, right? > > Btw, I also got a similar one-time failure in `SwingNodeDnDMemoryLeakTest`, so perhaps the same could be added there? Yes, I meant `invokeAndWait`. A force of habit from using our `Util` class... I also added it to `SwingNodeDnDMemoryLeakTest` just to be sure. After a few runs it works fine on my end (but also, it did earlier so I can't really fully test it). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186115826 From kcr at openjdk.org Fri May 5 14:00:30 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 14:00:30 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v6] In-Reply-To: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> References: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> Message-ID: On Fri, 5 May 2023 13:40:39 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Add an EDT no-op and sleep for a bit > > On some platforms Swing memory leak tests occasionally failed, this > might help to mitigate this problem. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1414849053 From lkostyra at openjdk.org Fri May 5 15:16:25 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 May 2023 15:16:25 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v3] In-Reply-To: <0izA_ihL0kd6T4fp4jfMyamD93t9icK-NM30SuyfLC4=.479e99fb-141c-473c-80c7-4a9e1c9efdc3@github.com> References: <0izA_ihL0kd6T4fp4jfMyamD93t9icK-NM30SuyfLC4=.479e99fb-141c-473c-80c7-4a9e1c9efdc3@github.com> Message-ID: On Wed, 3 May 2023 18:15:34 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor review updates >> >> * Changed ArrayList<> to Collection<> in one of assertCollectable-s >> * Updated LeakTest to use new assertCollectable helpers > > The changes look good! > Unfortunately, the project won't build in Eclipse due to > > `The type test.util.memory.JMemoryBuddy is not accessible LeakTest.java /web/src/test/java/test/javafx/scene/web` > > To fix that, could you please modify line 45 of modules/web/.classpath file to this (er, better include the whole file): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @andy-goryachev-oracle I'll wait for your last look at it before I integrate it ------------- PR Comment: https://git.openjdk.org/jfx/pull/1121#issuecomment-1536408063 From fweimer at openjdk.org Fri May 5 16:02:36 2023 From: fweimer at openjdk.org (Florian Weimer) Date: Fri, 5 May 2023 16:02:36 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments Message-ID: Related to: * https://fedoraproject.org/wiki/Changes/PortingToModernC * https://fedoraproject.org/wiki/Toolchain/PortingToModernC ------------- Commit messages: - 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments Changes: https://git.openjdk.org/jfx/pull/1128/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307542 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1128.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1128/head:pull/1128 PR: https://git.openjdk.org/jfx/pull/1128 From kcr at openjdk.org Fri May 5 16:19:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 16:19:26 GMT Subject: RFR: 8307542: Call to FcConfigAppFontAddFile uses wrong prototype, arguments In-Reply-To: References: Message-ID: On Fri, 5 May 2023 15:56:40 GMT, Florian Weimer wrote: > Related to: > > * https://fedoraproject.org/wiki/Changes/PortingToModernC > * https://fedoraproject.org/wiki/Toolchain/PortingToModernC @prrace Can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1128#issuecomment-1536483735 From angorya at openjdk.org Fri May 5 16:23:26 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 May 2023 16:23:26 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v6] In-Reply-To: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> References: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> Message-ID: On Fri, 5 May 2023 13:40:39 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Add an EDT no-op and sleep for a bit > > On some platforms Swing memory leak tests occasionally failed, this > might help to mitigate this problem. minor javadoc changes, I'll re-approve if you want to make them. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 96: > 94: > 95: /** > 96: * Checks whether an array of WeakReference objects can be collected. I think it should rather say something like "whether content of all references in the array", rather than array itself. modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 106: > 104: > 105: /** > 106: * Checks whether a Collection of WeakReference objects can be collected. same comment: "content of all references in a collection" modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 116: > 114: > 115: /** > 116: * Checks whether provided WeakReference objects can be collected. same comment: "content of references..." ------------- Marked as reviewed by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1415078517 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186274440 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186274647 PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1186277880 From mstrauss at openjdk.org Fri May 5 16:38:18 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 5 May 2023 16:38:18 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: <529YSbkPZY0-aVAigRPCuWPxZjtDNEW_D60pBakxP8o=.46c28694-5132-4190-a9aa-00652bcc6f06@github.com> On Thu, 4 May 2023 17:18:21 GMT, Martin Fox wrote: > Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. I'm not quite sold on having `notifyKey` and `notifyKeyEx` be two separate methods. Why not just have one? Not changing the existing call sites doesn't seem to be a sufficient reason to expand the toolkit API surface. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1536503360 From kcr at openjdk.org Fri May 5 16:47:45 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 5 May 2023 16:47:45 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Thu, 4 May 2023 17:18:21 GMT, Martin Fox wrote: > Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. This will need careful review and lots of testing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1536515060 From angorya at openjdk.org Fri May 5 18:11:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 May 2023 18:11:21 GMT Subject: RFR: JDK-8306990: The guarantees given by Region's floor and ceiling functions should work for larger values [v6] In-Reply-To: <484iszAUIMqb6-eJomeXxVSuEQhw_bnd57fKoPqBCOg=.3714c74f-2e43-4759-b485-3db0c878b06c@github.com> References: <484iszAUIMqb6-eJomeXxVSuEQhw_bnd57fKoPqBCOg=.3714c74f-2e43-4759-b485-3db0c878b06c@github.com> Message-ID: On Fri, 5 May 2023 08:08:30 GMT, John Hendrikx wrote: >> Region has floor and ceiling functions that ensure that calling them twice in a row will yield the same result: >> >> ceil(x) = ceil(ceil(x)) >> >> However, due to use of a constant `EPSILON` which is added/subtracted before doing the rounding, this only works for small numbers (in the range of 0-50 approximately). For larger values and scales, rounding errors can easily occur. This is visible as artifacts on screen where controls are a pixel wider than they should be. >> >> The use of the `EPSILON` constant is incorrect, as its value depends on the magnitude of the value in question (as magnitude increases, the fractional precision decreases). >> >> The Math class offers the function `ulp` that should be used here. It represents the smallest possible change in value for a given double. >> >> Extending the existing test case `snappingASnappedValueGivesTheSameValueTest` to use larger magnitude numbers exposes the problems. > > John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: > > - Remove seed > - Add test cases for negative values > - Add copyright headers LGTM, thanks! ------------- Marked as reviewed by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1118#pullrequestreview-1415236012 From duke at openjdk.org Fri May 5 19:41:18 2023 From: duke at openjdk.org (Martin Fox) Date: Fri, 5 May 2023 19:41:18 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: <529YSbkPZY0-aVAigRPCuWPxZjtDNEW_D60pBakxP8o=.46c28694-5132-4190-a9aa-00652bcc6f06@github.com> References: <529YSbkPZY0-aVAigRPCuWPxZjtDNEW_D60pBakxP8o=.46c28694-5132-4190-a9aa-00652bcc6f06@github.com> Message-ID: On Fri, 5 May 2023 16:35:38 GMT, Michael Strau? wrote: > I'm not quite sold on having `notifyKey` and `notifyKeyEx` be two separate methods. Why not just have one? Not changing the existing call sites doesn't seem to be a sufficient reason to expand the toolkit API surface. The long term goal is to have one method. Eventually the Mac and Linux platforms will transition over, PR #694 has already been entered for Linux and bugs like [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863) require the new method on the Mac. Once the transition is done I'll enter a bug to remove the old method and rename the new one. I thought it would be easiest to review and test one platform at a time so I kept `notifyView` around as a compatibility method. It just calls into `notifyViewEx` with a `hardwareCode` of -1. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1536693719 From jhendrikx at openjdk.org Fri May 5 20:18:25 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 20:18:25 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Thu, 4 May 2023 17:18:21 GMT, Martin Fox wrote: > Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. Not entirely sure it is good to have a hidden variable in `KeyEvent`, but looks good other than that. modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java line 382: > 380: // This platform has migrated to getKeyCanGenerateCharacter > 381: // so getKeyCodeForChar will no longer be called. > 382: return 0; If you are sure it is never called, then how about going all in and throwing an exception here? Currently it just returns an incorrect result. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java line 68: > 66: * > 67: * @param keyEvent The key event > 68: * @return true iff the event was consumed Suggestion: * @return {@code true} if the event was consumed modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 709: > 707: * The default implementation bridges into the existing getKeyCodeForChar call. > 708: */ > 709: public boolean getKeyCanGenerateCharacter(KeyEvent event, String character) { I think this method can be narrowed a bit to accept a `KeyCode` instead of `KeyEvent`, making it bit more generally useful (and easier to test). Also I think perhaps it can be named a bit more direct, like `canKeyGenerateCharacter`. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java line 169: > 167: WindowStage stage = scene.getWindowStage(); > 168: Boolean consumed = Boolean.FALSE; > 169: Consider not defining this variable, and just returning directly when a result has been determined. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2183: > 2181: > 2182: /** > 2183: * @return true iff the event was consumed Suggestion: * @return {@code true} if the event was consumed modules/javafx.graphics/src/main/java/javafx/scene/input/KeyEvent.java line 388: > 386: * The hardware key code which is private to the implementation. > 387: */ > 388: private int hardwareCode; Does it need to be private? Events are public, and I think it should be possible to make your own events that act exactly like an event created by the system, which would preclude hidden variables. modules/javafx.graphics/src/main/native-glass/win/KeyTable.cpp line 366: > 364: UINT keyChar = ::MapVirtualKeyEx(UINT(hardwareCode), 2, layout); > 365: // Filter out dead keys > 366: BOOL isDead = (keyChar & 0x80000000) != 0; Wouldn't `hardwareCode >= 0` already filter out dead keys since when the highest bit is set the value is negative? tests/manual/events/KeyboardTest.java line 134: > 132: static private class KeyList extends ArrayList {} > 133: > 134: static private class KeyListBuilder { minor: standard keyword order is `private static class` ------------- PR Review: https://git.openjdk.org/jfx/pull/1126#pullrequestreview-1415366666 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186465635 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186464101 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186448517 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186454982 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186456764 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186458329 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186460449 PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186461172 From jhendrikx at openjdk.org Fri May 5 20:22:22 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 20:22:22 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: <529YSbkPZY0-aVAigRPCuWPxZjtDNEW_D60pBakxP8o=.46c28694-5132-4190-a9aa-00652bcc6f06@github.com> Message-ID: <7WjxnVC2jWKFM8J6iOxF-lgZ-WUcZ1htjbnBINC63eY=.4f138eca-c30c-4d09-b225-9200816b0fa2@github.com> On Fri, 5 May 2023 19:38:36 GMT, Martin Fox wrote: > I'm not quite sold on having `notifyKey` and `notifyKeyEx` be two separate methods. Why not just have one? Not changing the existing call sites doesn't seem to be a sufficient reason to expand the toolkit API surface. I also think it isn't really needed; Mac and Linux can just ignore the extra parameter for now? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1536735587 From jhendrikx at openjdk.org Fri May 5 20:28:38 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 5 May 2023 20:28:38 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 5 May 2023 19:45:53 GMT, John Hendrikx wrote: >> Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). >> >> KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. >> >> `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). >> >> This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. >> >> On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. >> >> The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). >> >> For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. >> >> Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 709: > >> 707: * The default implementation bridges into the existing getKeyCodeForChar call. >> 708: */ >> 709: public boolean getKeyCanGenerateCharacter(KeyEvent event, String character) { > > I think this method can be narrowed a bit to accept a `KeyCode` instead of `KeyEvent`, making it bit more generally useful (and easier to test). Also I think perhaps it can be named a bit more direct, like `canKeyGenerateCharacter`. I forgot the `KeyEvent` is needed to extract the hardware code. Depending on whether this hardware code remains a hidden variable this may be for the best (or can pass both `KeyCode` and the hardware code). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1186474970 From mhanl at openjdk.org Fri May 5 21:19:19 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 5 May 2023 21:19:19 GMT Subject: Integrated: 8307208: Add GridPane constructor that accepts hGap and vGap values In-Reply-To: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> References: <1tHg8iZPvrk2CCyt-HUl-GGR_ImDY7FuuVUpdBRdh38=.156c0b62-8bdb-4a51-b168-76efc964b1b0@github.com> Message-ID: On Wed, 3 May 2023 20:13:42 GMT, Marius Hanl wrote: > This PR adds a new constructor to `GridPane` that accepts a `hgap` and a `vgap`. > As also written in the ticket, this is a small enhancement to improve the creation of a layout involving a `GridPane` without FXML. > In my experience, the `hgap` and the `vgap` are almost always set when creating a layout with the `GridPane`, as a space between the content just looks much better. > > This also fits well with other classes like `HBox` and `VBox`, which also provide a constructor that accepts the spacing. This pull request has now been integrated. Changeset: c50ce609 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/c50ce6093e1a91ee41a69e4fd25bff606b146118 Stats: 27 lines in 2 files changed: 25 ins; 0 del; 2 mod 8307208: Add GridPane constructor that accepts hGap and vGap values Reviewed-by: angorya, nlisker, jhendrikx, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1125 From tsayao at openjdk.org Sat May 6 13:33:23 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 13:33:23 GMT Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source code repository [v5] In-Reply-To: References: <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com> Message-ID: <-Ceat7qGOtEY4nBor3ZJvfXn9Ncw4ut2RdeCvisMhwU=.a31101c1-39b1-489c-adac-78729966db47@github.com> On Fri, 7 Apr 2023 22:42:20 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "Make intellij see :systemTests dependecies" >> >> This reverts commit dca7eab24958e1214147b7d291f0faf52ea27ddf. >> - Make intellij see :systemTests dependecies > > checkstyle.xml line 1: > >> 1: > > I'm not keen on adding yet another top-level file in our repo. Can it go somewhere else? @kevinrushforth can you guide me what should I do about this file? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1009#discussion_r1186698192 From kcr at openjdk.org Sat May 6 13:51:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 May 2023 13:51:27 GMT Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source code repository [v5] In-Reply-To: <-Ceat7qGOtEY4nBor3ZJvfXn9Ncw4ut2RdeCvisMhwU=.a31101c1-39b1-489c-adac-78729966db47@github.com> References: <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com> <-Ceat7qGOtEY4nBor3ZJvfXn9Ncw4ut2RdeCvisMhwU=.a31101c1-39b1-489c-adac-78729966db47@github.com> Message-ID: On Sat, 6 May 2023 13:30:55 GMT, Thiago Milczarek Sayao wrote: >> checkstyle.xml line 1: >> >>> 1: >> >> I'm not keen on adding yet another top-level file in our repo. Can it go somewhere else? > > @kevinrushforth can you guide me what should I do about this file? Since we already have a few other build and IDE-related files in the top repo, and since it could be shared by other IDEs, I won't object to putting it in the top repo. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1009#discussion_r1186700227 From kcr at openjdk.org Sat May 6 13:52:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 6 May 2023 13:52:19 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v4] In-Reply-To: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> References: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> Message-ID: On Tue, 2 May 2023 08:57:30 GMT, Ambarish Rapte wrote: >> Add `TEST_ONLY` flag to gradle with default value as false. >> Add new task named `shims`, This task depends on all shim tasks from all projects. Hence it will build all shim classes. >> >> If TEST_ONLY is set to true, the all non test tasks get disabled. When running a test task, this flag would reduce time in checking if all non test tasks are up to date. >> How to use: >> 1. Following command would fail in a clean repo, >> > gradle -PTEST_ONLY=true :base:test >> 2. The sdk and shims task must have been executed before running any test >> > gradle sdk shims >> > gradle -PTEST_ONLY=true :base:test >> 3. Setting this flag to true with non test task would result in no task being run. >> > gradle -PTEST_ONLY=true sdk -> It will not build sdk task >> >> TIP: use `--dry-run` option of gradle for speeding up testing the effect of this PR. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments @aghaisas can you be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1117#issuecomment-1537146580 From tsayao at openjdk.org Sat May 6 20:28:43 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:28:43 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v31] In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> Message-ID: <2BhPi-hLs71fgcmMbtJRs7oVDiF_5NdvXUwGoyZifrg=.b83a94fa-a6e0-436b-9850-77bf89a4fe9f@github.com> > This PR fixes 8273379. > > I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. > > It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). > > There's also some cleaup. > > To do general testing (two tests were added): > `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` > > Information for reviewing: > * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); > * There's a new `DragSourceContext` instead of global variables; > * DragView were simplified; > * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); > * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. > * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); > * The Scenario were the drag source window closes during the drag is now covered; > * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. > > > ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) > ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits: - Merge branch 'master' into 8273379-dnd-keys - Merge branch 'master' into 8273379-dnd-keys - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 67 more: https://git.openjdk.org/jfx/compare/559ad113...5460a045 ------------- Changes: https://git.openjdk.org/jfx/pull/986/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=30 Stats: 962 lines in 9 files changed: 611 ins; 177 del; 174 mod Patch: https://git.openjdk.org/jfx/pull/986.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/986/head:pull/986 PR: https://git.openjdk.org/jfx/pull/986 From tsayao at openjdk.org Sat May 6 20:28:45 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:28:45 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v30] In-Reply-To: <0eU_meshxVH1urcrxUFv4rB-7Rm687Pr7eyRJN6IMUQ=.39d9f337-2291-4d65-93f3-14e6a914efb9@github.com> References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> <0eU_meshxVH1urcrxUFv4rB-7Rm687Pr7eyRJN6IMUQ=.39d9f337-2291-4d65-93f3-14e6a914efb9@github.com> Message-ID: On Sun, 16 Apr 2023 00:03:47 GMT, Thiago Milczarek Sayao wrote: >> This PR fixes 8273379. >> >> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. >> >> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). >> >> There's also some cleaup. >> >> To do general testing (two tests were added): >> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` >> >> Information for reviewing: >> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); >> * There's a new `DragSourceContext` instead of global variables; >> * DragView were simplified; >> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); >> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. >> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); >> * The Scenario were the drag source window closes during the drag is now covered; >> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. >> >> >> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) >> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: > > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Don't call gdk_device_manager_get_client_pointer() on event processing > - ... and 66 more: https://git.openjdk.org/jfx/compare/0c03a411...2302657e modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 450: > 448: glass_evloop_call_hooks(event); > 449: > 450: if (!process_dnd_source(event)) { This let's the events fall-trough and is the most important part to fix the bug. Since the glass-gtk implementation uses GDK events, it made sense to go back to GDK for DND. modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 1014: > 1012: in_drag = false; > 1013: return true; > 1014: } This fixes a bug that would leave the DragView visible on the screen if the app is closed (ALT+F4) during the drag. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/986#discussion_r1167670033 PR Review Comment: https://git.openjdk.org/jfx/pull/986#discussion_r1167670688 From tsayao at openjdk.org Sat May 6 20:28:45 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:28:45 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v31] In-Reply-To: <2BhPi-hLs71fgcmMbtJRs7oVDiF_5NdvXUwGoyZifrg=.b83a94fa-a6e0-436b-9850-77bf89a4fe9f@github.com> References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> <2BhPi-hLs71fgcmMbtJRs7oVDiF_5NdvXUwGoyZifrg=.b83a94fa-a6e0-436b-9850-77bf89a4fe9f@github.com> Message-ID: On Sat, 6 May 2023 20:24:34 GMT, Thiago Milczarek Sayao wrote: >> This PR fixes 8273379. >> >> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. >> >> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). >> >> There's also some cleaup. >> >> To do general testing (two tests were added): >> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` >> >> Information for reviewing: >> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); >> * There's a new `DragSourceContext` instead of global variables; >> * DragView were simplified; >> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); >> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. >> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); >> * The Scenario were the drag source window closes during the drag is now covered; >> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. >> >> >> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) >> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits: > > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 67 more: https://git.openjdk.org/jfx/compare/559ad113...5460a045 modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 857: > 855: > 856: gint x, y; > 857: glass_gdk_master_pointer_get_position(&x, &y); Removing this fixes [JDK-8178131](https://bugs.openjdk.org/browse/JDK-8178131) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/986#discussion_r1167671326 From tsayao at openjdk.org Sat May 6 20:31:27 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:31:27 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v6] In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: > Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. > > Here's whats happening: > > We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). > > When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. > > The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 38 additional commits since the last revision: - Merge branch 'master' into fix_scrolling - Improve direction - Rename var - Fix direction - Fix for Ubuntu 20.04 - Fix scroll event - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 28 more: https://git.openjdk.org/jfx/compare/09166e0f...80285aef ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1044/files - new: https://git.openjdk.org/jfx/pull/1044/files/a3975da3..80285aef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=04-05 Stats: 20380 lines in 497 files changed: 11008 ins; 7486 del; 1886 mod Patch: https://git.openjdk.org/jfx/pull/1044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1044/head:pull/1044 PR: https://git.openjdk.org/jfx/pull/1044 From tsayao at openjdk.org Sat May 6 20:38:14 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:38:14 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v4] In-Reply-To: <4oYz-qhypbvfsHTaFxQ7JZtGIhc-w2n8LCaGwtRL4No=.1c6a592a-0f1b-42e8-a0c7-291ccc5e04ae@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> <4eZKC6XwnSZKny4XOPkirbwG_JMNRDXrLbCXjaRNP-w=.84f27394-76eb-4cdd-9f58-e79734cf4b2b@github.com> <2V8QPQSLqzUEhdQfET7c_bilf7po_0TA17POFmv3qIM=.eafe90f6-8bc1-43e1-9bc2-7cd4e7d38b70@github.com> <4oYz-qhypbvfsHTaFxQ7JZtGIhc-w2n8LCaGwtRL4No=.1c6a592a-0f1b-42e8-a0c7-291ccc5e04ae@github.com> Message-ID: <1yQRpTG8In7ePw3vCSlL6pFVY7QjmYFIxRnOASxNXsU=.bc02afb5-a49e-4ed7-9ce0-f372f651deed@github.com> On Wed, 1 Mar 2023 16:11:28 GMT, Andy Goryachev wrote: >> Will double check it, but I think I spaced out. > > dx = (dx != 0) ? -dx : 0; > > also, is jdouble a floating point type? if so, would that work correctly if dx/dy are very small? It's a floating point type. Output is: Delta: -0,000000, -0,058579 Delta: -0,000000, 0,029289 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1044#discussion_r1186743429 From tsayao at openjdk.org Sat May 6 20:38:13 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:38:13 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v7] In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: > Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. > > Here's whats happening: > > We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). > > When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. > > The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Remove print statement ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1044/files - new: https://git.openjdk.org/jfx/pull/1044/files/80285aef..15423b0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1044/head:pull/1044 PR: https://git.openjdk.org/jfx/pull/1044 From tsayao at openjdk.org Sat May 6 20:42:38 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:42:38 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v7] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'master' into change_scene_fix - Merge remote-tracking branch 'origin/master' ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/2649d15c..00c2461a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=05-06 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sat May 6 20:47:32 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 20:47:32 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v8] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 50 additional commits since the last revision: - Merge branch 'master' into change_scene_fix - Merge branch 'openjdk:master' into master - Merge branch 'master' into change_scene_fix - Merge remote-tracking branch 'origin/master' - Review changes - Merge branch 'master' into change_scene_fix - Change call to requestFocus - Revert "The window could start iconified." This reverts commit f92e25cbcc24fd772b9d6bb25a92386ec0561313. - The window could start iconified. - Request Focus on setVisible - ... and 40 more: https://git.openjdk.org/jfx/compare/b567615f...5893d847 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/00c2461a..5893d847 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=06-07 Stats: 7683 lines in 75 files changed: 7412 ins; 136 del; 135 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sat May 6 21:04:25 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 21:04:25 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v5] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 16:55:29 GMT, Jose Pereda wrote: >> @kevinrushforth I was checking and `SceneChangeShouldNotFocusStageTest` added on [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) does exactly that. >> >> But I noticed the same as you described on [JDK-8298500](https://bugs.openjdk.org/browse/JDK-8298500). >> >> @jperedadnr The `WinIconified.java` attached is to show that a window should stay iconified and that it is initially iconified (does not pop on the screen and then gets iconified). > > @tsayao thanks, and just for my understanding, do you intent to add WinIconified test to this PR, as system or manual test? `SceneChangeShouldNotFocusStageTest` covers the test that the window should start iconified. It does not cover the test where the window pops and then iconifies (causing a visual "weirdness"). I don't think the later is possible on a systemTest. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1186745917 From tsayao at openjdk.org Sat May 6 21:20:59 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 21:20:59 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v32] In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> Message-ID: > This PR fixes 8273379. > > I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. > > It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). > > There's also some cleaup. > > To do general testing (two tests were added): > `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` > > Information for reviewing: > * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); > * There's a new `DragSourceContext` instead of global variables; > * DragView were simplified; > * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); > * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. > * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); > * The Scenario were the drag source window closes during the drag is now covered; > * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. > > > ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) > ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: - Merge branch 'master' into 8273379-dnd-keys - Merge branch 'master' into 8273379-dnd-keys - Merge branch 'master' into 8273379-dnd-keys - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 68 more: https://git.openjdk.org/jfx/compare/c50ce609...53ee86e8 ------------- Changes: https://git.openjdk.org/jfx/pull/986/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=31 Stats: 962 lines in 9 files changed: 611 ins; 177 del; 174 mod Patch: https://git.openjdk.org/jfx/pull/986.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/986/head:pull/986 PR: https://git.openjdk.org/jfx/pull/986 From tsayao at openjdk.org Sat May 6 21:22:28 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 6 May 2023 21:22:28 GMT Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 [v8] In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: > Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. > > Here's whats happening: > > We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). > > When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. > > The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision: - Merge branch 'master' into fix_scrolling - Remove print statement - Merge branch 'master' into fix_scrolling - Improve direction - Rename var - Fix direction - Fix for Ubuntu 20.04 - Fix scroll event - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 30 more: https://git.openjdk.org/jfx/compare/c2c1a95d...dad897aa ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1044/files - new: https://git.openjdk.org/jfx/pull/1044/files/15423b0c..dad897aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=06-07 Stats: 7683 lines in 75 files changed: 7412 ins; 136 del; 135 mod Patch: https://git.openjdk.org/jfx/pull/1044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1044/head:pull/1044 PR: https://git.openjdk.org/jfx/pull/1044 From jhendrikx at openjdk.org Sun May 7 14:04:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 7 May 2023 14:04:19 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 22:25:29 GMT, Kevin Rushforth wrote: >> This was clearly a mistake back when the public API was first created in JDK 9. > >> @kevinrushforth I've created the CSR for this. Can I move it to proposed? > > I took a quick look, and it is fine to move to Proposed. @kevinrushforth do you think we can move forward with this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1537449611 From aghaisas at openjdk.org Mon May 8 08:30:26 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 8 May 2023 08:30:26 GMT Subject: RFR: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims [v4] In-Reply-To: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> References: <5YyscbZQp27N9SVD2hRB6K3TTmHcZYppUyAhiWtvf7Q=.c39566b1-ee69-4cb4-a683-6e6b4cd88cec@github.com> Message-ID: On Tue, 2 May 2023 08:57:30 GMT, Ambarish Rapte wrote: >> Add `TEST_ONLY` flag to gradle with default value as false. >> Add new task named `shims`, This task depends on all shim tasks from all projects. Hence it will build all shim classes. >> >> If TEST_ONLY is set to true, the all non test tasks get disabled. When running a test task, this flag would reduce time in checking if all non test tasks are up to date. >> How to use: >> 1. Following command would fail in a clean repo, >> > gradle -PTEST_ONLY=true :base:test >> 2. The sdk and shims task must have been executed before running any test >> > gradle sdk shims >> > gradle -PTEST_ONLY=true :base:test >> 3. Setting this flag to true with non test task would result in no task being run. >> > gradle -PTEST_ONLY=true sdk -> It will not build sdk task >> >> TIP: use `--dry-run` option of gradle for speeding up testing the effect of this PR. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1117#pullrequestreview-1416364136 From lkostyra at openjdk.org Mon May 8 08:49:13 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 May 2023 08:49:13 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v7] In-Reply-To: References: Message-ID: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: JMemoryBuddy: Update javadoc comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1121/files - new: https://git.openjdk.org/jfx/pull/1121/files/1230c8b8..98e72518 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1121&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1121.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1121/head:pull/1121 PR: https://git.openjdk.org/jfx/pull/1121 From lkostyra at openjdk.org Mon May 8 08:49:17 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 May 2023 08:49:17 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v6] In-Reply-To: References: <8yU2kwY_p3v5VS3CReYpJODhy6zTE7eqHx7a6PiraKo=.7ecff518-3e98-4cbd-9f1a-00d658c7672c@github.com> Message-ID: On Fri, 5 May 2023 16:13:39 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Add an EDT no-op and sleep for a bit >> >> On some platforms Swing memory leak tests occasionally failed, this >> might help to mitigate this problem. > > modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line 96: > >> 94: >> 95: /** >> 96: * Checks whether an array of WeakReference objects can be collected. > > I think it should rather say something like "whether content of all references in the array", rather than array itself. Done (+ others) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1121#discussion_r1187188130 From arapte at openjdk.org Mon May 8 09:26:25 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 8 May 2023 09:26:25 GMT Subject: Integrated: 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 17:08:50 GMT, Ambarish Rapte wrote: > Add `TEST_ONLY` flag to gradle with default value as false. > Add new task named `shims`, This task depends on all shim tasks from all projects. Hence it will build all shim classes. > > If TEST_ONLY is set to true, the all non test tasks get disabled. When running a test task, this flag would reduce time in checking if all non test tasks are up to date. > How to use: > 1. Following command would fail in a clean repo, > > gradle -PTEST_ONLY=true :base:test > 2. The sdk and shims task must have been executed before running any test > > gradle sdk shims > > gradle -PTEST_ONLY=true :base:test > 3. Setting this flag to true with non test task would result in no task being run. > > gradle -PTEST_ONLY=true sdk -> It will not build sdk task > > TIP: use `--dry-run` option of gradle for speeding up testing the effect of this PR. This pull request has now been integrated. Changeset: 27ee7e34 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/27ee7e34df7847e90f2aa4e326fd60715d74b7ac Stats: 58 lines in 3 files changed: 42 ins; 1 del; 15 mod 8297071: Provide gradle "TEST_ONLY" flag to completely suppress building the sdk and shims Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1117 From kpk at openjdk.org Mon May 8 12:22:17 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 8 May 2023 12:22:17 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v2] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix insertion index calculation issue with emojis. Add additional test cases ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/f741febc..e35f5bf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=00-01 Stats: 183 lines in 2 files changed: 157 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Mon May 8 12:25:23 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 8 May 2023 12:25:23 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v2] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 8 May 2023 12:22:17 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix insertion index calculation issue with emojis. Add additional test cases Fixed the above mentioned issue in calculating insertion index by adding insertion index calculation logic to `getHitInfo()` method. The previous fix was not calculating insertion index for emojis represented using value from 0x231A to 0x3299. Added additional test cases as suggested above. Please review the changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1538272519 From lkostyra at openjdk.org Mon May 8 13:06:49 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 May 2023 13:06:49 GMT Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop [v32] In-Reply-To: References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com> Message-ID: On Sat, 6 May 2023 21:20:59 GMT, Thiago Milczarek Sayao wrote: >> This PR fixes 8273379. >> >> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. >> >> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383). >> >> There's also some cleaup. >> >> To do general testing (two tests were added): >> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar` >> >> Information for reviewing: >> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started (`WindowContextBase::sm_mouse_drag_window`); >> * There's a new `DragSourceContext` instead of global variables; >> * DragView were simplified; >> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag); >> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND. >> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events); >> * The Scenario were the drag source window closes during the drag is now covered; >> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent. >> >> >> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png) >> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: > > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'master' into 8273379-dnd-keys > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 68 more: https://git.openjdk.org/jfx/compare/c50ce609...53ee86e8 apps/toys/DragDrop/src/dragdrop/DragDropDuke.java line 126: > 124: > 125: private void subDownload() throws IOException { > 126: URL url = new URL("http://cr.openjdk.java.net/~jeff/Duke/png/Hips.png"); I think, if possible, tests should be as independent from online-hosted content as possible (and in this case it seems like we only need an Image). I'd consider either adding Duke image to the repo, or (if adding a .png is not a good solution either - @kevinrushforth would have to confirm) generating a Test image. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/986#discussion_r1187418418 From kcr at openjdk.org Mon May 8 13:35:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 May 2023 13:35:23 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v7] In-Reply-To: References: Message-ID: <_NPw2f_Z76c6E35wK5K4QAR32o4soziiIW_Szx2CYJY=.9e023553-200c-45cd-bbcc-2ff47dabc140@github.com> On Mon, 8 May 2023 08:49:13 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > JMemoryBuddy: Update javadoc comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1416813682 From angorya at openjdk.org Mon May 8 15:01:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 15:01:29 GMT Subject: RFR: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility [v7] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 08:49:13 GMT, Lukasz Kostyra wrote: >> Verified these changes on all platforms and saw no abnormalities in test execution. >> >> This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > JMemoryBuddy: Update javadoc comments LGTM, thanks! ------------- Marked as reviewed by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1121#pullrequestreview-1416970892 From lkostyra at openjdk.org Mon May 8 15:26:24 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 May 2023 15:26:24 GMT Subject: Integrated: 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility In-Reply-To: References: Message-ID: <7SvqN4oe0zrcZfnqCyNHVmI8LTUhYxKdH0nlN1xSx7o=.dbfe4840-e76a-4bdc-9c85-5267f77d7afe@github.com> On Mon, 1 May 2023 14:48:32 GMT, Lukasz Kostyra wrote: > Verified these changes on all platforms and saw no abnormalities in test execution. > > This change is based on a preliminary patch done by @aghaisas , with some minor changes and the addition of one Leak-related web test. EventListenerLeak test was not touched, as it is a separate manual test app instead of a JUnit test. This pull request has now been integrated. Changeset: d9a82d10 Author: Lukasz Kostyra Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/d9a82d103d60bc38b35ba94a21354c84a75bb22d Stats: 228 lines in 11 files changed: 58 ins; 134 del; 36 mod 8296919: Make system tests that detect memory leaks more robust by using JMemoryBuddy utility Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1121 From jpereda at openjdk.org Mon May 8 15:29:29 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 8 May 2023 15:29:29 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v5] In-Reply-To: References: Message-ID: <97pZqoKP5dKYnIuN39fAw1x1jGX1-TLpDjpERC4HfUk=.6044cc70-6e7b-4ac3-9fdf-57b297c98590@github.com> On Sat, 6 May 2023 21:01:31 GMT, Thiago Milczarek Sayao wrote: >> @tsayao thanks, and just for my understanding, do you intent to add WinIconified test to this PR, as system or manual test? > > `SceneChangeShouldNotFocusStageTest` covers the test that the window should start iconified. It does not cover the test where the window pops and then iconifies (causing a visual "weirdness"). I don't think the later is possible on a systemTest. If not as system test, then could you add `WinIconified` as manual test, with some javadoc as quick instructions on how to check that it works as expected? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1187582264 From jpereda at openjdk.org Mon May 8 15:34:38 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 8 May 2023 15:34:38 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v11] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 00:36:55 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Enable compilation in Eclipse. Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/425#pullrequestreview-1417031102 From ambarish.rapte at oracle.com Mon May 8 15:39:52 2023 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 8 May 2023 15:39:52 +0000 Subject: CFV: New OpenJFX Reviewer: Andy Goryachev In-Reply-To: <5fa1c2ee-1073-9fcc-61ef-240d0b42a95c@oracle.com> References: <5fa1c2ee-1073-9fcc-61ef-240d0b42a95c@oracle.com> Message-ID: Vote: YES ~Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon May 8 15:43:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 15:43:23 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v2] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 8 May 2023 12:22:17 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix insertion index calculation issue with emojis. Add additional test cases minor changes requested modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 456: > 454: > 455: insertionIndex = charIndex; > 456: String txt = new String(getText()); possible NPE: looks like getText() might return null, in which case this line will throw an NPE. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 458: > 456: String txt = new String(getText()); > 457: if (!leading) { > 458: if (txt != null) { This check should be done earlier for getText() modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 461: > 459: int next; > 460: BreakIterator charIterator = BreakIterator.getCharacterInstance(); > 461: synchronized(charIterator) { question: why do we need to synchronize on the instance here? BreakIterator.get*Instance() creates a new instance each time, so synchronization is probably unnecessary. ------------- Changes requested by angorya (Committer). PR Review: https://git.openjdk.org/jfx/pull/1091#pullrequestreview-1417028467 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1187585950 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1187586532 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1187595409 From angorya at openjdk.org Mon May 8 16:36:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 16:36:24 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v2] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 8 May 2023 12:22:17 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix insertion index calculation issue with emojis. Add additional test cases Does not seem to work correctly still - the insertion index in TextFlow should not point in between surrogate pair of characters that comprise an emoji. Basically, it should be exactly the same as with Text.hitInfo(): ![Screenshot 2023-05-08 at 09 29 35](https://user-images.githubusercontent.com/107069028/236879369-f7634c6e-e5c8-41f4-8ded-dd59327de73b.png) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1538697285 From angorya at openjdk.org Mon May 8 17:40:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 17:40:53 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh Message-ID: Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. Added a unit test. Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). ------------- Commit messages: - whitespace - updated test - variable tree cell fix - fixed size selector - list view page - fix and test - skin menu - refresh button Changes: https://git.openjdk.org/jfx/pull/1129/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307538 Stats: 202 lines in 7 files changed: 160 ins; 15 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Mon May 8 17:45:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 17:45:20 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:55:48 GMT, Andy Goryachev wrote: > Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. > > Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). will separate Monkey Tester changes into a separate PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1538777573 From angorya at openjdk.org Mon May 8 18:55:38 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 18:55:38 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: > Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. > > Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - removed monkey tester changes - Merge remote-tracking branch 'origin/master' into 8307538.refresh - whitespace - updated test - variable tree cell fix - fixed size selector - list view page - fix and test - skin menu - refresh button ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/cc2f42e8..2b1ae8b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=00-01 Stats: 459 lines in 20 files changed: 131 ins; 270 del; 58 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From carl.carlec at gmail.com Mon May 8 19:03:02 2023 From: carl.carlec at gmail.com (Carl Carlec) Date: Mon, 8 May 2023 21:03:02 +0200 Subject: Define an intermediate superclass for Transitions with a duration property Message-ID: <3A279F79-4176-4586-A8CF-50B846D79831@gmail.com> Hello JavaFX community, I've created a draft PR for an enhancement to Transitions: https://github.com/openjdk/jfx/pull/1061 JavaFX contains many different Transitions that have a durationProperty() and related getter/setter. Those transitions benefit from an abstract super class which defines this once. This will therefore reduce a lot of code duplications or big switch-cases to handle all Transitions like the one linked in the ticket. I propose to create a new abstract class called TimedTransition, which extends from Transition and defines the durationProperty() + getter/setter. All Transitions which define a durationProperty() will now extend from it and do not need to define it. Those Transitions are affected: FadeTransition, FillTransition, PathTransition, PauseTransition, RotateTransition, ScaleTransition, StrokeTransition, TranslateTransition. Feedback welcome! Carl -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon May 8 19:07:28 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 19:07:28 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:29:48 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 342: > 340: private double computeChildWidth(Node child, Double leftAnchor, Double rightAnchor, double areaWidth, double height) { > 341: if (leftAnchor != null && rightAnchor != null && child.isResizable()) { > 342: return areaWidth - snappedLeftInset() - snappedRightInset() - leftAnchor - rightAnchor; should this line (and line 349) use snapped left/right anchors values? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1187784237 From angorya at openjdk.org Mon May 8 19:07:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 19:07:29 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Fri, 25 Nov 2022 08:12:49 GMT, Ambarish Rapte wrote: >> I also never understood that completely. >> Hence I asked at the mailing list about snapping in the past: https://mail.openjdk.org/pipermail/openjfx-dev/2021-September/032166.html >> In my opinion it also makes sense to snap the values once. But that would be a huge refactoring and everything is affected. We can not just change this now. Thats why I would stick to the existing solution and refactor that later. >> But some clarification here would be helpful here, maybe ask the people who created this (if available)?. And I haven't looked yet, but how does Swing handle this? > > It's seems little tricky to choose an approach for this fix. > > - NOT snapping intermediate values (new approach): > 1. It definitely seems correct NOT to snap intermediate values. > 2. But currently, code Controls snap the intermediate values, > 3. This PR seems to be the first change of snapping in a layout: > => Will it regress if we have different approach in layout than in control ? > I think No, It won?t regress. @Maran23 Can you please try it with this fix ? > In that case, we can adapt the new way for layout and file a new JBS to refactor existing code. I think I now understand the snapping better, especially after discussion in https://github.com/openjdk/jfx/pull/1111 it looks like we should be operating in terms of final pixels, that is, in snapped coordinates. this might mean what we should not, generally, mix snapped and unsnapped values: result = snap(a) + snap(b); // ok result = snap(snap(a) + b) // also ok result = snap(snap(a) + b + c) // not ok, should be written as result = snap(snap(a) + snap(b) + snap(c)) or result = snap(a) + snap(b) + snap(c) What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1187790783 From jhendrikx at openjdk.org Mon May 8 19:27:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 8 May 2023 19:27:19 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <-On6lQORVDRNGJ6xfSziGWsptiok3WULjWpetjGp2Qk=.3a7f7210-4940-48b6-b4d9-47e39f153b9f@github.com> On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button I've seen the problem with Views and Cell creation often enough now that I think we may want to talk about the fundamental problem that is causing these issues. The lifecycle of a Cell or Row is not the same as the View that contains them. Cells are created on demand, and should either be destroyed or unlinked. In JavaFX, we have chosen to not have an explicit `destroy` method for cells, but we do have a way to unlink cells. For a `TreeTableRow` this is a simple as calling `TreeTableRow#updateTreeTableView(null)`. The call already does exactly what you would expect: it unregisters all troublesome listeners (ones that were registered on the view). The skin also responds to this setting to `null` as it adds listeners to the `treeTableViewProperty` of its skinnable. In other words, a `TreeTableView` which creates cells on demand with a different lifecycle than itself should also be responsible to clean them up when it no longer needs them -- this is where the real bug is. It is managing the lifecycle of these cells and should not rely on these cells doing this indirectly by using a lot of weak listeners. If `TreeTableView` would correctly unlink cells and rows it doesn't need, it would remove the need for **all** weak listeners (and also references) in both `TreeTableRow` and `TreeTableRowSkin`, making their code much simpler, more predictable and easier to test. Specifically for this PR, only the listeners registered as part of `setupTreeTableViewListeners` need to be weak, the others are not the issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1538921567 From angorya at openjdk.org Mon May 8 19:31:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 May 2023 19:31:20 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button This is a very good suggestion, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1538926931 From jvos at openjdk.org Mon May 8 20:03:33 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 8 May 2023 20:03:33 GMT Subject: [jfx11u] RFR: 8307641: Change JavaFX release version to 11.0.20 in jfx11u Message-ID: Increase security version for JavaFX 11 to 20 Fix for JDK-8307641 ------------- Commit messages: - Increase security version for JavaFX 11 to 20 Changes: https://git.openjdk.org/jfx11u/pull/139/files Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307641 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx11u/pull/139.diff Fetch: git fetch https://git.openjdk.org/jfx11u.git pull/139/head:pull/139 PR: https://git.openjdk.org/jfx11u/pull/139 From jvos at openjdk.org Mon May 8 20:25:21 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 8 May 2023 20:25:21 GMT Subject: [jfx17u] RFR: 8307642: Change JavaFX release version to 17.0.8 in jfx17u Message-ID: Increase the security version for JavaFX 17 to 8 Fix for JDK-8307642 ------------- Commit messages: - Increase the security version for JavaFX 17 to 8 Changes: https://git.openjdk.org/jfx17u/pull/131/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307642 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/131.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/131/head:pull/131 PR: https://git.openjdk.org/jfx17u/pull/131 From nlisker at gmail.com Mon May 8 21:18:59 2023 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 May 2023 00:18:59 +0300 Subject: Define an intermediate superclass for Transitions with a duration property In-Reply-To: <3A279F79-4176-4586-A8CF-50B846D79831@gmail.com> References: <3A279F79-4176-4586-A8CF-50B846D79831@gmail.com> Message-ID: I am unconvinced yet that this is a good path. The reason is that different transitions have different combinations of properties to them. JDK-8091607 [1] asks for a common superclass for transitions that have a Node property. JDK-8226456 [2] asks for a common superclass for parent transitions (although this case is a bit different), Since only 1 superclass is possible, it might be better to use interfaces for these. The problem described in the ticket and in [1] is that many instanceof checks are needed, and this can be relieved with an interface as well. Code duplication will still be present though. I think that some prototyping is required first. - Nir [1] https://bugs.openjdk.org/browse/JDK-8091607 [2] https://bugs.openjdk.org/browse/JDK-8226456 On Mon, May 8, 2023 at 10:03?PM Carl Carlec wrote: > Hello JavaFX community, > I've created a draft PR for an enhancement to Transitions: > https://github.com/openjdk/jfx/pull/1061 > JavaFX contains many different Transitions that have a durationProperty() > and related getter/setter. > Those transitions benefit from an abstract super class which defines this > once. > This will therefore reduce a lot of code duplications or big switch-cases > to handle all Transitions like the one linked in the ticket. > > > I propose to create a new abstract class called TimedTransition, which > extends from Transition and defines the durationProperty() + getter/setter. > All Transitions which define a durationProperty() will now extend from it > and do not need to define it. > Those Transitions are affected: FadeTransition, FillTransition, > PathTransition, PauseTransition, RotateTransition, ScaleTransition, > StrokeTransition, TranslateTransition. > > > Feedback welcome! > > > Carl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Tue May 9 03:15:36 2023 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 9 May 2023 03:15:36 +0000 Subject: CFV: New OpenJFX Reviewer: Andy Goryachev In-Reply-To: <5fa1c2ee-1073-9fcc-61ef-240d0b42a95c@oracle.com> References: <5fa1c2ee-1073-9fcc-61ef-240d0b42a95c@oracle.com> Message-ID: Vote: Yes Regards, Ajit > On 26-Apr-2023, at 10:07 PM, Kevin Rushforth wrote: > > I hereby nominate Andy Goryachev [1] to OpenJFX Reviewer. > > Andy is a member of JavaFX team at Oracle, who has contributed 50 commits [2] to OpenJFX. Andy consistently participates in code reviews of various pull requests, especially in the areas of UI Controls and Scene Graph. > > Votes are due by May 10, 2023 at 17:00 UTC. > > Only current OpenJFX Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [4]. Nomination to a project Reviewer is described in [5]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.org/census#angorya > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Andy+Goryachev%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#three-vote-consensus > > [5] https://openjdk.java.net/projects#project-reviewer > From kpk at openjdk.org Tue May 9 05:10:25 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 9 May 2023 05:10:25 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Address code review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/e35f5bf6..03600552 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=01-02 Stats: 12 lines in 1 file changed: 2 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Tue May 9 05:10:27 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 9 May 2023 05:10:27 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v2] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Mon, 8 May 2023 16:33:50 GMT, Andy Goryachev wrote: > Does not seem to work correctly still - the insertion index in TextFlow should not point in between surrogate pair of characters that comprise an emoji. Basically, it should be exactly the same as with Text.hitInfo(): > This condition is working for me as `Text.hitInfo()`. The code is updated now to make the changes suggested above. Could you please recheck? > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 456: > >> 454: >> 455: insertionIndex = charIndex; >> 456: String txt = new String(getText()); > > possible NPE: looks like getText() might return null, in which case this line will throw an NPE. Updated code > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 458: > >> 456: String txt = new String(getText()); >> 457: if (!leading) { >> 458: if (txt != null) { > > This check should be done earlier for getText() Added null check for `getText()` > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 461: > >> 459: int next; >> 460: BreakIterator charIterator = BreakIterator.getCharacterInstance(); >> 461: synchronized(charIterator) { > > question: why do we need to synchronize on the instance here? BreakIterator.get*Instance() creates a new instance each time, so synchronization is probably unnecessary. Correct it is not necessary. Updated code to remove synchronization ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1539412625 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1188134287 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1188134476 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1188134760 From fkirmaier at openjdk.org Tue May 9 08:01:34 2023 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 9 May 2023 08:01:34 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v9] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 12:18:49 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - JDK-8273485 > Fixing issue caused by wrong merge. > - Merge remote-tracking branch 'origin/master' into JDK-8273485_swing-deadlock > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m > - JDK-8273485 > Added check for null when calling initScreens > - JDK-8273485 > Fixing toggle fullscreen! > - JDK-8273485 > removed the toggle fullscreen before closing - to avoid the beep and improve the user experience > - JDK-8273485 > Fixed Beep sound when closing a fullscreen window > - JDK-8273485 > small cleanup of the changes. > - JDK-8273485 > Removed the enter/leave nested event loop logic, for mac fullscreen > - JDK-8273485 > Added unit-test > - JDK-8273485 > Fixing deadlock when switching to fullscreen, when also swing is used. Annually reminder that this pull request still exists. Removing an unneeded NestedEventLoop is a huge reduction in complexity! ------------- PR Comment: https://git.openjdk.org/jfx/pull/622#issuecomment-1539637546 From mariushanl at web.de Tue May 9 08:51:33 2023 From: mariushanl at web.de (Marius Hanl) Date: Tue, 9 May 2023 10:51:33 +0200 Subject: Aw: Re: Define an intermediate superclass for Transitions with a duration property In-Reply-To: References: <3A279F79-4176-4586-A8CF-50B846D79831@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue May 9 12:33:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 12:33:28 GMT Subject: [jfx17u] RFR: 8307642: Change JavaFX release version to 17.0.8 in jfx17u In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:18:45 GMT, Johan Vos wrote: > Increase the security version for JavaFX 17 to 8 > Fix for JDK-8307642 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/131#pullrequestreview-1418515332 From kcr at openjdk.org Tue May 9 12:33:32 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 12:33:32 GMT Subject: [jfx11u] RFR: 8307641: Change JavaFX release version to 11.0.20 in jfx11u In-Reply-To: References: Message-ID: On Mon, 8 May 2023 19:58:16 GMT, Johan Vos wrote: > Increase security version for JavaFX 11 to 20 > Fix for JDK-8307641 Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx11u/pull/139#pullrequestreview-1418514841 From jvos at openjdk.org Tue May 9 12:39:30 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 May 2023 12:39:30 GMT Subject: [jfx11u] Integrated: 8307641: Change JavaFX release version to 11.0.20 in jfx11u In-Reply-To: References: Message-ID: On Mon, 8 May 2023 19:58:16 GMT, Johan Vos wrote: > Increase security version for JavaFX 11 to 20 > Fix for JDK-8307641 This pull request has now been integrated. Changeset: 992e6e4c Author: Johan Vos URL: https://git.openjdk.org/jfx11u/commit/992e6e4c9680e2d28e441d21ee21f954ba030b84 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8307641: Change JavaFX release version to 11.0.20 in jfx11u Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx11u/pull/139 From jvos at openjdk.org Tue May 9 12:39:30 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 May 2023 12:39:30 GMT Subject: [jfx17u] Integrated: 8307642: Change JavaFX release version to 17.0.8 in jfx17u In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:18:45 GMT, Johan Vos wrote: > Increase the security version for JavaFX 17 to 8 > Fix for JDK-8307642 This pull request has now been integrated. Changeset: c525c2a2 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/c525c2a2a0f891584f2f20b9592a17336be60ce0 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8307642: Change JavaFX release version to 17.0.8 in jfx17u Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx17u/pull/131 From lkostyra at openjdk.org Tue May 9 14:17:21 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 9 May 2023 14:17:21 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method Message-ID: Calls of `Runtime.getRuntime().exec()` were changed to `String[]` variant. Only Windows and macOS parts were affected, tests work good on both platforms. I looked through the code and didn't find any other cases of `Runtime.getRuntime().exec(String)` being used, so that should cover all possible deprecation warnings for this issue. ------------- Commit messages: - Replace deprecated Runtime.exec method Changes: https://git.openjdk.org/jfx/pull/1130/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278422 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1130.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1130/head:pull/1130 PR: https://git.openjdk.org/jfx/pull/1130 From kcr at openjdk.org Tue May 9 15:14:27 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 15:14:27 GMT Subject: RFR: 8284542: Missing attribute for state of CheckBox in CheckBoxTreeItem In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 15:13:25 GMT, Ambarish Rapte wrote: > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. I echo Andy's question about using an enum for the new AccessibleAttribute. More importantly, I think the values of that new attribute need to be a platform-independent. See inline comments. modules/javafx.controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java line 495: > 493: state = 2; > 494: } else if (checkBox.isSelected()) { > 495: state = 1; I recommend using platform-independent constants here (possibly an enum as discussed earlier). modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 1588: > 1586: if (isDisposed()) return 0; > 1587: if (getAttribute(ROLE) == AccessibleRole.CHECK_BOX_TREE_ITEM) { > 1588: return (int)getAttribute(TOGGLE_STATE); I recommend mapping the return value of `getAttribute(TOGGLE_STATE)`, which should be a platform-independent value, to one of the three Windows-specific values. Otherwise you are making an assumption that might not hold for other platforms (e.g., macOS). ------------- PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1417144589 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1188755406 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1188750544 From kcr at openjdk.org Tue May 9 15:14:29 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 15:14:29 GMT Subject: RFR: 8284542: Missing attribute for state of CheckBox in CheckBoxTreeItem In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:27:29 GMT, Andy Goryachev wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 357: > >> 355: * @since 21 >> 356: */ >> 357: TOGGLE_STATE(Integer.class), > > Would a dedicated enum be a better choice here? Yes, that might be cleaner. In any case, we should not hard-code or specify int values that are Windows-specific. I recommend defining this as a platform-independent attribute and then mapping it in the Windows platform code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1187660261 From duke at openjdk.org Tue May 9 15:15:41 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 9 May 2023 15:15:41 GMT Subject: Integrated: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 16:27:27 GMT, Martin Fox wrote: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) This pull request has now been integrated. Changeset: 9cca5f88 Author: Martin Fox Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/9cca5f88d8039d808b0ccf403d66518f9d592c46 Stats: 1080 lines in 4 files changed: 1076 ins; 1 del; 3 mod 8150709: Mac OSX and German Keyboard Layout (Y/Z) Reviewed-by: jpereda, angorya ------------- PR: https://git.openjdk.org/jfx/pull/425 From kcr at openjdk.org Tue May 9 15:40:32 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 15:40:32 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <8TreN0Dln_ZU4Uuuqo8ySo5oabtYY4x0aXTHigS2Kuw=.7fa5c7c2-e750-43af-8e46-40a9af8cad79@github.com> On Mon, 8 May 2023 19:28:54 GMT, Andy Goryachev wrote: > I agree that the idea of explicitly clearing the cells when they are not needed would be a much better solution. It will, however, require non-trivial changes in VirtualFlow, would impact three controls (List|Tree|TableView) and would require some careful testing. Yes, and we wouldn't do this as part of a regression bug fix like this. It seems worth filing a follow-up bug for this. An explicit life-cycle that eliminates the need for weak listeners is generally a good thing. > For the purposes of fixing the regression bug, I would like to proceed with this fix as is. Agreed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1540416777 From duke at openjdk.org Tue May 9 17:37:12 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 9 May 2023 17:37:12 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 5 May 2023 20:25:23 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 709: >> >>> 707: * The default implementation bridges into the existing getKeyCodeForChar call. >>> 708: */ >>> 709: public boolean getKeyCanGenerateCharacter(KeyEvent event, String character) { >> >> I think this method can be narrowed a bit to accept a `KeyCode` instead of `KeyEvent`, making it bit more generally useful (and easier to test). Also I think perhaps it can be named a bit more direct, like `canKeyGenerateCharacter`. > > I forgot the `KeyEvent` is needed to extract the hardware code. Depending on whether this hardware code remains a hidden variable this may be for the best (or can pass both `KeyCode` and the hardware code). I'll change the call over to `canKeyGenerateCharacter`, the longer form was starting to annoy me too. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1188926005 From duke at openjdk.org Tue May 9 17:37:16 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 9 May 2023 17:37:16 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 5 May 2023 20:00:55 GMT, John Hendrikx wrote: >> Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). >> >> KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. >> >> `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). >> >> This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. >> >> On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. >> >> The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). >> >> For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. >> >> Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. > > modules/javafx.graphics/src/main/java/javafx/scene/input/KeyEvent.java line 388: > >> 386: * The hardware key code which is private to the implementation. >> 387: */ >> 388: private int hardwareCode; > > Does it need to be private? Events are public, and I think it should be possible to make your own events that act exactly like an event created by the system, which would preclude hidden variables. At this point I don't have a strong opinion on whether this field is private or not. Originally I wanted it to be private because I thought of it as "whatever magic value makes KeyCharacterCombinations work" and was concerned we might want to tweak that over time. That's less of a concern now that I've prototyped the implementation on three different platforms. This is largely a policy issue that's above my pay grade. This is an intrinsically platform-specific bit of information we would be exposing to developers. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1188927478 From nlisker at gmail.com Tue May 9 17:42:26 2023 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 May 2023 20:42:26 +0300 Subject: Define an intermediate superclass for Transitions with a duration property In-Reply-To: References: <3A279F79-4176-4586-A8CF-50B846D79831@gmail.com> Message-ID: I made a similar observation about the list of transitions. Looking at Duration, is it normal for a property to unbind itself when it is assigned an illegal value? The Duration property also looks more verbose because Node uses the SimpleObjectProperty concrete class, which is less memory efficient than using an anonymous subclass, and JavaFX tends to use the anonymous class pattern. I think that interfaces for Node and Duration are fine. An abstract class might be too restrictive. We could make it a non-public class and that would give us more flexibility, but won't serve the user. I would have liked to have a generic interface NodeTransition where implementing transitions can choose which Node they act on, like Shape, but the Shape transitions have a different name for their methods, so that doesn't work. On Tue, May 9, 2023 at 11:51?AM Marius Hanl wrote: > I had a look and made list of every transition with their properties: > Transition > -> FadeTransition (node, duration) > -> FillTransition (shape, duration) > -> ParallelTransition (node) > -> PathTransition (node, duration) > -> PauseTransition (duration) > -> RotateTransition (node, duration) > -> ScaleTransition (node, duration) > -> SequentialTransition (node) > -> StrokeTransition (shape, duration) > -> TranslateTransition (node, duration) > > We can save a lot of duplicated code for the duration property since it > always does the same thing, which is calling *setCycleDuration()*. > This also beneficial for other developers so they don't need to deal with > that when creating an own Transition class with a duration. > *setNode()* or *setShape()* are simple property setters. So maybe a mix > of an abstract class and interfaces makes sense here. > > E.g. > Abstract class: TimedTransition > Interface: NodeTransition > Interface: ShapeTransition > > For *SequentialTransition *and *ParallelTransition *we can also think of > an abstract superclass as they share a lot of code. > And this would also be useful for developers as this abstract superclass > deals already with e.g. all the *children* property stuff for you when > extending such superclass. > > -- Marius > > *Gesendet:* Montag, 08. Mai 2023 um 23:18 Uhr > *Von:* "Nir Lisker" > *An:* "Carl Carlec" > *Cc:* openjfx-dev at openjdk.org > *Betreff:* Re: Define an intermediate superclass for Transitions with a > duration property > I am unconvinced yet that this is a good path. The reason is that > different transitions have different combinations of properties to them. > JDK-8091607 [1] asks for a common superclass for transitions that have a > Node property. JDK-8226456 [2] asks for a common superclass for parent > transitions (although this case is a bit different), Since only 1 > superclass is possible, it might be better to use interfaces for these. The > problem described in the ticket and in [1] is that many instanceof checks > are needed, and this can be relieved with an interface as well. Code > duplication will still be present though. > > I think that some prototyping is required first. > > - Nir > > [1] https://bugs.openjdk.org/browse/JDK-8091607 > [2] https://bugs.openjdk.org/browse/JDK-8226456 > > > On Mon, May 8, 2023 at 10:03?PM Carl Carlec wrote: > >> Hello JavaFX community, >> I've created a draft PR for an enhancement to Transitions: >> https://github.com/openjdk/jfx/pull/1061 >> JavaFX contains many different Transitions that have a durationProperty() >> and related getter/setter. >> Those transitions benefit from an abstract super class which defines this >> once. >> This will therefore reduce a lot of code duplications or big switch-cases >> to handle all Transitions like the one linked in the ticket. >> >> >> I propose to create a new abstract class called TimedTransition, which >> extends from Transition and defines the durationProperty() + getter/setter. >> All Transitions which define a durationProperty() will now extend from it >> and do not need to define it. >> Those Transitions are affected: FadeTransition, FillTransition, >> PathTransition, PauseTransition, RotateTransition, ScaleTransition, >> StrokeTransition, TranslateTransition. >> >> >> Feedback welcome! >> >> >> Carl >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue May 9 17:57:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 May 2023 17:57:23 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:12:09 GMT, Lukasz Kostyra wrote: > Calls of `Runtime.getRuntime().exec()` were changed to `String[]` variant. > > Only Windows and macOS parts were affected, tests work good on both platforms. > > I looked through the code and didn't find any other cases of `Runtime.getRuntime().exec(String)` being used, so that should cover all possible deprecation warnings for this issue. modules/javafx.graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java line 138: > 136: try { > 137: if (osName.startsWith("Mac OS")) { > 138: Runtime.getRuntime().exec(new String[] { not a review, but a general question: do we have (do we want) an enum identifying the platform? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1188949404 From nlisker at openjdk.org Tue May 9 18:28:22 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 9 May 2023 18:28:22 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 17:54:35 GMT, Andy Goryachev wrote: >> Calls of `Runtime.getRuntime().exec()` were changed to `String[]` variant. >> >> Only Windows and macOS parts were affected, tests work good on both platforms. >> >> I looked through the code and didn't find any other cases of `Runtime.getRuntime().exec(String)` being used, so that should cover all possible deprecation warnings for this issue. > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java line 138: > >> 136: try { >> 137: if (osName.startsWith("Mac OS")) { >> 138: Runtime.getRuntime().exec(new String[] { > > not a review, but a general question: > do we have (do we want) an enum identifying the platform? Don't think we have an enum (maybe we should), but `PlatformUtil` already takes care of identifying the OS, also using `System.getProperty("os.name")`. You can use `PlatformUtil.isMac()`. If we make an enum, that's where is should be. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1188981353 From angorya at openjdk.org Tue May 9 18:28:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 May 2023 18:28:23 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 18:23:15 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java line 138: >> >>> 136: try { >>> 137: if (osName.startsWith("Mac OS")) { >>> 138: Runtime.getRuntime().exec(new String[] { >> >> not a review, but a general question: >> do we have (do we want) an enum identifying the platform? > > Don't think we have an enum (maybe we should), but `PlatformUtil` already takes care of identifying the OS, also using `System.getProperty("os.name")`. You can use `PlatformUtil.isMac()`. If we make an enum, that's where is should be. There was a recent PR https://github.com/openjdk/jdk/pull/13357 adding an enum deep in the jdk bowels we probably can't use that ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1188986935 From nlisker at openjdk.org Tue May 9 18:33:22 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 9 May 2023 18:33:22 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 18:26:02 GMT, Andy Goryachev wrote: >> Don't think we have an enum (maybe we should), but `PlatformUtil` already takes care of identifying the OS, also using `System.getProperty("os.name")`. You can use `PlatformUtil.isMac()`. If we make an enum, that's where is should be. > > There was a recent PR > https://github.com/openjdk/jdk/pull/13357 > adding an enum deep in the jdk bowels > > we probably can't use that > There was a recent PR [openjdk/jdk#13357](https://github.com/openjdk/jdk/pull/13357) adding an enum deep in the jdk bowels > > we probably can't use that Isn't that for the architecture, not the OS? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1188992367 From angorya at openjdk.org Tue May 9 18:40:23 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 May 2023 18:40:23 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 18:30:56 GMT, Nir Lisker wrote: >> There was a recent PR >> https://github.com/openjdk/jdk/pull/13357 >> adding an enum deep in the jdk bowels >> >> we probably can't use that > >> There was a recent PR [openjdk/jdk#13357](https://github.com/openjdk/jdk/pull/13357) adding an enum deep in the jdk bowels >> >> we probably can't use that > > Isn't that for the architecture, not the OS? you are right, wrong PR, sorry https://github.com/openjdk/jdk/pull/12931 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1188998562 From angorya at openjdk.org Tue May 9 18:45:30 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 May 2023 18:45:30 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 9 May 2023 05:10:25 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address code review Testing looks good so far. There is one question whether it's possible to always initialize HitInfo.insertionIndex and remove the secondary computation from HitInfo.getInsertionIndex() I am not clear under which conditions it is not possible to initialize, and whether subsequent HitInfo.getInsertionIndex() would produce a meaningful result. Perhaps in a separate RFE. modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 425: > 423: public Hit getHitInfo(float x, float y) { > 424: int charIndex = -1; > 425: int insertionIndex = -1; [question] Currently, there are a few scenarios when a negative insertionIndex is passed down to HitInfo. This will trigger a similar (and probably incorrect) computation of the insertion index in HitInfo, see for example [JDK-8302511](https://bugs.openjdk.org/browse/JDK-8302511). My question is - should we instead resolve the insertion index always? ------------- PR Review: https://git.openjdk.org/jfx/pull/1091#pullrequestreview-1419212526 PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1188972363 From kcr at openjdk.org Tue May 9 20:24:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 20:24:20 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 18:37:24 GMT, Andy Goryachev wrote: >>> There was a recent PR [openjdk/jdk#13357](https://github.com/openjdk/jdk/pull/13357) adding an enum deep in the jdk bowels >>> >>> we probably can't use that >> >> Isn't that for the architecture, not the OS? > > you are right, wrong PR, sorry > https://github.com/openjdk/jdk/pull/12931 No, we can't use that. More to the point, it is unrelated to this PR (and thus out of scope). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1189093549 From kcr at openjdk.org Tue May 9 20:24:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 20:24:20 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:19:50 GMT, Kevin Rushforth wrote: >> you are right, wrong PR, sorry >> https://github.com/openjdk/jdk/pull/12931 > > No, we can't use that. More to the point, it is unrelated to this PR (and thus out of scope). But I do think it would be a good idea to use `PlatformUtil` here, so maybe file a cleanup issue to look for places where we explicitly parse `os.name`, and consider calling the appropriate `PlatformUtil` method instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1189095379 From duke at openjdk.org Tue May 9 20:41:24 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 9 May 2023 20:41:24 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Fri, 5 May 2023 20:04:12 GMT, John Hendrikx wrote: >> Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). >> >> KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. >> >> `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). >> >> This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. >> >> On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. >> >> The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). >> >> For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. >> >> Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. > > modules/javafx.graphics/src/main/native-glass/win/KeyTable.cpp line 366: > >> 364: UINT keyChar = ::MapVirtualKeyEx(UINT(hardwareCode), 2, layout); >> 365: // Filter out dead keys >> 366: BOOL isDead = (keyChar & 0x80000000) != 0; > > Wouldn't `hardwareCode >= 0` already filter out dead keys since when the highest bit is set the value is negative? I just realized that I never actually said what `hardwareCode` means on this platform. A negative number means the `hardwareCode` isn't known (in other words, the KeyEvent wasn't constructed by glass). If it's not negative it's a Windows VK code that identifies the key the user pressed. That code doesn't reflect whether the key is dead or not. Here I'm asking what character that key would generate if pressed without any modifiers and ignoring it if the key is dead. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1189109403 From angorya at openjdk.org Tue May 9 21:18:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 May 2023 21:18:19 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:22:05 GMT, Kevin Rushforth wrote: >> No, we can't use that. More to the point, it is unrelated to this PR (and thus out of scope). > > But I do think it would be a good idea to use `PlatformUtil` here, so maybe file a cleanup issue to look for places where we explicitly parse `os.name`, and consider calling the appropriate `PlatformUtil` method instead? +1 for PlatformUtil. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1189139175 From kcr at openjdk.org Tue May 9 22:56:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 22:56:21 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <-ydEbko5RKU-X45mxlw2nwcF84hEmdHC7J-MlvO_KTs=.217e69da-1650-457b-b666-0f7cae2489b6@github.com> On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button If I run just the `TreeTableRowSkinTest` test class, I now get a test failure: $ gradle --info -PTEST_ONLY=true :controls:test --tests TreeTableRowSkinTest TreeTableRowSkinTest > treeTableRowWithFixedCellSizeShouldIgnoreVerticalPadding() FAILED org.opentest4j.AssertionFailedError: expected: <18.0> but was: <23.0> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:86) at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:81) at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1010) at app//test.javafx.scene.control.skin.TreeTableRowSkinTest.treeTableRowWithFixedCellSizeShouldIgnoreVerticalPadding(TreeTableRowSkinTest.java:251) Given that the GHA run passes, as does a full controls test run on my system, that suggests something odd is going on with that test, possibly it is affected by tests in another class. If so, then it could fail randomly anyway, since the tests are run in an unspecified (and unpredictable) order. @aghaisas can you review this? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 215: > 213: int right = 23; > 214: int bottom = 37; > 215: int left = 49; After the fix and test change, this test now fails for me. ------------- PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1419545337 PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1540988869 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189195101 From kcr at openjdk.org Tue May 9 23:14:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 May 2023 23:14:18 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:12:09 GMT, Lukasz Kostyra wrote: > Calls of `Runtime.getRuntime().exec()` were changed to `String[]` variant. > > Only Windows and macOS parts were affected, tests work good on both platforms. > > I looked through the code and didn't find any other cases of `Runtime.getRuntime().exec(String)` being used, so that should cover all possible deprecation warnings for this issue. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1130#pullrequestreview-1419564934 From jhendrikx at openjdk.org Wed May 10 06:50:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 May 2023 06:50:19 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: <8TreN0Dln_ZU4Uuuqo8ySo5oabtYY4x0aXTHigS2Kuw=.7fa5c7c2-e750-43af-8e46-40a9af8cad79@github.com> References: <8TreN0Dln_ZU4Uuuqo8ySo5oabtYY4x0aXTHigS2Kuw=.7fa5c7c2-e750-43af-8e46-40a9af8cad79@github.com> Message-ID: On Tue, 9 May 2023 15:37:39 GMT, Kevin Rushforth wrote: > For the purposes of fixing the regression bug, I would like to proceed with this fix as is. I think that's fine, but I do think you should remove the changes that don't contribute to the fix (I'm pretty sure the weak listeners in the constructor are not a problem). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1541440933 From jhendrikx at openjdk.org Wed May 10 07:03:24 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 May 2023 07:03:24 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 101: > 99: control.indexProperty().addListener(new WeakInvalidationListener((x) -> { > 100: updateCells = true; > 101: })); I don't think this needed changing, the index property is directly available on `TreeTableRow` and so shouldn't cause GC issues. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 108: > 106: // determined to be unnecessary and led to performance issues such as > 107: // those detailed in JDK-8143266 > 108: })); As above, I don't think this needs to be weak. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 334: > 332: private void updateTreeItem() { > 333: unregisterInvalidationListeners(graphicProperty()); > 334: treeItem = (getSkinnable() == null) ? null : getSkinnable().getTreeItem(); This is not needed if the weak listener change is reverted in the constructor. The cause for it being `null` is that the listener is now no longer removed by `dispose` where before (with `ListenerHelper` or `registerXXXListener`) it would have been. Also, I think when `dispose` is called, this skin should still do its utmost best to remove all listeners immediately. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 335: > 333: > 334: treeTableView.refresh(); > 335: Toolkit.getToolkit().firePulse(); I think cells should also be collectable in other situations, like replacing the row factory. Is it worth adding a test for that? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189429842 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189430267 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189434672 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189438781 From jhendrikx at openjdk.org Wed May 10 07:03:26 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 May 2023 07:03:26 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: <-ydEbko5RKU-X45mxlw2nwcF84hEmdHC7J-MlvO_KTs=.217e69da-1650-457b-b666-0f7cae2489b6@github.com> References: <-ydEbko5RKU-X45mxlw2nwcF84hEmdHC7J-MlvO_KTs=.217e69da-1650-457b-b666-0f7cae2489b6@github.com> Message-ID: On Tue, 9 May 2023 22:41:41 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - removed monkey tester changes >> - Merge remote-tracking branch 'origin/master' into 8307538.refresh >> - whitespace >> - updated test >> - variable tree cell fix >> - fixed size selector >> - list view page >> - fix and test >> - skin menu >> - refresh button > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 215: > >> 213: int right = 23; >> 214: int bottom = 37; >> 215: int left = 49; > > After the fix and test change, this test now fails for me. I'm not quite seeing why these changes are needed. How are they related to the memory leak? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1189436860 From jhendrikx at openjdk.org Wed May 10 07:07:19 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 10 May 2023 07:07:19 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:38:35 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/native-glass/win/KeyTable.cpp line 366: >> >>> 364: UINT keyChar = ::MapVirtualKeyEx(UINT(hardwareCode), 2, layout); >>> 365: // Filter out dead keys >>> 366: BOOL isDead = (keyChar & 0x80000000) != 0; >> >> Wouldn't `hardwareCode >= 0` already filter out dead keys since when the highest bit is set the value is negative? > > I just realized that I never actually said what `hardwareCode` means on this platform. > > A negative number means the `hardwareCode` isn't known (in other words, the KeyEvent wasn't constructed by glass). If it's not negative it's a Windows VK code that identifies the key the user pressed. That code doesn't reflect whether the key is dead or not. Here I'm asking what character that key would generate if pressed without any modifiers and ignoring it if the key is dead. I misread partially, somehow I read `keyChar` as the same as `hardwareCode`. LGTM then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1126#discussion_r1189443592 From lkostyra at openjdk.org Wed May 10 08:52:24 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 10 May 2023 08:52:24 GMT Subject: RFR: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 21:15:38 GMT, Andy Goryachev wrote: >> But I do think it would be a good idea to use `PlatformUtil` here, so maybe file a cleanup issue to look for places where we explicitly parse `os.name`, and consider calling the appropriate `PlatformUtil` method instead? > > +1 for PlatformUtil. Also +1 for `PlatformUtil`, I'll file a cleanup issue for that purpose ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1130#discussion_r1189567973 From lkostyra at openjdk.org Wed May 10 08:58:25 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 10 May 2023 08:58:25 GMT Subject: Integrated: 8278422: Replace use of deprecated single string variant of Runtime.exec method In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:12:09 GMT, Lukasz Kostyra wrote: > Calls of `Runtime.getRuntime().exec()` were changed to `String[]` variant. > > Only Windows and macOS parts were affected, tests work good on both platforms. > > I looked through the code and didn't find any other cases of `Runtime.getRuntime().exec(String)` being used, so that should cover all possible deprecation warnings for this issue. This pull request has now been integrated. Changeset: d8da8d8c Author: Lukasz Kostyra Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/d8da8d8c9d9945196e90adbc7343c5b528905623 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod 8278422: Replace use of deprecated single string variant of Runtime.exec method Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1130 From duke at openjdk.org Wed May 10 15:03:29 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 10 May 2023 15:03:29 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v2] In-Reply-To: References: Message-ID: > Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Rename new routine to canKeyGenerateCharacter, other review cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1126/files - new: https://git.openjdk.org/jfx/pull/1126/files/a2fd0046..8c3a5c09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=00-01 Stats: 18 lines in 9 files changed: 0 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/1126.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1126/head:pull/1126 PR: https://git.openjdk.org/jfx/pull/1126 From angorya at openjdk.org Wed May 10 15:24:24 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 15:24:24 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 06:54:35 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - removed monkey tester changes >> - Merge remote-tracking branch 'origin/master' into 8307538.refresh >> - whitespace >> - updated test >> - variable tree cell fix >> - fixed size selector >> - list view page >> - fix and test >> - skin menu >> - refresh button > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 334: > >> 332: private void updateTreeItem() { >> 333: unregisterInvalidationListeners(graphicProperty()); >> 334: treeItem = (getSkinnable() == null) ? null : getSkinnable().getTreeItem(); > > This is not needed if the weak listener change is reverted in the constructor. The cause for it being `null` is that the listener is now no longer removed by `dispose` where before (with `ListenerHelper` or `registerXXXListener`) it would have been. > > Also, I think when `dispose` is called, this skin should still do its utmost best to remove all listeners immediately. The problem is, `dispose()` is never called for cells discarded by the refresh() method. In the absence of explicit release, these cells are still listening - so using a weak listener in this case is, I think, the right approach. Adding explicit release per your (absolutely valid) suggestion is a good idea, but much, much more complicated task. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 335: > >> 333: >> 334: treeTableView.refresh(); >> 335: Toolkit.getToolkit().firePulse(); > > I think cells should also be collectable in other situations, like replacing the row factory. Is it worth adding a test for that? this test reflects the exact failure scenario described in the ticket. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1190070346 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1190071689 From angorya at openjdk.org Wed May 10 15:49:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 15:49:17 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. @nlisker would you be able to take a look at this please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542432716 From nlisker at openjdk.org Wed May 10 16:33:21 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 10 May 2023 16:33:21 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. I'm not familiar enough with these classes to review. Is there something specific you want me to look at? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542498502 From kcr at openjdk.org Wed May 10 16:36:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 16:36:19 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <9imkFpjKXwXI7NeFshlU2eH-cKjR_Lj40-ll9wRXrBY=.a6678a5f-6679-4f25-81a3-4ca8e0c06921@github.com> On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button I left a couple inline comments. I also wonder whether the `index` and `treeItem` properties need to be weak (I don't think they do). The failing test is something that will need to be tracked down. If I revert your changes to `treeTableRowWithFixedCellSizeShouldIgnoreVerticalPadding`, the test passes when that class is run by itself, but fails when the entire controls test suite is run. The modified test fails with that class is run by itself, but passes when the entire controls test suite is run. This suggests a possible problem where the (now weak) listeners are getting GCed sometimes but not others, and that whether or not it is GCed causes differences that are visible to the test. So either the test is relying on an implementation detail, or there is a functional problem caused by the listeners being GCed too early or not early enough (the latter could point to the need to remove them in dispose). ------------- PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1420989135 From kcr at openjdk.org Wed May 10 16:36:22 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 16:36:22 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 15:20:25 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 334: >> >>> 332: private void updateTreeItem() { >>> 333: unregisterInvalidationListeners(graphicProperty()); >>> 334: treeItem = (getSkinnable() == null) ? null : getSkinnable().getTreeItem(); >> >> This is not needed if the weak listener change is reverted in the constructor. The cause for it being `null` is that the listener is now no longer removed by `dispose` where before (with `ListenerHelper` or `registerXXXListener`) it would have been. >> >> Also, I think when `dispose` is called, this skin should still do its utmost best to remove all listeners immediately. > > The problem is, `dispose()` is never called for cells discarded by the refresh() method. > > In the absence of explicit release, these cells are still listening - so using a weak listener in this case is, I think, the right approach. Adding explicit release per your (absolutely valid) suggestion is a good idea, but much, much more complicated task. Even if you are using weak listeners, `dispose` should remove them. >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 335: >> >>> 333: >>> 334: treeTableView.refresh(); >>> 335: Toolkit.getToolkit().firePulse(); >> >> I think cells should also be collectable in other situations, like replacing the row factory. Is it worth adding a test for that? > > this test reflects the exact failure scenario described in the ticket. If it's easy to add another test for additional missing cases that would provide better coverage for your fix, it seems worth doing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1190136063 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1190138025 From kcr at openjdk.org Wed May 10 16:36:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 16:36:24 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: <-ydEbko5RKU-X45mxlw2nwcF84hEmdHC7J-MlvO_KTs=.217e69da-1650-457b-b666-0f7cae2489b6@github.com> Message-ID: On Wed, 10 May 2023 06:57:04 GMT, John Hendrikx wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 215: >> >>> 213: int right = 23; >>> 214: int bottom = 37; >>> 215: int left = 49; >> >> After the fix and test change, this test now fails for me. > > I'm not quite seeing why these changes are needed. How are they related to the memory leak? They shouldn't be needed. This points to a problem either with the fix, or a preexisting problem with this test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1190136710 From nlisker at openjdk.org Wed May 10 16:52:22 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 10 May 2023 16:52:22 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:17:52 GMT, John Hendrikx wrote: > Focused only on raw type problems, and removing casts that were no longer needed because of the changes. I started reviewing but there are too many files, which makes the GitHub interface unresponsive. Can you break it into 4 PRs of ~50 files chunks? Many of these are not trivial changes - finding the correct type requires understanding what's going on in the code. modules/javafx.graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java line 1: > 1: /* Removing unused constructors (and their dependent methods) will require someone to look at why they aren't used. modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 238: > 236: } > 237: > 238: BitSet other = (BitSet) c; Shouldn't it be ``? modules/javafx.graphics/src/main/java/com/sun/javafx/css/ParsedValueImpl.java line 71: > 69: containsLookupsFlag = false; > 70: } > 71: else if(obj instanceof ParsedValueImpl value) { Space after `if`s. modules/javafx.graphics/src/main/java/com/sun/javafx/css/ParsedValueImpl.java line 431: > 429: pvi.writeBinary(os, stringStore); > 430: } else { > 431: final ParsedValueImpl impl = new ParsedValueImpl<>((Object) pv.getValue(), (StyleConverter) pv.getConverter()); I'm getting a warning on the cast to `(StyleConverter)`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1095#pullrequestreview-1419538322 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1189190166 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1189195406 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1189196266 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1190157435 From kcr at openjdk.org Wed May 10 16:58:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 16:58:21 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. Maybe @prrace can be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542526500 From prr at openjdk.org Wed May 10 17:24:20 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 17:24:20 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. Seems fine. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1127#pullrequestreview-1421091371 From angorya at openjdk.org Wed May 10 17:39:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 17:39:21 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:55:38 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. >> >> Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - removed monkey tester changes > - Merge remote-tracking branch 'origin/master' into 8307538.refresh > - whitespace > - updated test > - variable tree cell fix > - fixed size selector > - list view page > - fix and test > - skin menu > - refresh button it looks like the test is unstable - it works fine in Eclipse, but sometimes fails with gradle. investigating. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1542573868 From kcr at openjdk.org Wed May 10 17:40:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 17:40:19 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: <6ImHR3BgfeKNuiznIaFi9RQ8ySdmtpX7PoabFusf8QM=.ca7a6b35-1bae-400f-ac79-2671605bed07@github.com> On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. The API looks good. Go ahead and create the CSR. The implementation looks correct, as does the manual test addition to MonkeyTester. Can you also add an automated test? ------------- PR Review: https://git.openjdk.org/jfx/pull/1127#pullrequestreview-1421112283 From kcr at openjdk.org Wed May 10 17:45:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 17:45:21 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. ~~It's definitely affected by GC, so I'd start by looking there. I can change whether the the test passes or fails by changing the heap size or adding a call to gc before each test.~~ UPDATE: THIS COMMENT WAS MEANT FOR ANOTHER PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542578303 From kcr at openjdk.org Wed May 10 17:46:22 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 17:46:22 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <1wMBPv9j7cwXSffqkTYCNOolrbOhgpOGacwuWzvjfYI=.48dedb13-63f2-4d5d-9eb6-1ea1e57a400e@github.com> On Wed, 10 May 2023 17:36:41 GMT, Andy Goryachev wrote: > it looks like the test is unstable - it works fine in Eclipse, but sometimes fails with gradle. investigating. It's definitely affected by GC, so I'd start by looking there. I can change whether the the test passes or fails by changing the heap size or adding a call to gc before each test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1129#issuecomment-1542580543 From angorya at openjdk.org Wed May 10 17:50:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 17:50:20 GMT Subject: RFR: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: <7IOY0xW4FNsfS_ZP8bo-svHcN4cu24nHvbrArsHBcwc=.266bca96-5ad4-40db-9e62-e05e12827444@github.com> On Wed, 10 May 2023 17:40:59 GMT, Kevin Rushforth wrote: > UPDATE: THIS COMMENT WAS MEANT FOR ANOTHER PR. we've all been there! :-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542585334 From duke at openjdk.org Wed May 10 19:07:05 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Wed, 10 May 2023 19:07:05 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls Message-ID: Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` ------------- Commit messages: - Merge branch 'master' into JDK-8307807-replace-system-getproperty-osname-platform-utils - replaced sensible spots of system getproperty os name with platform util Changes: https://git.openjdk.org/jfx/pull/1132/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307807 Stats: 37 lines in 5 files changed: 9 ins; 10 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From angorya at openjdk.org Wed May 10 20:48:22 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 20:48:22 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v2] In-Reply-To: References: Message-ID: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. 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 five additional commits since the last revision: - Merge branch 'master' into 8307363.underline - added test - use the same javadoc as in Text - whitespace - 8307363: text flow underline shape ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1127/files - new: https://git.openjdk.org/jfx/pull/1127/files/7a1aa4ef..53ad2540 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1127&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1127&range=00-01 Stats: 1496 lines in 21 files changed: 1300 ins; 136 del; 60 mod Patch: https://git.openjdk.org/jfx/pull/1127.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1127/head:pull/1127 PR: https://git.openjdk.org/jfx/pull/1127 From angorya at openjdk.org Wed May 10 20:54:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 20:54:54 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v2] In-Reply-To: References: Message-ID: <-d8DLooFbdUMCdEHAsCYCd_V5WiXEBhYmEP4Qgu1lyo=.4f6cfc87-a4dd-4ca3-8e98-5b4592dcd9d8@github.com> On Wed, 10 May 2023 20:48:22 GMT, Andy Goryachev wrote: >> Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using >> >> getRange(start, end, TextLayout.TYPE_UNDERLINE); >> >> >> which mirrors an existing method in Text with exactly the same signature. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into 8307363.underline > - added test > - use the same javadoc as in Text > - whitespace > - 8307363: text flow underline shape CSR created https://bugs.openjdk.org/browse/JDK-8307861 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1542794089 From duke at openjdk.org Wed May 10 20:56:53 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 10 May 2023 20:56:53 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient In-Reply-To: <7WjxnVC2jWKFM8J6iOxF-lgZ-WUcZ1htjbnBINC63eY=.4f138eca-c30c-4d09-b225-9200816b0fa2@github.com> References: <529YSbkPZY0-aVAigRPCuWPxZjtDNEW_D60pBakxP8o=.46c28694-5132-4190-a9aa-00652bcc6f06@github.com> <7WjxnVC2jWKFM8J6iOxF-lgZ-WUcZ1htjbnBINC63eY=.4f138eca-c30c-4d09-b225-9200816b0fa2@github.com> Message-ID: On Fri, 5 May 2023 20:20:02 GMT, John Hendrikx wrote: > > I'm not quite sold on having `notifyKey` and `notifyKeyEx` be two separate methods. Why not just have one? Not changing the existing call sites doesn't seem to be a sufficient reason to expand the toolkit API surface. > > I also think it isn't really needed; Mac and Linux can just ignore the extra parameter for now? I now realize that there's no reason for `notifyKey` and `notifyKeyEx` to have unique names since `GetMethodID` has no problem distinguishing between Java overloads. I'll be tweaking this PR to rename `notifyKeyEx` to `notifyKey` so I won't have to get rid of the clunky name in a separate pass. Mac and Linux will migrate naturally to the new version of `notifyKey` as I fix bugs related to accelerator handling. The remaining clients would be iOS and Monocle. If we're still determined to stamp out the older version it would make sense to tweak iOS at the same time as the Mac since that's where the cross-compilation would happen. Both versions of `notifyKey` are one-liners that pass their parameters on to the same internal routine (the older version just defaults the `hardwareCode`). I'm still not convinced that it's worth the effort to mess with iOS and Monocle to make the older version go away. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1126#issuecomment-1542796058 From almatvee at openjdk.org Wed May 10 22:24:56 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 10 May 2023 22:24:56 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 In-Reply-To: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Wed, 10 May 2023 02:11:19 GMT, Alexander Matveev wrote: > - libFFI updated to 3.4.4. > - No additional changes are done to the code. > - Tested on Linux, Windows x64 and macOS x64/aarch64. > - Windows x86 config files are updated, but no build/testing was done for 32-bit. 8306328: Update libFFI to 3.4.4 [v2] - Fixed whitespace issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1131#issuecomment-1542885053 From almatvee at openjdk.org Wed May 10 22:24:55 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 10 May 2023 22:24:55 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 Message-ID: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> - libFFI updated to 3.4.4. - No additional changes are done to the code. - Tested on Linux, Windows x64 and macOS x64/aarch64. - Windows x86 config files are updated, but no build/testing was done for 32-bit. ------------- Commit messages: - 8306328: Update libFFI to 3.4.4 [v2] - 8306328: Update libFFI to 3.4.4 Changes: https://git.openjdk.org/jfx/pull/1131/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306328 Stats: 475 lines in 21 files changed: 222 ins; 41 del; 212 mod Patch: https://git.openjdk.org/jfx/pull/1131.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1131/head:pull/1131 PR: https://git.openjdk.org/jfx/pull/1131 From kcr at openjdk.org Wed May 10 22:34:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 22:34:46 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: <9k2hFTZZnKg9c2YScsuNiAfNJ0g0HdaqPzLQh7jxOHc=.a3b4befc-89de-4365-8f20-81c09c842006@github.com> On Wed, 12 Apr 2023 16:50:38 GMT, Lukasz Kostyra wrote: > Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. > > Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. > > One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. > > Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. This fixes the problem, but there is one regression in behavior I noticed. To reproduce: 1. Run `DndTest` (in the same manual tests dir as the one you added) 2. Hold down the CMD key 3. Drag the "DRAG ME" label to the "DROP ME" (while holding down CMD) BUG: When you release the button, the drag does not complete. The expected behavior is that the drag completes with a transfer mode of "MOVE" ------------- PR Review: https://git.openjdk.org/jfx/pull/1089#pullrequestreview-1421453641 From kcr at openjdk.org Wed May 10 23:17:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 23:17:48 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:48:22 GMT, Andy Goryachev wrote: >> Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using >> >> getRange(start, end, TextLayout.TYPE_UNDERLINE); >> >> >> which mirrors an existing method in Text with exactly the same signature. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into 8307363.underline > - added test > - use the same javadoc as in Text > - whitespace > - 8307363: text flow underline shape Test looks good with a couple comments. I'll give it a quick test drive. tests/system/src/test/java/test/javafx/scene/text/TextFlowNodeTest.java line 57: > 55: } catch (InterruptedException ex) { > 56: Assert.fail("Unexpected exception: " + ex); > 57: } Can this be replaced with `Util.startup()`? tests/system/src/test/java/test/javafx/scene/text/TextFlowNodeTest.java line 70: > 68: PathElement[] p = f.underlineShape(0, 0); > 69: Assert.assertNotNull(p); > 70: Assert.assertEquals(p.length, 0); Arguments are switched (expected value comes first). ------------- PR Review: https://git.openjdk.org/jfx/pull/1127#pullrequestreview-1421479704 PR Review Comment: https://git.openjdk.org/jfx/pull/1127#discussion_r1190466485 PR Review Comment: https://git.openjdk.org/jfx/pull/1127#discussion_r1190466766 From angorya at openjdk.org Wed May 10 23:32:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 23:32:04 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v3] In-Reply-To: References: Message-ID: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1127/files - new: https://git.openjdk.org/jfx/pull/1127/files/53ad2540..8c997262 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1127&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1127&range=01-02 Stats: 14 lines in 1 file changed: 0 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1127.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1127/head:pull/1127 PR: https://git.openjdk.org/jfx/pull/1127 From angorya at openjdk.org Wed May 10 23:32:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 May 2023 23:32:06 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 23:12:50 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 five additional commits since the last revision: >> >> - Merge branch 'master' into 8307363.underline >> - added test >> - use the same javadoc as in Text >> - whitespace >> - 8307363: text flow underline shape > > tests/system/src/test/java/test/javafx/scene/text/TextFlowNodeTest.java line 57: > >> 55: } catch (InterruptedException ex) { >> 56: Assert.fail("Unexpected exception: " + ex); >> 57: } > > Can this be replaced with `Util.startup()`? "shoemaker's children go barefoot" ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1127#discussion_r1190472245 From nlisker at openjdk.org Thu May 11 00:48:50 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 11 May 2023 00:48:50 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Wed, 10 May 2023 18:47:16 GMT, Carl D?bbelin wrote: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Found an occurrences: * `com.sun.javafx.application.LauncherImpl` line 386. * `com.sun.media.jfxmediaimpl.HostUtils` seems to be recreating the `PlatformUtil` API, can probably be replaced. `"os.arch"` could be moved to `PlatformUtil` probably. * `com.sun.webkit.network.URLLoader` line 244. * `ClipboardExtImageTest` line 59. * `BigGlyphIDTest` line 39. * `INVISIBLE_GLYPH_IDTest` line 39. * There are occurrences in the apps folder in ensemble. Creating an enum for the OS is not a bad idea by the way. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java line 363: > 361: // On non-Windows systems, replace "/~/" with home directory path + "/". > 362: if (!PlatformUtil.isWindows() > 363: && protocol.equals("file")) { Can be on the same line now. ------------- PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1421506932 PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1190487281 From almatvee at openjdk.org Thu May 11 01:09:53 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 11 May 2023 01:09:53 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 [v2] In-Reply-To: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: > - libFFI updated to 3.4.4. > - No additional changes are done to the code. > - Tested on Linux, Windows x64 and macOS x64/aarch64. > - Windows x86 config files are updated, but no build/testing was done for 32-bit. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8306328: Update libFFI to 3.4.4 [v3] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1131/files - new: https://git.openjdk.org/jfx/pull/1131/files/34bc8000..fed6d204 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1131&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1131&range=00-01 Stats: 45 lines in 1 file changed: 45 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1131.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1131/head:pull/1131 PR: https://git.openjdk.org/jfx/pull/1131 From almatvee at openjdk.org Thu May 11 01:09:53 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 11 May 2023 01:09:53 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 In-Reply-To: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Wed, 10 May 2023 02:11:19 GMT, Alexander Matveev wrote: > - libFFI updated to 3.4.4. > - No additional changes are done to the code. > - Tested on Linux, Windows x64 and macOS x64/aarch64. > - Windows x86 config files are updated, but no build/testing was done for 32-bit. 8306328: Update libFFI to 3.4.4 [v3] - Updated libffi.md. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1131#issuecomment-1543012858 From duke at openjdk.org Thu May 11 02:46:47 2023 From: duke at openjdk.org (Martin Fox) Date: Thu, 11 May 2023 02:46:47 GMT Subject: RFR: 8089373: Translation from character to key code is not sufficient [v3] In-Reply-To: References: Message-ID: > Note: the Java-side changes in this PR are also in #694 which fixes the same issue (and more) on Linux. Unfortunately the Linux Robot code is not working making it difficult to test on that platform (see #718). > > KeyCharacterCombinations allow the specification of accelerators based on characters whose KeyCodes vary across keyboard layouts. For example, the + character is on KeyCode.EQUALS on a U.S. English layout, KeyCode.PLUS on a German layout, and KeyCode.DIGIT1 on a Mac Swiss German layout. KeyCharacterCombinations finds the correct KeyCode by calling `Toolkit.getKeyCodeForChar`. > > `getKeyCodeForChar` can only return one KeyCode for a given character so it can't easily handle characters which appear in more than one location, like + which is on the main keyboard and the numeric keypad. It's also reliant on KeyCodes which prevents KeyCharacterCombinations from working on keys with no codes (e.g. the base character contains a diacritic). It also relies on the platform to map from a character to a key which is the reverse of how key mapping normally works making it slow and/or imprecise to implement on Mac and Linux (Windows is the only platform with a system call to do this). > > This PR introduces a new way for a platform to pass key information to the Java core. `View.notifyKeyEx` takes an additional platform-specific `hardwareCode` which identifies the key and is tracked in a private field in the KeyEvent. This is opt-in; a platform can continue to call the old `View.notifyKey` method and allow the `hardwareCode` to default to -1. > > On the back-end `KeyCharacterCombination.match` calls the new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the KeyEvent information and sends it on to the Application. This is also opt-in; the default implementation falls back to the Application's `getKeyCodeForChar` call. Platforms which call `View.notifyKeyEx` will be handed the `hardwareCode` for the key in addition to the Java KeyCode. > > The new `View.notifyKeyEx` returns a boolean indicating whether the event was consumed or not. This plays no role here but will be used later to fix [JDK-8087863](https://bugs.openjdk.org/browse/JDK-8087863). > > For testing I've included the manual KeyboardTest app that also appears in PR #425. Tests with keypad combinations should now work. > > Note: this PR only fixes Windows. Fixes for Mac and Linux but can't be submitted until #425 and #718 are integrated. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Renamed notifyKeyEx to notifyKey ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1126/files - new: https://git.openjdk.org/jfx/pull/1126/files/8c3a5c09..4afb44fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1126&range=01-02 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1126.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1126/head:pull/1126 PR: https://git.openjdk.org/jfx/pull/1126 From kpk at openjdk.org Thu May 11 06:06:47 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 May 2023 06:06:47 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 9 May 2023 18:43:07 GMT, Andy Goryachev wrote: > There is one question whether it's possible to always initialize HitInfo.insertionIndex and remove the secondary computation from HitInfo.getInsertionIndex() > > I am not clear under which conditions it is not possible to initialize, and whether subsequent HitInfo.getInsertionIndex() would produce a meaningful result. > I think it should be possible to initialize insertionIndex always in `getHitInfo()` method. Only scenario now it is not getting initialized is when `lineIndex >= getLineCount()` is true and we don't check for text runs further and initialize `charIndex` using `getCharCount()` method. I'm not completely clear if removing the `insertionIndex` calculation from `HitInfo.getInsertionIndex()` wouldn't cause any issue. So kept that as well. Like you mentioned, this can be considered in a separate RFE I think. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1543388818 From kpk at openjdk.org Thu May 11 06:19:45 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 May 2023 06:19:45 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 9 May 2023 18:16:09 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address code review > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 425: > >> 423: public Hit getHitInfo(float x, float y) { >> 424: int charIndex = -1; >> 425: int insertionIndex = -1; > > [question] > > Currently, there are a few scenarios when a negative insertionIndex is passed down to HitInfo. This will trigger a similar (and probably incorrect) computation of the insertion index in HitInfo, see for example [JDK-8302511](https://bugs.openjdk.org/browse/JDK-8302511). > > My question is - should we instead resolve the insertion index always? After current fix, only scenario where `insertionIndex` not getting initialized will be when `lineIndex >= getLineCount()` is true. So even if `insertionIndex` -1, text will be null and `HitInfo.getInsertionIndex()` will not have any computation to perform. So we can resolve the insertion index always I think. Please let me know your thoughts on this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1190682049 From arapte at openjdk.org Thu May 11 06:53:51 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 11 May 2023 06:53:51 GMT Subject: RFR: 8304290: Some JNI calls made without checking exceptions in media In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 02:08:03 GMT, Alexander Matveev wrote: > - Added missing exception checks for JNI calls. > - Improved JNI error checking by checking for both exception and return value. > - Minor code clean up. Looks good overall, suggesting few minor changes. modules/javafx.media/src/main/native/jfxmedia/Locator/Locator.cpp line 66: > 64: mid_toString = env->GetMethodID(klass, "getStringLocation", "()Ljava/lang/String;"); > 65: env->DeleteLocalRef(klass); > 66: if (javaEnv.clearException() || mid_toString == NULL) The variable name can be changed. It holds id to `Locator.getStringLocation()`, so the variable name does not reflect it correctly. As the PR is touching this code, it seems ok to change. modules/javafx.media/src/main/native/jfxmedia/jni/JavaInputStreamCallbacks.cpp line 68: > 66: createConnectionHolder = env->GetMethodID(klass, "createConnectionHolder", "()Lcom/sun/media/jfxmedia/locator/ConnectionHolder;"); > 67: env->DeleteLocalRef(klass); > 68: if (javaEnv.reportException() || createConnectionHolder == 0) I would recommend to add as `(createConnectionHolder == NULL)`, similar to the below changes. And may be change previous instance and declaration of `createConnectionHolder`. modules/javafx.media/src/main/native/jfxmedia/jni/JavaInputStreamCallbacks.cpp line 73: > 71: > 72: jobject connectionHolder = env->CallObjectMethod(jLocator, createConnectionHolder); > 73: if (javaEnv.reportException() || NULL == connectionHolder) May be enclose in parenthesis, like the below changes : `(NULL == connectionHolder)` modules/javafx.media/src/main/native/jfxmedia/jni/JavaInputStreamCallbacks.cpp line 244: > 242: } > 243: > 244: javaEnv.reportException(); modules/javafx.media/src/main/native/jfxmedia/jni/JavaInputStreamCallbacks.cpp : 240 The `reportException()` method clears the exception and **prints** the exception message. So this change would result in behavior change. Is this change safe ? Similar change of removing `reportException()` can be done in `NeedBuffer()` method also. modules/javafx.media/src/main/native/jfxmedia/jni/JavaMediaWarningListener.cpp line 49: > 47: jclass mediaUtilsClass = pEnv->FindClass("com/sun/media/jfxmediaimpl/MediaUtils"); > 48: if (!javaEnv.clearException() && mediaUtilsClass != NULL) { > 49: jmethodID errorMethodID = pEnv->GetStaticMethodID(mediaUtilsClass, `errorMethodID` -> `nativeWarningMethodID` ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1094#pullrequestreview-1418209160 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1188351969 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1188473239 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1188478660 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1188581142 PR Review Comment: https://git.openjdk.org/jfx/pull/1094#discussion_r1190643308 From mhanl at openjdk.org Thu May 11 07:11:47 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 07:11:47 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v4] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: <1o18yN7GITP5aEJbPbL-uknlRx5e3grJddX8CXO6c8Y=.8e1e8703-8133-4729-96d0-5fd89ee085cb@github.com> On Mon, 17 Apr 2023 06:00:19 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc changes LGTM ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1421893416 From jvos at openjdk.org Thu May 11 08:10:51 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 11 May 2023 08:10:51 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 [v2] In-Reply-To: References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Thu, 11 May 2023 01:09:53 GMT, Alexander Matveev wrote: >> - libFFI updated to 3.4.4. >> - No additional changes are done to the code. >> - Tested on Linux, Windows x64 and macOS x64/aarch64. >> - Windows x86 config files are updated, but no build/testing was done for 32-bit. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8306328: Update libFFI to 3.4.4 [v3] I did some random comparisons between the original changes in libffi and the ones in this PR and all seem to match. I did a test build and run on MacOS x64, all good. I believe this code is only used on mac builds? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1131#issuecomment-1543533964 From jhendrikx at openjdk.org Thu May 11 11:28:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 May 2023 11:28:50 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics [v2] In-Reply-To: References: Message-ID: <1Rg71ekPkQ1ddKB0-OVIoN8TUjcxxfu2hUL5C7HvDQ4=.0c428a45-aae0-4010-8823-2416cd5e7570@github.com> > Focused only on raw type problems, and removing casts that were no longer needed because of the changes. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Remove 136 changed files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1095/files - new: https://git.openjdk.org/jfx/pull/1095/files/1828c178..b694fa99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1095&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1095&range=00-01 Stats: 832 lines in 130 files changed: 41 ins; 76 del; 715 mod Patch: https://git.openjdk.org/jfx/pull/1095.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1095/head:pull/1095 PR: https://git.openjdk.org/jfx/pull/1095 From jhendrikx at openjdk.org Thu May 11 11:38:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 May 2023 11:38:49 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 16:49:56 GMT, Nir Lisker wrote: > I started reviewing but there are too many files, which makes the GitHub interface unresponsive. Can you break it into 4 PRs of ~50 files chunks? > > Many of these are not trivial changes - finding the correct type requires understanding what's going on in the code. I've removed about 2/3rds of the changes. There is a lot of relations between files so after a removal by package to slim down the PR I still had to fix like 50 problems manually again to make it an error free build. The results will be that not all files I touched in this split PR will have all fixes applied, so you may encounter files that are partially fixed. Please focus on the warnings fixes, not on style issues that you happen to see on the same line; often the whole file will be using that style and fixing it one place just makes it even less consistent. Also note: `ParsedValue` is an interface that has been parameterized that probably should not have been. The way it is used means that the parameters are more detrimental than beneficial. `ParsedValue`s are often layered, and are often arrays that are not homogenous (meaning they must be of type `Object`). It is unfortunately public API, and removing the parameters at this stage is probably going to be hard. I've done my best to specify the parameters when they are homegenous (like a `ParsedValue{]` where all parsed results are `Size`s), but far more often the contents are mixed types and so all you can say is `?`... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1095#issuecomment-1543835089 From jhendrikx at openjdk.org Thu May 11 11:48:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 May 2023 11:48:49 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 22:42:19 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove 136 changed files > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 238: > >> 236: } >> 237: >> 238: BitSet other = (BitSet) c; > > Shouldn't it be ``? It makes no difference, it could be `BitSet` or `BitSet` or anything really, because the type `T` is never used as part of this method. `BitSet` is the shortest form in that case. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/ParsedValueImpl.java line 431: > >> 429: pvi.writeBinary(os, stringStore); >> 430: } else { >> 431: final ParsedValueImpl impl = new ParsedValueImpl<>((Object) pv.getValue(), (StyleConverter) pv.getConverter()); > > I'm getting a warning on the cast to `(StyleConverter)`. It's an unchecked cast warning. Since it's not a raw type warning, I've ignored these. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1191043446 PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1191045080 From jhendrikx at openjdk.org Thu May 11 11:55:54 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 11 May 2023 11:55:54 GMT Subject: RFR: JDK-8306490: Fix raw type warnings in graphics [v2] In-Reply-To: References: Message-ID: <5aZI-tHfu98pwK9UwvG67h-Nimxda3Mu2mKGpYwRbyg=.4587ed30-b85c-4c29-9926-35711f33bc5c@github.com> On Tue, 9 May 2023 22:31:53 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove 136 changed files > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java line 1: > >> 1: /* > > Removing unused constructors (and their dependent methods) will require someone to look at why they aren't used. These are just oversights. Any large code base that has evolved without enforcing warnings will be full of them because they're easy to miss. There is quite some unused code in private methods, and there will probably be far more when public methods (in private packages) are included in this analysis. I only removed it in this case because fixing raw type warnings in unused code is not very useful. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1095#discussion_r1191055148 From kpk at openjdk.org Thu May 11 12:00:59 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 May 2023 12:00:59 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v2] In-Reply-To: References: Message-ID: > The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. > > Able to run the test consistently without failure in Linux after the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add latch for tooltip hide and mouse move events ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1119/files - new: https://git.openjdk.org/jfx/pull/1119/files/53a008e6..1033f258 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1119&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1119&range=00-01 Stats: 13 lines in 1 file changed: 8 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1119.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1119/head:pull/1119 PR: https://git.openjdk.org/jfx/pull/1119 From kpk at openjdk.org Thu May 11 12:07:48 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 11 May 2023 12:07:48 GMT Subject: RFR: 8304922: [testbug] SliderTooltipNPETest fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 12:00:59 GMT, Karthik P K wrote: >> The test was failing on the first run and then it was not failing. Cause for the failure looked to be the UI state not getting updated. Hence added call to `Toolkit` `firePulse` method. >> >> Able to run the test consistently without failure in Linux after the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add latch for tooltip hide and mouse move events Since `consumeAutoHidingEvents` property value is asserted in the test, I'm suspecting that it is getting asserted before the mouse moves away from the slider and `consumeAutoHidingEvents` property value is reset to original value. Since the test is not failing consistently for me in Ubuntu, I believe possibility of product issue is less. Hence added a latch and small delay to make sure that the property value is asserted only after the mouse is moved. @kevinrushforth could you please check this fix. I have ran the test in Ubuntu 22.04 VM multiple times and test didn't fail. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1119#issuecomment-1543875208 From kevin.rushforth at oracle.com Thu May 11 12:18:12 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 May 2023 05:18:12 -0700 Subject: Result: New OpenJFX Reviewer: Andy Goryachev Message-ID: Voting for Andy Goryachev [1] to OpenJFX Reviewer [2] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#angorya [2] https://mail.openjdk.org/pipermail/openjfx-dev/2023-April/040036.html From kcr at openjdk.org Thu May 11 13:52:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 13:52:49 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v3] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 23:32:04 GMT, Andy Goryachev wrote: >> Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using >> >> getRange(start, end, TextLayout.TYPE_UNDERLINE); >> >> >> which mirrors an existing method in Text with exactly the same signature. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1127#pullrequestreview-1422641869 From kcr at openjdk.org Thu May 11 13:52:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 13:52:51 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v3] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 17:22:01 GMT, Phil Race wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > Seems fine. @prrace Can you re-review this when you get a chance? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1127#issuecomment-1544028803 From kcr at openjdk.org Thu May 11 14:07:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 14:07:51 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Thu, 11 May 2023 00:45:42 GMT, Nir Lisker wrote: > * ... `"os.arch"` could be moved to `PlatformUtil` probably. Creating additional methods for os.arch would be best done via a separate JBS enhancement / separate PR. > * `ClipboardExtImageTest` line 59. > * `BigGlyphIDTest` line 39. > * `INVISIBLE_GLYPH_IDTest` line 39. > * There are occurrences in the apps folder in ensemble. None of the above can or should be changed. They are applications that need to use only public API. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544048868 From duke at openjdk.org Thu May 11 15:05:47 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 15:05:47 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Carl D?bbelin has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8307807-replace-system-getproperty-osname-platform-utils' of https://github.com/EstelonAgarwaen/jfx into JDK-8307807-replace-system-getproperty-osname-platform-utils - fixed linebreak and used platform util in launcherimpl ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1132/files - new: https://git.openjdk.org/jfx/pull/1132/files/2f954d65..43c07589 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=00-01 Stats: 24 lines in 3 files changed: 21 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From duke at openjdk.org Thu May 11 15:05:49 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 15:05:49 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Wed, 10 May 2023 18:47:16 GMT, Carl D?bbelin wrote: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` I cannot use the PlatformUtils in the `com.sun.webkit.network.URLLoader` class, as the PlatformUtils are not Exported to the corresponding module. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544146865 From nlisker at openjdk.org Thu May 11 15:45:48 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 11 May 2023 15:45:48 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Thu, 11 May 2023 14:57:31 GMT, Carl D?bbelin wrote: > I cannot use the PlatformUtils in the `com.sun.webkit.network.URLLoader` class, as the PlatformUtils are not Exported to the corresponding module. I wonder if this was done on purpose. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544229212 From duke at openjdk.org Thu May 11 16:13:28 2023 From: duke at openjdk.org (Martin Fox) Date: Thu, 11 May 2023 16:13:28 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 16:50:38 GMT, Lukasz Kostyra wrote: > Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. > > Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. > > One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. > > Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m line 44: > 42: return self->dragOperation; > 43: } > 44: `sourceOperationMaskForDraggingContext` replaces the deprecated `draggingSourceOperationMaskForLocal:` over in GlassViewDelegate.m. There's some logic there that needs to be copied over here. Basically the Apple documentation on how the Cmd key filters the set of available operations doesn't match reality and we have to compensate for that. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 988: > 986: } > 987: > 988: if (image == nil && [pbItemTypes containsObject:NSPasteboardTypeFileURL]) `NSPasteboardTypeFileURL` was introduced in MacOS 10.13 and JavaFX is currently targeted at 10.12. The compiler caught this but the warning was lost in the sea of other warnings the Mac build generates. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1191383010 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1191393521 From duke at openjdk.org Thu May 11 16:14:12 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 16:14:12 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: <5cD2A5caXia5cXzBU69sdTz1CB9VRy5gAqhvJlv9Swg=.3e305117-980f-4dd2-8382-e6f27d6a4494@github.com> On Thu, 11 May 2023 15:43:30 GMT, Nir Lisker wrote: > > I cannot use the PlatformUtils in the `com.sun.webkit.network.URLLoader` class, as the PlatformUtils are not Exported to the corresponding module. > > I wonder if this was done on purpose. i assumed it was. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544280412 From kcr at openjdk.org Thu May 11 16:23:33 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 16:23:33 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: <5cD2A5caXia5cXzBU69sdTz1CB9VRy5gAqhvJlv9Swg=.3e305117-980f-4dd2-8382-e6f27d6a4494@github.com> References: <5cD2A5caXia5cXzBU69sdTz1CB9VRy5gAqhvJlv9Swg=.3e305117-980f-4dd2-8382-e6f27d6a4494@github.com> Message-ID: On Thu, 11 May 2023 16:11:44 GMT, Carl D?bbelin wrote: > > > I cannot use the PlatformUtils in the `com.sun.webkit.network.URLLoader` class, as the PlatformUtils are not Exported to the corresponding module. > > > > > > I wonder if this was done on purpose. > > i assumed it was. In this case, it just wasn't needed at the time `module-info.java` was created. There would be no problem adding `javafx.web` to the list of modules that `com.sun.javafx` is exported to. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544293105 From duke at openjdk.org Thu May 11 16:23:34 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 16:23:34 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: <5cD2A5caXia5cXzBU69sdTz1CB9VRy5gAqhvJlv9Swg=.3e305117-980f-4dd2-8382-e6f27d6a4494@github.com> Message-ID: On Thu, 11 May 2023 16:20:10 GMT, Kevin Rushforth wrote: > > > > I cannot use the PlatformUtils in the `com.sun.webkit.network.URLLoader` class, as the PlatformUtils are not Exported to the corresponding module. > > > > > > > > > I wonder if this was done on purpose. > > > > > > i assumed it was. > > In this case, it just wasn't needed at the time `module-info.java` was created. There would be no problem adding `javafx.web` to the list of modules that `com.sun.javafx` is exported to. then i will do so. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1544294221 From duke at openjdk.org Thu May 11 16:30:58 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 16:30:58 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: Message-ID: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: added export of javafx.base to javafx.web and added platform utils call in urlloader ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1132/files - new: https://git.openjdk.org/jfx/pull/1132/files/43c07589..91ac5783 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From kcr at openjdk.org Thu May 11 16:32:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 16:32:21 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: On Thu, 11 May 2023 15:48:39 GMT, Martin Fox wrote: >> Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. >> >> Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. >> >> One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. >> >> Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. > > modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m line 44: > >> 42: return self->dragOperation; >> 43: } >> 44: > > `sourceOperationMaskForDraggingContext` replaces the deprecated `draggingSourceOperationMaskForLocal:` over in GlassViewDelegate.m. There's some logic there that needs to be copied over here. Basically the Apple documentation on how the Cmd key filters the set of available operations doesn't match reality and we have to compensate for that. This sounds like it could be the reason for the functional regression in handling the CMD modifier while dragging. > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 988: > >> 986: } >> 987: >> 988: if (image == nil && [pbItemTypes containsObject:NSPasteboardTypeFileURL]) > > `NSPasteboardTypeFileURL` was introduced in MacOS 10.13 and JavaFX is currently targeted at 10.12. The compiler caught this but the warning was lost in the sea of other warnings the Mac build generates. Good catch (which reminds me that I need to get back to your warnings PR). This might misbehave on macOS 10.12 then, but I haven't seen a machine that old in a few years, so it would be difficult to test. We really should bump the minimum at some point (to at _least_ 10.14, but ideally to 11 to match what Apple currently supports, and to match what the minimum has always been for ARM-based Mac systems), so this seems like the right time to broach that subject. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1191426568 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1191431942 From kcr at openjdk.org Thu May 11 17:16:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 17:16:56 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> References: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> Message-ID: On Thu, 11 May 2023 16:30:58 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > added export of javafx.base to javafx.web and added platform utils call in urlloader Looks OK with two comments. .idea/jarRepositories.xml line 1: > 1: This is not relevant to the bug fix. You need to revert the addition of this file. modules/javafx.base/src/main/java/module-info.java line 53: > 51: javafx.fxml, > 52: javafx.media, > 53: javafx.swing, javafx.web; Minor: can you move `javafx.web` onto its own line to match the formatting in the rest of the file? ------------- PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1423080447 PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1191473561 PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1191472455 From duke at openjdk.org Thu May 11 17:24:09 2023 From: duke at openjdk.org (Glavo) Date: Thu, 11 May 2023 17:24:09 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> References: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> Message-ID: On Thu, 11 May 2023 16:30:58 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > added export of javafx.base to javafx.web and added platform utils call in urlloader modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatformFactory.java line 1: > 1: /* https://github.com/openjdk/jfx/blob/91ac578372e0676967151315556fa31556927725/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxPlatformFactory.java#L30-L31 redundant imports ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1191481439 From duke at openjdk.org Thu May 11 17:38:07 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 17:38:07 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v4] In-Reply-To: References: Message-ID: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: removed unneeded idea xml and imports, fixed line breaks in module info ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1132/files - new: https://git.openjdk.org/jfx/pull/1132/files/91ac5783..adff6534 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From kevin.rushforth at oracle.com Thu May 11 17:48:12 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 May 2023 10:48:12 -0700 Subject: Proposal: Bump the minimum version of macOS for which we target JavaFX Message-ID: I propose bumping the minimum version of macOS for which we target JavaFX. The current minimum version of macOS is: ARM (aarch64) : 11.0 -- this is the first version that Apple added ARM support Intel (x64) : 10.12 Apple hasn't supported 10.12 in several years (it went out of support in XXXXX), and there is an ongoing *and increasing) cost to our code base to keep building and targeting a system that old. See this PR comment [1] for the latest example. It is also a little awkward to have a different minimum version for the two different chip architectures. My preference is to change the minimum version for Mac / x64 to be macOS 11.0, matching both the currently oldest version of macOS supported by Apple, and also unifying the minimum for the two chip architectures. We could do that in one step or two steps. Option 1: JavaFX 21: Bump the minimum (for Intel platforms) to macOS 11 Option 2: JavaFX 21: Bump the minimum (for Intel platforms) to macOS 10.14 JavaFX 22: Bump the minimum (for Intel platforms) to macOS 11 There are of course other options, but one of those two seems best to me. Option 1 is more aggressive, but might cause some concerns, given that JavaFX 21 is an LTS. Option 2 is less aggressive, and still gets us away from the troublesome 10.12 release (and dropping 10.13 makes it easier to consider backporting Metal to 21 some day, since 10.14 is the minimum we can support). Thoughts? -- Kevin [1] https://git.openjdk.org/jfx/pull/1089#discussion_r1191393521 From kcr at openjdk.org Thu May 11 17:52:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 17:52:38 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:29:14 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 988: >> >>> 986: } >>> 987: >>> 988: if (image == nil && [pbItemTypes containsObject:NSPasteboardTypeFileURL]) >> >> `NSPasteboardTypeFileURL` was introduced in MacOS 10.13 and JavaFX is currently targeted at 10.12. The compiler caught this but the warning was lost in the sea of other warnings the Mac build generates. > > Good catch (which reminds me that I need to get back to your warnings PR). This might misbehave on macOS 10.12 then, but I haven't seen a machine that old in a few years, so it would be difficult to test. > > We really should bump the minimum at some point (to at _least_ 10.14, but ideally to 11 to match what Apple currently supports, and to match what the minimum has always been for ARM-based Mac systems), so this seems like the right time to broach that subject. I just sent a [proposal](https://mail.openjdk.org/pipermail/openjfx-dev/2023-May/040392.html) to openjfx-dev to bump the minimum version of macOS to either 10.14 or 11. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1191512491 From duke at openjdk.org Thu May 11 17:59:48 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 17:59:48 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v5] In-Reply-To: References: Message-ID: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: Delete jarRepositories.xml ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1132/files - new: https://git.openjdk.org/jfx/pull/1132/files/adff6534..97dfdb99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=03-04 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From mhanl at openjdk.org Thu May 11 18:01:43 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 18:01:43 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: <_u5h-CwGh_26IU-lkv8WOEtLIOgrrPvOBMzMKTtEtOY=.55a545bb-71f9-4f78-9262-863ca22507d4@github.com> Message-ID: On Thu, 11 May 2023 17:09:34 GMT, Kevin Rushforth wrote: >> Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: >> >> added export of javafx.base to javafx.web and added platform utils call in urlloader > > .idea/jarRepositories.xml line 1: > >> 1: > > This is not relevant to the bug fix. You need to revert the addition of this file. Note that when this PR https://github.com/openjdk/jfx/pull/1009 is merged, this file is inside the `.gitignore` and mistakes like this can not happen anymore. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1191521498 From mhanl at openjdk.org Thu May 11 18:04:42 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 18:04:42 GMT Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source code repository [v6] In-Reply-To: References: Message-ID: On Sat, 15 Apr 2023 23:32:40 GMT, Thiago Milczarek Sayao wrote: >> This PR does: >> >> - Remove specific Idea files and let it be imported from gradle; >> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes); >> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules)); >> - Automatically sets Copyright notice (updates year too); > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Update .gitignore > - Remove unrelated gitignore LGTM. And I agree, checkstyle can be used on every IDE afaik, so if we don't want to keep it in the root we may need (to use) another neutral folder for it. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1009#pullrequestreview-1423160486 From martin at martinfox.com Thu May 11 19:00:37 2023 From: martin at martinfox.com (Martin Fox) Date: Thu, 11 May 2023 12:00:37 -0700 Subject: Proposal: Bump the minimum version of macOS for which we target JavaFX In-Reply-To: References: Message-ID: > My preference is to change the minimum version for Mac / x64 to be macOS 11.0, matching both the currently oldest version of macOS supported by Apple, and also unifying the minimum for the two chip architectures. So no one else has to look this up: The last security update for macOS 10.12 was in September of 2019. It was released in 2016. The last security update for macOS 10.14 was in July of 2021. It was released in 2018. macOS 11.0 was released in November of 2020. Support is likely to end this year. 11.0 could be installed on MacBooks from 2013 and desktops from 2014 (with some exceptions). If there?s a Mac out there that just can?t upgrade to 11.0 that machine is getting a little long in the tooth. FWIW I?m using an iMac from late 2017 and running the latest OS just fine. I think ditching 10.x is the right move. Martin From mhanl at openjdk.org Thu May 11 19:15:40 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 19:15:40 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: On Mon, 8 May 2023 19:04:01 GMT, Andy Goryachev wrote: >> It's seems little tricky to choose an approach for this fix. >> >> - NOT snapping intermediate values (new approach): >> 1. It definitely seems correct NOT to snap intermediate values. >> 2. But currently, code Controls snap the intermediate values, >> 3. This PR seems to be the first change of snapping in a layout: >> => Will it regress if we have different approach in layout than in control ? >> I think No, It won?t regress. @Maran23 Can you please try it with this fix ? >> In that case, we can adapt the new way for layout and file a new JBS to refactor existing code. > > I think I now understand the snapping better, especially after discussion in https://github.com/openjdk/jfx/pull/1111 > > it looks like we should be operating in terms of final pixels, that is, in snapped coordinates. this might mean what we should not, generally, mix snapped and unsnapped values: > > result = snap(a) + snap(b); // ok > > result = snap(snap(a) + b) // also ok > > result = snap(snap(a) + b + c) // not ok, should be written as > result = snap(snap(a) + snap(b) + snap(c)) or > result = snap(a) + snap(b) + snap(c) > > What do you think? I agree but that is also what I do here, isn't it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191590759 From kevin.rushforth at oracle.com Thu May 11 19:22:39 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 May 2023 12:22:39 -0700 Subject: [External] : Re: Proposal: Bump the minimum version of macOS for which we target JavaFX In-Reply-To: References: Message-ID: <8d8511ac-e6a6-cb01-1508-1392e111b991@oracle.com> Thanks for the additional info. I had meant to look it up and add it prior to sending it out, but hit "send" too soon. My preference would be Option 1: change the minimum to macOS 11.0 in JavaFX 21. If there are some significant concerns over doing that, we could go with Option 2 as a fallback: change the minimum to 10.14 in 21 and to 11.0 in 22. -- Kevin On 5/11/2023 12:00 PM, Martin Fox wrote: >> My preference is to change the minimum version for Mac / x64 to be macOS 11.0, matching both the currently oldest version of macOS supported by Apple, and also unifying the minimum for the two chip architectures. > So no one else has to look this up: > > The last security update for macOS 10.12 was in September of 2019. It was released in 2016. > The last security update for macOS 10.14 was in July of 2021. It was released in 2018. > > macOS 11.0 was released in November of 2020. Support is likely to end this year. > > 11.0 could be installed on MacBooks from 2013 and desktops from 2014 (with some exceptions). If there?s a Mac out there that just can?t upgrade to 11.0 that machine is getting a little long in the tooth. FWIW I?m using an iMac from late 2017 and running the latest OS just fine. > > I think ditching 10.x is the right move. > > Martin > > > > > From mhanl at openjdk.org Thu May 11 19:45:39 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 19:45:39 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily Message-ID: This PR changes the `columnPopupMenu`, so that it is created lazily. The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. I also added many tests to ensure that everything still works (there are no tests for that area as of now). Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. ------------- Commit messages: - JDK-8307960: Create Table Column PopupMenu lazily Changes: https://git.openjdk.org/jfx/pull/1133/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307960 Stats: 449 lines in 4 files changed: 440 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1133.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1133/head:pull/1133 PR: https://git.openjdk.org/jfx/pull/1133 From angorya at openjdk.org Thu May 11 20:01:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 20:01:49 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> Message-ID: <-AJzDmalPjdQIfBFkFRXQbaThCJXC3i3w5wDuqT1FxI=.abd74768-73b2-432b-9d5b-8eabeb03af71@github.com> On Thu, 11 May 2023 19:12:52 GMT, Marius Hanl wrote: >> I think I now understand the snapping better, especially after discussion in https://github.com/openjdk/jfx/pull/1111 >> >> it looks like we should be operating in terms of final pixels, that is, in snapped coordinates. this might mean what we should not, generally, mix snapped and unsnapped values: >> >> result = snap(a) + snap(b); // ok >> >> result = snap(snap(a) + b) // also ok >> >> result = snap(snap(a) + b + c) // not ok, should be written as >> result = snap(snap(a) + snap(b) + snap(c)) or >> result = snap(a) + snap(b) + snap(c) >> >> What do you think? > > I agree but that is also what I do here, isn't it? here: yes! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191632124 From prr at openjdk.org Thu May 11 20:03:40 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 11 May 2023 20:03:40 GMT Subject: RFR: 8307363: TextFlow.underlineShape() [v3] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 23:32:04 GMT, Andy Goryachev wrote: >> Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using >> >> getRange(start, end, TextLayout.TYPE_UNDERLINE); >> >> >> which mirrors an existing method in Text with exactly the same signature. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1127#pullrequestreview-1423342306 From angorya at openjdk.org Thu May 11 20:01:46 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 20:01:46 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:56:43 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 five commits: >> >> - 8295078: Snap anchors as well >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry >> >>  Conflicts: >>  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java >> - 8295078: Replace JUnit4 with Junit5 imports >> - 8295078: Adjusted Copyright year >> - 8295078: TextField blurry when inside an TitledPane -> AnchorPane > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 342: > >> 340: private double computeChildWidth(Node child, Double leftAnchor, Double rightAnchor, double areaWidth, double height) { >> 341: if (leftAnchor != null && rightAnchor != null && child.isResizable()) { >> 342: return areaWidth - snappedLeftInset() - snappedRightInset() - leftAnchor - rightAnchor; > > should this line (and line 349) use snapped left/right anchors values? it is not immediately clear that left/right anchors are snapped. areaWidth, however, is not. should it be snappedSize? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191631451 From angorya at openjdk.org Thu May 11 20:01:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 20:01:48 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:29:48 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 349: > 347: private double computeChildHeight(Node child, Double topAnchor, Double bottomAnchor, double areaHeight, double width) { > 348: if (topAnchor != null && bottomAnchor != null && child.isResizable()) { > 349: return areaHeight - snappedTopInset() - snappedBottomInset() - topAnchor - bottomAnchor; same comment about areaHeight - should it be snapSize'd? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191631791 From mhanl at openjdk.org Thu May 11 20:11:45 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 20:11:45 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions In-Reply-To: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: <0pWJnyczpQUKF7L3SLs_iT8llcxIDm8Pn3e01nQ0Ewk=.3f91d541-04c7-4d3d-a5db-cd573811ea93@github.com> On Mon, 26 Dec 2022 03:03:50 GMT, Michael Strau? wrote: > On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. > > Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. LGTM, left some minor comments. modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. minor: this can be updated now ? modules/javafx.graphics/src/main/native-glass/win/GlassWindow.h line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. minor: this can be updated now ? tests/system/src/test/java/test/com/sun/glass/ui/InitialWindowSizeTest.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. minor: this can be updated now ? tests/system/src/test/java/test/com/sun/glass/ui/InitialWindowSizeTest.java line 40: > 38: import java.util.concurrent.CountDownLatch; > 39: > 40: import static org.junit.Assert.*; Since this is a new test class, I would recommend rather using JUnit5 (`org.junit.jupiter`). ------------- PR Review: https://git.openjdk.org/jfx/pull/984#pullrequestreview-1423350088 PR Review Comment: https://git.openjdk.org/jfx/pull/984#discussion_r1191639496 PR Review Comment: https://git.openjdk.org/jfx/pull/984#discussion_r1191639448 PR Review Comment: https://git.openjdk.org/jfx/pull/984#discussion_r1191637781 PR Review Comment: https://git.openjdk.org/jfx/pull/984#discussion_r1191639048 From duke at openjdk.org Thu May 11 20:19:38 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Thu, 11 May 2023 20:19:38 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: Message-ID: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: made launcherimpl one line ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1132/files - new: https://git.openjdk.org/jfx/pull/1132/files/97dfdb99..dc6630cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1132&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1132.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1132/head:pull/1132 PR: https://git.openjdk.org/jfx/pull/1132 From mhanl at openjdk.org Thu May 11 20:25:52 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 20:25:52 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:58:18 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 five commits: >> >> - 8295078: Snap anchors as well >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry >> >>  Conflicts: >>  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java >> - 8295078: Replace JUnit4 with Junit5 imports >> - 8295078: Adjusted Copyright year >> - 8295078: TextField blurry when inside an TitledPane -> AnchorPane > > modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 349: > >> 347: private double computeChildHeight(Node child, Double topAnchor, Double bottomAnchor, double areaHeight, double width) { >> 348: if (topAnchor != null && bottomAnchor != null && child.isResizable()) { >> 349: return areaHeight - snappedTopInset() - snappedBottomInset() - topAnchor - bottomAnchor; > > same comment about areaHeight - should it be snapSize'd? Well, given that we (should) snap everything including the calculation of the width, I expected that the `areaWidth` and `height`, which are basically `getWidth` and `getHeight` are already snapped. That was at least my thinking back then, not sure now. I need to check everything again since this was a while ago. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191651134 From mhanl at openjdk.org Thu May 11 20:25:49 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 May 2023 20:25:49 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v5] In-Reply-To: References: Message-ID: > The problem here is, that the `AnchorPane` does not use its snapped insets. > Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. > > Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. > Line 2995 in `modena.css`: > > .titled-pane > .content > AnchorPane { > -fx-padding: 0.8em; > } > > which translates to 9.6px. > > EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry - 8295078: Snap anchors as well - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry  Conflicts:  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java - 8295078: Replace JUnit4 with Junit5 imports - 8295078: Adjusted Copyright year - 8295078: TextField blurry when inside an TitledPane -> AnchorPane ------------- Changes: https://git.openjdk.org/jfx/pull/910/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=04 Stats: 183 lines in 3 files changed: 153 ins; 6 del; 24 mod Patch: https://git.openjdk.org/jfx/pull/910.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/910/head:pull/910 PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Thu May 11 20:54:43 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 20:54:43 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. Reviewer: @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1133#issuecomment-1544662572 From nlisker at openjdk.org Thu May 11 20:13:39 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 11 May 2023 20:13:39 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v5] In-Reply-To: References: Message-ID: <9zC1DHGbkJgUZkoirsbfjDxGG0ffEws8Ndt71HKFzww=.f11e4385-43d2-42f1-b542-cef78ba099dc@github.com> On Thu, 11 May 2023 17:59:48 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > Delete jarRepositories.xml Looks good. Do you want to replace `HostUtils`'s OS detection with `PlatformUtil` (or were they split on purpose)? modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 388: > 386: > 387: if (clz == null && PlatformUtil.isMac() > 388: && Normalizer.isNormalized(className, Normalizer.Form.NFD)) { Can also be in 1 line. ------------- PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1423355943 PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1191639526 From angorya at openjdk.org Thu May 11 21:25:44 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 21:25:44 GMT Subject: Integrated: 8307363: TextFlow.underlineShape() In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:50:35 GMT, Andy Goryachev wrote: > Adding TextFlow.underlineShape() to add support for a spellchecker-like decoration, using > > getRange(start, end, TextLayout.TYPE_UNDERLINE); > > > which mirrors an existing method in Text with exactly the same signature. This pull request has now been integrated. Changeset: 604fc262 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/604fc26219a10114c22aea5062bad228a34dc7c0 Stats: 147 lines in 3 files changed: 136 ins; 5 del; 6 mod 8307363: TextFlow.underlineShape() Reviewed-by: prr, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1127 From almatvee at openjdk.org Thu May 11 21:51:02 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 11 May 2023 21:51:02 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 [v2] In-Reply-To: References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: <93Iv1VaBYSdRmJpGdjxVVUdojvohFmQu83zDI2EPsoo=.dfe34d29-0b6e-4a13-b913-92dc8e6bd13f@github.com> On Thu, 11 May 2023 01:09:53 GMT, Alexander Matveev wrote: >> - libFFI updated to 3.4.4. >> - No additional changes are done to the code. >> - Tested on Linux, Windows x64 and macOS x64/aarch64. >> - Windows x86 config files are updated, but no build/testing was done for 32-bit. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8306328: Update libFFI to 3.4.4 [v3] No, this code is used on macOS and Windows. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1131#issuecomment-1544722133 From angorya at openjdk.org Thu May 11 22:26:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 22:26:53 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v3] In-Reply-To: References: Message-ID: > Fixed a memory leak in TreeTableView by using WeakInvalidationListener (which is the right approach in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. > > Added Refresh buttons and Skin menu to the Monkey Tester (will expand these to other controls as a part next MT update). Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: - back to register listener - weak lambdas are getting collected ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/2b1ae8b7..4b9563cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=01-02 Stats: 43 lines in 2 files changed: 18 ins; 5 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Thu May 11 22:31:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 22:31:19 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: <3X02LeYTL-PhzNutFX0CgP68hL9Suwt2AJJ4BNE0sSg=.13078258-46e0-4f27-bd05-4c631d9f1224@github.com> On Wed, 10 May 2023 16:14:43 GMT, Kevin Rushforth wrote: >> The problem is, `dispose()` is never called for cells discarded by the refresh() method. >> >> In the absence of explicit release, these cells are still listening - so using a weak listener in this case is, I think, the right approach. Adding explicit release per your (absolutely valid) suggestion is a good idea, but much, much more complicated task. > > Even if you are using weak listeners, `dispose` should remove them. revered back to using register*Listener, which creates a weak listener and also disconnects them in dispose() ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1191748091 From angorya at openjdk.org Thu May 11 22:38:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 22:38:58 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: References: Message-ID: > Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: one more test case ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/4b9563cf..75ff9a8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=02-03 Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Thu May 11 22:38:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 22:38:59 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 16:16:36 GMT, Kevin Rushforth wrote: >> this test reflects the exact failure scenario described in the ticket. > > If it's easy to add another test for additional missing cases that would provide better coverage for your fix, it seems worth doing. added one more test case, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1191750638 From angorya at openjdk.org Thu May 11 23:02:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 May 2023 23:02:53 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> On Thu, 11 May 2023 20:20:01 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java line 349: >> >>> 347: private double computeChildHeight(Node child, Double topAnchor, Double bottomAnchor, double areaHeight, double width) { >>> 348: if (topAnchor != null && bottomAnchor != null && child.isResizable()) { >>> 349: return areaHeight - snappedTopInset() - snappedBottomInset() - topAnchor - bottomAnchor; >> >> same comment about areaHeight - should it be snapSize'd? > > Well, given that we (should) snap everything including the calculation of the width, I expected that the `areaWidth` and `height`, which are basically `getWidth` and `getHeight` are already snapped. > That was at least my thinking back then, not sure now. I need to check everything again since this was a while ago. :) I wonder. This might be a contrived example: what would happen if the parent containing the TitledPane is unsnapped, but TitledPane is? In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191763338 From swpalmer at gmail.com Thu May 11 23:37:09 2023 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 11 May 2023 19:37:09 -0400 Subject: [External] : Re: Proposal: Bump the minimum version of macOS for which we target JavaFX In-Reply-To: <8d8511ac-e6a6-cb01-1508-1392e111b991@oracle.com> References: <8d8511ac-e6a6-cb01-1508-1392e111b991@oracle.com> Message-ID: <64870D4D-C6F0-44A3-A2C3-B644F24ECC78@gmail.com> I think Option 1 makes the most sense. Specially since JDK 21 is LTS. Do we want to be stuck with OS 10.x through the entire LTS period? Scott > On May 11, 2023, at 3:23 PM, Kevin Rushforth wrote: > > ?Thanks for the additional info. I had meant to look it up and add it prior to sending it out, but hit "send" too soon. > > My preference would be Option 1: change the minimum to macOS 11.0 in JavaFX 21. > > If there are some significant concerns over doing that, we could go with Option 2 as a fallback: change the minimum to 10.14 in 21 and to 11.0 in 22. > > -- Kevin > > > On 5/11/2023 12:00 PM, Martin Fox wrote: >>> My preference is to change the minimum version for Mac / x64 to be macOS 11.0, matching both the currently oldest version of macOS supported by Apple, and also unifying the minimum for the two chip architectures. >> So no one else has to look this up: >> >> The last security update for macOS 10.12 was in September of 2019. It was released in 2016. >> The last security update for macOS 10.14 was in July of 2021. It was released in 2018. >> >> macOS 11.0 was released in November of 2020. Support is likely to end this year. >> >> 11.0 could be installed on MacBooks from 2013 and desktops from 2014 (with some exceptions). If there?s a Mac out there that just can?t upgrade to 11.0 that machine is getting a little long in the tooth. FWIW I?m using an iMac from late 2017 and running the latest OS just fine. >> >> I think ditching 10.x is the right move. >> >> Martin From jhendrikx at openjdk.org Fri May 12 07:46:57 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 07:46:57 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> Message-ID: On Thu, 11 May 2023 23:00:34 GMT, Andy Goryachev wrote: >> Well, given that we (should) snap everything including the calculation of the width, I expected that the `areaWidth` and `height`, which are basically `getWidth` and `getHeight` are already snapped. >> That was at least my thinking back then, not sure now. I need to check everything again since this was a while ago. :) > > I wonder. > > This might be a contrived example: what would happen if the parent containing the TitledPane is unsnapped, but TitledPane is? > In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). There would otherwise be little point in setting a parent to unsnapped if one didn't also turn off snapping on all the children. Note that we tested what happens when you put snapped content in an unsnapped container; currently this results in all children to be misaligned (not pixel aligned). I think that's the only real solution, as trying to resnap your positions when your parent container is misaligning you would otherwise need to introduce some kind of flexible border that "absorbs" some of the misalignment so the rest of the content can be snapped again... Basically, there are three strategies for children when dealing with an unsnapped parent: - Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions - Ignore snapping when a parent is unsnapped and use standard calculations - Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192025301 From jhendrikx at openjdk.org Fri May 12 07:51:58 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 07:51:58 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> Message-ID: On Fri, 12 May 2023 07:44:04 GMT, John Hendrikx wrote: >> I wonder. >> >> This might be a contrived example: what would happen if the parent containing the TitledPane is unsnapped, but TitledPane is? >> In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. > > I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). > > There would otherwise be little point in setting a parent to unsnapped if one didn't also turn off snapping on all the children. > > Note that we tested what happens when you put snapped content in an unsnapped container; currently this results in all children to be misaligned (not pixel aligned). I think that's the only real solution, as trying to resnap your positions when your parent container is misaligning you would otherwise need to introduce some kind of flexible border that "absorbs" some of the misalignment so the rest of the content can be snapped again... > > Basically, there are three strategies for children when dealing with an unsnapped parent: > > - Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions > - Ignore snapping when a parent is unsnapped and use standard calculations > - Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border > In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. And when that happens, you can't do anything about it either. If you adjust the width, you risk not covering the entire area that the parent gave you (or more if you round up), and if you use it in any calculations you need to resnap any values resulting from it, and you would still end up with some dead space that your snapped calculations can't cover... The only real solution seems to be to treat snapping like visibility IMHO. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192030858 From jhendrikx at openjdk.org Fri May 12 08:03:00 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 08:03:00 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: <-AJzDmalPjdQIfBFkFRXQbaThCJXC3i3w5wDuqT1FxI=.abd74768-73b2-432b-9d5b-8eabeb03af71@github.com> References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> <-AJzDmalPjdQIfBFkFRXQbaThCJXC3i3w5wDuqT1FxI=.abd74768-73b2-432b-9d5b-8eabeb03af71@github.com> Message-ID: On Thu, 11 May 2023 19:58:46 GMT, Andy Goryachev wrote: >> I agree but that is also what I do here, isn't it? > > here: yes! This looks good to me, the snapping as explained by Andy is how it should be. A source of error can be still be that floating point calculations can introduce small deviations so sometimes it is needed to resnap after doing calculations that seem harmless (ie. `snappedSize * 10` or `snappedWidth - snappedLeftInset` may need resnapping). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192039051 From jhendrikx at openjdk.org Fri May 12 08:02:58 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 08:02:58 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v5] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:25:49 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/910#pullrequestreview-1423975118 From jhendrikx at openjdk.org Fri May 12 08:22:54 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 08:22:54 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: References: Message-ID: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> On Thu, 11 May 2023 22:38:58 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > one more test case I confirmed the tests fail before the changes in `setupTreeTableViewListeners` and pass with those changes. Removing the constructor and dispose changes did not fail any tests. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 103: > 101: updateTreeItem(); > 102: // There used to be an isDirty = true statement here, but this was > 103: // determined to be unnecessary and led to performance issues such as These changes don't fail the test when I undo them. As said before, they're unnecessary. Reasoning: they register on `TreeTableRow`, which is associated with the skin directly. If their lifecycles don't match, then `dispose` will take care of unregistering. If their lifecycles do match, then they go out of scope at the same time. Unless you prefer using the `register` functions, I think this change should be undone. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 161: > 159: fixedCellSize = p.get(); > 160: fixedCellSizeEnabled = fixedCellSize > 0; > 161: } The `null` check on the property is not needed, properties never return `null`. I would suggest just calling the getter: `t.getFixedCellSize()`. ------------- Changes requested by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1423999964 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192054924 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192057917 From jhendrikx at openjdk.org Fri May 12 08:22:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 08:22:56 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v2] In-Reply-To: <3X02LeYTL-PhzNutFX0CgP68hL9Suwt2AJJ4BNE0sSg=.13078258-46e0-4f27-bd05-4c631d9f1224@github.com> References: <3X02LeYTL-PhzNutFX0CgP68hL9Suwt2AJJ4BNE0sSg=.13078258-46e0-4f27-bd05-4c631d9f1224@github.com> Message-ID: On Thu, 11 May 2023 22:28:27 GMT, Andy Goryachev wrote: >> Even if you are using weak listeners, `dispose` should remove them. > > revered back to using register*Listener, which creates a weak listener and also disconnects them in dispose() I removed this change, and ran the tests, no failures occurred, which leads me to believe that this change is unnecessary or needs a test to cover this case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192058926 From arapte at openjdk.org Fri May 12 10:28:01 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 May 2023 10:28:01 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v2] In-Reply-To: References: Message-ID: > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Review Comment: Add enum ToggleState ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1088/files - new: https://git.openjdk.org/jfx/pull/1088/files/29dbf6c8..b5beba53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=00-01 Stats: 42 lines in 3 files changed: 32 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1088.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1088/head:pull/1088 PR: https://git.openjdk.org/jfx/pull/1088 From arapte at openjdk.org Fri May 12 10:36:12 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 May 2023 10:36:12 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: Message-ID: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem - Review Comment: Add enum ToggleState - Add CheckBoxTreeItem role and TOGGLE_STATE attribute ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1088/files - new: https://git.openjdk.org/jfx/pull/1088/files/b5beba53..2d89e9fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=01-02 Stats: 11728 lines in 134 files changed: 10044 ins; 1404 del; 280 mod Patch: https://git.openjdk.org/jfx/pull/1088.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1088/head:pull/1088 PR: https://git.openjdk.org/jfx/pull/1088 From arapte at openjdk.org Fri May 12 10:40:56 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 May 2023 10:40:56 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 15:08:30 GMT, Kevin Rushforth wrote: >> Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem >> - Review Comment: Add enum ToggleState >> - Add CheckBoxTreeItem role and TOGGLE_STATE attribute > > modules/javafx.controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java line 495: > >> 493: state = 2; >> 494: } else if (checkBox.isSelected()) { >> 495: state = 1; > > I recommend using platform-independent constants here (possibly an enum as discussed earlier). Added a new enum `ToggleState`. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 1588: > >> 1586: if (isDisposed()) return 0; >> 1587: if (getAttribute(ROLE) == AccessibleRole.CHECK_BOX_TREE_ITEM) { >> 1588: return (int)getAttribute(TOGGLE_STATE); > > I recommend mapping the return value of `getAttribute(TOGGLE_STATE)`, which should be a platform-independent value, to one of the three Windows-specific values. Otherwise you are making an assumption that might not hold for other platforms (e.g., macOS). Added a new enum `ToggleState`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192205065 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192204855 From arapte at openjdk.org Fri May 12 10:41:01 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 12 May 2023 10:41:01 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 16:46:54 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 357: >> >>> 355: * @since 21 >>> 356: */ >>> 357: TOGGLE_STATE(Integer.class), >> >> Would a dedicated enum be a better choice here? > > Yes, that might be cleaner. In any case, we should not hard-code or specify int values that are Windows-specific. I recommend defining this as a platform-independent attribute and then mapping it in the Windows platform code. Added a new enum `ToggleState`. It is added as a member of `AccessibleAttribute` : Please see if it is a good place for the enum. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192203187 From mstrauss at openjdk.org Fri May 12 11:11:55 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 12 May 2023 11:11:55 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v5] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:25:49 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane I think we should document the insights gained in this discussion (and others) somewhere in JavaFX, since snapping is such a difficult thing to get right, and the source of so many visual artifacts. ------------- PR Comment: https://git.openjdk.org/jfx/pull/910#issuecomment-1545573926 From lkostyra at openjdk.org Fri May 12 11:16:52 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 May 2023 11:16:52 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: <2O7Wc_hVRJqWx6OSQttzNJef7NRTm_orBlkX6fhcgv4=.28f52375-5d01-47cf-b3a8-ea779761e508@github.com> On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. Left a couple very minor style-related comments modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableHeaderRowShim.java line 38: > 36: > 37: public static ContextMenu getColumnPopupMenu(TableHeaderRow tableHeaderRow) { > 38: return tableHeaderRow.getColumnPopupMenu(); Minor: I would keep `tr` instead of `tableHeaderRow` for consistency with already existing static method. modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableHeaderRowShim.java line 42: > 40: > 41: public static Pane getCornerRegion(TableHeaderRow tableHeaderRow) { > 42: return tableHeaderRow.getCornerRegion(); As above ------------- PR Review: https://git.openjdk.org/jfx/pull/1133#pullrequestreview-1424274489 PR Review Comment: https://git.openjdk.org/jfx/pull/1133#discussion_r1192230921 PR Review Comment: https://git.openjdk.org/jfx/pull/1133#discussion_r1192230993 From lkostyra at openjdk.org Fri May 12 11:40:50 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 May 2023 11:40:50 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:19:38 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > made launcherimpl one line Looks good, tests are passing as expected on all platforms ------------- Marked as reviewed by lkostyra (Author). PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1424313030 From lkostyra at openjdk.org Fri May 12 11:58:52 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 May 2023 11:58:52 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:24:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m line 44: >> >>> 42: return self->dragOperation; >>> 43: } >>> 44: >> >> `sourceOperationMaskForDraggingContext` replaces the deprecated `draggingSourceOperationMaskForLocal:` over in GlassViewDelegate.m. There's some logic there that needs to be copied over here. Basically the Apple documentation on how the Cmd key filters the set of available operations doesn't match reality and we have to compensate for that. > > This sounds like it could be the reason for the functional regression in handling the CMD modifier while dragging. Good catch, I'll take a look into that ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1192270396 From lkostyra at openjdk.org Fri May 12 11:58:53 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 May 2023 11:58:53 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop In-Reply-To: References: Message-ID: On Thu, 11 May 2023 17:49:49 GMT, Kevin Rushforth wrote: >> Good catch (which reminds me that I need to get back to your warnings PR). This might misbehave on macOS 10.12 then, but I haven't seen a machine that old in a few years, so it would be difficult to test. >> >> We really should bump the minimum at some point (to at _least_ 10.14, but ideally to 11 to match what Apple currently supports, and to match what the minimum has always been for ARM-based Mac systems), so this seems like the right time to broach that subject. > > I just sent a [proposal](https://mail.openjdk.org/pipermail/openjfx-dev/2023-May/040392.html) to openjfx-dev to bump the minimum version of macOS to either 10.14 or 11. I tried to cover as many cases as possible with this part since `canInitWithPasteboard` is no longer possible (new API requires not having any items in the Pasteboard, as it puts them in there for you). I can ultimately remove this part, I think it won't hurt the change as it is - only some drag images based from URLs might instead be shown as a generic document icon, which is not a big deal. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1192269783 From angorya at openjdk.org Fri May 12 14:48:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 14:48:54 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: Message-ID: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> On Thu, 11 May 2023 20:19:38 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > made launcherimpl one line modules/javafx.graphics/src/main/java/com/sun/glass/ui/Platform.java line 67: > 65: } > 66: > 67: if (PlatformUtil.isMac()) { this change might be ok, but it is not strictly equivalent. before, MAC path would be selected if os.name lowercase starts from either "mac" or "darwin", after the change, only starts with "Mac". Do we want to support "darwin"? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192471257 From angorya at openjdk.org Fri May 12 14:58:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 14:58:56 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> Message-ID: On Fri, 12 May 2023 14:45:43 GMT, Andy Goryachev wrote: >> Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: >> >> made launcherimpl one line > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Platform.java line 67: > >> 65: } >> 66: >> 67: if (PlatformUtil.isMac()) { > > this change might be ok, but it is not strictly equivalent. > before, MAC path would be selected if os.name lowercase starts from either "mac" or "darwin", after the change, only starts with "Mac". > Do we want to support "darwin"? I'd still prefer to use PlatformUtil, since this is a cleaner solution that the variety of methods used before: osNameLowerCase.startsWith("wind" "ios".equals(System.getProperty("os.name") osName.startsWith("Windows" osName.startsWith("Mac OS" ("os.name").toLowerCase().indexOf("win") ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192483282 From kcr at openjdk.org Fri May 12 15:03:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 15:03:56 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> Message-ID: <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> On Fri, 12 May 2023 14:56:29 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Platform.java line 67: >> >>> 65: } >>> 66: >>> 67: if (PlatformUtil.isMac()) { >> >> this change might be ok, but it is not strictly equivalent. >> before, MAC path would be selected if os.name lowercase starts from either "mac" or "darwin", after the change, only starts with "Mac". >> Do we want to support "darwin"? > > I'd still prefer to use PlatformUtil, since this is a cleaner solution that the variety of methods used before: > > osNameLowerCase.startsWith("wind" > "ios".equals(System.getProperty("os.name") > osName.startsWith("Windows" > osName.startsWith("Mac OS" > ("os.name").toLowerCase().indexOf("win") I initially had the same thought. What this actually highlights, though, is the danger of having this sort of check scattered in multiple places, but done differently. If it was important that "darwin" be recognized (it isn't), then it would be wrong to have this check recognize it, but all other "isMac" checks not recognize it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192488457 From lkostyra at openjdk.org Fri May 12 15:05:01 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 12 May 2023 15:05:01 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v2] In-Reply-To: References: Message-ID: > Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. > > Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. > > One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. > > Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - GlassViewDelegate: Return to deprecated *PboardType symbols New NSPasteboardType* symbols were introduced starting 10.13, and we're targetting 10.12. This deprecation should probably be resolved once we target macOS 10.13+. Old NS*PboardType symbols do not have an equivalent of NSPasteboardTypeFileURL, so this branch was removed. - GlassPasteboard: Correct macOS version information in comments New DnD API was introduced starting macOS 10.7, not 10.14 - GlassView: Remove deprecated draggingSourceOperationMask - DndTest: Update instructions On Mac to enable moving you must press Cmd, not Shift. - Restore logic responsible for Cmd key support - Merge branch 'master' into dnd_multiple_items-JDK-8233955 - Add DnD Multiple File manual test - Fix preview position; cleanup code - Add image previews and finish DnD code Fixes issues with tests caused by first commit. Removes old code used as placeholder. - Migrate DnD native code to DraggingSession API Previous implementation used dragImage call which is deprecated since macOS 10.14. Additionally, 10.14 introduced a restriction not allowing for more than one drag item in the Pasteboard. This change fixes crashes caused by old API use when DnD-ing more than one item. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1089/files - new: https://git.openjdk.org/jfx/pull/1089/files/939a0d2f..fa42b1b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1089&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1089&range=00-01 Stats: 10564 lines in 133 files changed: 8844 ins; 1440 del; 280 mod Patch: https://git.openjdk.org/jfx/pull/1089.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1089/head:pull/1089 PR: https://git.openjdk.org/jfx/pull/1089 From kcr at openjdk.org Fri May 12 15:11:57 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 15:11:57 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v5] In-Reply-To: <9zC1DHGbkJgUZkoirsbfjDxGG0ffEws8Ndt71HKFzww=.f11e4385-43d2-42f1-b542-cef78ba099dc@github.com> References: <9zC1DHGbkJgUZkoirsbfjDxGG0ffEws8Ndt71HKFzww=.f11e4385-43d2-42f1-b542-cef78ba099dc@github.com> Message-ID: On Thu, 11 May 2023 20:11:07 GMT, Nir Lisker wrote: > Looks good. Do you want to replace `HostUtils`'s OS detection with `PlatformUtil` (or were they split on purpose)? I think this might be a good change, but I'll leave it up to @EstelonAgarwaen . To minimize the intrusion, you could just change the implementation of the four `HostUtils` methods that check `os.name` to call the equivalent `PlatformUtil` methods rather than changing all of the call sites. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1545896369 From angorya at openjdk.org Fri May 12 15:14:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:14:59 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v5] In-Reply-To: References: Message-ID: <7zdgwe5d9dymsr4gOqBVdKM59-b64iq9m1J94Kc3Eug=.28281167-da6a-4303-8dbc-cc91315f030e@github.com> On Thu, 11 May 2023 20:25:49 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane Thank you @hjohn for a detailed writeup! I fully agree with the idea of explaining snapping in some form of "application note", let research the subject of where and how we can do that. I suppose the next step would be to review other layouts to see if they fail with snapping, especially with fractional scale (hm, HBox). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/910#pullrequestreview-1424706254 From angorya at openjdk.org Fri May 12 15:17:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:17:50 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> Message-ID: On Fri, 12 May 2023 15:00:55 GMT, Kevin Rushforth wrote: >> I'd still prefer to use PlatformUtil, since this is a cleaner solution that the variety of methods used before: >> >> osNameLowerCase.startsWith("wind" >> "ios".equals(System.getProperty("os.name") >> osName.startsWith("Windows" >> osName.startsWith("Mac OS" >> ("os.name").toLowerCase().indexOf("win") > > I initially had the same thought. What this actually highlights, though, is the danger of having this sort of check scattered in multiple places, but done differently. If it was important that "darwin" be recognized (it isn't), then it would be wrong to have this check recognize it, but all other "isMac" checks not recognize it. Do we officially support Darwin OS? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192504164 From duke at openjdk.org Fri May 12 15:20:55 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Fri, 12 May 2023 15:20:55 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> Message-ID: On Fri, 12 May 2023 15:15:09 GMT, Andy Goryachev wrote: >> I initially had the same thought. What this actually highlights, though, is the danger of having this sort of check scattered in multiple places, but done differently. If it was important that "darwin" be recognized (it isn't), then it would be wrong to have this check recognize it, but all other "isMac" checks not recognize it. > > Do we officially support Darwin OS? Darwin OS was a precursor of OS X that followed after rhapsody. As its own OS it stopped being supported in 2002. since kevin was discussing to only support MacOS 11 or newer in jfx 21, i think its safe to say we dont support this old pre version. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192507771 From angorya at openjdk.org Fri May 12 15:26:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:26:52 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> Message-ID: On Fri, 12 May 2023 15:18:29 GMT, Carl D?bbelin wrote: >> Do we officially support Darwin OS? > > Darwin OS was a precursor of OS X that followed after rhapsody. As its own OS it stopped being supported in 2002. since kevin was discussing to only support MacOS 11 or newer in jfx 21, i think its safe to say we dont support this old pre version. Wikipedia says it's currently at the level of macOS Ventura 22.4.0 | March 27, 2023 | macOS 13.3, iOS 16.4, iPadOS 16.4, watchOS 9.4 and tvOS 16.4 https://en.wikipedia.org/wiki/Darwin_(operating_system)#Darwin_20_onwards ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192513689 From duke at openjdk.org Fri May 12 15:31:52 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Fri, 12 May 2023 15:31:52 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> Message-ID: On Fri, 12 May 2023 15:24:27 GMT, Andy Goryachev wrote: >> Darwin OS was a precursor of OS X that followed after rhapsody. As its own OS it stopped being supported in 2002. since kevin was discussing to only support MacOS 11 or newer in jfx 21, i think its safe to say we dont support this old pre version. > > Wikipedia says it's currently at the level of macOS Ventura > > 22.4.0 | March 27, 2023 | macOS 13.3, iOS 16.4, iPadOS 16.4, watchOS 9.4 and tvOS 16.4 > > https://en.wikipedia.org/wiki/Darwin_(operating_system)#Darwin_20_onwards Darwin as its own OS stopped existing after 2002 (at least german wilipedia sais so) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192518148 From angorya at openjdk.org Fri May 12 15:47:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:47:56 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> References: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> Message-ID: <-9rQO3sXP58bTl6t2QHINArT93PsOpW_G3tXiRHo2b8=.42e002a0-2019-41cf-969e-a1eaf1587342@github.com> On Fri, 12 May 2023 08:15:50 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> one more test case > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 161: > >> 159: fixedCellSize = p.get(); >> 160: fixedCellSizeEnabled = fixedCellSize > 0; >> 161: } > > The `null` check on the property is not needed, properties never return `null`. I would suggest just calling the getter: `t.getFixedCellSize()`. good point, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192534644 From angorya at openjdk.org Fri May 12 15:59:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:59:02 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v5] In-Reply-To: References: Message-ID: > Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/75ff9a8f..a4cdc148 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Fri May 12 15:59:06 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:59:06 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> References: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> Message-ID: <-cFQhuCf46uZFSr6andO6e5m_IgemUSiFtoMoKiXbRk=.2daae781-f51d-48af-a193-c3f62bb42abe@github.com> On Fri, 12 May 2023 08:13:01 GMT, John Hendrikx wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> one more test case > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 103: > >> 101: updateTreeItem(); >> 102: // There used to be an isDirty = true statement here, but this was >> 103: // determined to be unnecessary and led to performance issues such as > > These changes don't fail the test when I undo them. As said before, they're unnecessary. > > Reasoning: they register on `TreeTableRow`, which is associated with the skin directly. If their lifecycles don't match, then `dispose` will take care of unregistering. If their lifecycles do match, then they go out of scope at the same time. > > Unless you prefer using the `register` functions, I think this change should be undone. Even though I don't particularly like register*Listener() because of its asymmetric nature (when it comes to removing listeners), here we do need to create weak listeners that get unregistered upon `dispose()`. We need weak listeners because TreeTableView does not explicitly "disconnect" unused cells (e.g. refresh()), and we need `dispose()` due to skin life cycle. So, in this particular case, I think this change should be ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192542423 From angorya at openjdk.org Fri May 12 15:59:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 15:59:57 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:19:38 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > made launcherimpl one line thank you for clarification! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1424779107 From kcr at openjdk.org Fri May 12 15:59:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 15:59:59 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: <2_0o5pP9rOS3kM2BgEe0v_CwrvTBZJU84OqWYJIGskg=.05f80a13-5a6b-4a64-8deb-e4158763ffbf@github.com> <4277YfHuFPL1VMfkqEh-7HJjyhugAKfIbbZZ0rmM-es=.0ba42882-af97-433f-b706-83c28aaaedfe@github.com> Message-ID: On Fri, 12 May 2023 15:28:51 GMT, Carl D?bbelin wrote: >> Wikipedia says it's currently at the level of macOS Ventura >> >> 22.4.0 | March 27, 2023 | macOS 13.3, iOS 16.4, iPadOS 16.4, watchOS 9.4 and tvOS 16.4 >> >> https://en.wikipedia.org/wiki/Darwin_(operating_system)#Darwin_20_onwards > > Darwin as its own OS stopped existing after 2002 (at least german wilipedia sais so) Apple still calls their macOS Kernel "Darwin", but that's not the important bit. If it was _ever_ reported as the value of `os.name` (I'm not sure it was), it would have been in the pre-Java 6 time frame. It's a long-dead holdover. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1132#discussion_r1192544257 From mhanl at openjdk.org Fri May 12 16:15:48 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 May 2023 16:15:48 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v6] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:19:38 GMT, Carl D?bbelin wrote: >> Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > made launcherimpl one line Looks good to me too. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1132#pullrequestreview-1424801952 From kcr at openjdk.org Fri May 12 16:22:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 16:22:54 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> Message-ID: <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> On Fri, 12 May 2023 07:49:29 GMT, John Hendrikx wrote: >> I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). >> >> There would otherwise be little point in setting a parent to unsnapped if one didn't also turn off snapping on all the children. >> >> Note that we tested what happens when you put snapped content in an unsnapped container; currently this results in all children to be misaligned (not pixel aligned). I think that's the only real solution, as trying to resnap your positions when your parent container is misaligning you would otherwise need to introduce some kind of flexible border that "absorbs" some of the misalignment so the rest of the content can be snapped again... >> >> Basically, there are three strategies for children when dealing with an unsnapped parent: >> >> - Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions >> - Ignore snapping when a parent is unsnapped and use standard calculations >> - Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border > >> In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. > > And when that happens, you can't do anything about it either. If you adjust the width, you risk not covering the entire area that the parent gave you (or more if you round up), and if you use it in any calculations you need to resnap any values resulting from it, and you would still end up with some dead space that your snapped calculations can't cover... > > The only real solution seems to be to treat snapping like visibility IMHO. > I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). One complication with this is that the `snapToPixel` property is on `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't have that property. What you describe _might_ be OK as long as you ignore any parent that isn't a `Region` when asking the question "are all my ancestors have `snapToPixel`". > Basically, there are three strategies for children when dealing with an unsnapped parent: > > * Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). > * Ignore snapping when a parent is unsnapped and use standard calculations A change to do this _might_ be OK, with the caveat I mentioned above about non-Region parents, but this would need careful analysis. As part of this, I would want to understand the motivation for doing this (i.e., what is the benefit?). > * Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border Yeah, this doesn't seems like a good idea. If you want to explore this further, you could file a new RFE to consider making a change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192574561 From duke at openjdk.org Fri May 12 16:29:50 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Fri, 12 May 2023 16:29:50 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v5] In-Reply-To: References: <9zC1DHGbkJgUZkoirsbfjDxGG0ffEws8Ndt71HKFzww=.f11e4385-43d2-42f1-b542-cef78ba099dc@github.com> Message-ID: On Fri, 12 May 2023 15:09:35 GMT, Kevin Rushforth wrote: > > Looks good. Do you want to replace `HostUtils`'s OS detection with `PlatformUtil` (or were they split on purpose)? > > I think this might be a good change, but I'll leave it up to @EstelonAgarwaen . To minimize the intrusion, you could just change the implementation of the four `HostUtils` methods that check `os.name` to call the equivalent `PlatformUtil` methods rather than changing all of the call sites. Can you open a ticket in the Bugtracker? Ill create a separate PR for it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1545996996 From duke at openjdk.org Fri May 12 17:06:56 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Fri, 12 May 2023 17:06:56 GMT Subject: Integrated: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: <31zByOInfuVficUGHmnCcDRafo_jwqFlXbZbzc1a5VE=.0da6e1a2-5ea4-42c6-82f9-bc46bd0230d9@github.com> On Wed, 10 May 2023 18:47:16 GMT, Carl D?bbelin wrote: > Replaced querying of `System.getProperty("os.name")` to check for OS with the use of the methods provided by `PlatformUtils` This pull request has now been integrated. Changeset: 70953643 Author: Carl D?bbelin Committer: Marius Hanl URL: https://git.openjdk.org/jfx/commit/70953643a9dc05c76924fc4c602ee39038d71295 Stats: 45 lines in 8 files changed: 10 ins; 13 del; 22 mod 8307807: Replace use of System.getProperty("os.name") with PlatformUtil calls Reviewed-by: lkostyra, angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1132 From angorya at openjdk.org Fri May 12 17:21:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 17:21:58 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> Message-ID: On Fri, 12 May 2023 16:20:35 GMT, Kevin Rushforth wrote: >>> In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. >> >> And when that happens, you can't do anything about it either. If you adjust the width, you risk not covering the entire area that the parent gave you (or more if you round up), and if you use it in any calculations you need to resnap any values resulting from it, and you would still end up with some dead space that your snapped calculations can't cover... >> >> The only real solution seems to be to treat snapping like visibility IMHO. > >> I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). > > One complication with this is that the `snapToPixel` property is on `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't have that property. What you describe _might_ be OK as long as you ignore any parent that isn't a `Region` when asking the question "are all my ancestors have `snapToPixel`". > >> Basically, there are three strategies for children when dealing with an unsnapped parent: >> >> * Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions > > Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). > >> * Ignore snapping when a parent is unsnapped and use standard calculations > > A change to do this _might_ be OK, with the caveat I mentioned above about non-Region parents, but this would need careful analysis. As part of this, I would want to understand the motivation for doing this (i.e., what is the benefit?). > >> * Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border > > Yeah, this doesn't seems like a good idea. > > If you want to explore this further, you could file a new RFE to consider making a change. I think it's probably not worth doing. When the application developer sets snapping off when it's on by default, they do it for a reason, so the current behavior is the right one. May be they want to smooth some transition during animation (a-la scrolling ticker tape), who knows. FX gives this choice at per-Region basis for this kind of flexibility, otherwise there would be one global setting, right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192625442 From angorya at openjdk.org Fri May 12 17:50:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 17:50:49 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: <12OWNxtX3Sd773wuTcnt4TSVLa6D8cqQIJ9ypdrI2pY=.65f05f24-f6a7-477b-957a-cf4dbda3bcc8@github.com> On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. There is also a similar property in `TreeTableView` which also goes through the same code path in `TableHeaderRow`. Should we have a separate test or set of tests for TTV? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1133#issuecomment-1546083536 From angorya at openjdk.org Fri May 12 17:54:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 17:54:54 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. Verified that the code works as expected with Tree- and TableView, with no ill effects (on Mac), using https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Comment: https://git.openjdk.org/jfx/pull/1133#issuecomment-1546087494 From angorya at openjdk.org Fri May 12 17:57:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 17:57:48 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. Would it be possible to add test(s) for TreeTableView? Otherwise, looks good. edit: tests are there, I must be blind! ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1133#pullrequestreview-1424901774 From angorya at openjdk.org Fri May 12 17:57:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 17:57:50 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: <2O7Wc_hVRJqWx6OSQttzNJef7NRTm_orBlkX6fhcgv4=.28f52375-5d01-47cf-b3a8-ea779761e508@github.com> References: <2O7Wc_hVRJqWx6OSQttzNJef7NRTm_orBlkX6fhcgv4=.28f52375-5d01-47cf-b3a8-ea779761e508@github.com> Message-ID: On Fri, 12 May 2023 11:08:57 GMT, Lukasz Kostyra wrote: >> This PR changes the `columnPopupMenu`, so that it is created lazily. >> >> The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. >> This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. >> >> I also added many tests to ensure that everything still works (there are no tests for that area as of now). >> >> Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. > > modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableHeaderRowShim.java line 38: > >> 36: >> 37: public static ContextMenu getColumnPopupMenu(TableHeaderRow tableHeaderRow) { >> 38: return tableHeaderRow.getColumnPopupMenu(); > > Minor: I would keep `tr` instead of `tableHeaderRow` for consistency with already existing static method. I would too - avoids wrapping the line, and there is no need to spell the name for a one line method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1133#discussion_r1192630713 From angorya at openjdk.org Fri May 12 18:00:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 18:00:52 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1133#pullrequestreview-1424942681 From angorya at openjdk.org Fri May 12 18:03:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 18:03:50 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. @Maran23 I'll re-approve if you want to make minor changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1133#issuecomment-1546097480 From jhendrikx at openjdk.org Fri May 12 18:16:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 18:16:50 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: <-cFQhuCf46uZFSr6andO6e5m_IgemUSiFtoMoKiXbRk=.2daae781-f51d-48af-a193-c3f62bb42abe@github.com> References: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> <-cFQhuCf46uZFSr6andO6e5m_IgemUSiFtoMoKiXbRk=.2daae781-f51d-48af-a193-c3f62bb42abe@github.com> Message-ID: On Fri, 12 May 2023 15:52:56 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 103: >> >>> 101: updateTreeItem(); >>> 102: // There used to be an isDirty = true statement here, but this was >>> 103: // determined to be unnecessary and led to performance issues such as >> >> These changes don't fail the test when I undo them. As said before, they're unnecessary. >> >> Reasoning: they register on `TreeTableRow`, which is associated with the skin directly. If their lifecycles don't match, then `dispose` will take care of unregistering. If their lifecycles do match, then they go out of scope at the same time. >> >> Unless you prefer using the `register` functions, I think this change should be undone. > > Even though I don't particularly like register*Listener() because of its asymmetric nature (when it comes to removing listeners), here we do need to create weak listeners that get unregistered upon `dispose()`. We need weak listeners because TreeTableView does not explicitly "disconnect" unused cells (e.g. refresh()), and we need `dispose()` due to skin life cycle. > > So, in this particular case, I think this change should be ok. Sorry, I think we may be misunderstanding each other. I'm specifically talking about the two listeners added in `TreeTableRowSkin`'s constructor on `indexProperty` and `treeItemProperty`. These are part of the `TreeTableRow` which is also discarded when `refresh` is called. 1) The test passes if these changes are reverted. This is a clear indication that either the test is insufficient, or that your assumption, that these must be weak, is incorrect. If you can construct a test that requires these listeners to be weak, then I think the changes are warranted. 2) At the risk of stating the obvious, the listeners in the constructor added using `ListenerHelper` are also correctly removed in `dispose`. `ListenerHelper` does this in a similar way to the `register` methods. 3) The `indexProperty` and `treeItemProperty` listeners are attached to the `TreeTableRow`, not the `TreeTableView`. The refresh function replaces the entire row, including the skin. There is no need to use weak listeners for this purpose. Compare this to the listeners that are attached to the `TreeTableView` or the `VirtualFlow`; these have a much longer lifecycle and can survive multiple refreshes and row factory replacements, and hence should be weak (for now). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192669636 From jhendrikx at openjdk.org Fri May 12 18:37:54 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 18:37:54 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> Message-ID: On Fri, 12 May 2023 17:19:29 GMT, Andy Goryachev wrote: > I think it's probably not worth doing. When the application developer sets snapping off when it's on by default, they do it for a reason, so the current behavior is the right one. May be they want to smooth some transition during animation (a-la scrolling ticker tape), who knows. > > FX gives this choice at per-Region basis for this kind of flexibility, otherwise there would be one global setting, right? For sure it shouldn't be a global setting, and the per Region choice seems absolutely the right one. What I was talking about is more how sensible it would be for children of an unsnapped Region to still use snapping logic, and if it shouldn't work similar to how visibility works (ie. if a parent is invisible, all its children are invisible, regardless of those children's individual visible status). If the scrolling ticker tape you mentioned contains any other children, the user probably wants snapping off for those as well as the ticker tape would otherwise not be as smooth as it could be; if the parent region is misaligned, all the children (if snapped) would still advance by an exact multiple of pixels, but they would always fall in the same spot between pixels. Also, if the speed is not a nice pixel multiple (ie. 4.5 pixels per frame) then the children would sometimes move 4 pixels, sometimes 5. It's not truly a big issue, just something that may be unexpected. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192685485 From jhendrikx at openjdk.org Fri May 12 18:42:52 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 18:42:52 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> Message-ID: On Fri, 12 May 2023 16:20:35 GMT, Kevin Rushforth wrote: >>> In this case getWidth() may not be snapped since the titled pane has been laid out by an unsnapped parent. >> >> And when that happens, you can't do anything about it either. If you adjust the width, you risk not covering the entire area that the parent gave you (or more if you round up), and if you use it in any calculations you need to resnap any values resulting from it, and you would still end up with some dead space that your snapped calculations can't cover... >> >> The only real solution seems to be to treat snapping like visibility IMHO. > >> I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). > > One complication with this is that the `snapToPixel` property is on `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't have that property. What you describe _might_ be OK as long as you ignore any parent that isn't a `Region` when asking the question "are all my ancestors have `snapToPixel`". > >> Basically, there are three strategies for children when dealing with an unsnapped parent: >> >> * Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions > > Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). > >> * Ignore snapping when a parent is unsnapped and use standard calculations > > A change to do this _might_ be OK, with the caveat I mentioned above about non-Region parents, but this would need careful analysis. As part of this, I would want to understand the motivation for doing this (i.e., what is the benefit?). > >> * Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border > > Yeah, this doesn't seems like a good idea. > > If you want to explore this further, you could file a new RFE to consider making a change. @kevinrushforth it probably isn't worth pursuing a change in the child/parent snapping logic right now, at least not without some compelling case. First I think snapping is rarely disabled (I never have, despite working on graphics heavy JavaFX applications). Second, one can already get the (possibly more) desired situation by taking care all children are unsnapped as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192691370 From john.hendrikx at gmail.com Fri May 12 19:02:04 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 12 May 2023 21:02:04 +0200 Subject: Developer documentation Message-ID: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights were gained in the snapping logic.? Michael Strauss suggested documenting this, and I thought we may as well discuss this on the mailing list instead of continuing the discussion in that PR. In my normal line of work, I usually encourage projects to include developer documentation as part of the Git repository. This allows any developer to access and modify the documentation easily, and allows you to keep documentation in sync with relevant commits (and one can ask developers to do so as part of the PR). The documentation is provided in markdown format and is usually stored in a /doc folder. If there are multiple modules, there can be specialized doc folders per module with a top level doc folder which contains an index.md linking all the docs together, and containing documentation that is not module specific. The documentation is intended for developers only, not for users of JavaFX, and hence does not need to be published. Markdown files can either be read directly in your IDE of choice or online via GitHub/GitLab. The build documentation may be a good candidate to place there as well. So, my suggestion would be: - Create a top level /doc folder, and create module level /doc folders as needed when relevant documentation is written - In each /doc folder there is an index.md file that links to all documentation in that folder - A higher level index.md also contains links to child indexes - Consider moving the build and any onboarding documentation there - The top level README.md should have a link to /doc/index.md - Use only GitHub supported markdown features --John From andy.goryachev at oracle.com Fri May 12 19:12:48 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 12 May 2023 19:12:48 +0000 Subject: Developer documentation In-Reply-To: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: I think this is a great idea! Some projects use a separate wiki, but sometimes it backfires when domain name changes or wiki software gets updated. Making certain parts of documentation such as these notes, a part of the code repository not only eliminates these failure modes, but provides additional benefit of doc review along with the code review, documentation in sync with the code, and ability to diff the changes. Github markdown is a fairly new feature, sometimes a bit complicated to use (tables), but it does get rendered by Github and some IDEs (Eclipse, for example). I second John's suggestion, but also I am curious as to what other people think. -andy From: openjfx-dev on behalf of John Hendrikx Date: Friday, May 12, 2023 at 12:02 To: openjfx-dev at openjdk.org Subject: Developer documentation In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights were gained in the snapping logic. Michael Strauss suggested documenting this, and I thought we may as well discuss this on the mailing list instead of continuing the discussion in that PR. In my normal line of work, I usually encourage projects to include developer documentation as part of the Git repository. This allows any developer to access and modify the documentation easily, and allows you to keep documentation in sync with relevant commits (and one can ask developers to do so as part of the PR). The documentation is provided in markdown format and is usually stored in a /doc folder. If there are multiple modules, there can be specialized doc folders per module with a top level doc folder which contains an index.md linking all the docs together, and containing documentation that is not module specific. The documentation is intended for developers only, not for users of JavaFX, and hence does not need to be published. Markdown files can either be read directly in your IDE of choice or online via GitHub/GitLab. The build documentation may be a good candidate to place there as well. So, my suggestion would be: - Create a top level /doc folder, and create module level /doc folders as needed when relevant documentation is written - In each /doc folder there is an index.md file that links to all documentation in that folder - A higher level index.md also contains links to child indexes - Consider moving the build and any onboarding documentation there - The top level README.md should have a link to /doc/index.md - Use only GitHub supported markdown features --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri May 12 19:42:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 19:42:49 GMT Subject: RFR: JDK-8307807 Replace use of System.getProperty("os.name") with PlatformUtil calls [v5] In-Reply-To: References: <9zC1DHGbkJgUZkoirsbfjDxGG0ffEws8Ndt71HKFzww=.f11e4385-43d2-42f1-b542-cef78ba099dc@github.com> Message-ID: On Fri, 12 May 2023 16:26:42 GMT, Carl D?bbelin wrote: > > > Looks good. Do you want to replace `HostUtils`'s OS detection with `PlatformUtil` (or were they split on purpose)? > > > > > > I think this might be a good change, but I'll leave it up to @EstelonAgarwaen . To minimize the intrusion, you could just change the implementation of the four `HostUtils` methods that check `os.name` to call the equivalent `PlatformUtil` methods rather than changing all of the call sites. > > Can you open a ticket in the Bugtracker? Ill create a separate PR for it. https://bugs.openjdk.org/browse/JDK-8308028 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1132#issuecomment-1546201775 From angorya at openjdk.org Fri May 12 19:57:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 19:57:57 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute Testing with VoiceOver on Mac M1 Ventura 13.3.1(a): undetermined checkbox is pronounced as "mixed checkbox" - is this expected behavior? Also, probably unrelated to this PR: the outlines placed by VoiceOver are shifted to the wrong positions on the secondary monitor, for all nodes in the javafx window. For Chrome, the positioning is correct which makes me believe there might be a problem with FX. Also, the VoiceOver popup (black thing with white outline) inexplicably spans two monitors, though I think it might be a problem with VoiceOver: ![Screenshot 2023-05-12 at 12 46 03](https://github.com/openjdk/jfx/assets/107069028/99a0bee1-6be3-4ba2-b1e6-6d503e0445c7) my setup is: secondary monitor (scale=1) is above the primary (scale=2) modules/javafx.controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java line 498: > 496: state = ToggleState.CHECKED; > 497: } > 498: return state; very minor, a question of style. i would avoid double assignment by doing this: if (checkBox.isIndeterminate()) { return ToggleState.INDETERMINATE; } else if (checkBox.isSelected()) { return ToggleState.CHECKED; } else { return ToggleState.UNCHECKED; } modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java line 369: > 367: AccessibleRole.TREE_ITEM, > 368: AccessibleRole.CHECK_BOX_TREE_ITEM, > 369: AccessibleRole.TREE_TABLE_ROW [question] is the order of elements significant in any way? modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java line 761: > 759: > 760: AccessibleRole role = (AccessibleRole) getAttribute(ROLE); > 761: if (role == AccessibleRole.TREE_ITEM || role == AccessibleRole.CHECK_BOX_TREE_ITEM || role == AccessibleRole.TREE_TABLE_ROW) { could a `switch` statement be used here instead? modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 303: > 301: case INDETERMINATE: { > 302: if (getAttribute(ROLE) == AccessibleRole.CHECK_BOX > 303: || getAttribute(ROLE) == AccessibleRole.CHECK_BOX_TREE_ITEM) { same Q.: could we use a `switch` statement to avoid double getter call? (I don't know if JVM will optimize that away anyway, but `switch` makes a cleaner code, in my opinion) modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 310: > 308: case SELECTED: { > 309: Object role = getAttribute(ROLE); > 310: if (role == AccessibleRole.CHECK_BOX || role == AccessibleRole.TOGGLE_BUTTON switch? modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 436: > 434: case TAB_ITEM: return getContainerAccessible(AccessibleRole.TAB_PANE); > 435: case PAGE_ITEM: return getContainerAccessible(AccessibleRole.PAGINATION); > 436: case CHECK_BOX_TREE_ITEM: I would recommend reformatting the switch cases here for clarity: private Accessible getContainer() { if (isDisposed()) { return null; } AccessibleRole role = (AccessibleRole)getAttribute(ROLE); if (role != null) { switch (role) { case TABLE_ROW: case TABLE_CELL: return getContainerAccessible(AccessibleRole.TABLE_VIEW); case LIST_ITEM: return getContainerAccessible(AccessibleRole.LIST_VIEW); case TAB_ITEM: return getContainerAccessible(AccessibleRole.TAB_PANE); case PAGE_ITEM: return getContainerAccessible(AccessibleRole.PAGINATION); case CHECK_BOX_TREE_ITEM: case TREE_ITEM: return getContainerAccessible(AccessibleRole.TREE_VIEW); case TREE_TABLE_ROW: case TREE_TABLE_CELL: return getContainerAccessible(AccessibleRole.TREE_TABLE_VIEW); } } return null; } (and below also. but again, this is just my preference) modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 1594: > 1592: return ToggleState_On; > 1593: } > 1594: return ToggleState_Off; also here, I'd do if { } else if { } else { } modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 828: > 826: * This enum describes the values for TOGGLE_STATE attribute. > 827: * > 828: * @see TOGGLE_STATE this might be Eclipse limitation, but this link does not resolve (in Eclipse javadoc widget). should it? modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 846: > 844: */ > 845: INDETERMINATE > 846: } is this the right place for ToggleState? looks like the right place, just want to confirm. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546216763 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192668641 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192674675 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192675679 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192677649 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192678082 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192679829 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192681071 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192695563 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192747447 From mhanl at openjdk.org Fri May 12 20:31:51 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 May 2023 20:31:51 GMT Subject: RFR: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: <2O7Wc_hVRJqWx6OSQttzNJef7NRTm_orBlkX6fhcgv4=.28f52375-5d01-47cf-b3a8-ea779761e508@github.com> Message-ID: <4o6qtsu6HFXywL7OJ8Cly5zMyy4rrMP2xmM6kpzHIPE=.7c6dcf65-20df-4892-8df3-fc8c3c2209e4@github.com> On Fri, 12 May 2023 17:25:22 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableHeaderRowShim.java line 38: >> >>> 36: >>> 37: public static ContextMenu getColumnPopupMenu(TableHeaderRow tableHeaderRow) { >>> 38: return tableHeaderRow.getColumnPopupMenu(); >> >> Minor: I would keep `tr` instead of `tableHeaderRow` for consistency with already existing static method. > > I would too - avoids wrapping the line, and there is no need to spell the name for a one line method. I am more a fan of descriptive variable names. I know this is a one-line method - but on the other hand `tr` is just not a good understandable name, even for a very short method. Since you read code more often than you write it, I'm for keeping the descriptive name, also in this simple case :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1133#discussion_r1192768054 From mhanl at openjdk.org Fri May 12 20:31:52 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 May 2023 20:31:52 GMT Subject: Integrated: 8307960: Create Table Column PopupMenu lazily In-Reply-To: References: Message-ID: <8T71mPur_6AncCnKhElp7v78pHSVRn11UiOog58pABg=.50cd8e5e-764b-4c4d-9ded-17436df63355@github.com> On Thu, 11 May 2023 19:39:36 GMT, Marius Hanl wrote: > This PR changes the `columnPopupMenu`, so that it is created lazily. > > The problem here is, that the `columnPopupMenu` is always initialized and updated via bindings, even if the table menu button is never shown (`setTableMenuButtonVisible(false)`) or the user never clicked on it. > This problem can be solved by creating the `columnPopupMenu` and related bindings when it should be shown the first time. > > I also added many tests to ensure that everything still works (there are no tests for that area as of now). > > Side note: There are a bunch of tickets with the wish to customize the Popup shown by the table menu button or show it programmatically. This ticket will prepare this, as now all Popup related code is on one place and in the future we can think of implementing a way to override this behaviour in a way that the Popup and all related bindings are never created and therefore do not decrease performance. This pull request has now been integrated. Changeset: 8aff5252 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/8aff5252339a7a45bd03b2656387c2651c0f70f7 Stats: 449 lines in 4 files changed: 440 ins; 6 del; 3 mod 8307960: Create Table Column PopupMenu lazily Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1133 From angorya at openjdk.org Fri May 12 20:38:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 20:38:52 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v4] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 17 Apr 2023 06:00:19 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc changes Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1090#pullrequestreview-1425123160 From angorya at openjdk.org Fri May 12 20:41:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 20:41:52 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v4] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Mon, 17 Apr 2023 06:00:19 GMT, Michael Strau? wrote: >> This PR adds the following methods to the `EventTarget` interface: >> 1. `addEventHandler` >> 2. `removeEventHandler` >> 3. `addEventFilter` >> 4. `removeEventFilter` > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > doc changes I think CSR needs to be out of Draft status to move this PR along. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1090#issuecomment-1546267609 From mstrauss at openjdk.org Fri May 12 20:46:50 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 12 May 2023 20:46:50 GMT Subject: RFR: 8306021: Add event handler management to EventTarget [v4] In-Reply-To: References: <5BIM8D2acRWXNCALew4jS8OrndcHWMWC9-hCDCkvLwI=.f1283fbc-0421-48d1-b81d-b979437d1770@github.com> Message-ID: On Fri, 12 May 2023 20:39:16 GMT, Andy Goryachev wrote: > I think CSR needs to be out of Draft status to move this PR along. I changed the status to Proposed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1090#issuecomment-1546273668 From mhanl at openjdk.org Fri May 12 20:51:53 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 May 2023 20:51:53 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: <-ethq_Lxb9UaH3KXz94E6Ht2uZyt5JYVXs7yoJttP6I=.96f5bb33-f4e0-4974-90cd-da21bd33be34@github.com> <2_oh-UD07bvG6PU6jtWg26dT_weYwQpwfGjx8vzUUuY=.3fe435fa-9d56-4479-a097-56f0f82f5bb5@github.com> Message-ID: On Fri, 12 May 2023 18:40:20 GMT, John Hendrikx wrote: >>> I think once there is an unsnapped parent, all children should probably also be unsnapped (ie. the property should work like the visible property; if I turn it off for one parent, all children become invisible/unsnapped). >> >> One complication with this is that the `snapToPixel` property is on `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't have that property. What you describe _might_ be OK as long as you ignore any parent that isn't a `Region` when asking the question "are all my ancestors have `snapToPixel`". >> >>> Basically, there are three strategies for children when dealing with an unsnapped parent: >>> >>> * Just do snapping as normal (JavaFX currently) and when the parent translation is added, all final positions will be shifted by an unsnapped amount resulting in all calculations (even though they used snapping logic) to be in the "wrong" positions >> >> Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). >> >>> * Ignore snapping when a parent is unsnapped and use standard calculations >> >> A change to do this _might_ be OK, with the caveat I mentioned above about non-Region parents, but this would need careful analysis. As part of this, I would want to understand the motivation for doing this (i.e., what is the benefit?). >> >>> * Somehow try to resnap content taking the parent misalignment into account; this is going to cause visual artifacts as the parent is moved, and requires some kind of flexible border >> >> Yeah, this doesn't seems like a good idea. >> >> If you want to explore this further, you could file a new RFE to consider making a change. > > @kevinrushforth it probably isn't worth pursuing a change in the child/parent snapping logic right now, at least not without some compelling case. First I think snapping is rarely disabled (I never have, despite working on graphics heavy JavaFX applications). Second, one can already get the (possibly more) desired situation by taking care all children are unsnapped as well. I agree with the consensus here. And same as @hjohn, I actually also never disabled snapping. There was never usecase where I needed to do so (And I worked on a lot of UI related things, including creating custom components of all kind). > Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). I agree here.The defaultis fine, and it's hard to say what would be a better default 'setting' here (if there really is a better way). Does a developer really expect that all children of a unsnapped node are unsnapped as well? Or is there a usecase where you don't want this? It's hard to answer, so as written above, the default seems fine and logicial. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192780661 From mhanl at openjdk.org Fri May 12 20:51:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 May 2023 20:51:55 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v3] In-Reply-To: References: <2uF3rI77WdbjkmasA6jhkWHET92z9Fon9UL0jZU7XRM=.81d6953a-f098-4a75-99c2-f942061f9328@github.com> <-AJzDmalPjdQIfBFkFRXQbaThCJXC3i3w5wDuqT1FxI=.abd74768-73b2-432b-9d5b-8eabeb03af71@github.com> Message-ID: On Fri, 12 May 2023 07:57:27 GMT, John Hendrikx wrote: >> here: yes! > > This looks good to me, the snapping as explained by Andy is how it should be. A source of error can be still be that floating point calculations can introduce small deviations so sometimes it is needed to resnap after doing calculations that seem harmless (ie. `snappedSize * 10` or `snappedWidth - snappedLeftInset` may need resnapping). Good point. That is something we should think about - this may or may not be a problem with some of the snapping code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192782950 From mariushanl at web.de Fri May 12 20:57:18 2023 From: mariushanl at web.de (Marius Hanl) Date: Fri, 12 May 2023 22:57:18 +0200 Subject: Aw: Developer documentation In-Reply-To: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri May 12 21:00:31 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 12 May 2023 21:00:31 +0000 Subject: Developer documentation In-Reply-To: References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: Looks like JDK uses a different flavor of markdown: > % Testing the JDK https://github.com/openjdk/jdk/blob/38838b344af00b32251b3141350ba4deb3962d6f/doc/testing.md?plain=1#LL1C18-L1C18 Are there any scripts that process the .md in jdk? -andy From: openjfx-dev on behalf of Marius Hanl Date: Friday, May 12, 2023 at 13:57 To: John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Aw: Developer documentation I like this idea as well. And I agree, especially the snapping insight are good to document as this topic really isn't trivial. I think we should stick to the official JDK, which also follows the idea suggested by John. See here: https://github.com/openjdk/jdk/tree/master/doc -> There is a doc folder in the root directory. The JDK decided to always have a .md as well as a .html file. See: https://github.com/openjdk/jdk/blob/master/doc/building.md And: https://github.com/openjdk/jdk/blob/master/doc/building.html +1 for the Markdown format (.md). IntelliJ is also able to render this format. -- Marius Gesendet: Freitag, 12. Mai 2023 um 21:02 Uhr Von: "John Hendrikx" An: openjfx-dev at openjdk.org Betreff: Developer documentation In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights were gained in the snapping logic. Michael Strauss suggested documenting this, and I thought we may as well discuss this on the mailing list instead of continuing the discussion in that PR. In my normal line of work, I usually encourage projects to include developer documentation as part of the Git repository. This allows any developer to access and modify the documentation easily, and allows you to keep documentation in sync with relevant commits (and one can ask developers to do so as part of the PR). The documentation is provided in markdown format and is usually stored in a /doc folder. If there are multiple modules, there can be specialized doc folders per module with a top level doc folder which contains an index.md linking all the docs together, and containing documentation that is not module specific. The documentation is intended for developers only, not for users of JavaFX, and hence does not need to be published. Markdown files can either be read directly in your IDE of choice or online via GitHub/GitLab. The build documentation may be a good candidate to place there as well. So, my suggestion would be: - Create a top level /doc folder, and create module level /doc folders as needed when relevant documentation is written - In each /doc folder there is an index.md file that links to all documentation in that folder - A higher level index.md also contains links to child indexes - Consider moving the build and any onboarding documentation there - The top level README.md should have a link to /doc/index.md - Use only GitHub supported markdown features --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri May 12 21:07:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 21:07:49 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Tue, 9 May 2023 05:10:25 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address code review Just by looking at the code, the code paths that leave `insertionIndex=-1` in `PrismTextLayout.getHitInfo()` are on lines: 431, 450(when run==null), 472 If we can initialize insertionIndex to a positive value, then the buggy code in HitInfo.getInsertionIndex() will never get executed, and we can remove it later (in JDK-8302511). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1546300130 From angorya at openjdk.org Fri May 12 21:26:51 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 21:26:51 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v6] In-Reply-To: References: Message-ID: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> > Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: John is right ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/a4cdc148..e1b72a13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=04-05 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Fri May 12 21:26:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 21:26:52 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v4] In-Reply-To: References: <6vaVklRgVJYcChsv6Nv6xE-xfuKRohDyb3JzKW_bBrQ=.86c01f03-12e5-4f58-a060-1b6fd71526a6@github.com> <-cFQhuCf46uZFSr6andO6e5m_IgemUSiFtoMoKiXbRk=.2daae781-f51d-48af-a193-c3f62bb42abe@github.com> Message-ID: On Fri, 12 May 2023 18:13:46 GMT, John Hendrikx wrote: >> Even though I don't particularly like register*Listener() because of its asymmetric nature (when it comes to removing listeners), here we do need to create weak listeners that get unregistered upon `dispose()`. We need weak listeners because TreeTableView does not explicitly "disconnect" unused cells (e.g. refresh()), and we need `dispose()` due to skin life cycle. >> >> So, in this particular case, I think this change should be ok. > > Sorry, I think we may be misunderstanding each other. I'm specifically talking about the two listeners added in `TreeTableRowSkin`'s constructor on `indexProperty` and `treeItemProperty`. These are part of the `TreeTableRow` which is also discarded when `refresh` is called. > > 1) The test passes if these changes are reverted. This is a clear indication that either the test is insufficient, or that your assumption, that these must be weak, is incorrect. If you can construct a test that requires these listeners to be weak, then I think the changes are warranted. > > 2) At the risk of stating the obvious, the listeners in the constructor added using `ListenerHelper` are also correctly removed in `dispose`. `ListenerHelper` does this in a similar way to the `register` methods. > > 3) The `indexProperty` and `treeItemProperty` listeners are attached to the `TreeTableRow`, not the `TreeTableView`. The refresh function replaces the entire row, including the skin. There is no need to use weak listeners for this purpose. Compare this to the listeners that are attached to the `TreeTableView` or the `VirtualFlow`; these have a much longer lifecycle and can survive multiple refreshes and row factory replacements, and hence should be weak (for now). you are right, of course. and I should know - ListenerHelper is my baby. I guess the fear of another regression overtook me. reverting. thank you for your patience and persistence! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1192803129 From kcr at openjdk.org Fri May 12 21:38:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 21:38:49 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: <72y5seOysWSEYq2caiYhN8r6x_LYXxmkcFk496lCYco=.1de459ad-69ce-4fb2-8ba1-a85fc40e5458@github.com> On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute The additional changes to add the enum look good to me. I'll test it and review the javadoc. ------------- PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1425177875 From kcr at openjdk.org Fri May 12 21:38:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 21:38:54 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> Message-ID: <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> On Fri, 12 May 2023 18:24:29 GMT, Andy Goryachev wrote: >> Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem >> - Review Comment: Add enum ToggleState >> - Add CheckBoxTreeItem role and TOGGLE_STATE attribute > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 303: > >> 301: case INDETERMINATE: { >> 302: if (getAttribute(ROLE) == AccessibleRole.CHECK_BOX >> 303: || getAttribute(ROLE) == AccessibleRole.CHECK_BOX_TREE_ITEM) { > > same Q.: could we use a `switch` statement to avoid double getter call? (I don't know if JVM will optimize that away anyway, but `switch` makes a cleaner code, in my opinion) I think the proposed change is less intrusive than a switch, but I don't mind either way. It might make sense to use a local variable to avoid calling `getAttribute` twice. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 310: > >> 308: case SELECTED: { >> 309: Object role = getAttribute(ROLE); >> 310: if (role == AccessibleRole.CHECK_BOX || role == AccessibleRole.TOGGLE_BUTTON > > switch? I wouldn't bother. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 436: > >> 434: case TAB_ITEM: return getContainerAccessible(AccessibleRole.TAB_PANE); >> 435: case PAGE_ITEM: return getContainerAccessible(AccessibleRole.PAGINATION); >> 436: case CHECK_BOX_TREE_ITEM: > > I would recommend reformatting the switch cases here for clarity: > > > private Accessible getContainer() { > if (isDisposed()) { > return null; > } > AccessibleRole role = (AccessibleRole)getAttribute(ROLE); > if (role != null) { > switch (role) { > case TABLE_ROW: > case TABLE_CELL: > return getContainerAccessible(AccessibleRole.TABLE_VIEW); > case LIST_ITEM: > return getContainerAccessible(AccessibleRole.LIST_VIEW); > case TAB_ITEM: > return getContainerAccessible(AccessibleRole.TAB_PANE); > case PAGE_ITEM: > return getContainerAccessible(AccessibleRole.PAGINATION); > case CHECK_BOX_TREE_ITEM: > case TREE_ITEM: > return getContainerAccessible(AccessibleRole.TREE_VIEW); > case TREE_TABLE_ROW: > case TREE_TABLE_CELL: > return getContainerAccessible(AccessibleRole.TREE_TABLE_VIEW); > } > } > return null; > } > > (and below also. but again, this is just my preference) I usually prefer to avoid these sort of unrelated changes to minimize the diffs. Either way is fine. > modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 828: > >> 826: * This enum describes the values for TOGGLE_STATE attribute. >> 827: * >> 828: * @see TOGGLE_STATE > > this might be Eclipse limitation, but this link does not resolve (in Eclipse javadoc widget). should it? Hopefully, this is just an Eclipse limitation. I'll check the actual javadoc (which I was planning to do anyway). > modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 846: > >> 844: */ >> 845: INDETERMINATE >> 846: } > > is this the right place for ToggleState? > looks like the right place, just want to confirm. Yes, this is where I would recommend putting it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192809729 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192811319 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192812188 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192812665 PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192812774 From kcr at openjdk.org Fri May 12 21:42:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 21:42:49 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> Message-ID: On Fri, 12 May 2023 19:53:35 GMT, Andy Goryachev wrote: > Testing with VoiceOver on Mac M1 Ventura 13.3.1(a): undetermined checkbox is pronounced as "mixed checkbox" - is this expected behavior? This is a Windows-only fix, so the behavior should be unchanged on Mac from before this fix. The only change on Mac is to react to the new AccessibleRole value (to do what it would have done before). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546333863 From angorya at openjdk.org Fri May 12 22:09:58 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 22:09:58 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Fri, 12 May 2023 21:34:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java line 436: >> >>> 434: case TAB_ITEM: return getContainerAccessible(AccessibleRole.TAB_PANE); >>> 435: case PAGE_ITEM: return getContainerAccessible(AccessibleRole.PAGINATION); >>> 436: case CHECK_BOX_TREE_ITEM: >> >> I would recommend reformatting the switch cases here for clarity: >> >> >> private Accessible getContainer() { >> if (isDisposed()) { >> return null; >> } >> AccessibleRole role = (AccessibleRole)getAttribute(ROLE); >> if (role != null) { >> switch (role) { >> case TABLE_ROW: >> case TABLE_CELL: >> return getContainerAccessible(AccessibleRole.TABLE_VIEW); >> case LIST_ITEM: >> return getContainerAccessible(AccessibleRole.LIST_VIEW); >> case TAB_ITEM: >> return getContainerAccessible(AccessibleRole.TAB_PANE); >> case PAGE_ITEM: >> return getContainerAccessible(AccessibleRole.PAGINATION); >> case CHECK_BOX_TREE_ITEM: >> case TREE_ITEM: >> return getContainerAccessible(AccessibleRole.TREE_VIEW); >> case TREE_TABLE_ROW: >> case TREE_TABLE_CELL: >> return getContainerAccessible(AccessibleRole.TREE_TABLE_VIEW); >> } >> } >> return null; >> } >> >> (and below also. but again, this is just my preference) > > I usually prefer to avoid these sort of unrelated changes to minimize the diffs. Either way is fine. in this particular case, with many fall-throughs, I think the code would benefit from reformatting. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192827969 From angorya at openjdk.org Fri May 12 22:09:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 22:09:57 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute it looks like the behavior on Mac is unchanged. I can't find anything like VoiceOver on Windows 11. Do you need JAWS or similar to test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546359354 PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546360548 From angorya at openjdk.org Fri May 12 22:12:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 22:12:50 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v6] In-Reply-To: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> References: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> Message-ID: On Sun, 9 Apr 2023 09:22:54 GMT, John Hendrikx wrote: >> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix PseudoClassTest I'll take a look at this next week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1546363118 From angorya at openjdk.org Fri May 12 22:16:02 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 May 2023 22:16:02 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Fri, 12 May 2023 22:10:43 GMT, Kevin Rushforth wrote: >> Hopefully, this is just an Eclipse limitation. I'll check the actual javadoc (which I was planning to do anyway). > > It does work in the actual javadocs (so almost certainly an Eclipse issue). > > Minor suggestion: use `{@link ...}` in the Description (and then you can remove the `@see`) like this: > > > This enum describes the values for the {@link TOGGLE_STATE} attribute. In Eclipse, only this works: {@link AccessibleAttribute#TOGGLE_STATE} ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192830249 From kcr at openjdk.org Fri May 12 22:16:00 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 22:16:00 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Fri, 12 May 2023 21:35:25 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/AccessibleAttribute.java line 828: >> >>> 826: * This enum describes the values for TOGGLE_STATE attribute. >>> 827: * >>> 828: * @see TOGGLE_STATE >> >> this might be Eclipse limitation, but this link does not resolve (in Eclipse javadoc widget). should it? > > Hopefully, this is just an Eclipse limitation. I'll check the actual javadoc (which I was planning to do anyway). It does work in the actual javadocs (so almost certainly an Eclipse issue). Minor suggestion: use `{@link ...}` in the Description (and then you can remove the `@see`) like this: This enum describes the values for the {@link TOGGLE_STATE} attribute. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192829341 From kcr at openjdk.org Fri May 12 22:21:49 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 22:21:49 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: <18Ua1YJfkyfnWWOZwpfbHaktroAylKHNyZSI21HCNLg=.c9da3c27-1808-4223-b4ca-25b155a30d6e@github.com> On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute Testing looks (and sounds) good to me. I'll reapprove if you make the suggested formatting or doc changes. Go ahead and update the CSR when ready. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1425210899 From kcr at openjdk.org Fri May 12 22:21:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 22:21:50 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: On Fri, 12 May 2023 22:06:04 GMT, Andy Goryachev wrote: > I can't find anything like VoiceOver on Windows 11. Do you need JAWS or similar to test? You can use Windows Narrator. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546368615 From john at status6.com Fri May 12 22:32:14 2023 From: john at status6.com (John Neffenger) Date: Fri, 12 May 2023 15:32:14 -0700 Subject: Developer documentation In-Reply-To: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: <331b9043-1ea0-24b0-75b0-c89b267ad369@status6.com> On 5/12/23 12:02 PM, John Hendrikx wrote: > The build documentation may be a good candidate to place there as well. I'm all for it. Some of us were in agreement on moving at least the build instructions back in November 2022. See the following thread on the mailing list from a pull request discussion: https://mail.openjdk.org/pipermail/openjfx-dev/2022-November/036434.html I think the current build instructions on the Wiki need to be completely rewritten and simplified, but I haven't yet found the time (and courage) to do it. John From kcr at openjdk.org Fri May 12 22:32:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 22:32:50 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> Message-ID: <7do4IWip2YovnYccDUx94vNM35jRbz7-ks78FMYRxvM=.b5514092-626c-4930-91ed-70f9c8ff5702@github.com> On Fri, 12 May 2023 19:53:35 GMT, Andy Goryachev wrote: > Also, probably unrelated to this PR: the outlines placed by VoiceOver are shifted to the wrong positions on the secondary monitor Definitely unrelated, but it should be filed as a bug. I remember seeing this before, but I don't see a bug for it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1546384311 From john.hendrikx at gmail.com Fri May 12 23:07:37 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 13 May 2023 01:07:37 +0200 Subject: Developer documentation In-Reply-To: References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: <4bc80b1d-8026-e1e2-63d4-ce311f19c249@gmail.com> Apart from the first line which may have special significance, GitHub renders this nicely enough when you activate the preview. I didn't mean to specifically suggest a special flavor of markdown, just that we should ensure it looks okay on GitHub as that will often be the viewer used. --John On 12/05/2023 23:00, Andy Goryachev wrote: > > Looks like JDK uses a different flavor of markdown: > > > % Testing the JDK > > https://github.com/openjdk/jdk/blob/38838b344af00b32251b3141350ba4deb3962d6f/doc/testing.md?plain=1#LL1C18-L1C18 > > Are there any scripts that process the .md in jdk? > > -andy > > *From: *openjfx-dev on behalf of Marius > Hanl > *Date: *Friday, May 12, 2023 at 13:57 > *To: *John Hendrikx > *Cc: *openjfx-dev at openjdk.org > *Subject: *Aw: Developer documentation > > I like this idea as well. And I agree, especially the snapping insight > are good to document as this topic really isn't trivial. > I think we should stick to the official JDK, which also follows the > idea suggested by John. > See here: https://github.com/openjdk/jdk/tree/master/doc > -> There is a doc folder in the root directory. > > > The JDK decided to always have a .md as well as a .html file. > See: https://github.com/openjdk/jdk/blob/master/doc/building.md > And: https://github.com/openjdk/jdk/blob/master/doc/building.html > > > +1 for the Markdown format (.md). IntelliJ is also able to render this > format. > > -- Marius > > *Gesendet:*?Freitag, 12. Mai 2023 um 21:02 Uhr > *Von:*?"John Hendrikx" > *An:* openjfx-dev at openjdk.org > *Betreff:*?Developer documentation > > In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights > were gained in the snapping logic.? Michael Strauss suggested > documenting this, and I thought we may as well discuss this on the > mailing list instead of continuing the discussion in that PR. > > In my normal line of work, I usually encourage projects to include > developer documentation as part of the Git repository. This allows any > developer to access and modify the documentation easily, and allows you > to keep documentation in sync with relevant commits (and one can ask > developers to do so as part of the PR). > > The documentation is provided in markdown format and is usually stored > in a /doc folder. If there are multiple modules, there can be > specialized doc folders per module with a top level doc folder which > contains an index.md linking all the docs together, and containing > documentation that is not module specific. > > The documentation is intended for developers only, not for users of > JavaFX, and hence does not need to be published. Markdown files can > either be read directly in your IDE of choice or online via GitHub/GitLab. > > The build documentation may be a good candidate to place there as well. > > So, my suggestion would be: > > - Create a top level /doc folder, and create module level /doc folders > as needed when relevant documentation is written > - In each /doc folder there is an index.md file that links to all > documentation in that folder > - A higher level index.md also contains links to child indexes > - Consider moving the build and any onboarding documentation there > - The top level README.md should have a link to /doc/index.md > - Use only GitHub supported markdown features > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri May 12 23:09:54 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 23:09:54 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v6] In-Reply-To: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> References: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> Message-ID: On Sun, 9 Apr 2023 09:22:54 GMT, John Hendrikx wrote: >> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix PseudoClassTest The changes look good with a few inline comments. modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 519: > 517: > 518: @Override > 519: public boolean equals(Object obj) { Since you override `equals`, you should also override `hashCode`. Presuming that `super.hashCode` honors the contract of `equals` / `hashCode`, I'd prefer that to be explicit along with a comment as to why it's OK (which you sort of do in a comment in the equals method). modules/javafx.graphics/src/main/java/javafx/css/Match.java line 74: > 72: * Gets the {@code Selector}. > 73: * > 74: * @return the {@code Selector}, never {@code null} Can you add this to the CSR? modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 97: > 95: * Creates a {@code Match}. > 96: * > 97: * @return a match, never {@code null} Can you add this to the CSR? modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 76: > 74: * @return an immutable list of style-classes of the {@code Selector} > 75: */ > 76: public List getStyleClasses() { This is a public method, so removing it would be an incompatible API change. Given the decision to live with this public class, I think you should restore this method. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 136: > 134: > 135: if (styleClasses != null) { > 136: for(int n = 0; n < styleClasses.size(); n++) { Minor: space after `for` modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 152: > 150: > 151: if (pseudoClasses != null) { > 152: for(int n = 0; n < pseudoClasses.size(); n++) { Minor: space after `for` ------------- PR Review: https://git.openjdk.org/jfx/pull/1070#pullrequestreview-1421475805 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192844466 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192847207 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1190464417 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192854967 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192856315 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192856335 From kcr at openjdk.org Fri May 12 23:09:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 23:09:56 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v6] In-Reply-To: References: <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com> Message-ID: On Sat, 8 Apr 2023 19:43:51 GMT, John Hendrikx wrote: >>> I think that Match is supposed to be immutable, given the non-public constructor. Match itself will never change the set (and nothing else will) so making it observable seems unnecessary. >> >> Agreed. >> >>> In other words, simpleSelector.createMatch().getPseudoClasses().clear() would break the Selectors encapsulation. >>> >>> I think it's best to close that loophole. If you agree, I can document this method that it returns an immutable set, which is also what I assumed would be the case in my other PR where I made many of these immutable. >> >> Yes, this seems like the best solution to me. >> >>> Essentially this means that SimpleSelector and CompoundSelector should probably be package private. >> >> I agree that these two classes should not have been made public when the javafx.css package was created as public API back in JDK 9. >> >> The usual process for removing API is to deprecate it for removal in one release and then remove it in a future release, but in this case, since those classes cannot be constructed, and are never returned by any public API, any use of them would be relying on an implementation detail (via an `instanceof` and a cast, to no good purpose). >> >> Since there is no useful way an application could be using these classes, I recommend option 1, as long as those two classes can be cleanly moved to com.sun.javafx.css. Otherwise, we could go with option 2 along with deprecating those two classes for removal. >> >> The Specification section of the CSR would simply propose to remove those two classes. You could describe what is happening (moving them to a non-exported package) in the Solution section. > > @kevinrushforth It looks like it will have to be option 2; the reason is that both `Selector` and `Match` are abstract classes (with a package private constructor). The `CompoundSelector` and `SimpleSelector` extend this abstract class (as there is some small overlap). If `Selector` and `Match` had been interfaces, it would have allowed this. > > I couldn't find anything about binary compatibility when changing an abstract class with a package private constructor to an interface, so I tested it and I got an `IncompatibleClassChangeError` when calling `Selector Selector.createSelector(...)` method. Apparently, the compiled method call does encode the difference between an interface and a class: > > invokestatic #7 // Method Selector.createSelector:(I)LSelector; > > vs: > > invokestatic #7 // InterfaceMethod Selector.createSelector:(I)LSelector; > > ~~At the most, I could make `CompoundSelector` and `SimpleSelector` package private, or nested classes in `Selector`; they would at least be hidden then.~~ Can't do that either, they're referred in private API. OK. In that case, option 2 it is. And since there doesn't seem to be a good way to remove these classes from the public API, it makes no sense to deprecate them for removal. We could deprecate them with a note that they are used by the CSS implementation, and not intended to be used by applications, but since applications aren't usefully using them today, we could defer that to a later time (or not do it at all). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1190463585 From kevin.rushforth at oracle.com Fri May 12 23:16:26 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 May 2023 16:16:26 -0700 Subject: Aw: Developer documentation In-Reply-To: References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: <0070aaaf-693a-cd1e-f37e-ed73b26d8a28@oracle.com> Yes, this seems like a good idea. I'm less sure about scattering module-specific docs in the module dir, but let's start with a top-level "doc" directory and see where we get. Also, I'd stick with just Markdown for now. -- Kevin On 5/12/2023 1:57 PM, Marius Hanl wrote: > I like this idea as well. And I agree, especially the snapping insight > are good to document as this topic really isn't trivial. > I think we should stick to the official JDK, which also follows the > idea suggested by John. > See here: https://github.com/openjdk/jdk/tree/master/doc > -> There is a doc folder in the root directory. > > The JDK decided to always have a .md as well as a .html file. > See: https://github.com/openjdk/jdk/blob/master/doc/building.md > And: https://github.com/openjdk/jdk/blob/master/doc/building.html > > +1 for the Markdown format (.md). IntelliJ is also able to render this > format. > -- Marius > *Gesendet:*?Freitag, 12. Mai 2023 um 21:02 Uhr > *Von:*?"John Hendrikx" > *An:* openjfx-dev at openjdk.org > *Betreff:*?Developer documentation > In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights > were gained in the snapping logic.? Michael Strauss suggested > documenting this, and I thought we may as well discuss this on the > mailing list instead of continuing the discussion in that PR. > > In my normal line of work, I usually encourage projects to include > developer documentation as part of the Git repository. This allows any > developer to access and modify the documentation easily, and allows you > to keep documentation in sync with relevant commits (and one can ask > developers to do so as part of the PR). > > The documentation is provided in markdown format and is usually stored > in a /doc folder. If there are multiple modules, there can be > specialized doc folders per module with a top level doc folder which > contains an index.md linking all the docs together, and containing > documentation that is not module specific. > > The documentation is intended for developers only, not for users of > JavaFX, and hence does not need to be published. Markdown files can > either be read directly in your IDE of choice or online via GitHub/GitLab. > > The build documentation may be a good candidate to place there as well. > > So, my suggestion would be: > > - Create a top level /doc folder, and create module level /doc folders > as needed when relevant documentation is written > - In each /doc folder there is an index.md file that links to all > documentation in that folder > - A higher level index.md also contains links to child indexes > - Consider moving the build and any onboarding documentation there > - The top level README.md should have a link to /doc/index.md > - Use only GitHub supported markdown features > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri May 12 23:17:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 23:17:51 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v6] In-Reply-To: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> References: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> Message-ID: On Fri, 12 May 2023 21:26:51 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > John is right Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1129#pullrequestreview-1425252776 From kevin.rushforth at oracle.com Fri May 12 23:24:19 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 May 2023 16:24:19 -0700 Subject: Developer documentation In-Reply-To: References: <1911c1bf-0e27-ea47-d0d5-b59d859844a5@gmail.com> Message-ID: <004fc0cd-40e1-4e09-97a3-09ccfb2e7b19@oracle.com> Not scripts, but yes, the JDK uses pandoc to process their markdown files. I'd prefer not to go down that route at this time. The docs we are talking about can be rendered directly by the GitHub UI. -- Kevin On 5/12/2023 2:00 PM, Andy Goryachev wrote: > > Looks like JDK uses a different flavor of markdown: > > > % Testing the JDK > > https://github.com/openjdk/jdk/blob/38838b344af00b32251b3141350ba4deb3962d6f/doc/testing.md?plain=1#LL1C18-L1C18 > > Are there any scripts that process the .md in jdk? > > -andy > > *From: *openjfx-dev on behalf of Marius > Hanl > *Date: *Friday, May 12, 2023 at 13:57 > *To: *John Hendrikx > *Cc: *openjfx-dev at openjdk.org > *Subject: *Aw: Developer documentation > > I like this idea as well. And I agree, especially the snapping insight > are good to document as this topic really isn't trivial. > I think we should stick to the official JDK, which also follows the > idea suggested by John. > See here: https://github.com/openjdk/jdk/tree/master/doc > -> There is a doc folder in the root directory. > > > The JDK decided to always have a .md as well as a .html file. > See: https://github.com/openjdk/jdk/blob/master/doc/building.md > And: https://github.com/openjdk/jdk/blob/master/doc/building.html > > > +1 for the Markdown format (.md). IntelliJ is also able to render this > format. > > -- Marius > > *Gesendet:*?Freitag, 12. Mai 2023 um 21:02 Uhr > *Von:*?"John Hendrikx" > *An:* openjfx-dev at openjdk.org > *Betreff:*?Developer documentation > > In PR https://github.com/openjdk/jfx/pull/910 a lot of "new" insights > were gained in the snapping logic.? Michael Strauss suggested > documenting this, and I thought we may as well discuss this on the > mailing list instead of continuing the discussion in that PR. > > In my normal line of work, I usually encourage projects to include > developer documentation as part of the Git repository. This allows any > developer to access and modify the documentation easily, and allows you > to keep documentation in sync with relevant commits (and one can ask > developers to do so as part of the PR). > > The documentation is provided in markdown format and is usually stored > in a /doc folder. If there are multiple modules, there can be > specialized doc folders per module with a top level doc folder which > contains an index.md linking all the docs together, and containing > documentation that is not module specific. > > The documentation is intended for developers only, not for users of > JavaFX, and hence does not need to be published. Markdown files can > either be read directly in your IDE of choice or online via GitHub/GitLab. > > The build documentation may be a good candidate to place there as well. > > So, my suggestion would be: > > - Create a top level /doc folder, and create module level /doc folders > as needed when relevant documentation is written > - In each /doc folder there is an index.md file that links to all > documentation in that folder > - A higher level index.md also contains links to child indexes > - Consider moving the build and any onboarding documentation there > - The top level README.md should have a link to /doc/index.md > - Use only GitHub supported markdown features > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri May 12 23:40:04 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 23:40:04 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v6] In-Reply-To: References: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> Message-ID: On Fri, 12 May 2023 22:44:50 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PseudoClassTest > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 519: > >> 517: >> 518: @Override >> 519: public boolean equals(Object obj) { > > Since you override `equals`, you should also override `hashCode`. Presuming that `super.hashCode` honors the contract of `equals` / `hashCode`, I'd prefer that to be explicit along with a comment as to why it's OK (which you sort of do in a comment in the equals method). I made it explicit, and slightly reworded the comment. Please note, the equals code that BitSet uses is still broken in this PR, but as fixing it entails more changes to BitSet, and the goal of this PR is to fix a different issue, I've left that for #1076 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192866671 From jhendrikx at openjdk.org Fri May 12 23:40:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 23:40:03 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: > The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: - Override hashCode with a comment explaining why - Fix style issues - Restore removed public method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1070/files - new: https://git.openjdk.org/jfx/pull/1070/files/bcc9a941..270d0cbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1070&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1070&range=05-06 Stats: 28 lines in 2 files changed: 23 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1070.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1070/head:pull/1070 PR: https://git.openjdk.org/jfx/pull/1070 From jhendrikx at openjdk.org Fri May 12 23:43:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 May 2023 23:43:51 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v6] In-Reply-To: References: <_PrViuFXWq5IapY4T5Z8TsvG9qJkzf_rm4XRxxk_NsQ=.a4d31346-8d99-4263-be26-e0cfb824588a@github.com> Message-ID: On Fri, 12 May 2023 22:48:31 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix PseudoClassTest > > modules/javafx.graphics/src/main/java/javafx/css/Match.java line 74: > >> 72: * Gets the {@code Selector}. >> 73: * >> 74: * @return the {@code Selector}, never {@code null} > > Can you add this to the CSR? Added both changes to the CSR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1192868562 From kcr at openjdk.org Sat May 13 13:29:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 13 May 2023 13:29:50 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Fri, 12 May 2023 22:13:00 GMT, Andy Goryachev wrote: >> It does work in the actual javadocs (so almost certainly an Eclipse issue). >> >> Minor suggestion: use `{@link ...}` in the Description (and then you can remove the `@see`) like this: >> >> >> This enum describes the values for the {@link TOGGLE_STATE} attribute. > > In Eclipse, only this works: > > {@link AccessibleAttribute#TOGGLE_STATE} Then I think Eclipse has a bug. `TOGGLE_STATE` is a field (enum value) in the outer enum class, `AccessibleAttribute`, so can be referenced from the nested enum class without qualifying it with the outer class name. If we wanted to be more clear (and work around the Eclipse limitation), it could be written as: {@link AccessibleAttribute#TOGGLE_STATE TOGGLE_STATE} ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1192983753 From duke at openjdk.org Sat May 13 16:01:51 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 16:01:51 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls Message-ID: replaced implementation of OS checks in HostUtils with calls of PlatformUtil ------------- Commit messages: - replaced implementation of OS checks in HostUtils with calls of PlatformUtil Changes: https://git.openjdk.org/jfx/pull/1134/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308028 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1134.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1134/head:pull/1134 PR: https://git.openjdk.org/jfx/pull/1134 From mhanl at openjdk.org Sat May 13 16:32:47 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 16:32:47 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Sat, 13 May 2023 15:56:15 GMT, Carl D?bbelin wrote: > replaced implementation of OS checks in HostUtils with calls of PlatformUtil modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 77: > 75: } > 76: > 77: /** `isEmbedded` can also be replaced by `PlatformUtil`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193010989 From duke at openjdk.org Sat May 13 16:40:39 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 16:40:39 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: > replaced implementation of OS checks in HostUtils with calls of PlatformUtil Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: added isEmbedded ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1134/files - new: https://git.openjdk.org/jfx/pull/1134/files/9867d8bd..28131e2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1134.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1134/head:pull/1134 PR: https://git.openjdk.org/jfx/pull/1134 From mhanl at openjdk.org Sat May 13 16:44:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 16:44:55 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:40:39 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > added isEmbedded modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 60: > 58: > 59: public static boolean isWindows() { > 60: return osName.startsWith("windows"); `osName` is unused now ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193012298 From nlisker at openjdk.org Sat May 13 16:50:52 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 13 May 2023 16:50:52 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:42:33 GMT, Marius Hanl wrote: >> Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: >> >> added isEmbedded > > modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 60: > >> 58: >> 59: public static boolean isWindows() { >> 60: return osName.startsWith("windows"); > > `osName` is unused now `osArch` is also unused. It's just a local variable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193012839 From duke at openjdk.org Sat May 13 17:01:51 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 17:01:51 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:48:12 GMT, Nir Lisker wrote: >> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 60: >> >>> 58: >>> 59: public static boolean isWindows() { >>> 60: return osName.startsWith("windows"); >> >> `osName` is unused now > > `osArch` is also unused. It's just a local variable. @nlisker osArch seems to be used for is64bit still ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193013776 From mhanl at openjdk.org Sat May 13 17:05:50 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 17:05:50 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:48:12 GMT, Nir Lisker wrote: >> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 60: >> >>> 58: >>> 59: public static boolean isWindows() { >>> 60: return osName.startsWith("windows"); >> >> `osName` is unused now > > `osArch` is also unused. It's just a local variable. Yes, but what @nlisker means is that `osArch` does not need to be a member variable but only a local one inside the static initializer above. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193014192 From mhanl at openjdk.org Sat May 13 17:20:54 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 17:20:54 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v6] In-Reply-To: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> References: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> Message-ID: On Fri, 12 May 2023 21:26:51 GMT, Andy Goryachev wrote: >> Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. >> >> Added a unit test. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > John is right modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 158: > 156: private void updateCachedFixedSize() { > 157: if (getSkinnable() != null) { > 158: TreeTableView t = getSkinnable().getTreeTableView(); I know this is a short method, but I would rather see a more descriptive variable name here modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 161: > 159: if (t != null) { > 160: double sz = t.getFixedCellSize(); > 161: fixedCellSize = sz; Why you don't just assign the variable directly? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1193015659 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1193015561 From mstrauss at openjdk.org Sat May 13 17:22:53 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 13 May 2023 17:22:53 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions [v2] In-Reply-To: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: > On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. > > Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/984/files - new: https://git.openjdk.org/jfx/pull/984/files/28cc7207..4b75556f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=984&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=984&range=00-01 Stats: 14 lines in 3 files changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/984.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/984/head:pull/984 PR: https://git.openjdk.org/jfx/pull/984 From duke at openjdk.org Sat May 13 17:23:55 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 17:23:55 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: Message-ID: > replaced implementation of OS checks in HostUtils with calls of PlatformUtil Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: refactored HostUtils ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1134/files - new: https://git.openjdk.org/jfx/pull/1134/files/28131e2d..a14bab71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1134.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1134/head:pull/1134 PR: https://git.openjdk.org/jfx/pull/1134 From duke at openjdk.org Sat May 13 17:23:56 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 17:23:56 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:40:39 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > added isEmbedded I have looked at `HostUtils` further. The only method it implements itself is the `is64bit`, which checks whether the architechture is 64 bit. i could not find any usages of this method anywhere. i think it may be a valid option to replace calls of `HostUtils` by calls of `PlatformUtil` and move `is64bit` in the `PlatformUtil` as well. It may also be an option to remove it completely. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1134#issuecomment-1546713625 From duke at openjdk.org Sat May 13 17:23:56 2023 From: duke at openjdk.org (Glavo) Date: Sat, 13 May 2023 17:23:56 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 16:40:39 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > added isEmbedded > I have looked at `HostUtils` further. The only method it implements itself is the `is64bit`, which checks whether the architechture is 64 bit. i could not find any uses os this method anywhere. > > i think it may be a valid option to replace calls of `HostUtils` by calls of `PlatformUtil` and move `is64bit` in the `PlatformUtil` as well. It may also be an option to remove it completely. Sounds great, I was just about to say the same. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1134#issuecomment-1546714118 From duke at openjdk.org Sat May 13 17:23:58 2023 From: duke at openjdk.org (Glavo) Date: Sat, 13 May 2023 17:23:58 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 17:19:34 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > refactored HostUtils modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/HostUtils.java line 42: > 40: @SuppressWarnings("removal") > 41: boolean temp = AccessController.doPrivileged((PrivilegedAction) () -> { > 42: String osArch = System.getProperty("os.arch").toLowerCase(); Suggestion: String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1134#discussion_r1193015665 From mhanl at openjdk.org Sat May 13 17:25:49 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 17:25:49 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v2] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 17:19:34 GMT, Glavo wrote: > i think it may be a valid option to replace calls of `HostUtils` by calls of `PlatformUtil` and move `is64bit` in the `PlatformUtil` as well. It may also be an option to remove it completely. Since `is64bit` is unused, `HostUtils` is basically a delegate for `PlatformUtil`. So we might as well delete it completely and replace all occurrences with `PlatformUtil`. And as written by Kevin in the ticket, this is a valid choice so we might as well do it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1134#issuecomment-1546714629 From nlisker at openjdk.org Sat May 13 17:31:50 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 13 May 2023 17:31:50 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: Message-ID: On Sat, 13 May 2023 17:23:55 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > refactored HostUtils `isEmbedded()` is also unused as far as I can tell. The question is why this and `is64bit` were created. Before removing unused code I would try to find out if it is *supposed* to be used. > i think it may be a valid option to replace calls of HostUtils by calls of PlatformUtil and move is64bit in the PlatformUtil as well. It may also be an option to remove it completely. This is what I would have done. No need to have duplicate functionalities. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1134#issuecomment-1546715646 From duke at openjdk.org Sat May 13 17:36:59 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 17:36:59 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v4] In-Reply-To: References: Message-ID: > replaced implementation of OS checks in HostUtils with calls of PlatformUtil Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: removed HostUtils ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1134/files - new: https://git.openjdk.org/jfx/pull/1134/files/a14bab71..6a637dec Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1134&range=02-03 Stats: 106 lines in 8 files changed: 5 ins; 83 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1134.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1134/head:pull/1134 PR: https://git.openjdk.org/jfx/pull/1134 From duke at openjdk.org Sat May 13 17:38:50 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Sat, 13 May 2023 17:38:50 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v3] In-Reply-To: References: Message-ID: <7N6tObTr-hQZlrdiVH5NPOx2QpyP1RHKY4iBYDptYUc=.aa13fb4b-74fc-4c33-964e-62a754a40730@github.com> On Sat, 13 May 2023 17:23:55 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > refactored HostUtils Since `HostUtils` is internal API and not used outside of JFX itself, and `is64bit` is not used anywhere i would say its safe to remove. >From its implementation I saw that it checked whether the operating systems architechture was either intel/amd 64 bit or intel itanium(ia64). In any case of an ARM-Architecture, even on ARM64, the method would have returned false. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1134#issuecomment-1546716940 From nlisker at openjdk.org Sat May 13 17:46:50 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 13 May 2023 17:46:50 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v4] In-Reply-To: References: Message-ID: <4fOIuNhNY20eBeUoah6mQlK9RqZVOfpsUF2fAVDS0Yg=.007c7fb7-db1c-46f6-a94e-f86ab73dadf5@github.com> On Sat, 13 May 2023 17:36:59 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > removed HostUtils Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1134#pullrequestreview-1425445476 From mhanl at openjdk.org Sat May 13 18:04:51 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 18:04:51 GMT Subject: RFR: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls [v4] In-Reply-To: References: Message-ID: <3vXOSqKbGuXyfD3BSyN18IUJgMvvZqPbQt-GzJIkg60=.df5c7537-6874-406d-b365-025eb3f34757@github.com> On Sat, 13 May 2023 17:36:59 GMT, Carl D?bbelin wrote: >> replaced implementation of OS checks in HostUtils with calls of PlatformUtil > > Carl D?bbelin has updated the pull request incrementally with one additional commit since the last revision: > > removed HostUtils Looks good. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1134#pullrequestreview-1425446985 From mhanl at openjdk.org Sat May 13 19:17:56 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 13 May 2023 19:17:56 GMT Subject: RFR: 8091153: Customize the Table Button Menu Message-ID: This PR implements a way to override the table column menu. When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. ------------- Commit messages: - JDK-8091153: Implement ability to override and therefore customize the column menu Changes: https://git.openjdk.org/jfx/pull/1135/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8091153 Stats: 123 lines in 3 files changed: 109 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1135.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1135/head:pull/1135 PR: https://git.openjdk.org/jfx/pull/1135 From tsayao at openjdk.org Sun May 14 12:31:52 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 12:31:52 GMT Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source code repository [v6] In-Reply-To: References: Message-ID: On Sat, 15 Apr 2023 23:32:40 GMT, Thiago Milczarek Sayao wrote: >> This PR does: >> >> - Remove specific Idea files and let it be imported from gradle; >> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes); >> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules)); >> - Automatically sets Copyright notice (updates year too); > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Update .gitignore > - Remove unrelated gitignore @arapte Would you take a look when you have time? Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1009#issuecomment-1546888925 From tsayao at openjdk.org Sun May 14 12:47:53 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 12:47:53 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v9] In-Reply-To: References: Message-ID: <-MVo2cH7JMkhdXD5HY5q5s9aM32llwZaCRh4M0nc8WI=.815dbb74-e57e-42f3-8de1-b4ab06bb2e39@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add manual test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/5893d847..0e600533 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=07-08 Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun May 14 12:47:54 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 12:47:54 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v5] In-Reply-To: <97pZqoKP5dKYnIuN39fAw1x1jGX1-TLpDjpERC4HfUk=.6044cc70-6e7b-4ac3-9fdf-57b297c98590@github.com> References: <97pZqoKP5dKYnIuN39fAw1x1jGX1-TLpDjpERC4HfUk=.6044cc70-6e7b-4ac3-9fdf-57b297c98590@github.com> Message-ID: On Mon, 8 May 2023 15:26:48 GMT, Jose Pereda wrote: >> `SceneChangeShouldNotFocusStageTest` covers the test that the window should start iconified. It does not cover the test where the window pops and then iconifies (causing a visual "weirdness"). I don't think the later is possible on a systemTest. > > If not as system test, then could you add `WinIconified` as manual test, with some javadoc as quick instructions on how to check that it works as expected? @jperedadnr added. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1110#discussion_r1193140429 From mhanl at openjdk.org Sun May 14 17:38:48 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 14 May 2023 17:38:48 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 12:17:53 GMT, John Hendrikx wrote: >> Fix bug in CSS caching code that could reset values on unrelated nodes. >> >> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. > > John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug > - Fix typo > - Fix bug in CSS caching code that could reset values on unrelated nodes > > The bug occurs due to a cache entry being constructed incorrectly when > the initial node that triggered the cache entry creation has user set > values. The calculated values for properties with a user set value were > omitted in the cache entry, and other nodes that later share the same > entry would incorrectly assume the omitted property was unstyled and > were therefore reset to their default values. Just tested: This PR also fixes [JDK-8306747](https://bugs.openjdk.org/browse/JDK-8306747). We can probably close it as duplicate of this one then. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1072#issuecomment-1546955937 From mhanl at openjdk.org Sun May 14 18:27:47 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 14 May 2023 18:27:47 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 12:17:53 GMT, John Hendrikx wrote: >> Fix bug in CSS caching code that could reset values on unrelated nodes. >> >> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. > > John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug > - Fix typo > - Fix bug in CSS caching code that could reset values on unrelated nodes > > The bug occurs due to a cache entry being constructed incorrectly when > the initial node that triggered the cache entry creation has user set > values. The calculated values for properties with a user set value were > omitted in the cache entry, and other nodes that later share the same > entry would incorrectly assume the omitted property was unstyled and > were therefore reset to their default values. Fix looks good to me. Test failes before and passes with the fix. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1072#pullrequestreview-1425586221 From tsayao at openjdk.org Sun May 14 20:13:04 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 20:13:04 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v10] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix ComboBoxTest ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/0e600533..c394214c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=08-09 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun May 14 20:13:04 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 20:13:04 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v9] In-Reply-To: <-MVo2cH7JMkhdXD5HY5q5s9aM32llwZaCRh4M0nc8WI=.815dbb74-e57e-42f3-8de1-b4ab06bb2e39@github.com> References: <-MVo2cH7JMkhdXD5HY5q5s9aM32llwZaCRh4M0nc8WI=.815dbb74-e57e-42f3-8de1-b4ab06bb2e39@github.com> Message-ID: On Sun, 14 May 2023 12:47:53 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add manual test I don't know why `ComboBoxTest.test_rt28245` was working before, but it had just an ENTER to select an element. I fixed it by using the combination of keys to select the first element. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1546990585 From tsayao at openjdk.org Sun May 14 20:17:58 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 20:17:58 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v11] In-Reply-To: References: Message-ID: > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 53 additional commits since the last revision: - Merge branch 'master' into change_scene_fix - Fix ComboBoxTest - Add manual test - Merge branch 'master' into change_scene_fix - Merge branch 'openjdk:master' into master - Merge branch 'master' into change_scene_fix - Merge remote-tracking branch 'origin/master' - Review changes - Merge branch 'master' into change_scene_fix - Change call to requestFocus - ... and 43 more: https://git.openjdk.org/jfx/compare/08e5f00e...7828c2a9 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/c394214c..7828c2a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=09-10 Stats: 2016 lines in 32 files changed: 1767 ins; 160 del; 89 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From jvos at openjdk.org Sun May 14 20:48:52 2023 From: jvos at openjdk.org (Johan Vos) Date: Sun, 14 May 2023 20:48:52 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Thu, 6 Apr 2023 06:39:00 GMT, Fabian Wolter wrote: >> There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. >> >> The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. >> >> We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. > > Do you need any additional information to start reviewing this bug? Hi @fwolter . I still think this would be a good fix, but it would be really helpful if there was a regression test for this. There have been a number of changes in how touch handling should be processed, and I want to make sure we don't run in circles (where patch A breaks the fix from patch B and vice versa). Do you think you can come up with a unit test for this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/641#issuecomment-1546997979 From tsayao at openjdk.org Sun May 14 21:35:01 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 21:35:01 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v12] In-Reply-To: References: Message-ID: <76ql7zgfe4iuuBqYc9cdwoqlqwJPQjlSgH5Gn6ox2mw=.1a6628f0-f029-4298-8850-f778ad926855@github.com> > I replicated the fix on #1054 on Linux. > > Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Antecipate request focus ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1110/files - new: https://git.openjdk.org/jfx/pull/1110/files/7828c2a9..c339b26c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1110&range=10-11 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1110.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1110/head:pull/1110 PR: https://git.openjdk.org/jfx/pull/1110 From tsayao at openjdk.org Sun May 14 21:42:53 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 14 May 2023 21:42:53 GMT Subject: RFR: 8306121: Scene not rendered initially when changing scenes after fix for JDK-8296621 [v12] In-Reply-To: <76ql7zgfe4iuuBqYc9cdwoqlqwJPQjlSgH5Gn6ox2mw=.1a6628f0-f029-4298-8850-f778ad926855@github.com> References: <76ql7zgfe4iuuBqYc9cdwoqlqwJPQjlSgH5Gn6ox2mw=.1a6628f0-f029-4298-8850-f778ad926855@github.com> Message-ID: On Sun, 14 May 2023 21:35:01 GMT, Thiago Milczarek Sayao wrote: >> I replicated the fix on #1054 on Linux. >> >> Also fixes [Monocle: Stage no longer gets focus after fix for JDK-8296621](https://bugs.openjdk.org/browse/JDK-8304734) > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Antecipate request focus The `MouseEventFirerTest. testAnchorRight[0]` is failing because the `requestFocus` call: if (!isIconified()) { peer.requestFocus(); } Weird.. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1110#issuecomment-1547007411 From jvos at openjdk.org Mon May 15 07:40:00 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 15 May 2023 07:40:00 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 [v2] In-Reply-To: References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Thu, 11 May 2023 01:09:53 GMT, Alexander Matveev wrote: >> - libFFI updated to 3.4.4. >> - No additional changes are done to the code. >> - Tested on Linux, Windows x64 and macOS x64/aarch64. >> - Windows x86 config files are updated, but no build/testing was done for 32-bit. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8306328: Update libFFI to 3.4.4 [v3] I didn't test this on windows, but the changes look good. (tested on mac). Would be good if another reviewer would test on windows to make sure it works fine there as well. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1131#pullrequestreview-1425940703 From kizune at openjdk.org Mon May 15 09:49:57 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 15 May 2023 09:49:57 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: <1-ly3LHfeT5_iUMKKv8_YNSdvYHFz--SRKh69tn-y90=.38543c29-e33b-477d-ba46-43df945cbfdf@github.com> On Fri, 12 May 2023 22:19:00 GMT, Kevin Rushforth wrote: > I can't find anything like VoiceOver on Windows 11. Do you need JAWS or similar to test? On Windows 10/11 it is called Narrator and is in Start->All Apps->Accessibility->Narrator Unlike AWT/Swing JavaFX does not require JAWS or NVDA. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1547532027 From kizune at openjdk.org Mon May 15 09:52:54 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 15 May 2023 09:52:54 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute Looks good. Looks good. ------------- Marked as reviewed by kizune (no project role). PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1426185216 PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1426185287 From kpk at openjdk.org Mon May 15 09:57:59 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 15 May 2023 09:57:59 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Initialize insertion index in PrismTextLayout ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/03600552..7919d5b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=02-03 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Mon May 15 09:58:00 2023 From: kpk at openjdk.org (Karthik P K) Date: Mon, 15 May 2023 09:58:00 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v3] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: On Fri, 12 May 2023 21:05:27 GMT, Andy Goryachev wrote: > Just by looking at the code, the code paths that leave `insertionIndex=-1` in `PrismTextLayout.getHitInfo()` are on lines: 431, 450(when run==null), 472 > > If we can initialize insertionIndex to a positive value, then the buggy code in HitInfo.getInsertionIndex() will never get executed, and we can remove it later (in JDK-8302511). Updated the code to initialize `insertionIndex` in `HitInfo.getInsertionIndex()`. Please check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1547540128 From lkostyra at openjdk.org Mon May 15 12:56:03 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 15 May 2023 12:56:03 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet Message-ID: This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. ------------- Commit messages: - Add negative index test for Parent - Parent: Throw exception when added child index is negative Changes: https://git.openjdk.org/jfx/pull/1136/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301763 Stats: 22 lines in 2 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1136.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1136/head:pull/1136 PR: https://git.openjdk.org/jfx/pull/1136 From duke at openjdk.org Mon May 15 13:19:56 2023 From: duke at openjdk.org (Carl =?UTF-8?B?RMO2YmJlbGlu?=) Date: Mon, 15 May 2023 13:19:56 GMT Subject: Integrated: JDK-8308028 Replace more uses of System.getProperty("os.name") with PlatformUtil calls In-Reply-To: References: Message-ID: On Sat, 13 May 2023 15:56:15 GMT, Carl D?bbelin wrote: > replaced implementation of OS checks in HostUtils with calls of PlatformUtil This pull request has now been integrated. Changeset: e7974bc8 Author: Carl D?bbelin Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e7974bc84618c9f954e075935cc2ff324c741aad Stats: 110 lines in 8 files changed: 5 ins; 87 del; 18 mod 8308028: Replace more uses of System.getProperty("os.name") with PlatformUtil calls Reviewed-by: nlisker, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1134 From kcr at openjdk.org Mon May 15 13:36:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 13:36:51 GMT Subject: RFR: 8091153: Customize the Table Button Menu In-Reply-To: References: Message-ID: On Sat, 13 May 2023 19:11:26 GMT, Marius Hanl wrote: > This PR implements a way to override the table column menu. > When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. > > This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) > > This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. > Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. This adds new public API and, as such, will need additional discussion. Can you start a thread on the openjfx-dev mailing list? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1135#issuecomment-1547870144 From duke at openjdk.org Mon May 15 15:15:07 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 15 May 2023 15:15:07 GMT Subject: RFR: 8308017: [Mac] Update deprecated constants in GlassWindow code Message-ID: In macOS 10.12 Apple renamed a bunch of constants to match the Swift enumeration style. JavaFX is still using the old deprecated constants which generates over 50 warnings during the build. JavaFX 18 upped the minimum macOS version to 10.12 so it's time to migrate to the new names. This is strictly a rename to mollify the compiler. At a binary level the values are the same so JavaFX should work fine on a pre-10.12 system. Fun fact: Xcode 14 (released late 2022) officially dropped support for macOS 10.12. ------------- Commit messages: - Update constants renamed by Apple in macOS 10.12 Changes: https://git.openjdk.org/jfx/pull/1137/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308017 Stats: 20 lines in 3 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1137.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1137/head:pull/1137 PR: https://git.openjdk.org/jfx/pull/1137 From jhendrikx at openjdk.org Mon May 15 15:27:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 May 2023 15:27:50 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet In-Reply-To: References: Message-ID: <7SWQNcOE0gbt-WIteXdHjproCnUSELf5a7WWvNg3ODs=.24495736-5863-45d6-afdf-5f2506cd5d90@github.com> On Mon, 15 May 2023 12:49:41 GMT, Lukasz Kostyra wrote: > This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. > > This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. I think it may be better to do this check in the callers of `onProposedChange` (using the assertions in `Objects` to test for valid indices.). This will also allow to check when the index is too large, which is a similar problem. Note that you can't do the "too large" check in `onProposedChange` as for `remove`, `size()` would be too large, while for `add(int, E)` `size()` would still be valid. Also, for the cases where `onProposedChange` is called with multiple sets of indices, those don't need a check (they come from calls like `removeAll`, which will all be valid). Furthermore, it should be an `IndexOutOfBoundsException` as this is specified by the `List` interface. I noticed there are similar problems in `ObservableListWrapper`. This method for example: @Override protected void doAdd(int index, E element) { if (elementObserver != null) elementObserver.attachListener(element); backingList.add(index, element); } This will attach a listener to the element (assuming it is an `Observable`) even if `backingList.add` fails... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1136#issuecomment-1548075656 From angorya at openjdk.org Mon May 15 16:01:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 16:01:54 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> Message-ID: On Mon, 15 May 2023 09:57:59 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Initialize insertion index in PrismTextLayout modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 479: > 477: insertionIndex = charIndex; > 478: if (!leading) { > 479: insertionIndex += 1; I would have initialized insertionIndex directly in all the blocks instead of adding conditional logic, but this code does seem to produce the desired result. For clarify, would it be possible to avoid this additional conditional logic? Also, do existing unit tests cover the newly modified paths? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1194033275 From angorya at openjdk.org Mon May 15 16:12:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 16:12:10 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v7] In-Reply-To: References: Message-ID: <_cRT1w2QchXm5_KUdMpOjONs6weVvJ9A53cLzVAOrYU=.2de6eca4-d1ae-43c0-89c3-af7db1fddbf9@github.com> > Fixed a memory leak in TreeTableView by reverting to register**Listener (which is ok in this particular situation) - the leak is specific to TreeTableRowSkin. > > Added a unit test. 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 17 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8307538.refresh - review comments - John is right - review comments - one more test case - back to register listener - weak lambdas are getting collected - removed monkey tester changes - Merge remote-tracking branch 'origin/master' into 8307538.refresh - whitespace - ... and 7 more: https://git.openjdk.org/jfx/compare/782a7150...f68de127 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1129/files - new: https://git.openjdk.org/jfx/pull/1129/files/e1b72a13..f68de127 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1129&range=05-06 Stats: 1842 lines in 27 files changed: 1672 ins; 113 del; 57 mod Patch: https://git.openjdk.org/jfx/pull/1129.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1129/head:pull/1129 PR: https://git.openjdk.org/jfx/pull/1129 From angorya at openjdk.org Mon May 15 16:12:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 16:12:12 GMT Subject: RFR: 8307538: Memory leak in TreeTableView when calling refresh [v6] In-Reply-To: References: <1eDLCokjHRFoRmIl7RCYVZnvY8KGDVojxgkxSDMJhKo=.2b5d20af-52c1-437e-acad-473120fac6df@github.com> Message-ID: On Sat, 13 May 2023 17:17:42 GMT, Marius Hanl wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> John is right > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 158: > >> 156: private void updateCachedFixedSize() { >> 157: if (getSkinnable() != null) { >> 158: TreeTableView t = getSkinnable().getTreeTableView(); > > I know this is a short method, but I would rather see a more descriptive variable name here I prefer not to drag long names if a very descriptive type is right there: `TreeTableView t` > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 161: > >> 159: if (t != null) { >> 160: double sz = t.getFixedCellSize(); >> 161: fixedCellSize = sz; > > Why you don't just assign the variable directly? fixed, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1194050378 PR Review Comment: https://git.openjdk.org/jfx/pull/1129#discussion_r1194047875 From angorya at openjdk.org Mon May 15 16:19:50 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 16:19:50 GMT Subject: RFR: 8091153: Customize the Table Button Menu In-Reply-To: References: Message-ID: <1t-iTdyR95iwSbw_-5bthgno6c-zlebMiWL5Ty6jHrk=.7e049bea-e854-4fb4-a797-5b1c6117bcfb@github.com> On Sat, 13 May 2023 19:11:26 GMT, Marius Hanl wrote: > This PR implements a way to override the table column menu. > When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. > > This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) > > This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. > Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 472: > 470: * This method can be overridden if there is a desire to create and show a custom menu. > 471: * > 472: * @param mouseEvent the {@link MouseEvent} which was generated when the corner region was pressed. probably needs `@since 21` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1135#discussion_r1194064131 From angorya at openjdk.org Mon May 15 16:42:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 16:42:52 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Sun, 14 May 2023 17:36:12 GMT, Marius Hanl wrote: >> John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug >> - Fix typo >> - Fix bug in CSS caching code that could reset values on unrelated nodes >> >> The bug occurs due to a cache entry being constructed incorrectly when >> the initial node that triggered the cache entry creation has user set >> values. The calculated values for properties with a user set value were >> omitted in the cache entry, and other nodes that later share the same >> entry would incorrectly assume the omitted property was unstyled and >> were therefore reset to their default values. > > Just tested: This PR also fixes [JDK-8306747](https://bugs.openjdk.org/browse/JDK-8306747). We can probably close it as duplicate of this one then. @Maran23 : you are right, closed JDK-8306747 as a duplicate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1072#issuecomment-1548193029 From angorya at openjdk.org Mon May 15 17:04:57 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 17:04:57 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 12:17:53 GMT, John Hendrikx wrote: >> Fix bug in CSS caching code that could reset values on unrelated nodes. >> >> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. > > John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug > - Fix typo > - Fix bug in CSS caching code that could reset values on unrelated nodes > > The bug occurs due to a cache entry being constructed incorrectly when > the initial node that triggered the cache entry creation has user set > values. The calculated values for properties with a user set value were > omitted in the cache entry, and other nodes that later share the same > entry would incorrectly assume the omitted property was unstyled and > were therefore reset to their default values. minor comments, otherwise LGTM modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 1185: > 1183: if (cssValue != null && "inherit".equals(cssValue.getValue())) { > 1184: style = getInheritedStyle(styleable, property); > 1185: if (style == null) return SKIP; minor: could we surround return with { }'s please? To keep one statement per line. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 622: > 620: } > 621: """ > 622: ); is there a chance we would backport this fix (to < java15)? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1072#pullrequestreview-1426954523 PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194089298 PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194092591 From jhendrikx at openjdk.org Mon May 15 17:22:54 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 May 2023 17:22:54 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions [v2] In-Reply-To: References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: On Sat, 13 May 2023 17:22:53 GMT, Michael Strau? wrote: >> On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. >> >> Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/984#pullrequestreview-1427021884 From jhendrikx at openjdk.org Mon May 15 17:26:57 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 May 2023 17:26:57 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 16:41:33 GMT, Andy Goryachev wrote: >> John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug >> - Fix typo >> - Fix bug in CSS caching code that could reset values on unrelated nodes >> >> The bug occurs due to a cache entry being constructed incorrectly when >> the initial node that triggered the cache entry creation has user set >> values. The calculated values for properties with a user set value were >> omitted in the cache entry, and other nodes that later share the same >> entry would incorrectly assume the omitted property was unstyled and >> were therefore reset to their default values. > > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 1185: > >> 1183: if (cssValue != null && "inherit".equals(cssValue.getValue())) { >> 1184: style = getInheritedStyle(styleable, property); >> 1185: if (style == null) return SKIP; > > minor: could we surround return with { }'s please? To keep one statement per line. It's not my code originally, I only changed the indent here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194138111 From duke at openjdk.org Mon May 15 17:42:56 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 15 May 2023 17:42:56 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v2] In-Reply-To: References: Message-ID: <8QeaseaxJmNqjDRU0475nQPEDSdbBpZwufeY5v1KE38=.bc8ffd5a-3a9b-4179-aaad-b3d84b556241@github.com> On Fri, 12 May 2023 15:05:01 GMT, Lukasz Kostyra wrote: >> Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. >> >> Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. >> >> One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. >> >> Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. > > Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - GlassViewDelegate: Return to deprecated *PboardType symbols > > New NSPasteboardType* symbols were introduced starting 10.13, and we're > targetting 10.12. This deprecation should probably be resolved once we target > macOS 10.13+. > > Old NS*PboardType symbols do not have an equivalent of NSPasteboardTypeFileURL, > so this branch was removed. > - GlassPasteboard: Correct macOS version information in comments > > New DnD API was introduced starting macOS 10.7, not 10.14 > - GlassView: Remove deprecated draggingSourceOperationMask > - DndTest: Update instructions > > On Mac to enable moving you must press Cmd, not Shift. > - Restore logic responsible for Cmd key support > - Merge branch 'master' into dnd_multiple_items-JDK-8233955 > - Add DnD Multiple File manual test > - Fix preview position; cleanup code > - Add image previews and finish DnD code > > Fixes issues with tests caused by first commit. > > Removes old code used as placeholder. > - Migrate DnD native code to DraggingSession API > > Previous implementation used dragImage call which is deprecated since macOS 10.14. Additionally, > 10.14 introduced a restriction not allowing for more than one drag item in the Pasteboard. This > change fixes crashes caused by old API use when DnD-ing more than one item. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.h line 71: > 69: > 70: NSDragOperation dragOperation; > 71: NSDraggingSession *draggingSession; I don't think the dragOperation is used anymore. You also don't need draggingSession since you're not assigning anything to it. I think you can just remove it, the NSView should retain the draggingSession while the drag is going on and release it afterward. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 962: > 960: for (NSDraggingItem* item in items) > 961: { > 962: NSPoint dragPoint = [self->nsView convertPoint:[self->lastEvent locationInWindow] fromView:nil];//[self->lastEvent locationInWindow]; Minor: left over comment at end of line modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1061: > 1059: // main thread blocked here until drag completes > 1060: > 1061: [GlassDragSource setDelegate:nil]; I don't see any place where the delegate is set back to `nil` in this PR so `isDelegateSet` will always return `true` after a mouse drag. And it could turn into a dangling pointer if the GlassViewDelegate goes away. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1194126454 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1194079640 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1194152034 From duke at openjdk.org Mon May 15 17:42:51 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 15 May 2023 17:42:51 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 11:56:00 GMT, Lukasz Kostyra wrote: >> This sounds like it could be the reason for the functional regression in handling the CMD modifier while dragging. > > Good catch, I'll take a look into that Looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1194153005 From angorya at openjdk.org Mon May 15 17:57:55 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 17:57:55 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> Message-ID: <0PO8LgdcEuuDb-FfKZxqBSt8qRX6-cCNMwQ4zOMujas=.d0c8749e-8fef-4baf-88e6-72c3ec84439f@github.com> On Fri, 12 May 2023 10:36:12 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem > - Review Comment: Add enum ToggleState > - Add CheckBoxTreeItem role and TOGGLE_STATE attribute looks and sounds good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1427076936 From mhanl at openjdk.org Mon May 15 17:59:53 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 15 May 2023 17:59:53 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 16:44:58 GMT, Andy Goryachev wrote: >> John Hendrikx 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 branch 'openjdk:master' into feature/css-cache-bug >> - Fix typo >> - Fix bug in CSS caching code that could reset values on unrelated nodes >> >> The bug occurs due to a cache entry being constructed incorrectly when >> the initial node that triggered the cache entry creation has user set >> values. The calculated values for properties with a user set value were >> omitted in the cache entry, and other nodes that later share the same >> entry would incorrectly assume the omitted property was unstyled and >> were therefore reset to their default values. > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 622: > >> 620: } >> 621: """ >> 622: ); > > is there a chance we would backport this fix (to < java15)? Even if there is, this still shouln't stop us using new language features, should it? Otherwise we can't really use any new feature, as a fix *might* be backported. On the other hand it is also easy to replace this text block when backported. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194170939 From angorya at openjdk.org Mon May 15 17:59:54 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 17:59:54 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:55:09 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 622: >> >>> 620: } >>> 621: """ >>> 622: ); >> >> is there a chance we would backport this fix (to < java15)? > > Even if there is, this still shouln't stop us using new language features, should it? Otherwise we can't really use any new feature, as a fix *might* be backported. > On the other hand it is also easy to replace this text block when backported. it could also be a one liner ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194172909 From kevin.rushforth at oracle.com Mon May 15 18:11:45 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 May 2023 11:11:45 -0700 Subject: [External] : Re: Proposal: Bump the minimum version of macOS for which we target JavaFX In-Reply-To: <64870D4D-C6F0-44A3-A2C3-B644F24ECC78@gmail.com> References: <8d8511ac-e6a6-cb01-1508-1392e111b991@oracle.com> <64870D4D-C6F0-44A3-A2C3-B644F24ECC78@gmail.com> Message-ID: <9759f4e8-ca50-bed6-a03a-b951ee26e92c@oracle.com> One more reason why we need to bump the minimum is that Xcode 14 no longer supports deploying to 10.12, and we will need to update to Xcode 14 relatively soon. So the only remaining question is whether to choose Option 1 or Option 2. I haven't heard any objection to going straight to macOS 11.0 as the minimum for JavaFX 12, so I'll prepare a PR for Option 1 and send it out shortly. -- Kevin On 5/11/2023 4:37 PM, Scott Palmer wrote: > I think Option 1 makes the most sense. Specially since JDK 21 is LTS. Do we want to be stuck with OS 10.x through the entire LTS period? > > Scott > >> On May 11, 2023, at 3:23 PM, Kevin Rushforth wrote: >> >> ?Thanks for the additional info. I had meant to look it up and add it prior to sending it out, but hit "send" too soon. >> >> My preference would be Option 1: change the minimum to macOS 11.0 in JavaFX 21. >> >> If there are some significant concerns over doing that, we could go with Option 2 as a fallback: change the minimum to 10.14 in 21 and to 11.0 in 22. >> >> -- Kevin >> >> >> On 5/11/2023 12:00 PM, Martin Fox wrote: >>>> My preference is to change the minimum version for Mac / x64 to be macOS 11.0, matching both the currently oldest version of macOS supported by Apple, and also unifying the minimum for the two chip architectures. >>> So no one else has to look this up: >>> >>> The last security update for macOS 10.12 was in September of 2019. It was released in 2016. >>> The last security update for macOS 10.14 was in July of 2021. It was released in 2018. >>> >>> macOS 11.0 was released in November of 2020. Support is likely to end this year. >>> >>> 11.0 could be installed on MacBooks from 2013 and desktops from 2014 (with some exceptions). If there?s a Mac out there that just can?t upgrade to 11.0 that machine is getting a little long in the tooth. FWIW I?m using an iMac from late 2017 and running the latest OS just fine. >>> >>> I think ditching 10.x is the right move. >>> >>> Martin From kcr at openjdk.org Mon May 15 18:18:59 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 18:18:59 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) Message-ID: This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. ------------- Commit messages: - 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) Changes: https://git.openjdk.org/jfx/pull/1139/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308114 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1139.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1139/head:pull/1139 PR: https://git.openjdk.org/jfx/pull/1139 From kcr at openjdk.org Mon May 15 18:25:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 18:25:50 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:23:45 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 1185: >> >>> 1183: if (cssValue != null && "inherit".equals(cssValue.getValue())) { >>> 1184: style = getInheritedStyle(styleable, property); >>> 1185: if (style == null) return SKIP; >> >> minor: could we surround return with { }'s please? To keep one statement per line. > > It's not my code originally, I only changed the indent here. Agreed. This code is otherwise unchanged, so I'd prefer it left as is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194196694 From kcr at openjdk.org Mon May 15 18:25:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 18:25:52 GMT Subject: RFR: JDK-8245919: Region#padding property rendering error [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:57:21 GMT, Andy Goryachev wrote: >> Even if there is, this still shouln't stop us using new language features, should it? Otherwise we can't really use any new feature, as a fix *might* be backported. >> On the other hand it is also easy to replace this text block when backported. > > it could also be a one liner This is a similar case to using pattern matching `instanceof`, which we've started using in new code. My thinking is that in new code it's should be OK to use new language features in new code, unless we know that it is a bug fix that needs to be backported. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1072#discussion_r1194203537 From kcr at openjdk.org Mon May 15 18:30:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 18:30:53 GMT Subject: RFR: 8308017: [Mac] Update deprecated constants in GlassWindow code In-Reply-To: References: Message-ID: <3MYuHbVdAAuboMs7LFljVYjP-i2MZqFDq2mlG3Tx-EY=.7f10b277-4ce4-46af-8f3a-29545ca5e4eb@github.com> On Mon, 15 May 2023 15:09:27 GMT, Martin Fox wrote: > Fun fact: Xcode 14 (released late 2022) officially dropped support for macOS 10.12. Thanks for pointing this out. I had missed that, so added it as another point in favor of bumping our minimum in the mailing list thread where we are discussing it. Btw, I just now filed [JDK-8308114](https://bugs.openjdk.org/browse/JDK-8308114) / PR #1139 to bump the minimum version of macOS to 11.0. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1137#issuecomment-1548353100 From angorya at openjdk.org Mon May 15 18:56:49 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 18:56:49 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:13:00 GMT, Kevin Rushforth wrote: > This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. > > As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. buildSrc/mac.gradle line 58: > 56: // Set the minimum API version that we require (developers do not need to override this) > 57: // Note that this is not necessarily the same as the preferred SDK version > 58: def macOSMinVersion = "11.0"; is the intent here to always be in sync? or do you see a possible situation where we would need to have target-specific conditionals again? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1139#discussion_r1194236925 From kcr at openjdk.org Mon May 15 19:02:52 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 19:02:52 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:54:16 GMT, Andy Goryachev wrote: > is the intent here to always be in sync? Yes. Having a different minimum was a one-time anomaly due to the fact that Apple required a minimum target of 11.0 for M1 systems when they introduced them. See [JDK-8265031](https://bugs.openjdk.org/browse/JDK-8265031). > do you see a possible situation where we would need to have target-specific conditionals again? No. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1139#discussion_r1194249299 From angorya at openjdk.org Mon May 15 19:06:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 May 2023 19:06:52 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: <7xosAwjByRFh__Y6tc_0ge5BWP8fR2dgnsbhkPKV0Fc=.b5425923-b692-4779-a971-570f2ea893f3@github.com> On Mon, 15 May 2023 18:13:00 GMT, Kevin Rushforth wrote: > This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. > > As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1139#pullrequestreview-1427197226 From jvos at openjdk.org Mon May 15 19:30:49 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 15 May 2023 19:30:49 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:13:00 GMT, Kevin Rushforth wrote: > This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. > > As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. Marked as reviewed by jvos (Reviewer). There were no objections raised on the mailinglist, hence I am ok with bumping to 11.0 for JavaFX 21. ------------- PR Review: https://git.openjdk.org/jfx/pull/1139#pullrequestreview-1427239746 PR Comment: https://git.openjdk.org/jfx/pull/1139#issuecomment-1548449827 From kcr at openjdk.org Mon May 15 19:42:50 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 May 2023 19:42:50 GMT Subject: RFR: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:13:00 GMT, Kevin Rushforth wrote: > This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. > > As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. I'll wait 24 hours to integrate this in case other concerns are raised. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1139#issuecomment-1548467502 From mariushanl at web.de Mon May 15 22:05:10 2023 From: mariushanl at web.de (Marius Hanl) Date: Tue, 16 May 2023 00:05:10 +0200 Subject: Customizable Table Button Menu Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Mon May 15 22:39:52 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 15 May 2023 22:39:52 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v2] In-Reply-To: References: Message-ID: > This PR implements a way to override the table column menu. > When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. > > This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) > > This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. > Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8091153: Improve javadoc to match the CSR ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1135/files - new: https://git.openjdk.org/jfx/pull/1135/files/8fd5c719..aadbb432 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1135.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1135/head:pull/1135 PR: https://git.openjdk.org/jfx/pull/1135 From mhanl at openjdk.org Mon May 15 22:50:52 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 15 May 2023 22:50:52 GMT Subject: RFR: 8299348: Size-restricted window can be observed with incorrect dimensions [v2] In-Reply-To: References: <9zNyOtonYujDxiJZQQs_Xtx8ewS63NLff04eebFzEWU=.8ddb924d-d8cd-49bb-a61e-ec2c447c9ad0@github.com> Message-ID: On Sat, 13 May 2023 17:22:53 GMT, Michael Strau? wrote: >> On Windows, a `Stage` that is restricted by minimum and maximum sizes can briefly be observed to appear with incorrect dimensions when it is first shown. The root cause of this bug is that the native `WinWindow._setBounds` method doesn't respect min/max sizes when calculating the window rect. >> >> Note to reviewers: I've removed the unused `GlassWindow::updateMinMaxSize` method as to not confuse readers where min-max handling actually happens. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/984#pullrequestreview-1427466541 From jgneff at openjdk.org Tue May 16 01:10:03 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 16 May 2023 01:10:03 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures Message-ID: Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for the `i386` architecture. The Debian names for these architectures are `armhf`, `i386`, `ppc64el`, and `s390x`. ------------- Commit messages: - Warn instead of failing on unknown architectures - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x - Merge branch 'master' into allow-armhf-i386-ppc64el-s390x - Allow building on armhf, i386, ppc64el, and s390x Changes: https://git.openjdk.org/jfx/pull/1124/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307316 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1124.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1124/head:pull/1124 PR: https://git.openjdk.org/jfx/pull/1124 From jgneff at openjdk.org Tue May 16 01:10:03 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 16 May 2023 01:10:03 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures In-Reply-To: References: Message-ID: <_Nxhx-oeO8yawdL5SJvxiDWwvED-pmKFO3YwbImp7RY=.3b740bfc-480d-447c-b49c-8b86126766e7@github.com> On Wed, 3 May 2023 16:02:34 GMT, John Neffenger wrote: > Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for the `i386` architecture. The Debian names for these architectures are `armhf`, `i386`, `ppc64el`, and `s390x`. I changed the patch to print a warning message instead of failing when the build machine's architecture is unrecognized, based on the discussion [on the mailing list][1]. I then built JavaFX on six Linux architectures. Three of the resulting build log files contain the warning message as expected (`arm`, `ppc64le`, and `s390x`): $ grep -T -A5 'Configure project' *.txt openjfx_amd64.txt: > Configure project : openjfx_amd64.txt- gradle.gradleVersion: 7.6 openjfx_amd64.txt- OS_NAME: linux openjfx_amd64.txt- OS_ARCH: amd64 openjfx_amd64.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-amd64 openjfx_amd64.txt- JDK_HOME: /usr/lib/jvm/java-17-openjdk-amd64 -- openjfx_arm64.txt: > Configure project : openjfx_arm64.txt- gradle.gradleVersion: 7.6 openjfx_arm64.txt- OS_NAME: linux openjfx_arm64.txt- OS_ARCH: aarch64 openjfx_arm64.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-arm64 openjfx_arm64.txt- JDK_HOME: /usr/lib/jvm/java-17-openjdk-arm64 -- openjfx_armhf.txt: > Configure project : openjfx_armhf.txt- Unknown and unsupported build architecture: arm openjfx_armhf.txt- gradle.gradleVersion: 7.6 openjfx_armhf.txt- OS_NAME: linux openjfx_armhf.txt- OS_ARCH: arm openjfx_armhf.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-armhf -- openjfx_i386.txt: > Configure project : openjfx_i386.txt- gradle.gradleVersion: 7.6 openjfx_i386.txt- OS_NAME: linux openjfx_i386.txt- OS_ARCH: i386 openjfx_i386.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-i386 openjfx_i386.txt- JDK_HOME: /usr/lib/jvm/java-17-openjdk-i386 -- openjfx_ppc64el.txt: > Configure project : openjfx_ppc64el.txt- Unknown and unsupported build architecture: ppc64le openjfx_ppc64el.txt- gradle.gradleVersion: 7.6 openjfx_ppc64el.txt- OS_NAME: linux openjfx_ppc64el.txt- OS_ARCH: ppc64le openjfx_ppc64el.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-ppc64el -- openjfx_s390x.txt: > Configure project : openjfx_s390x.txt- Unknown and unsupported build architecture: s390x openjfx_s390x.txt- gradle.gradleVersion: 7.6 openjfx_s390x.txt- OS_NAME: linux openjfx_s390x.txt- OS_ARCH: s390x openjfx_s390x.txt- JAVA_HOME: /usr/lib/jvm/java-17-openjdk-s390x All of the builds were successful: $ grep -T -A1 ^BUILD *.txt openjfx_amd64.txt: BUILD SUCCESSFUL in 2m 40s openjfx_amd64.txt- 137 actionable tasks: 137 executed -- openjfx_arm64.txt: BUILD SUCCESSFUL in 3m 42s openjfx_arm64.txt- 137 actionable tasks: 137 executed -- openjfx_armhf.txt: BUILD SUCCESSFUL in 16m 51s openjfx_armhf.txt- 137 actionable tasks: 137 executed -- openjfx_i386.txt: BUILD SUCCESSFUL in 2m 42s openjfx_i386.txt- 137 actionable tasks: 137 executed -- openjfx_ppc64el.txt: BUILD SUCCESSFUL in 3m 29s openjfx_ppc64el.txt- 137 actionable tasks: 137 executed -- openjfx_s390x.txt: BUILD SUCCESSFUL in 2m 34s openjfx_s390x.txt- 137 actionable tasks: 137 executed [1]: https://mail.openjdk.org/pipermail/openjfx-dev/2023-April/039439.html Two GitHub pre-submit tests failed, but they appear to be temporary network errors: * [Linux] Connecting to archive.apache.org (archive.apache.org)|138.201.131.134|:443... failed: Connection timed out. * [Windows] curl: (28) Failed to connect to archive.apache.org port 443 after 21065 ms: Couldn't connect to server ------------- PR Comment: https://git.openjdk.org/jfx/pull/1124#issuecomment-1548787652 PR Comment: https://git.openjdk.org/jfx/pull/1124#issuecomment-1548794987 From hmeda at openjdk.org Tue May 16 03:11:02 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 16 May 2023 03:11:02 GMT Subject: RFR: 8306329 : Update ICU4C to 73 Message-ID: Updated ICU to v73.1. Verified build and sanity. No issues seen. ------------- Commit messages: - resolve compile error on windows - change file mode for rbbicst.pl - whitespace corrections - chmod to 644 for regexcst.pl - white space corrections - remove unwanted files - Merge branch 'master' into icu-update-73 - update version and sha sum - Update CMakeLists.txt - Update license and remove unwanted files - ... and 1 more: https://git.openjdk.org/jfx/compare/e7974bc8...599b7523 Changes: https://git.openjdk.org/jfx/pull/1138/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306329 Stats: 35594 lines in 738 files changed: 9104 ins; 2562 del; 23928 mod Patch: https://git.openjdk.org/jfx/pull/1138.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1138/head:pull/1138 PR: https://git.openjdk.org/jfx/pull/1138 From jhendrikx at openjdk.org Tue May 16 06:40:55 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 May 2023 06:40:55 GMT Subject: Integrated: JDK-8245919: Region#padding property rendering error In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 23:05:00 GMT, John Hendrikx wrote: > Fix bug in CSS caching code that could reset values on unrelated nodes. > > The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. This pull request has now been integrated. Changeset: c1a11795 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/c1a1179595158c8611357dcf1d17ee2c641bece9 Stats: 95 lines in 2 files changed: 69 ins; 23 del; 3 mod 8245919: Region#padding property rendering error Reviewed-by: mstrauss, mhanl, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1072 From lkostyra at openjdk.org Tue May 16 07:05:50 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 16 May 2023 07:05:50 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet In-Reply-To: References: Message-ID: On Mon, 15 May 2023 12:49:41 GMT, Lukasz Kostyra wrote: > This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. > > This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. Thanks for your notes, I was wondering if there was a better approach. I'll rework the patch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1136#issuecomment-1549102672 From arapte at openjdk.org Tue May 16 10:00:53 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 10:00:53 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Sat, 13 May 2023 13:20:26 GMT, Kevin Rushforth wrote: >> In Eclipse, only this works: >> >> {@link AccessibleAttribute#TOGGLE_STATE} > > Then I think Eclipse has a bug. `TOGGLE_STATE` is a field (enum value) in the outer enum class, `AccessibleAttribute`, so can be referenced from the nested enum class without qualifying it with the outer class name. If we wanted to be more clear (and work around the Eclipse limitation), it could be written as: > > > {@link AccessibleAttribute#TOGGLE_STATE TOGGLE_STATE} Changed it as : `This enum describes the values for {@link AccessibleAttribute#TOGGLE_STATE TOGGLE_STATE} attribute.` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1194921928 From arapte at openjdk.org Tue May 16 10:27:05 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 10:27:05 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v4] In-Reply-To: References: Message-ID: > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1088/files - new: https://git.openjdk.org/jfx/pull/1088/files/2d89e9fb..5c8da124 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1088&range=02-03 Stats: 13 lines in 3 files changed: 4 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1088.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1088/head:pull/1088 PR: https://git.openjdk.org/jfx/pull/1088 From arapte at openjdk.org Tue May 16 10:27:07 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 10:27:07 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> Message-ID: On Fri, 12 May 2023 18:20:37 GMT, Andy Goryachev wrote: >> Ambarish Rapte 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 branch 'master' into a11y-8284542-CheckBoxTreeItem >> - Review Comment: Add enum ToggleState >> - Add CheckBoxTreeItem role and TOGGLE_STATE attribute > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java line 369: > >> 367: AccessibleRole.TREE_ITEM, >> 368: AccessibleRole.CHECK_BOX_TREE_ITEM, >> 369: AccessibleRole.TREE_TABLE_ROW > > [question] is the order of elements significant in any way? The order does not matter, the roles are accessed by value on the native side code. (`initEnum()`) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1194948439 From arapte at openjdk.org Tue May 16 10:29:55 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 10:29:55 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <_IRx1xTIlGXxdi5Syrxb4-OQgTibgDwxswcYoBCzcxI=.fbbd3ff2-e66f-4afd-8f6c-6eae04dbcd6b@github.com> Message-ID: On Fri, 12 May 2023 22:07:31 GMT, Andy Goryachev wrote: >> I usually prefer to avoid these sort of unrelated changes to minimize the diffs. Either way is fine. > > in this particular case, with many fall-throughs, I think the code would benefit from reformatting. Minimal diff eases in tracing regression and in review. May be we can take up the cleanup as a separate issue, there seems to be multiple of such instances. (of switch/replacing if with switch) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1088#discussion_r1194954318 From kpk at openjdk.org Tue May 16 10:32:00 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 May 2023 10:32:00 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v5] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Change insertion index initialization approach. Add additional test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/7919d5b5..1eb11749 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=03-04 Stats: 31 lines in 2 files changed: 25 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Tue May 16 10:34:54 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 May 2023 10:34:54 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> Message-ID: On Mon, 15 May 2023 15:50:06 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize insertion index in PrismTextLayout > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 479: > >> 477: insertionIndex = charIndex; >> 478: if (!leading) { >> 479: insertionIndex += 1; > > I would have initialized insertionIndex directly in all the blocks instead of adding conditional logic, but this code does seem to produce the desired result. > For clarify, would it be possible to avoid this additional conditional logic? > > Also, do existing unit tests cover the newly modified paths? Initializing the insertion index directly with character index looks better. In this way we can avoid additional conditional logic as well. Changed code to do so. Added additional test case. This tests the condition present in line 430. I couldn't create the scenario to hit line 473. If you have any suggestions please let me know. While testing I found that `testTextFlowInsertionIndexUsingMultipleEmojis()` was failing intermittently when all the tests are run. Hence added small delay. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1194959394 From john.hendrikx at gmail.com Tue May 16 11:54:57 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 16 May 2023 13:54:57 +0200 Subject: Improvements for Focus Traversal code Message-ID: Hi list, I've gone down another rabbit hole in JavaFX, this time related to focus traversal. # Navigation keys are not handled universally for all controls Some controls install custom behaviors, and some don't.? The custom behaviors often include direct handling of navigation keys (getFocusTraversalMappings).? The controls that don't (often controls that are not focus traversable by default, like Label) rely on the SceneEventDispatcher to handle navigation keys. However, this leads to subtle differences; when placed inside another control that may be interested in the navigation keys (like ListView, TableView, ScrollPane) a Button will still respond to all navigation keys directly (and correctly), while a focus traversable Label will let these events bubble up, possibly to be consumed by its parent (ie. pressing DOWN may not focus another control inside the View, but instead scroll the view down as if the View had focus).? This is inconsistent. ==> As any Node can be made focus traversable, I think the handling of navigation keys should be done by Node itself; basically, after all event handlers have run for a Node, a final event handler should be called which checks for unconsumed navigation key events, and triggers navigation only then.? This would make all Nodes work consistently where navigation is concerned and would remove the need to add focus traversal key mappings in Behaviors.? Button would respond as it always has, while a focus traversable label would now work exactly as a Button would, even when nested in a View type parent. # Translate Navigation Keys to Higher Level Events When a key is determined to trigger navigation, we should translate this to a new type of event, for example NavigationEvent (or TraversalEvent). This Key event that triggered it is consumed, and this new event is fired.? This new event captures the intention to navigate somewhere (Navigate NEXT, PREVIOUS, UP, DOWN, LEFT, RIGHT) and participates in the usual filtering/bubbling phases.? This is far better than having a (potentially platform specific) key event with multiple possible meanings (sometimes it navigates, sometimes it scrolls) when one wants to deal with navigation issues. This would solve a number of problems: - Navigation events can all be handled in the same place, the Scene. - One can trigger navigation in a nice programmatic way, instead of simulating a key press, which may be platform specific, one can send out a NavigationEvent#NEXT event type. - Influencing the focus traversal mechanism is much easier, as these events can be listened to, filtered and consumed as needed. Contrast this with trying to do this with key events which may have different meanings depending on the state of the control receiving them.? Blocking navigation for example is a matter of consuming a type of Navigation event before it bubbles up to the Scene. - It could allow for focus traversal that goes beyond Scenes (ie. focus another Scene, or a Swing control).? Navigation events not consumed by Scene could trigger other actions.? For NEXT/PREVIOUS navigation this may require a Scene setting that prevents wrapping around to the first/last control, and perhaps with the help of some further Navigation event variations (like nagivating to FIRST or LAST). - A lot of the Accessor code to be able to reach the (private) traverse methods would not be needed anymore as the event system can reach the Scene code without needing accessors --John From cjgunzel at gmail.com Tue May 16 12:53:11 2023 From: cjgunzel at gmail.com (Chuck Davis) Date: Tue, 16 May 2023 05:53:11 -0700 Subject: Improvements for Focus Traversal code In-Reply-To: References: Message-ID: One of the things I really miss about Swing was the ease with which we could move focus programmatically. All we had to do was call the focus object (don't remember the name) and call focus.next() or focus.previous(). Having to get the next Control and call Control.requestFocus() is a hack. While the focus traversal code is being upgraded, please include Control.getFocusTraversal().next() and Control.getFocusTraversal().previous() so we can catch up with Swing capabilities. Those of us old enough to have grown up with real computers still remember that focus from input to input is supposed to be done by pressing the "enter" key -- NOT the "tab" key. On Tue, May 16, 2023 at 4:55?AM John Hendrikx wrote: > Hi list, > > I've gone down another rabbit hole in JavaFX, this time related to focus > traversal. > > # Navigation keys are not handled universally for all controls > > Some controls install custom behaviors, and some don't. The custom > behaviors often include direct handling of navigation keys > (getFocusTraversalMappings). The controls that don't (often controls > that are not focus traversable by default, like Label) rely on the > SceneEventDispatcher to handle navigation keys. > > However, this leads to subtle differences; when placed inside another > control that may be interested in the navigation keys (like ListView, > TableView, ScrollPane) a Button will still respond to all navigation > keys directly (and correctly), while a focus traversable Label will let > these events bubble up, possibly to be consumed by its parent (ie. > pressing DOWN may not focus another control inside the View, but instead > scroll the view down as if the View had focus). This is inconsistent. > > ==> As any Node can be made focus traversable, I think the handling of > navigation keys should be done by Node itself; basically, after all > event handlers have run for a Node, a final event handler should be > called which checks for unconsumed navigation key events, and triggers > navigation only then. This would make all Nodes work consistently where > navigation is concerned and would remove the need to add focus traversal > key mappings in Behaviors. Button would respond as it always has, while > a focus traversable label would now work exactly as a Button would, even > when nested in a View type parent. > > # Translate Navigation Keys to Higher Level Events > > When a key is determined to trigger navigation, we should translate this > to a new type of event, for example NavigationEvent (or TraversalEvent). > This Key event that triggered it is consumed, and this new event is > fired. This new event captures the intention to navigate somewhere > (Navigate NEXT, PREVIOUS, UP, DOWN, LEFT, RIGHT) and participates in the > usual filtering/bubbling phases. This is far better than having a > (potentially platform specific) key event with multiple possible > meanings (sometimes it navigates, sometimes it scrolls) when one wants > to deal with navigation issues. > > This would solve a number of problems: > > - Navigation events can all be handled in the same place, the Scene. > - One can trigger navigation in a nice programmatic way, instead of > simulating a key press, which may be platform specific, one can send out > a NavigationEvent#NEXT event type. > - Influencing the focus traversal mechanism is much easier, as these > events can be listened to, filtered and consumed as needed. Contrast > this with trying to do this with key events which may have different > meanings depending on the state of the control receiving them. Blocking > navigation for example is a matter of consuming a type of Navigation > event before it bubbles up to the Scene. > - It could allow for focus traversal that goes beyond Scenes (ie. focus > another Scene, or a Swing control). Navigation events not consumed by > Scene could trigger other actions. For NEXT/PREVIOUS navigation this > may require a Scene setting that prevents wrapping around to the > first/last control, and perhaps with the help of some further Navigation > event variations (like nagivating to FIRST or LAST). > - A lot of the Accessor code to be able to reach the (private) traverse > methods would not be needed anymore as the event system can reach the > Scene code without needing accessors > > --John > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue May 16 13:11:59 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 13:11:59 GMT Subject: RFR: 8306328: Update libFFI to 3.4.4 [v2] In-Reply-To: References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Thu, 11 May 2023 01:09:53 GMT, Alexander Matveev wrote: >> - libFFI updated to 3.4.4. >> - No additional changes are done to the code. >> - Tested on Linux, Windows x64 and macOS x64/aarch64. >> - Windows x86 config files are updated, but no build/testing was done for 32-bit. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8306328: Update libFFI to 3.4.4 [v3] LGTM, tested on windows-x64. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1131#pullrequestreview-1428544370 From lkostyra at openjdk.org Tue May 16 13:20:56 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 16 May 2023 13:20:56 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v2] In-Reply-To: <9k2hFTZZnKg9c2YScsuNiAfNJ0g0HdaqPzLQh7jxOHc=.a3b4befc-89de-4365-8f20-81c09c842006@github.com> References: <9k2hFTZZnKg9c2YScsuNiAfNJ0g0HdaqPzLQh7jxOHc=.a3b4befc-89de-4365-8f20-81c09c842006@github.com> Message-ID: On Wed, 10 May 2023 22:31:53 GMT, Kevin Rushforth wrote: >> Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - GlassViewDelegate: Return to deprecated *PboardType symbols >> >> New NSPasteboardType* symbols were introduced starting 10.13, and we're >> targetting 10.12. This deprecation should probably be resolved once we target >> macOS 10.13+. >> >> Old NS*PboardType symbols do not have an equivalent of NSPasteboardTypeFileURL, >> so this branch was removed. >> - GlassPasteboard: Correct macOS version information in comments >> >> New DnD API was introduced starting macOS 10.7, not 10.14 >> - GlassView: Remove deprecated draggingSourceOperationMask >> - DndTest: Update instructions >> >> On Mac to enable moving you must press Cmd, not Shift. >> - Restore logic responsible for Cmd key support >> - Merge branch 'master' into dnd_multiple_items-JDK-8233955 >> - Add DnD Multiple File manual test >> - Fix preview position; cleanup code >> - Add image previews and finish DnD code >> >> Fixes issues with tests caused by first commit. >> >> Removes old code used as placeholder. >> - Migrate DnD native code to DraggingSession API >> >> Previous implementation used dragImage call which is deprecated since macOS 10.14. Additionally, >> 10.14 introduced a restriction not allowing for more than one drag item in the Pasteboard. This >> change fixes crashes caused by old API use when DnD-ing more than one item. > > This fixes the problem, but there is one regression in behavior I noticed. To reproduce: > > 1. Run `DndTest` (in the same manual tests dir as the one you added) > 2. Hold down the CMD key > 3. Drag the "DRAG ME" label to the "DROP ME" (while holding down CMD) > > BUG: When you release the button, the drag does not complete. The expected behavior is that the drag completes with a transfer mode of "MOVE" @kevinrushforth now that #1139 is up, should I revert fa42b1b? I could update more constants in the process too to keep DnD code clean of deprecated constants, kind of like #1137 does ------------- PR Comment: https://git.openjdk.org/jfx/pull/1089#issuecomment-1549662273 From arapte at openjdk.org Tue May 16 15:15:00 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 16 May 2023 15:15:00 GMT Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source code repository [v6] In-Reply-To: References: Message-ID: On Sun, 14 May 2023 12:29:01 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update .gitignore >> - Remove unrelated gitignore > > @arapte Would you take a look when you have time? Thanks. @tsayao I am reviewing/testing the change. Please allow me couple days to conclude. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1009#issuecomment-1549867642 From angorya at openjdk.org Tue May 16 15:27:55 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 May 2023 15:27:55 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v4] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:27:05 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by angorya (Reviewer). Is JDK-8087651 a duplicate of this issue? or related? ------------- PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1428854464 PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1549887560 From angorya at openjdk.org Tue May 16 15:52:52 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 May 2023 15:52:52 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v3] In-Reply-To: <7do4IWip2YovnYccDUx94vNM35jRbz7-ks78FMYRxvM=.b5514092-626c-4930-91ed-70f9c8ff5702@github.com> References: <28x0cupN_FBG82EUxaxaIMzoAfAd9Q0oouDb-lQRAYQ=.7ade697e-77da-4604-9ee4-66609d7fe9da@github.com> <3EmqW6So5ybYj57F7-Hnt8X2Hr06dlVJfX1CeRb0Nbo=.0f938a22-0b2e-4a6c-873a-c6e4a9651904@github.com> <7do4IWip2YovnYccDUx94vNM35jRbz7-ks78FMYRxvM=.b5514092-626c-4930-91ed-70f9c8ff5702@github.com> Message-ID: On Fri, 12 May 2023 22:30:27 GMT, Kevin Rushforth wrote: > Definitely unrelated, but it should be filed as a bug. I remember seeing this before, but I don't see a bug for it. created [JDK-8308191](https://bugs.openjdk.org/browse/JDK-8308191) [macOS] VoiceOver decorations are shifted on second monitor ------------- PR Comment: https://git.openjdk.org/jfx/pull/1088#issuecomment-1549931471 From andy.goryachev at oracle.com Tue May 16 16:11:30 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 16 May 2023 16:11:30 +0000 Subject: Improvements for Focus Traversal code In-Reply-To: References: Message-ID: I agree that focus management is one of the less developed parts of JavaFX. In addition to all the scenarios listed by John and Chuck, there is a case where input is accepted by two controls at the same time * JDK-8292933 Multiple focused components accepting keyboard input I was thinking we could have a FocusManager that would keep track of where the focus is at any given time (across all the visible Stages), as well as FocusTraversalPolicy that governs traversal on a Stage or a Parent. The FocusManager would expose a currentFocusOwner and a currentFocusedStage properies, provide programmatic focus traversal, manage the keys etc. I also think Swing got the focus subsystem right, so perhaps we could consider doing something similar. Would this change be backward compatible, or it will introduce breaking changes in the public APIs? -andy From: openjfx-dev on behalf of Chuck Davis Date: Tuesday, May 16, 2023 at 05:53 To: Cc: openjfx-dev Subject: Re: Improvements for Focus Traversal code One of the things I really miss about Swing was the ease with which we could move focus programmatically. All we had to do was call the focus object (don't remember the name) and call focus.next() or focus.previous(). Having to get the next Control and call Control.requestFocus() is a hack. While the focus traversal code is being upgraded, please include Control.getFocusTraversal().next() and Control.getFocusTraversal().previous() so we can catch up with Swing capabilities. Those of us old enough to have grown up with real computers still remember that focus from input to input is supposed to be done by pressing the "enter" key -- NOT the "tab" key. On Tue, May 16, 2023 at 4:55?AM John Hendrikx > wrote: Hi list, I've gone down another rabbit hole in JavaFX, this time related to focus traversal. # Navigation keys are not handled universally for all controls Some controls install custom behaviors, and some don't. The custom behaviors often include direct handling of navigation keys (getFocusTraversalMappings). The controls that don't (often controls that are not focus traversable by default, like Label) rely on the SceneEventDispatcher to handle navigation keys. However, this leads to subtle differences; when placed inside another control that may be interested in the navigation keys (like ListView, TableView, ScrollPane) a Button will still respond to all navigation keys directly (and correctly), while a focus traversable Label will let these events bubble up, possibly to be consumed by its parent (ie. pressing DOWN may not focus another control inside the View, but instead scroll the view down as if the View had focus). This is inconsistent. ==> As any Node can be made focus traversable, I think the handling of navigation keys should be done by Node itself; basically, after all event handlers have run for a Node, a final event handler should be called which checks for unconsumed navigation key events, and triggers navigation only then. This would make all Nodes work consistently where navigation is concerned and would remove the need to add focus traversal key mappings in Behaviors. Button would respond as it always has, while a focus traversable label would now work exactly as a Button would, even when nested in a View type parent. # Translate Navigation Keys to Higher Level Events When a key is determined to trigger navigation, we should translate this to a new type of event, for example NavigationEvent (or TraversalEvent). This Key event that triggered it is consumed, and this new event is fired. This new event captures the intention to navigate somewhere (Navigate NEXT, PREVIOUS, UP, DOWN, LEFT, RIGHT) and participates in the usual filtering/bubbling phases. This is far better than having a (potentially platform specific) key event with multiple possible meanings (sometimes it navigates, sometimes it scrolls) when one wants to deal with navigation issues. This would solve a number of problems: - Navigation events can all be handled in the same place, the Scene. - One can trigger navigation in a nice programmatic way, instead of simulating a key press, which may be platform specific, one can send out a NavigationEvent#NEXT event type. - Influencing the focus traversal mechanism is much easier, as these events can be listened to, filtered and consumed as needed. Contrast this with trying to do this with key events which may have different meanings depending on the state of the control receiving them. Blocking navigation for example is a matter of consuming a type of Navigation event before it bubbles up to the Scene. - It could allow for focus traversal that goes beyond Scenes (ie. focus another Scene, or a Swing control). Navigation events not consumed by Scene could trigger other actions. For NEXT/PREVIOUS navigation this may require a Scene setting that prevents wrapping around to the first/last control, and perhaps with the help of some further Navigation event variations (like nagivating to FIRST or LAST). - A lot of the Accessor code to be able to reach the (private) traverse methods would not be needed anymore as the event system can reach the Scene code without needing accessors --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue May 16 16:11:58 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 May 2023 16:11:58 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v4] In-Reply-To: References: Message-ID: <7HoqsozmdHTMOWSqXZUZwcmm1XM0859CePcjfT7ualM=.4c95ad47-24ab-439c-b641-d2c0564bfc97@github.com> On Tue, 16 May 2023 10:27:05 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1428941400 From jgneff at openjdk.org Tue May 16 16:24:54 2023 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 16 May 2023 16:24:54 GMT Subject: RFR: 8307316: Let JavaFX be built on unknown architectures In-Reply-To: References: Message-ID: On Wed, 3 May 2023 16:02:34 GMT, John Neffenger wrote: > Please review these changes to the Gradle build files and the dependency verification file. The initial version of this pull request extends the permitted build platforms for Linux to the Java architectures `arm`, `ppc64le`, and `s390x` and adds an entry to the dependency verification file for the `i386` architecture. The Debian names for these architectures are `armhf`, `i386`, `ppc64el`, and `s390x`. @Glavo I would also appreciate your comments and suggestions. I modified the initial patch [that you said][1] you were using, so please let me know if the latest changes in this pull request still work for you on the MIPS64el and RISC-V architectures. Thanks! [1]: https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039383.html ------------- PR Comment: https://git.openjdk.org/jfx/pull/1124#issuecomment-1549985464 From andy.goryachev at oracle.com Tue May 16 16:36:39 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 16 May 2023 16:36:39 +0000 Subject: Customizable Table Button Menu In-Reply-To: References: Message-ID: This looks to me like a good solution, with a rather small probability of breaking the existing application code. -andy From: openjfx-dev on behalf of Marius Hanl Date: Monday, May 15, 2023 at 15:05 To: openjfx-dev Subject: Customizable Table Button Menu In https://github.com/openjdk/jfx/pull/1135 I implemented a way to override the behaviour when the table menu button is clicked. Current behaviour The table menu button is visible when setTableMenuButtonVisible(true) is called. When clicked, a ContextMenu is shown with all available columns of the table shown as MenuItem. A user can then click on a MenuItem to make the corresponding column (in)visible and the ContextMenu closes afterwards. Problems This comes with some limitations as described here https://bugs.openjdk.org/browse/JDK-8091419, here https://bugs.openjdk.org/browse/JDK-8091153 and here https://bugs.openjdk.org/browse/JDK-8092148. In short: - It is not always desired that the ContextMenu closes after the user clicked on a MenuItem. This is a limitation of the ContextMenu - The menu can not be invoked programmatically - The menu can not overridden in any way Solution To address these issues, the PR mentioned above adds a new protected method showColumnMenu(MouseEvent) which is called when the table menu button is clicked. Since this new method is protected, it can be overidden by developers. If not overridden, the known default ContextMenu is created and shown, as described above. This gives every developer the ability to fully customize the behaviour when the table menu button is clicked. A developer can implement their own Menu if the behaviour of the ContextMenu is not desired. The method can now also be invoked programmatically. Feel free to give Feedback and/or checkout the PR. -- Marius -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmeda at openjdk.org Tue May 16 16:53:41 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 16 May 2023 16:53:41 GMT Subject: RFR: 8306329 : Update ICU4C to 73 [v2] In-Reply-To: References: Message-ID: > Updated ICU to v73.1. Verified build and sanity. No issues seen. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1138/files - new: https://git.openjdk.org/jfx/pull/1138/files/599b7523..096c4d39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1138&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1138&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1138.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1138/head:pull/1138 PR: https://git.openjdk.org/jfx/pull/1138 From angorya at openjdk.org Tue May 16 17:42:53 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 May 2023 17:42:53 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v5] In-Reply-To: <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> Message-ID: On Tue, 16 May 2023 10:32:00 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Change insertion index initialization approach. Add additional test Karthik, we are very close! I see one consistent failure on macOS 13.3.1(a): java.lang.AssertionError: expected:<0> but was:<-2> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:633) at test.robot.javafx.scene.TextFlowSurrogatePairInsertionIndexTest.testTextFlowInsertionIndexUsingMultipleEmojis(TextFlowSurrogatePairInsertionIndexTest.java:227) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:147) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:127) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:90) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:55) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:102) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:54) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:95) at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:91) at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:60) at org.eclipse.jdt.internal.junit5.runner.JUnit5TestReference.run(JUnit5TestReference.java:98) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210) Also, I noticed that the tests do not cover a case of line wrapping - would it be possible to add a similar test where the text string is wrapped, so we can verify that monotonic test works across the wrap point please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1550100188 From kpk at openjdk.org Tue May 16 17:55:53 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 16 May 2023 17:55:53 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v5] In-Reply-To: <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> Message-ID: On Tue, 16 May 2023 10:32:00 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Change insertion index initialization approach. Add additional test Sure. I will check if I can add new test case with wrapped text. I was also getting same failure but after the latest fix I didn't find failure in `testTextFlowInsertionIndexUsingMultipleEmojis` test. I will check this again. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1550113233 From angorya at openjdk.org Tue May 16 17:55:56 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 May 2023 17:55:56 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v4] In-Reply-To: References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <2c5EycXlOR17gt5cf_1xOE_Ncm0BBiRNugiCKFuVTe4=.e9e13776-d795-4745-9caa-8e33452f7ac1@github.com> Message-ID: On Tue, 16 May 2023 10:31:57 GMT, Karthik P K wrote: > I couldn't create the scenario to hit line 473. If you have any suggestions please let me know. I can't seem to trigger this code path (I wonder if it's possible to hit it at all). Anyway, the code there looks correct to me, even if this condition would never happen. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1091#discussion_r1195510090 From kcr at openjdk.org Tue May 16 20:43:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 May 2023 20:43:51 GMT Subject: Integrated: 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) In-Reply-To: References: Message-ID: On Mon, 15 May 2023 18:13:00 GMT, Kevin Rushforth wrote: > This PR bumps the minimum deployment target for JavaFX to macOS 11.0 (Big Sur) on x64 platforms, matching the current minimum on aarch64. > > As a follow-on to this, I will file a (low-priority) cleanup issue to remove any `@available` checks for 10.x, since those will then be no-ops. This pull request has now been integrated. Changeset: bff41c29 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/bff41c29478a00665ed7b561ecbb8b138c9b3245 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8308114: Bump minimum version of macOS for x64 to 11.0 (matching aarch64) Reviewed-by: angorya, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1139 From kizune at openjdk.org Tue May 16 22:04:10 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 16 May 2023 22:04:10 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v2] In-Reply-To: References: Message-ID: > Add the common base component for all the new implementing native classes Change native peer creation to use the new base component The new code will instantiate new protocol implementation for the given role if it exists or an old one if it does not exist > Added BUTTON role implementing class Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixes based on review. Modified parent retrieval to cache the parent inside the component peer because retrieving parent every time can be costly. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1084/files - new: https://git.openjdk.org/jfx/pull/1084/files/396e1308..e000a0e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=00-01 Stats: 74 lines in 5 files changed: 47 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1084.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1084/head:pull/1084 PR: https://git.openjdk.org/jfx/pull/1084 From michaelstrau2 at gmail.com Tue May 16 22:25:27 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 17 May 2023 00:25:27 +0200 Subject: ObservableValue.map special-cases the null value Message-ID: I'm trying to map an ObservableValue such that `null` is mapped to `false` and any other value is mapped to `true`. The following line of code should do the trick: ObservableValue mappedValue = nullableValue.map(x -> x != null); It turns out that this doesn't work, since `map` doesn't pass `null` to the mapping function. Instead of calling the mapping function, it always returns `null`. This is not technically a bug, as `map` is specified to have this behavior. It is a bit unfortunate, though; `null` is a perfectly valid value in many cases and its special treatment comes off as a bit of a surprise. I'm wondering whether we need a `mapNullable` operator that does what I intuitively expecting `map` to do, which is just unconditionally passing the value to the mapping function. From kcr at openjdk.org Tue May 16 23:26:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 May 2023 23:26:51 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v2] In-Reply-To: <9k2hFTZZnKg9c2YScsuNiAfNJ0g0HdaqPzLQh7jxOHc=.a3b4befc-89de-4365-8f20-81c09c842006@github.com> References: <9k2hFTZZnKg9c2YScsuNiAfNJ0g0HdaqPzLQh7jxOHc=.a3b4befc-89de-4365-8f20-81c09c842006@github.com> Message-ID: <65u_PmJUI9AnSbOOPTmqgnt7CSNkCH7ZToCqfR2VQ8Y=.18136a22-b68b-4e92-bd9c-75c74e5a4b65@github.com> On Wed, 10 May 2023 22:31:53 GMT, Kevin Rushforth wrote: >> Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - GlassViewDelegate: Return to deprecated *PboardType symbols >> >> New NSPasteboardType* symbols were introduced starting 10.13, and we're >> targetting 10.12. This deprecation should probably be resolved once we target >> macOS 10.13+. >> >> Old NS*PboardType symbols do not have an equivalent of NSPasteboardTypeFileURL, >> so this branch was removed. >> - GlassPasteboard: Correct macOS version information in comments >> >> New DnD API was introduced starting macOS 10.7, not 10.14 >> - GlassView: Remove deprecated draggingSourceOperationMask >> - DndTest: Update instructions >> >> On Mac to enable moving you must press Cmd, not Shift. >> - Restore logic responsible for Cmd key support >> - Merge branch 'master' into dnd_multiple_items-JDK-8233955 >> - Add DnD Multiple File manual test >> - Fix preview position; cleanup code >> - Add image previews and finish DnD code >> >> Fixes issues with tests caused by first commit. >> >> Removes old code used as placeholder. >> - Migrate DnD native code to DraggingSession API >> >> Previous implementation used dragImage call which is deprecated since macOS 10.14. Additionally, >> 10.14 introduced a restriction not allowing for more than one drag item in the Pasteboard. This >> change fixes crashes caused by old API use when DnD-ing more than one item. > > This fixes the problem, but there is one regression in behavior I noticed. To reproduce: > > 1. Run `DndTest` (in the same manual tests dir as the one you added) > 2. Hold down the CMD key > 3. Drag the "DRAG ME" label to the "DROP ME" (while holding down CMD) > > BUG: When you release the button, the drag does not complete. The expected behavior is that the drag completes with a transfer mode of "MOVE" > @kevinrushforth now that #1139 is up, should I revert [fa42b1b](https://github.com/openjdk/jfx/commit/fa42b1b13755dec05d77b3865ed657e954854286)? I think you could either revert the changes you mention (so that we won't be introducing any additional deprecated constants as part of this fix) or do it in a follow-up issue. Whichever you prefer. > I could update more constants in the process too to keep DnD code clean of deprecated constants, kind of like #1137 does That seems best left for a follow-on fix. Btw, I'll take a look at the updated PR tomorrow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1089#issuecomment-1550480809 From john.hendrikx at gmail.com Wed May 17 01:08:21 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 17 May 2023 03:08:21 +0200 Subject: ObservableValue.map special-cases the null value In-Reply-To: References: Message-ID: Hi Michael, As you're only trying to map to true/false, it is a bit ugly to do this I suppose: ????? nullableValue.map(x -> true).orElse(false); I've encountered situations like these before, where you only want to know about the presence of a value, and don't care what the value is.? If there are sufficient use cases, we could consider adding a method for this.? Instead of `mapNullable` though I was thinking more along the lines of `isPresent` and `isEmpty`: ????? ObservableValue isPresent();? // true if not null ????? ObservableValue isEmpty();? // true if null So far I didn't think it would be warranted to add such methods, but they're trivial to add. On 17/05/2023 00:25, Michael Strau? wrote: > I'm trying to map an ObservableValue such that `null` is mapped to > `false` and any other value is mapped to `true`. The following line of > code should do the trick: > ObservableValue mappedValue = nullableValue.map(x -> x != null); > > It turns out that this doesn't work, since `map` doesn't pass `null` > to the mapping function. Instead of calling the mapping function, it > always returns `null`. This is not technically a bug, as `map` is > specified to have this behavior. It is a bit unfortunate, though; > `null` is a perfectly valid value in many cases and its special > treatment comes off as a bit of a surprise. The alternative is worse I think, as JavaFX properties can easily be `null`, you'd have to add null checks to your map/flatMaps. Especially a construct like this: ????? node.sceneProperty() ? ?? ???? .flatMap(Scene::windowProperty) ??? ? ? ? .flatMap(Window::showingProperty) ? ?? ???? .orElse(false); ... would be really annoying to write if you had to deal with the nulls.? The functionality is closely related to what Optional offers, and that one doesn't pass `null` to its map/flatMap methods either, nor will it ever add a `mapNullable` :-) > I'm wondering whether we need a `mapNullable` operator that does what > I intuitively expecting `map` to do, which is just unconditionally > passing the value to the mapping function. Maybe, I think however that you'd only need this for the very special case where you are intending to ignore the actual value being passed to a map/flatMap, and only want to check it for null.? `isPresent` / `isEmpty` would be nicer for this.? For all other cases, where you are actually doing some kind of mapping, I think a map/orElse combo works great. --John From kizune at openjdk.org Wed May 17 06:47:52 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 06:47:52 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 07:22:54 GMT, Ambarish Rapte wrote: > I noticed two behavioral change, when VoiceOver is running. > > * Focus Rectangle: A Black (focus) rectangle is drawn around a focused control, or an item that has Accessibility focus. This seems correct and offers more visual information. > * Control + Option + space key and only space key can perform an action on two different controls at the same time. > Steps to observe: > > 1. Launch Ensemble and run Timeline sample from Animation section. > 2. Notice there are four buttons. > 3. At launch the button Start gets focus and focus rectangle. > 4. Press Space or Control+Option+Space button, both would trigger same Start button. > 5. Press tab once, the focus moves to Pause button. > 6. Press and hold Control+Option and press right arrow key two times. > 7. The black focus rectangle moves to Restart button but Pause button retains the focus. > 8. Pressing space button would trigger Pause button and > 9. Pressing Control+Option+Space button would trigger Restart button. > => I am not sure if this is expected behavior. > => Similar behavior is not observed with a simple AWT sample with three buttons added to Frame. This is expected behaviour. The square block is an accessibility cursor and it can be different from the keyboard focus. Pressing space will trigger action on the button from the FX side and Ctrl+Option+Space will launch an action from the accessibility subsystem. Note that my change does not alter this behaviour, FX acted the same before it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1084#issuecomment-1550835722 From lkostyra at openjdk.org Wed May 17 08:50:23 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 17 May 2023 08:50:23 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v3] In-Reply-To: References: Message-ID: > Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. > > Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. > > One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. > > Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: - GlassViewDelegate: Address review issues * Removed draggingSource pointer * Removed some leftover comments * Set delegate to nil - Revert "GlassViewDelegate: Return to deprecated *PboardType symbols" This reverts commit fa42b1b13755dec05d77b3865ed657e954854286. fa42b1b13 is not needed anymore - JFX will target macOS 11 soon. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1089/files - new: https://git.openjdk.org/jfx/pull/1089/files/fa42b1b1..a8b5b3de Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1089&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1089&range=01-02 Stats: 27 lines in 2 files changed: 13 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1089.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1089/head:pull/1089 PR: https://git.openjdk.org/jfx/pull/1089 From hmeda at openjdk.org Wed May 17 11:47:11 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 17 May 2023 11:47:11 GMT Subject: RFR: 8306329 : Update ICU4C to 73.1 [v3] In-Reply-To: References: Message-ID: > Updated ICU to v73.1. Verified build and sanity. No issues seen. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: update license ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1138/files - new: https://git.openjdk.org/jfx/pull/1138/files/096c4d39..d96d239c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1138&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1138&range=01-02 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1138.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1138/head:pull/1138 PR: https://git.openjdk.org/jfx/pull/1138 From kcr at openjdk.org Wed May 17 12:55:03 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 May 2023 12:55:03 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v5] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:25:49 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/910#pullrequestreview-1430612525 From kcr at openjdk.org Wed May 17 13:12:51 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 May 2023 13:12:51 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v2] In-Reply-To: References: Message-ID: <1BULtAhl8FQp0M0-IcDZlVPUU-eWjdQ6xpBOQjEQlUM=.890fa69d-e4fa-43b8-84ab-150746f5eeae@github.com> On Mon, 15 May 2023 22:39:52 GMT, Marius Hanl wrote: >> This PR implements a way to override the table column menu. >> When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. >> >> This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) >> >> This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. >> Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8091153: Improve javadoc to match the CSR The new API looks OK to me. I left a couple comments on the API docs. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 468: > 466: > 467: /** > 468: * Shows a menu containing all leaf columns as item. "item" --> "items" modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 472: > 470: * > 471: * @implNote This method can be overridden to create and show a custom menu. > 472: * @param mouseEvent the {@link MouseEvent} which was generated when the table menu button was pressed. Minor: by convention, the text following `@param` and `@return` tags should not end with a period. ------------- PR Review: https://git.openjdk.org/jfx/pull/1135#pullrequestreview-1430646782 PR Review Comment: https://git.openjdk.org/jfx/pull/1135#discussion_r1196490418 PR Review Comment: https://git.openjdk.org/jfx/pull/1135#discussion_r1196493786 From lkostyra at openjdk.org Wed May 17 15:22:57 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 17 May 2023 15:22:57 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet [v2] In-Reply-To: References: Message-ID: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> > This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. > > This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. Lukasz Kostyra has updated the pull request incrementally with three additional commits since the last revision: - Add index/null checks to ObservableListWrapper and VetoableListDecorator - ParentTest: Expect IndexOutOfBoundsException, add test cases - Parent: Remove index check from onProposedChange ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1136/files - new: https://git.openjdk.org/jfx/pull/1136/files/1508c62d..63023839 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1136&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1136&range=00-01 Stats: 77 lines in 4 files changed: 63 ins; 11 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1136.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1136/head:pull/1136 PR: https://git.openjdk.org/jfx/pull/1136 From kizune at openjdk.org Wed May 17 16:22:40 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 16:22:40 GMT Subject: RFR: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem [v4] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 10:27:05 GMT, Ambarish Rapte wrote: >> Issue: >> CheckBoxTreeItem extends TreeItem and adds a CheckBox. >> The state of this CheckBox is not visible to an accessibility client application. >> If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. >> >> Fix: >> Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. >> >> Verification: >> On Windows: Do the following with and without the fix. >> 1. Run the sample program attached to JBS issue. >> 2. Launch "Accessibility Insights for Window" >> 3. Observe that patterns section for each item >> 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by kizune (no project role). ------------- PR Review: https://git.openjdk.org/jfx/pull/1088#pullrequestreview-1431111424 From lkostyra at openjdk.org Wed May 17 16:42:32 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 17 May 2023 16:42:32 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet [v2] In-Reply-To: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> References: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> Message-ID: On Wed, 17 May 2023 15:22:57 GMT, Lukasz Kostyra wrote: >> This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. >> >> This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. > > Lukasz Kostyra has updated the pull request incrementally with three additional commits since the last revision: > > - Add index/null checks to ObservableListWrapper and VetoableListDecorator > - ParentTest: Expect IndexOutOfBoundsException, add test cases > - Parent: Remove index check from onProposedChange As a small note, the issue is solved with current patches, however I think the best solution would be what I mentioned in the original PR message - an interface in `VetoableListDecorator` which would let us "roll-back" any changes from `onProposedChange` (ex. revert `childSet` to original state) when backing lists throw an exception. This would require a more thorough analysis of what bits use `VetoableListDecorator` and if any roll-backs are necessary there in addition to Parent code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1136#issuecomment-1551732200 From mhanl at openjdk.org Wed May 17 16:44:11 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 May 2023 16:44:11 GMT Subject: Integrated: 8295078: TextField blurry when inside an TitledPane -> AnchorPane In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 09:05:34 GMT, Marius Hanl wrote: > The problem here is, that the `AnchorPane` does not use its snapped insets. > Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. > > Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. > Line 2995 in `modena.css`: > > .titled-pane > .content > AnchorPane { > -fx-padding: 0.8em; > } > > which translates to 9.6px. > > EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` This pull request has now been integrated. Changeset: 6aeaff36 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/6aeaff36c07129d807fd3efa8aa20fb8dd8dc31a Stats: 183 lines in 3 files changed: 153 ins; 6 del; 24 mod 8295078: TextField blurry when inside an TitledPane -> AnchorPane Reviewed-by: angorya, kcr, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/910 From arapte at openjdk.org Wed May 17 16:49:01 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 17 May 2023 16:49:01 GMT Subject: Integrated: 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 15:13:25 GMT, Ambarish Rapte wrote: > Issue: > CheckBoxTreeItem extends TreeItem and adds a CheckBox. > The state of this CheckBox is not visible to an accessibility client application. > If we analyze a simple program that contains a CheckBoxTreeItem using a windows application "Accessibility Insights for Window", we can notice that toggle state of CheckBox is not exposed. > > Fix: > Include the [Toggle Control Pattern](https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementingtoggle) in Accessibility information of a CheckBoxTreeItem in addition to the patterns that are used for a TreeItem. > > Verification: > On Windows: Do the following with and without the fix. > 1. Run the sample program attached to JBS issue. > 2. Launch "Accessibility Insights for Window" > 3. Observe that patterns section for each item > 4. Select / de-select the CheckBoxes and observe the patterns section for correctness of toggle state. This pull request has now been integrated. Changeset: bdadcb2c Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/bdadcb2c99ae5ffb8deb88d1591b9691016ac646 Stats: 141 lines in 5 files changed: 134 ins; 0 del; 7 mod 8284542: [Accessibility] [Win] Missing attribute for toggle state of CheckBox in CheckBoxTreeItem Reviewed-by: kcr, kizune, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1088 From almatvee at openjdk.org Wed May 17 18:21:00 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 17 May 2023 18:21:00 GMT Subject: Integrated: 8306328: Update libFFI to 3.4.4 In-Reply-To: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> References: <_5nLLb0mRexYL7rozwzih2pLB3vQfZ-5qYedAvNqQNI=.4c50859b-35f0-4464-ab00-251e962704c1@github.com> Message-ID: On Wed, 10 May 2023 02:11:19 GMT, Alexander Matveev wrote: > - libFFI updated to 3.4.4. > - No additional changes are done to the code. > - Tested on Linux, Windows x64 and macOS x64/aarch64. > - Windows x86 config files are updated, but no build/testing was done for 32-bit. This pull request has now been integrated. Changeset: 8110f548 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/8110f548fc561dc39e15deb7ac0c5555ececa8b6 Stats: 520 lines in 21 files changed: 267 ins; 41 del; 212 mod 8306328: Update libFFI to 3.4.4 Reviewed-by: jvos, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1131 From kevin.rushforth at oracle.com Wed May 17 18:25:49 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 May 2023 11:25:49 -0700 Subject: Upcoming compiler updates for Mac, Linux, Windows Message-ID: <531a2237-e7d6-ef7d-0049-d08898047273@oracle.com> As a heads-up, I have filed the following JBS issues to bump the compiler versions used to build JavaFX production builds: Mac: JDK-8308306 [1] : Update to Xcode 14.3 on macOS Linux : JDK-8308307 [2] : Update to gcc 12.2.0 on Linux Windows: JDK-8308308 [3] : Update to Visual Studio 2022 version 17.5.0 on Windows Initial testing for these compilers has already done by the JDK team, and we've been doing some testing of JavaFX as well. In addition to it being a generally good idea to keep up to date, the next WebKit update (616.1) will require newer compilers: WebKit uses C++20 features, which aren't supported by the current compilers. Known implications: Windows: The existing WebKit sources, which use the C++17 flag, won't build with VS2022 17.5.0. This is tracked by JDK-8303748 , and will be fixed in the same PR as the update to 17.5.0. Mac : Xcode 14.3 requires building on macOS 13 (Ventura), although it is known to build on macOS 12 (Monterrey). Additionally, Xcode 14.x dropped support for deploying to 10.12 (Sierra) or earlier, but we already bumped our minimum to a higher version (macOS 11 is now the minimum). Linux: Nothing so far. Questions? Concerns? -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8308306 [2] https://bugs.openjdk.org/browse/JDK-8308307 [3] https://bugs.openjdk.org/browse/JDK-8308308 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Wed May 17 19:23:35 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 May 2023 19:23:35 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v3] In-Reply-To: References: Message-ID: <4ETtGEdoPWwV_7Serc744g36mAhS9tZ0CPGrtDuIDhg=.04039db8-4714-4667-b9cd-e08d5c266f33@github.com> > This PR implements a way to override the table column menu. > When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. > > This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) > > This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. > Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8091153: Improve javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1135/files - new: https://git.openjdk.org/jfx/pull/1135/files/aadbb432..86f854f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1135.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1135/head:pull/1135 PR: https://git.openjdk.org/jfx/pull/1135 From mhanl at openjdk.org Wed May 17 19:29:13 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 May 2023 19:29:13 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v4] In-Reply-To: References: Message-ID: > This PR implements a way to override the table column menu. > When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. > > This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) > > This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. > Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8091153: Added period to @implNote ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1135/files - new: https://git.openjdk.org/jfx/pull/1135/files/86f854f5..17520472 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1135&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1135.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1135/head:pull/1135 PR: https://git.openjdk.org/jfx/pull/1135 From mhanl at openjdk.org Wed May 17 19:34:00 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 May 2023 19:34:00 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v2] In-Reply-To: <1BULtAhl8FQp0M0-IcDZlVPUU-eWjdQ6xpBOQjEQlUM=.890fa69d-e4fa-43b8-84ab-150746f5eeae@github.com> References: <1BULtAhl8FQp0M0-IcDZlVPUU-eWjdQ6xpBOQjEQlUM=.890fa69d-e4fa-43b8-84ab-150746f5eeae@github.com> Message-ID: <8ifNzjWex8sJVQ1CWEMTeatkfwg8Oho1sNYo58FgrKY=.3eb46c28-2bb8-4803-94ea-d6eb1866e923@github.com> On Wed, 17 May 2023 13:09:09 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8091153: Improve javadoc to match the CSR > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableHeaderRow.java line 472: > >> 470: * >> 471: * @implNote This method can be overridden to create and show a custom menu. >> 472: * @param mouseEvent the {@link MouseEvent} which was generated when the table menu button was pressed. > > Minor: by convention, the text following `@param` and `@return` tags should not end with a period. Changed. And thanks for the hint, I actually didn't know that this is a convention. Personally, I also use the variant without a period, so it's good to know that this is indeed the convention. ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1135#discussion_r1196971714 From angorya at openjdk.org Wed May 17 19:38:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 May 2023 19:38:01 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v4] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 19:29:13 GMT, Marius Hanl wrote: >> This PR implements a way to override the table column menu. >> When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. >> >> This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) >> >> This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. >> Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8091153: Added period to @implNote tested on macOS with Tree/TableView, working as expected. I wish the default implementation did not hide the popup on mouse click, to allow for toggling multiple columns, but it is out of scope for this PR. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1135#pullrequestreview-1431430131 From mhanl at openjdk.org Wed May 17 19:49:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 17 May 2023 19:49:55 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v4] In-Reply-To: References: Message-ID: <1uJPMFayZoXF9UtmaUGGcxKqPnX49KFNr6QjRrtMg2A=.9c492307-0e09-4bf0-ae4d-2b9a337e3aca@github.com> On Wed, 17 May 2023 19:35:41 GMT, Andy Goryachev wrote: > I wish the default implementation did not hide the popup on mouse click, to allow for toggling multiple columns, but it is out of scope for this PR. I agree that this behavior is rather uncomfortable. The problem is that we are changing a behavior that may or may not be expected. Regardless, we should evaluate it. I think the value is higher than the risk. In any case, anyone can now customize this to their needs without sacrificing performance or anything else. This also gives us the possibility to close improvements that we think don't fit to a standard implementation with the hint that this can be implemented by yourself in this case. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1135#issuecomment-1551958205 From kizune at openjdk.org Wed May 17 20:23:28 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 20:23:28 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v3] In-Reply-To: References: Message-ID: > Add the common base component for all the new implementing native classes Change native peer creation to use the new base component The new code will instantiate new protocol implementation for the given role if it exists or an old one if it does not exist > Added BUTTON role implementing class Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fixed situation when performAction throws an exception on Java side - now we are properly returning FALSE notifying system that action has not been performed successfully. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1084/files - new: https://git.openjdk.org/jfx/pull/1084/files/e000a0e4..2834c7da Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=01-02 Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1084.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1084/head:pull/1084 PR: https://git.openjdk.org/jfx/pull/1084 From kizune at openjdk.org Wed May 17 20:23:28 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 20:23:28 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v3] In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 14:31:01 GMT, Kevin Rushforth wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed situation when performAction throws an exception on Java side - now we are properly >> returning FALSE notifying system that action has not been performed successfully. > > modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 120: > >> 118: (*env)->CallVoidMethod(env, self->jAccessible, jAccessibilityPerformAction, actionId); >> 119: GLASS_CHECK_EXCEPTION(env); >> 120: return TRUE; > > Are there any cases where an exception is possible? If so, then might checking the exception and returning false if there is one be warranted? Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1084#discussion_r1197010760 From kizune at openjdk.org Wed May 17 20:31:27 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 20:31:27 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v4] In-Reply-To: References: Message-ID: > Add the common base component for all the new implementing native classes Change native peer creation to use the new base component The new code will instantiate new protocol implementation for the given role if it exists or an old one if it does not exist > Added BUTTON role implementing class Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Properly use NSObject instead of the GlassAccessible type. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1084/files - new: https://git.openjdk.org/jfx/pull/1084/files/2834c7da..d7602336 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1084&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1084.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1084/head:pull/1084 PR: https://git.openjdk.org/jfx/pull/1084 From kizune at openjdk.org Wed May 17 20:31:27 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 May 2023 20:31:27 GMT Subject: RFR: 8301312: Create implementation of NSAccessibilityButton protocol [v4] In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 14:36:30 GMT, Kevin Rushforth wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Properly use NSObject instead of the GlassAccessible type. > > modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 156: > >> 154: NSString *roleName = jStringToNSString(env, forRole); >> 155: Class classType = [AccessibleBase getComponentAccessibilityClass:roleName]; >> 156: GlassAccessible* accessible = NULL; > > It might be clearer to use `NSObject` here (which is the common supertype of `GlassAccessible` and `AccessibileBase`). Fixed. > modules/javafx.graphics/src/main/native-glass/mac/a11y/ButtonAccessibility.h line 37: > >> 35: - (NSRect)accessibilityFrame; >> 36: @end >> 37: > > Very minor: extra newline at the end of file. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1084#discussion_r1197014453 PR Review Comment: https://git.openjdk.org/jfx/pull/1084#discussion_r1197017319 From angorya at openjdk.org Wed May 17 21:50:04 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 May 2023 21:50:04 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 23:40:03 GMT, John Hendrikx wrote: >> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. > > John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: > > - Override hashCode with a comment explaining why > - Fix style issues > - Restore removed public method two sticky points: - verify somehow that nulls cannot be passed to *All() methods - consider adding a component type to BitSet modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 233: > 231: @Override > 232: public boolean containsAll(Collection c) { > 233: if (this.getClass() != c.getClass()) { this change is not equivalent: in the old code, null `c` would return false, in the new it'll throw an NPE modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 266: > 264: @Override > 265: public boolean addAll(Collection c) { > 266: if (this.getClass() != c.getClass()) { same, handling of the null 'c' argument. I wonder if this is intended behavior? modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 342: > 340: @Override > 341: public boolean retainAll(Collection c) { > 342: if (this.getClass() != c.getClass()) { ditto, null 'c' modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 433: > 431: @Override > 432: public boolean removeAll(Collection c) { > 433: if (this.getClass() != c.getClass()) { null 'c' modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 532: > 530: return true; > 531: } > 532: if (obj instanceof BitSet bitSet) { // fast path if other is a BitSet I think we may need to add a 'component type' to BitSet, to make sure than BitSet never intersects with BitSet. (Didn't we do it already, may be in some other PR?) modules/javafx.graphics/src/main/java/javafx/css/Match.java line 54: > 52: final int specificity; > 53: > 54: Match(final Selector selector, Set pseudoClasses, int idCount, int styleClassCount) { just curious: do we really need a 'final' for an effectively final argument? modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 135: > 133: node.styleHelper.cacheContainer.forceSlowpath = true; > 134: > 135: if (triggerStates[0] != null) { I see that a null check was added. Are we sure we added it to *every* possible place? (it's not trivial to verify that with Eclipse without massive changes) ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1070#pullrequestreview-1431658165 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197058675 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197059303 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197059913 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197060203 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197064223 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197065543 PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197077475 From jhendrikx at openjdk.org Wed May 17 22:00:00 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:00:00 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:12:48 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Override hashCode with a comment explaining why >> - Fix style issues >> - Restore removed public method > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 233: > >> 231: @Override >> 232: public boolean containsAll(Collection c) { >> 233: if (this.getClass() != c.getClass()) { > > this change is not equivalent: in the old code, null `c` would return false, in the new it'll throw an NPE That's correct, before it broke the contract of `Set`. It's not supposed to return `false` when the parameter is `null`. This class is sometimes exposed as public API (via `ObservableSet`) and so must respect the `Set` contract. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197092382 From jhendrikx at openjdk.org Wed May 17 22:02:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:02:56 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:13:46 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Override hashCode with a comment explaining why >> - Fix style issues >> - Restore removed public method > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 266: > >> 264: @Override >> 265: public boolean addAll(Collection c) { >> 266: if (this.getClass() != c.getClass()) { > > same, handling of the null 'c' argument. > I wonder if this is intended behavior? I doubt the `Set` contract was breached here on purpose. More likely, the original implementation was never exposed, or the original developer didn't realize that `Set` has a very specific contract that you must follow, or it won't interact well with other collections. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197094968 From jhendrikx at openjdk.org Wed May 17 22:06:00 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:06:00 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:20:28 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Override hashCode with a comment explaining why >> - Fix style issues >> - Restore removed public method > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 532: > >> 530: return true; >> 531: } >> 532: if (obj instanceof BitSet bitSet) { // fast path if other is a BitSet > > I think we may need to add a 'component type' to BitSet, to make sure than BitSet never intersects with BitSet. > > (Didn't we do it already, may be in some other PR?) We did, in #1076. However, I would like to not pull in all the `BitSet` fixes into this PR as this has nothing to do with `BitSet` and its many problems. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197097814 From angorya at openjdk.org Wed May 17 22:12:03 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 May 2023 22:12:03 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> On Wed, 17 May 2023 22:03:31 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 532: >> >>> 530: return true; >>> 531: } >>> 532: if (obj instanceof BitSet bitSet) { // fast path if other is a BitSet >> >> I think we may need to add a 'component type' to BitSet, to make sure than BitSet never intersects with BitSet. >> >> (Didn't we do it already, may be in some other PR?) > > We did, in #1076. However, I would like to not pull in all the `BitSet` fixes into this PR as this has nothing to do with `BitSet` and its many problems. Since it's an internal class, and both PseudoClassState and StyleClassSet are final, checking for class == class is probably sufficient. Do you think we should add a warning to BitSet, it is not a problem since no-one will ever extend it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197101958 From jhendrikx at openjdk.org Wed May 17 22:15:58 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:15:58 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:22:15 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Override hashCode with a comment explaining why >> - Fix style issues >> - Restore removed public method > > modules/javafx.graphics/src/main/java/javafx/css/Match.java line 54: > >> 52: final int specificity; >> 53: >> 54: Match(final Selector selector, Set pseudoClasses, int idCount, int styleClassCount) { > > just curious: do we really need a 'final' for an effectively final argument? `final` here will just warn you if you try to reassign the parameter. It was present in the original code. Reassigning locals and parameters should generally be avoided. For the first, you can have your IDE generate a warning or error. For the second, I have the habit of always assigning a variable when it is declared. In the rare cases where this can't be done, the `final` keyword offers little benefit. The keyword does not offer any further benefits on parameters and locals, and it hasn't since Java added the concept of effectively final (in Java 8 I think). Before this, you sometimes needed to add `final` so a local could be referred to in anonymous subclasses. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197105574 From jhendrikx at openjdk.org Wed May 17 22:23:03 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:23:03 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:39:10 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Override hashCode with a comment explaining why >> - Fix style issues >> - Restore removed public method > > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 135: > >> 133: node.styleHelper.cacheContainer.forceSlowpath = true; >> 134: >> 135: if (triggerStates[0] != null) { > > I see that a null check was added. > Are we sure we added it to *every* possible place? > > (it's not trivial to verify that with Eclipse without massive changes) The underlying collection `BitSet` is only used by classes dealing with styles and pseudo class states. I checked the classes involved, and only this one needed changing. The check was added because `BitSet` erroneously allowed adding `null` before (which resulted in no change), but that breaks the `Set` contract. In any case, adding a `null` collection is an error, we should never be lenient when it comes to `null`s. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197109602 From jhendrikx at openjdk.org Wed May 17 22:32:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:32:01 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:59:58 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 266: >> >>> 264: @Override >>> 265: public boolean addAll(Collection c) { >>> 266: if (this.getClass() != c.getClass()) { >> >> same, handling of the null 'c' argument. >> I wonder if this is intended behavior? > > I doubt the `Set` contract was breached here on purpose. More likely, the original implementation was never exposed, or the original developer didn't realize that `Set` has a very specific contract that you must follow, or it won't interact well with other collections. To be clear, `BitSet` is currently exposed via `Node#getPseudoClassStates`. I suspect it is almost never used by anyone, because there are a lot of bugs. For example, equality won't work correctly: node.getPseudoClassStates().equals(Set.of( ... )); // Always false, sets are of different types Nor will `containsAll`: node.getPseudoClassStates().containsAll(Set.of( ... )); // Always false, because Set is not a BitSet node.getPseudoClassStates().containsAll(null); // Doesn't throw NPE, returns false All of these are `Set` contract violations, that I suppose were thought to be irrelevant because it is a com.sun.* class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197116933 From jhendrikx at openjdk.org Wed May 17 22:39:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:39:56 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> References: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> Message-ID: On Wed, 17 May 2023 22:08:53 GMT, Andy Goryachev wrote: >> We did, in #1076. However, I would like to not pull in all the `BitSet` fixes into this PR as this has nothing to do with `BitSet` and its many problems. > > Since it's an internal class, and both PseudoClassState and StyleClassSet are final, checking for class == class is probably sufficient. > Do you think we should add a warning to BitSet, it is not a problem since no-one will ever extend it? This is also solved in #1076: if (obj instanceof BitSet bitSet && getElementType().equals(bitSet.getElementType())) But since that requires pulling in even more changes (`getElementType`) I've left it there. Relying on subclasses being final though seems like a bad idea for an abstract class, unless we seal it and use permits (or, just remove `BitSet` completely... it's purpose will be minimal if #1076 is accepted). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197124589 From jhendrikx at openjdk.org Wed May 17 22:56:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 22:56:56 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet [v2] In-Reply-To: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> References: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> Message-ID: On Wed, 17 May 2023 15:22:57 GMT, Lukasz Kostyra wrote: >> This issue happened because `childSet` member of Parent was modified during `onProposedChange()` call - that call did not recognize negative indexes as invalid, which caused an exception when actually adding the Node to a List. >> >> This seemed like the simplest solution which doesn't rework a lot of code underneath. Exceptions coming from a backing list/collection technically are handled by `VetoableListDecorator`'s try-catch clauses, however `VetoableListDecorator` does not provide an interface to react when such an exception happens - without it we cannot revert `childSet` back to its original state. > > Lukasz Kostyra has updated the pull request incrementally with three additional commits since the last revision: > > - Add index/null checks to ObservableListWrapper and VetoableListDecorator > - ParentTest: Expect IndexOutOfBoundsException, add test cases > - Parent: Remove index check from onProposedChange I think `ObservableListWrapper#remove(int, int)` also needs a check index check, or it may end up remove some items and then throw an exception (exceptions thrown from collections should not modify its state). modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 116: > 114: public boolean setAll(Collection col) { > 115: Objects.requireNonNull(col); > 116: onProposedChange(Collections.unmodifiableList(new ArrayList<>(col)), 0, size()); It's good to make it explicit. It already threw NPE because of `new ArrayList<>(col)`, so this is not a change. modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 270: > 268: @Override > 269: public boolean removeAll(Collection c) { > 270: Objects.requireNonNull(c); Looks like a good change, if `c` was `null` and the backing list was empty, this would not throw NPE, but now it does. modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java line 894: > 892: g.getChildren().remove(0); > 893: } > 894: I think you should also add tests for the `null` cases, if they aren't part of this test already. ------------- Changes requested by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1136#pullrequestreview-1431766296 PR Review Comment: https://git.openjdk.org/jfx/pull/1136#discussion_r1197130391 PR Review Comment: https://git.openjdk.org/jfx/pull/1136#discussion_r1197132309 PR Review Comment: https://git.openjdk.org/jfx/pull/1136#discussion_r1197133728 From jhendrikx at openjdk.org Wed May 17 23:17:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 23:17:56 GMT Subject: RFR: 8301763: Adding children to wrong index leaves inconsistent state in Parent#childrenSet [v2] In-Reply-To: References: <4CjSCzoExXLhFzuegtioZjvwfUG6S-S-w9rX-nORcLI=.4a0e6830-5a1c-45b0-a343-4db91649bd65@github.com> Message-ID: On Wed, 17 May 2023 16:40:01 GMT, Lukasz Kostyra wrote: > As a small note, the issue is solved with current patches, however I think the best solution would be what I mentioned in the original PR message - an interface in `VetoableListDecorator` which would let us "roll-back" any changes from `onProposedChange` (ex. revert `childSet` to original state) when backing lists throw an exception. This would require a more thorough analysis of what bits use `VetoableListDecorator` and if any roll-backs are necessary there in addition to Parent code. I'm not convinced this is needed or desirable. The `VetoableListDecorator` is currently set up that its owner can already make "preparations" for the change when it knows it won't veto it (there can be only one vetoer, making this reasonable). Furthermore, it has the wrapped list under its own control, so it knows what to expect (no exceptions can occur (after this fix) if it decides not to veto). A roll back mechanism would just complicate the code for very little benefit (a correct FX application won't run into these situations, you'll only be likely to encounter them during development). The whole mechanism surrounding the children list and bad additions should be seen as a best effort early warning system (like ConcurrentModificationExeption). With this fix I don't see any other ways you could get it in a bad state. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1136#issuecomment-1552201754 From angorya at openjdk.org Wed May 17 23:19:59 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 May 2023 23:19:59 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> Message-ID: On Wed, 17 May 2023 22:37:27 GMT, John Hendrikx wrote: >> Since it's an internal class, and both PseudoClassState and StyleClassSet are final, checking for class == class is probably sufficient. >> Do you think we should add a warning to BitSet, it is not a problem since no-one will ever extend it? > > This is also solved in #1076: > > if (obj instanceof BitSet bitSet && getElementType().equals(bitSet.getElementType())) > > But since that requires pulling in even more changes (`getElementType`) I've left it there. > > Relying on subclasses being final though seems like a bad idea for an abstract class, unless we seal it and use permits (or, just remove `BitSet` completely... it's purpose will be minimal if #1076 is accepted). that's my point. I suppose we could use sealed class here, since javafx requires minimum java17? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197153628 From kcr at openjdk.org Wed May 17 23:49:56 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 May 2023 23:49:56 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 08:50:23 GMT, Lukasz Kostyra wrote: >> Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. >> >> Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. >> >> One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. >> >> Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. > > Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: > > - GlassViewDelegate: Address review issues > > * Removed draggingSource pointer > * Removed some leftover comments > * Set delegate to nil > - Revert "GlassViewDelegate: Return to deprecated *PboardType symbols" > > This reverts commit fa42b1b13755dec05d77b3865ed657e954854286. > > fa42b1b13 is not needed anymore - JFX will target macOS 11 soon. All my testing looks good. I left a couple comments about possible memory leaks. modules/javafx.graphics/src/main/native-glass/mac/GlassPasteboard.m line 788: > 786: for (NSPasteboardItem* i in objects) > 787: { > 788: [dItems addObject:[[NSDraggingItem alloc] initWithPasteboardWriter:i]]; I think you need to call `autorelease` on the allocated `NSDraggingItem` (unless I missed seeing a release later on). modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 976: > 974: { > 975: // create an image with contents of URL > 976: image = [[NSImage alloc] initByReferencingFile:[[NSString alloc] initWithData:[pbItem dataForType:NSPasteboardTypeFileURL] encoding:NSUTF8StringEncoding]]; I think you need to call `autorelease` on the allocated `NSString`. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 989: > 987: { > 988: // create an image with contents of URL > 989: image = [[NSImage alloc] initByReferencingURL:[NSURL URLWithString:[[NSString alloc] initWithData:[pbItem dataForType:NSPasteboardTypeURL] encoding:NSUTF8StringEncoding]]]; I think you need to call `autorelease` on the allocated `NSString`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1089#pullrequestreview-1431803867 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1197174973 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1197175780 PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1197176435 From jhendrikx at openjdk.org Wed May 17 23:55:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 17 May 2023 23:55:56 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> Message-ID: On Wed, 17 May 2023 23:17:30 GMT, Andy Goryachev wrote: >> This is also solved in #1076: >> >> if (obj instanceof BitSet bitSet && getElementType().equals(bitSet.getElementType())) >> >> But since that requires pulling in even more changes (`getElementType`) I've left it there. >> >> Relying on subclasses being final though seems like a bad idea for an abstract class, unless we seal it and use permits (or, just remove `BitSet` completely... it's purpose will be minimal if #1076 is accepted). > > that's my point. I suppose we could use sealed class here, since javafx requires minimum java17? Do you think this needs to be changed as part of this PR? Note that the `==` solution requires: - sealing BitSet permitting only PseudoClassState and StyleClassSet - adding a warning that if you ever unseal it, that you must re-evaluate the `equals` implementation - adding a warning to PseudoClassState / StyleClassSet to re-evaluate `BitSet#equals` if you remove `final` The `instanceof` solution allows arbitary subclasses, like any other Set implementation does (`AbstractSet#equals` for example use `instanceof Set`) and requires no further changes. What I'm missing is the reasoning why you would want to change this. I realize that the other solution can also work, but that's not enough IMHO. For me the two options are practically equivalent, neither being truly better than the other, so then it is a matter of preference, and I slightly favor using `instanceof` here to avoid potential problems down the road. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197182269 From kcr at openjdk.org Wed May 17 23:54:01 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 May 2023 23:54:01 GMT Subject: RFR: 8233955: VM crashes if more than one file are added to ClipboardContent via drag and drop [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 08:50:23 GMT, Lukasz Kostyra wrote: >> Crashes started happening due to macOS DnD API change from macOS 10.14 onwards. 10.14 incrodues some [DnD constrains](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-10_14#Drag-and-Drop) which our DnD code happened to trigger on some occasions. >> >> Our code used deprecated `dragImage` API which since 10.14 had new requirement - each NSPasteboard item had to have a corresponding drag image. Not meeting this constraint raised an exception, which crashed the app. Since there was no possibility to add more drag images to `dragImage` API (it only took one NSImage as parameter) the code had to be rewritten - as such I upgraded it to new DnD API utilizing NSDraggingSession and related protocols. >> >> One side-effect of new DnD API is that it now modifies NSPasteboard for us - previous behavior was more "separated" from user code perspective (write items to pasteboard -> initiate a drag via `dragImage`). Manually updating NSPasteboard before calling `beginDraggingSessionWithItems` raised another exception related to NSPasteboard already having DnD-ed elements inside it. Some system tests, however, relied on that behavior and writing to NSPasteboard (`MacPasteboardShim.java` used in some tests creates a `Clipboard.DND` for test purposes). Since this path is in tests I assumed this behavior should stay and tried to make it as close to working as possible. Tests (including those using `MacPasteboardShim`) pass after my changes. >> >> Additionally, added a new manual test based on `DndTest.java` test which creates two temporary files and allows for testing faulty behavior. > > Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision: > > - GlassViewDelegate: Address review issues > > * Removed draggingSource pointer > * Removed some leftover comments > * Set delegate to nil > - Revert "GlassViewDelegate: Return to deprecated *PboardType symbols" > > This reverts commit fa42b1b13755dec05d77b3865ed657e954854286. > > fa42b1b13 is not needed anymore - JFX will target macOS 11 soon. modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1063: > 1061: [GlassDragSource setDelegate:nil]; > 1062: > 1063: [image release]; It looks like you aren't releasing the image now. You need to call `[image release]` to avoid a leak. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1089#discussion_r1197181145 From kcr at openjdk.org Thu May 18 00:01:57 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 May 2023 00:01:57 GMT Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState [v7] In-Reply-To: References: <1r2Z2KSlnKsiCcvONIedz9WRyXtm5gLhcOUuwbkl-wc=.684161fc-0365-47a3-8349-308ceacfe6cf@github.com> Message-ID: <5akT7Jt6q--MlR2Jg2ZPxLZOjX9rOyJ7daJ5oDAaFhM=.a3bac5e9-854f-45dd-bc98-d5d2a3cf7ab3@github.com> On Wed, 17 May 2023 23:53:14 GMT, John Hendrikx wrote: > Do you think this needs to be changed as part of this PR? I'll answer this part of your question: No. It seems out of scope for this particular bug fix, which is aimed at fixing an API and impl problem with `Match`, and should limit the changes to other classes to those needed to accomplish this. It's great to point out existing weaknesses in, say, `BitSet`, but they should be addressed separately, after evaluating the need. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1197185891 From kpk at openjdk.org Thu May 18 09:27:18 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 18 May 2023 09:27:18 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v6] In-Reply-To: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> Message-ID: <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> > Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. > > Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. > The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. > > Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add new test. Optimizations to make the tests robust ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1091/files - new: https://git.openjdk.org/jfx/pull/1091/files/1eb11749..a43bbdb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1091&range=04-05 Stats: 108 lines in 1 file changed: 70 ins; 24 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1091.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1091/head:pull/1091 PR: https://git.openjdk.org/jfx/pull/1091 From kpk at openjdk.org Thu May 18 09:29:57 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 18 May 2023 09:29:57 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v5] In-Reply-To: <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <-ocS0BmM_6rQq9-d4KU46UJyuoqJklki4GGHZJfP3ac=.80c35bdd-5949-4177-8443-5a8516f26dd6@github.com> Message-ID: On Tue, 16 May 2023 10:32:00 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Change insertion index initialization approach. Add additional test Added new test to validate character index and insertion index in wrapped text. Made optimizations to use single mouse move function in all the tests. @andy-goryachev-oracle , above failure is caused because test is asserting before the mouse event handler could retrive hitinfo values. So added small delays in all the tests to make sure that the text is rendered and test becomes stable before getting the hitinfo values and assertion. Please let me know if you are able to run all the tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1552785330 From kcr at openjdk.org Thu May 18 13:00:57 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 May 2023 13:00:57 GMT Subject: RFR: 8306329 : Update ICU4C to 73.1 [v3] In-Reply-To: References: Message-ID: On Wed, 17 May 2023 11:47:11 GMT, Hima Bindu Meda wrote: >> Updated ICU to v73.1. Verified build and sanity. No issues seen. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > update license This looks good with one comment about a missing LICENSE section. modules/javafx.web/src/main/native/Source/ThirdParty/icu/LICENSE line 3: > 1: COPYRIGHT AND PERMISSION NOTICE > 2: > 3: Copyright ? 1991-2023 Unicode, Inc. All rights reserved. This LICENSE file is missing the same preamble you recently added to `icu_web.md` lines 6-18. Or you can copy from: https://github.com/unicode-org/icu/blob/release-73-1/icu4c/LICENSE ------------- PR Review: https://git.openjdk.org/jfx/pull/1138#pullrequestreview-1432659228 PR Review Comment: https://git.openjdk.org/jfx/pull/1138#discussion_r1197782309 From angorya at openjdk.org Thu May 18 16:41:01 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 May 2023 16:41:01 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v6] In-Reply-To: <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> Message-ID: On Thu, 18 May 2023 09:27:18 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add new test. Optimizations to make the tests robust Almost good! It looks like there might be some timing issue still lingering in one test: the very first run failed with java.lang.AssertionError: expected:<0> but was:<-2> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:633) at test.robot.javafx.scene.TextFlowSurrogatePairInsertionIndexTest.testTextFlowInsertionIndexUsingMultipleEmojis(TextFlowSurrogatePairInsertionIndexTest.java:242) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:147) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:127) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:90) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:55) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:102) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:54) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:95) at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:91) at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:60) at org.eclipse.jdt.internal.junit5.runner.JUnit5TestReference.run(JUnit5TestReference.java:98) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210) Subsequent runs were ok. What could it be? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1553322557 From kpk at openjdk.org Thu May 18 17:00:02 2023 From: kpk at openjdk.org (Karthik P K) Date: Thu, 18 May 2023 17:00:02 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v6] In-Reply-To: <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> Message-ID: <_8ghe5EDkTE3qzoy0JQdkzkQyksNxSqqhUujeDdXlDs=.240f45ee-9fdd-4f44-8c48-9f6fd4037ec3@github.com> On Thu, 18 May 2023 09:27:18 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add new test. Optimizations to make the tests robust This looks like timing issue only. I believe we have to increase the delays little bit more. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1553343325 From angorya at openjdk.org Thu May 18 17:03:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 May 2023 17:03:10 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v6] In-Reply-To: <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> Message-ID: On Thu, 18 May 2023 09:27:18 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add new test. Optimizations to make the tests robust OK, I think I know what the problem is. Instead of adding `Thread.sleep(500);`, we should add `Toolkit.getToolkit().firePulse();` before `textSetLatch.countDown();` (after we add all children to TextFlow). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1091#issuecomment-1553347146 From michaelstrau2 at gmail.com Thu May 18 17:05:16 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 18 May 2023 19:05:16 +0200 Subject: ObservableValue.map special-cases the null value In-Reply-To: References: Message-ID: Hi John, the `isPresent()` and `isEmtpy()` methods don't feel entirely natural to me. I think the problem is that Optional has slightly different semantics compared to ObservableValue. An Optional either has a value, or it doesn't. The "it doesn't have a value" state doesn't feel exactly equivalent to "having the null value", since no Optional API will ever expose the null value. In contrast, ObservableValue will happily expose the null value. While the map(...).orElse(...) combination is sufficient for some scenarios, it doesn't allow to disambiguate the case where map() returns `null` from the case where map() was elided because the input argument was `null`. That's where mapNullable() would be materially different. But I acknowledge that this is an edge case. On Wed, May 17, 2023 at 3:08?AM John Hendrikx wrote: > > Hi Michael, > > As you're only trying to map to true/false, it is a bit ugly to do this > I suppose: > > nullableValue.map(x -> true).orElse(false); > > I've encountered situations like these before, where you only want to > know about the presence of a value, and don't care what the value is. > If there are sufficient use cases, we could consider adding a method for > this. Instead of `mapNullable` though I was thinking more along the > lines of `isPresent` and `isEmpty`: > > ObservableValue isPresent(); // true if not null > > ObservableValue isEmpty(); // true if null > > So far I didn't think it would be warranted to add such methods, but > they're trivial to add. > > On 17/05/2023 00:25, Michael Strau? wrote: > > I'm trying to map an ObservableValue such that `null` is mapped to > > `false` and any other value is mapped to `true`. The following line of > > code should do the trick: > > ObservableValue mappedValue = nullableValue.map(x -> x != null); > > > > It turns out that this doesn't work, since `map` doesn't pass `null` > > to the mapping function. Instead of calling the mapping function, it > > always returns `null`. This is not technically a bug, as `map` is > > specified to have this behavior. It is a bit unfortunate, though; > > `null` is a perfectly valid value in many cases and its special > > treatment comes off as a bit of a surprise. > > The alternative is worse I think, as JavaFX properties can easily be > `null`, you'd have to add null checks to your map/flatMaps. Especially a > construct like this: > > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false); > > ... would be really annoying to write if you had to deal with the > nulls. The functionality is closely related to what Optional offers, > and that one doesn't pass `null` to its map/flatMap methods either, nor > will it ever add a `mapNullable` :-) > > > I'm wondering whether we need a `mapNullable` operator that does what > > I intuitively expecting `map` to do, which is just unconditionally > > passing the value to the mapping function. > > Maybe, I think however that you'd only need this for the very special > case where you are intending to ignore the actual value being passed to > a map/flatMap, and only want to check it for null. `isPresent` / > `isEmpty` would be nicer for this. For all other cases, where you are > actually doing some kind of mapping, I think a map/orElse combo works great. > > --John > From angorya at openjdk.org Thu May 18 17:08:05 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 May 2023 17:08:05 GMT Subject: RFR: 8304831: TextFlow.hitTest.insertionIndex incorrect with surrogate pairs [v6] In-Reply-To: <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> References: <3SN8lehcrLh8DJJ_qumZ_eGYw8y5aglKYVY9PPNquk0=.166e3e46-58c3-4fcf-b032-39f9fb9dd59b@github.com> <7P5GSYbYsuFfpXt2U7EdEROb1xAhaYeY2_D39w9MHCM=.8fe88bdc-761c-4d89-9ffe-0e7e77d81ca8@github.com> Message-ID: On Thu, 18 May 2023 09:27:18 GMT, Karthik P K wrote: >> Since surrogate pairs are internally considered as 2 characters and text field is null in `HitInfo` when `getInsertionIndex` is invoked from `TextFlow`, wrong insertion index was returned. >> >> Updated code to calculate insertion index in `getHitInfo` method of `PrismTextLayout` class when `hitTest` of trailing side of surrogate pair is requested. Since text runs are processed in this method already, calculating the insertion index in this method looks better than calculating in `getInsertionIndex` of `HitInfo` method. >> The latter approach also requires the text to be sent to `HitInfo` as parameter from the `hitTest` method of `TextFlow`. If the number of `Text` nodes in `TextFlow` are very large, processing all the `Text` nodes on each `hitTest` method invocation might cause performance issue. Hence implemented first approach. >> >> Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add new test. Optimizations to make the tests robust please try adding firePulse(), and also please check on Windows and Linux. thanks! tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 153: > 151: textFlow.getChildren().clear(); > 152: textFlow.getChildren().setAll(text); > 153: let's add Toolkit.getToolkit().firePulse(); before textSetLatch.countDown(); tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 166: > 164: textFlow.getChildren().clear(); > 165: textFlow.getChildren().setAll(text); > 166: let's add Toolkit.getToolkit().firePulse(); before textSetLatch.countDown(); tests/system/src/test/java/test/robot/javafx/scene/TextFlowSurrogatePairInsertionIndexTest.java line 179: > 177: textFlow.getChildren().