From kcr at openjdk.org Fri Mar 1 00:02:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 00:02:52 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> Message-ID: On Thu, 29 Feb 2024 23:56:06 GMT, Andy Goryachev wrote: >> Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. > > 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/1386#pullrequestreview-1910074402 From kcr at openjdk.org Fri Mar 1 00:05:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 00:05:55 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Wed, 28 Feb 2024 21:48:38 GMT, Andy Goryachev wrote: > This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) > > - adds missing information in `@param` tags > - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) > - fixed an empty `

` in `Subscription` > - cleaned up unnecessary `@throws` in Filtered/SortedList > > Q: Does this PR need a CSR? I did a quick pass, and confirm that there is nothing here that needs a CSR. There are enough changes that a second pair of eyes might be helpful, but not required. I left a few inline comments. I might have more when I do a second pass. modules/javafx.base/src/main/java/javafx/beans/binding/When.java line 810: > 808: * An intermediate class needed while assembling the ternary expression. It > 809: * should not be used in another context. > 810: * @param the type of an object being built Suggestion: type of "the" object modules/javafx.base/src/main/java/javafx/collections/transformation/FilteredList.java line 164: > 162: * @param index index of the element to return > 163: * @return the element at the specified position in this list > 164: * @throws IndexOutOfBoundsException {@inheritDoc} Was this generating a warning? Does the superclass specify `@throws`? modules/javafx.base/src/main/java/javafx/collections/transformation/SortedList.java line 163: > 161: * @param index index of the element to return > 162: * @return the element at the specified position in this list > 163: * @throws IndexOutOfBoundsException {@inheritDoc} Same question as above about the removal of the `@throws` modules/javafx.base/src/main/java/javafx/util/Builder.java line 32: > 30: * construct other objects. > 31: * > 32: * @param the type of an object being built Suggestion: type of "the" object. modules/javafx.base/src/main/java/javafx/util/Pair.java line 32: > 30: > 31: /** > 32: *

A convenience class to represent name-value pairs.

Maybe also remove the redundant `

` and `

` tags? modules/javafx.base/src/main/java/javafx/util/StringConverter.java line 32: > 30: * The type of objects and formats of strings are defined by the subclasses > 31: * of Converter. > 32: * @param the type of an object being converted Suggestion: type of "the" object. modules/javafx.base/src/main/java/javafx/util/converter/FormatStringConverter.java line 36: > 34: * instance.

> 35: * > 36: * @param the type of an object being converted Suggestion: type of "the" object. modules/javafx.controls/src/main/java/javafx/scene/control/ScrollToEvent.java line 37: > 35: * {@link ListView}, {@link TableView}, {@link TreeView} and {@link TreeTableView}. > 36: * > 37: * @param the scroll to event type Minor: Maybe hyphenate "scroll-to"? ------------- PR Review: https://git.openjdk.org/jfx/pull/1384#pullrequestreview-1907683236 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506825695 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506822986 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506823180 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506826213 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506823672 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506825090 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506826533 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1506827331 From angorya at openjdk.org Fri Mar 1 00:14:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 00:14:51 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues In-Reply-To: References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Thu, 29 Feb 2024 00:07:37 GMT, Kevin Rushforth wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> Q: Does this PR need a CSR? > > modules/javafx.base/src/main/java/javafx/collections/transformation/FilteredList.java line 164: > >> 162: * @param index index of the element to return >> 163: * @return the element at the specified position in this list >> 164: * @throws IndexOutOfBoundsException {@inheritDoc} > > Was this generating a warning? Does the superclass specify `@throws`? yes, the superclass specified @throws. this line generated FilteredList.java:164: warning: overridden methods do not document exception type java.lang.IndexOutOfBoundsException (module java.base package java.lang class IndexOutOfBoundsException) * @throws IndexOutOfBoundsException {@inheritDoc} ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1508331500 From angorya at openjdk.org Fri Mar 1 00:22:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 00:22:05 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v2] In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: > This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) > > - adds missing information in `@param` tags > - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) > - fixed an empty `

` in `Subscription` > - cleaned up unnecessary `@throws` in Filtered/SortedList > > This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. 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/1384/files - new: https://git.openjdk.org/jfx/pull/1384/files/bdc3c5bd..7fb2715a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1384&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1384&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1384.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1384/head:pull/1384 PR: https://git.openjdk.org/jfx/pull/1384 From arapte at openjdk.org Fri Mar 1 03:43:52 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 1 Mar 2024 03:43:52 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v2] In-Reply-To: References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Fri, 1 Mar 2024 00:22:05 GMT, Andy Goryachev wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Looks good. Warnings reduced from 186 to 91. One minor comment that at several instances there is no empty line between the description and `@param`. Shall re-approve if changed. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1384#pullrequestreview-1910264103 From psadhukhan at openjdk.org Fri Mar 1 03:51:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 1 Mar 2024 03:51:50 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> Message-ID: <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> On Thu, 29 Feb 2024 23:56:06 GMT, Andy Goryachev wrote: >> Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 142: > 140: * future Swing or JavaFX releases. The current serialization support is > 141: * appropriate for short term storage or RMI between applications running > 142: * the same version of Swing and the same version of JavaFX. Shouldn;t we need to add @SuppressWarnings("serial") // Same-version serialization only which I see in almost all classes in Swing which has the above serialization warning... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1508447661 From jvos at openjdk.org Fri Mar 1 09:26:52 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Mar 2024 09:26:52 GMT Subject: [jfx17u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: <5V1EU6Z5EenPAMGemJUTVi82QO0ezfcrmf1L0dJRINo=.521d2331-4029-48f4-94c7-09bf74947f9a@github.com> References: <5V1EU6Z5EenPAMGemJUTVi82QO0ezfcrmf1L0dJRINo=.521d2331-4029-48f4-94c7-09bf74947f9a@github.com> Message-ID: <-1cC4Zmc0oDue8QvoxZy_4wDP7wbtTg_9SK0xGnjXTs=.488d558a-7d70-4723-8a86-359b66baa42b@github.com> On Thu, 29 Feb 2024 15:48:30 GMT, Jose Pereda wrote: > Almost clean backport of 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS > > Reviewed-by: jbhaskar, arapte > > Very minor conflicts after cherry picking the commit: > > // InputMethodRequests implementation > +<<<<<<< HEAD > +======= > ... > @Override > +>>>>>>> 40809a3f84 (8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS) > public Point2D getTextLocation(int offset) { > > > I fixed it manually, and pushed the change. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/179#pullrequestreview-1910678848 From dlemmermann at gmail.com Fri Mar 1 10:59:09 2024 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 1 Mar 2024 11:59:09 +0100 Subject: Validation Support Message-ID: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Hi everyone, I updated the validation framework ValidatorFX today in our project to the latest release and I really like it a lot. It is a small compact API and works with any observable as opposed to the validation support provided by ControlsFX. Using it made me wonder whether it would make sense to bundle it or something like it directly with JavaFX. Developers often mention missing validation support as a drawback of using JavaFX. Adding this would take one item off from the list of arguments against using JavaFX. Many UI frameworks do have built-in validation support, e.g. Vaadin [0], Angular, [1], or QT [2] What do you think? ?Dirk [0] https://vaadin.com/docs/latest/binding-data/components-binder-validation [1] https://angular.io/guide/form-validation [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Fri Mar 1 12:50:51 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 1 Mar 2024 12:50:51 GMT Subject: [jfx17u] Integrated: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS In-Reply-To: <5V1EU6Z5EenPAMGemJUTVi82QO0ezfcrmf1L0dJRINo=.521d2331-4029-48f4-94c7-09bf74947f9a@github.com> References: <5V1EU6Z5EenPAMGemJUTVi82QO0ezfcrmf1L0dJRINo=.521d2331-4029-48f4-94c7-09bf74947f9a@github.com> Message-ID: On Thu, 29 Feb 2024 15:48:30 GMT, Jose Pereda wrote: > Almost clean backport of 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS > > Reviewed-by: jbhaskar, arapte > > Very minor conflicts after cherry picking the commit: > > // InputMethodRequests implementation > +<<<<<<< HEAD > +======= > ... > @Override > +>>>>>>> 40809a3f84 (8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS) > public Point2D getTextLocation(int offset) { > > > I fixed it manually, and pushed the change. This pull request has now been integrated. Changeset: c54a9ed3 Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/c54a9ed3e91dad2d0b06302d75387882310b3fe6 Stats: 63 lines in 1 file changed: 34 ins; 18 del; 11 mod 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS Reviewed-by: jvos Backport-of: 40809a3f84d5f9f91b265f455a95d045e5b4f692 ------------- PR: https://git.openjdk.org/jfx17u/pull/179 From kcr at openjdk.org Fri Mar 1 13:07:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 13:07:57 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> Message-ID: On Fri, 1 Mar 2024 03:49:20 GMT, Prasanta Sadhukhan wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 142: > >> 140: * future Swing or JavaFX releases. The current serialization support is >> 141: * appropriate for short term storage or RMI between applications running >> 142: * the same version of Swing and the same version of JavaFX. > > Shouldn;t we need to add > @SuppressWarnings("serial") // Same-version serialization only > > which I see in almost all classes in Swing which has the above serialization warning... This PR is addressing doclint warnings, not javac lint warnings. javac warnings can be addressed in a follow-up bug. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1508960125 From johan.vos at gluonhq.com Fri Mar 1 14:18:22 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 1 Mar 2024 15:18:22 +0100 Subject: running systemtests in isolated java processes Message-ID: Hi, We currently run systemtests using a gradle command, but that doesn't start a clean Java process for the individual tests (which would be very convenient as that allows us to inspect the process with VisualVM). We know the behavior of a JavaFX application can be different depending if 1. the mainClass is the class extending from Application 2. the mainClass is a wrapper class from e.g. Gradle or Maven. For system tests, I think it would be real handy to run them using the first option, but I am not aware of an easy solution to make that work with the current gradle setup. Or am I missing something obvious? Thanks, - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Fri Mar 1 14:59:02 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 1 Mar 2024 14:59:02 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 09:30:14 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into 8319779-systemmenu > - Add additional test for IOOBE detection. > This test comes from JDK-8323787 > - Revert some of the conditional bindings. > Clear menu construction when an menuitem that is a menu needs to be removed > Add a test for the latter > - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu > - Cleanup test > - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. > Add a test to make sure those references are gone. > - Revert WeakInvalidationListeners and use new listener resource management approach. > - Fix more memoryleaks due to listeners never being unregistered. > - These changes are related to JBS-8318841 so we want to have that code in > as well. > > Merge branch 'master' into 8319779-systemmenu > - process reviewers comments > - ... and 1 more: https://git.openjdk.org/jfx/compare/831d6526...ec7308df The failure on Linux has an interesting cause. The GlassSystemMenu (in com.sun.javafx.tk.quantum) has this code: /* * Leave the Apple menu in place */ for (int index = existingSize - 1; index >= 0; index--) { Menu menu = existingMenus.get(index); clearMenu(menu); glassSystemMenuBar.remove(index); } As a consequence, the first menu is not cleared -- regardless of the presence of an apple or not. There are plenty quick and dirty ways to fix this, but this platform-specific check probably does not belong in this package. @kevinrushforth what do you prefer to do in cases like these? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1973342702 From kevin.rushforth at oracle.com Fri Mar 1 15:02:17 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 1 Mar 2024 07:02:17 -0800 Subject: running systemtests in isolated java processes In-Reply-To: References: Message-ID: <14a8ab1f-cf27-4dc1-bc92-843decac2c04@oracle.com> Hi Johan, FOr the systemTests project, the gradle test runner does run each test class in its own VM, as a result of the "forkEvery = 1" setting. As noted, gradle launches tests using a gradle test runner class as the main method, but there is still a 1 VM to 1 test class relationship. We have a few tests that specifically test launching JavaFX applications, including testing classes that extend Application (with and without a main method), such as the ones in test.launchertest, but they do it by exec-ing a new Java process. Would that work for what you want to do? Perhaps tangentially related to this, I spent some time a while ago looking at what it would take to use jtreg to run our tests. I was looking at jtreg's ability to run JUnit tests, but there is also a mode of jtreg to run standalone main program tests. That could provide a way to run test applications directly, although likely only for tests written with that in mind. -- Kevin On 3/1/2024 6:18 AM, Johan Vos wrote: > Hi, > > We currently run?systemtests?using a gradle command, but that doesn't > start a clean Java process for the individual?tests (which would be > very convenient as that allows us to inspect the process with VisualVM). > We know the behavior of a JavaFX application can be different depending if > 1. the mainClass is the class extending from Application > 2. the mainClass is a wrapper class from e.g. Gradle or Maven. > > For system tests, I think it would be real handy to run them using the > first option, but I am not aware of an easy solution to make that work > with the current gradle setup. Or am I missing something obvious? > > Thanks, > > - Johan From kcr at openjdk.org Fri Mar 1 15:38:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 15:38:54 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v2] In-Reply-To: References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Fri, 1 Mar 2024 00:22:05 GMT, Andy Goryachev wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Looks good with two minor comments. I'll reapprove if you make the changes. modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 34: > 32: * A wrapper class for use by the column resize policies offered by > 33: * controls such as {@link TableView} and {@link TreeTableView}. > 34: * @param the type of the objects contained within the TableView items list Minor: This class isn't limited to TableView, so I recommend changing it to something like "the control's items list" modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java line 66: > 64: * Default skin implementation for the {@link ComboBox} control. > 65: * > 66: * @param the type of the ComboBox-like control Minor: should this be just "ComboBox" rather than "ComboBox-like"? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1384#pullrequestreview-1911409755 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1509151841 PR Review Comment: https://git.openjdk.org/jfx/pull/1384#discussion_r1509163073 From angorya at openjdk.org Fri Mar 1 15:53:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 15:53:21 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v3] In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> > This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) > > - adds missing information in `@param` tags > - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) > - fixed an empty `

` in `Subscription` > - cleaned up unnecessary `@throws` in Filtered/SortedList > > This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. 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/1384/files - new: https://git.openjdk.org/jfx/pull/1384/files/7fb2715a..61cc3e9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1384&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1384&range=01-02 Stats: 14 lines in 11 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1384.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1384/head:pull/1384 PR: https://git.openjdk.org/jfx/pull/1384 From angorya at openjdk.org Fri Mar 1 15:53:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 15:53:21 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v2] In-Reply-To: References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Fri, 1 Mar 2024 03:40:57 GMT, Ambarish Rapte wrote: > there is no empty line between the description and `@param` it makes no difference in the generated javadoc output. I've made the changes anyway, for the developers' sake. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1384#issuecomment-1973419301 From kcr at openjdk.org Fri Mar 1 15:56:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 15:56:53 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v3] In-Reply-To: <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> Message-ID: On Fri, 1 Mar 2024 15:53:21 GMT, Andy Goryachev wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1384#pullrequestreview-1911471727 From angorya at openjdk.org Fri Mar 1 16:21:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 16:21:53 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> Message-ID: On Fri, 1 Mar 2024 13:05:23 GMT, Kevin Rushforth wrote: >> modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 142: >> >>> 140: * future Swing or JavaFX releases. The current serialization support is >>> 141: * appropriate for short term storage or RMI between applications running >>> 142: * the same version of Swing and the same version of JavaFX. >> >> Shouldn;t we need to add >> @SuppressWarnings("serial") // Same-version serialization only >> >> which I see in almost all classes in Swing which has the above serialization warning... > > This PR is addressing doclint warnings, not javac lint warnings. javac warnings can be addressed in a follow-up bug. FYI: after merging this and #1384 together all I see in the build log are 4 native warnings (on macOS): /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:93:21: warning: 'lockFocusIfCanDraw' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] if ([nsView lockFocusIfCanDraw] == NO) { ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:190:1: note: 'lockFocusIfCanDraw' has been explicitly marked deprecated here - (BOOL)lockFocusIfCanDraw API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); ^ /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:98:25: warning: 'unlockFocus' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] [nsView unlockFocus]; ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:189:1: note: 'unlockFocus' has been explicitly marked deprecated here - (void)unlockFocus API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); ^ /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:120:24: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations] [nsContext setView : nsView]; ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here @property (nullable, weak) NSView *view NS_SWIFT_UI_ACTOR API_DEPRECATED("", macos(10.0,10.14)); ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:194:1: note: 'setView:' has been explicitly marked deprecated here - (void)setView:(nullable NSView *)view NS_SWIFT_UI_ACTOR API_DEPRECATED("Use NSOpenGLView to provide OpenGL content in a Cocoa app.", macos(10.0,10.14)); ^ /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:121:21: warning: 'unlockFocus' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] [nsView unlockFocus]; ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:189:1: note: 'unlockFocus' has been explicitly marked deprecated here - (void)unlockFocus API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); ^ 4 warnings generated. as well as a number of these messages: -do-compile: [mkdir] Created dir: /Users/angorya/Projects/jfx-1/jfx/rt/apps/toys/PickTest3D/build/empty [mkdir] Created dir: /Users/angorya/Projects/jfx-1/jfx/rt/apps/toys/PickTest3D/build/generated-sources/ap-source-output [javac] Compiling 6 source files to /Users/angorya/Projects/jfx-1/jfx/rt/apps/toys/PickTest3D/build/classes [javac] warning: [options] system modules path not set in conjunction with -source 9 [javac] Note: /Users/angorya/Projects/jfx-1/jfx/rt/apps/toys/PickTest3D/src/picktest/PickTest3D.java uses unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 warning ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1509220929 From arapte at openjdk.org Fri Mar 1 16:35:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 1 Mar 2024 16:35:53 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v3] In-Reply-To: <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> Message-ID: On Fri, 1 Mar 2024 15:53:21 GMT, Andy Goryachev wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1384#pullrequestreview-1911546391 From johan.vos at gluonhq.com Fri Mar 1 16:43:11 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 1 Mar 2024 17:43:11 +0100 Subject: running systemtests in isolated java processes In-Reply-To: <14a8ab1f-cf27-4dc1-bc92-843decac2c04@oracle.com> References: <14a8ab1f-cf27-4dc1-bc92-843decac2c04@oracle.com> Message-ID: On Fri, Mar 1, 2024 at 4:04?PM Kevin Rushforth wrote: > Hi Johan, > > FOr the systemTests project, the gradle test runner does run each test > class in its own VM, as a result of the "forkEvery = 1" setting. As > noted, gradle launches tests using a gradle test runner class as the > main method, but there is still a 1 VM to 1 test class relationship. > Yes, but the main class is not the class extending from Application, which makes a difference for sun.launcher.LauncherHelper > We have a few tests that specifically test launching JavaFX > applications, including testing classes that extend Application (with > and without a main method), such as the ones in test.launchertest, but > they do it by exec-ing a new Java process. Would that work for what you > want to do? > That looks indeed exactly what I want. Thanks for the pointer, I'll have a look! Perhaps tangentially related to this, I spent some time a while ago > looking at what it would take to use jtreg to run our tests. I was > looking at jtreg's ability to run JUnit tests, but there is also a mode > of jtreg to run standalone main program tests. That could provide a way > to run test applications directly, although likely only for tests > written with that in mind. > Sounds interesting. > -- Kevin > > > On 3/1/2024 6:18 AM, Johan Vos wrote: > > Hi, > > > > We currently run systemtests using a gradle command, but that doesn't > > start a clean Java process for the individual tests (which would be > > very convenient as that allows us to inspect the process with VisualVM). > > We know the behavior of a JavaFX application can be different depending > if > > 1. the mainClass is the class extending from Application > > 2. the mainClass is a wrapper class from e.g. Gradle or Maven. > > > > For system tests, I think it would be real handy to run them using the > > first option, but I am not aware of an easy solution to make that work > > with the current gradle setup. Or am I missing something obvious? > > > > Thanks, > > > > - Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Mar 1 17:13:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 1 Mar 2024 17:13:52 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> Message-ID: On Fri, 1 Mar 2024 16:19:14 GMT, Andy Goryachev wrote: >> This PR is addressing doclint warnings, not javac lint warnings. javac warnings can be addressed in a follow-up bug. > > FYI: after merging this and #1384 together all I see in the build log are 4 native warnings (on macOS): > > > /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:93:21: warning: 'lockFocusIfCanDraw' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] > if ([nsView lockFocusIfCanDraw] == NO) { > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:190:1: note: 'lockFocusIfCanDraw' has been explicitly marked deprecated here > - (BOOL)lockFocusIfCanDraw API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); > ^ > /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:98:25: warning: 'unlockFocus' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] > [nsView unlockFocus]; > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:189:1: note: 'unlockFocus' has been explicitly marked deprecated here > - (void)unlockFocus API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); > ^ > /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:120:24: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations] > [nsContext setView : nsView]; > ^ > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here > @property (nulla... That's because we don't enable javac lint warnings by default. I am getting ready to file a few JBS issues related to this. Stay tuned. In the mean time, if you want to see how many warnings we do have, try running with `gradle -PLINT=all`. Or rather, you'll see how many modules hit the 100 warnings limit. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1509281214 From angorya at openjdk.org Fri Mar 1 17:34:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 17:34:00 GMT Subject: RFR: 8325073: javadoc warnings: missing @param tags and other issues [v3] In-Reply-To: <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> <9IFJhHqjwFGff8BNgGZF1KCSdonbhwBVX4J0E5VgRGA=.1c42ed61-f6a6-461d-8852-d212915d78aa@github.com> Message-ID: <8Jso4G5RCagXJXmEABjUKgpwLhKrftxm9jDJHmbhmVA=.fd849fb3-2a82-4920-b311-50a3fa9c64ac@github.com> On Fri, 1 Mar 2024 15:53:21 GMT, Andy Goryachev wrote: >> This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) >> >> - adds missing information in `@param` tags >> - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) >> - fixed an empty `

` in `Subscription` >> - cleaned up unnecessary `@throws` in Filtered/SortedList >> >> This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments This PR is labeled READY but no integration email. Is Scara down? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1384#issuecomment-1973599060 From angorya at openjdk.org Fri Mar 1 17:50:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 1 Mar 2024 17:50:53 GMT Subject: Integrated: 8325073: javadoc warnings: missing @param tags and other issues In-Reply-To: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> References: <4DE0zYpDrbwema3mjQwbBKJ65lcc56mluCb-yvBL90Q=.ced6a7ff-dca9-4e05-9836-5bb8ba02c010@github.com> Message-ID: On Wed, 28 Feb 2024 21:48:38 GMT, Andy Goryachev wrote: > This change brings the number of javadoc warnings back to 91 (to be fixed in [JDK-8270996](https://bugs.openjdk.org/browse/JDK-8270996)) > > - adds missing information in `@param` tags > - adds `@SuppressWarnings("doclint:missing")` to `Skinnable` to silence the warning due to [JDK-8325071](https://bugs.openjdk.org/browse/JDK-8325071) > - fixed an empty `

` in `Subscription` > - cleaned up unnecessary `@throws` in Filtered/SortedList > > This PR does not need a CSR: most of the changes are clarifications or documenting of missing parameters. This pull request has now been integrated. Changeset: 56b20dee Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/56b20dee26a01a770f50e2ef9718891ee528f703 Stats: 215 lines in 68 files changed: 120 ins; 9 del; 86 mod 8325073: javadoc warnings: missing @param tags and other issues Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1384 From mhanl at openjdk.org Fri Mar 1 18:44:17 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Mar 2024 18:44:17 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/cb8865e8..a4cce087 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=01-02 Stats: 1338 lines in 147 files changed: 810 ins; 156 del; 372 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From mhanl at openjdk.org Fri Mar 1 19:28:53 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Mar 2024 19:28:53 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: <4U7adOG2Tc4CmJT-nmuuzqv__ELl0uppsC_YEUIrt7g=.b218444d-15e7-434f-a595-bb4a48cfb9cb@github.com> On Fri, 1 Mar 2024 18:44:17 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen So I could finally look into the issue. Unfortunately, the problem is much deeper than I thought. Consider the following testcase: Platform.runLater(() -> { System.out.println("exit1"); Platform.exitNestedEventLoop(this, "123"); Platform.runLater(() -> { System.out.println("exit2"); Platform.exitNestedEventLoop("this", "456"); }); System.out.println("enter2"); Object o = Platform.enterNestedEventLoop("this"); System.out.println(o); }); System.out.println("enter1"); Object o = Platform.enterNestedEventLoop(this); System.out.println(o); What I would expect: enter1 exit1 123 enter2 exit2 456 New behaviour: enter1 exit1 enter2 exit2 456 Old behaviour: enter1 exit1 enter2 Application hangs (Makes sense, as it is the same logic as if we hide a dialog and show a new one) So it is better now, since we do not stall the application anymore, but we never return back from the first event loop, since the native code did not return. And I would like to fix this completely. Maybe, the approach needs to be a little bit different. Something like: If we enter a nested event loop WHILE we are exiting one, we should somewhat wait for it to finish. That is a pretty though one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1973787728 From mfox at openjdk.org Fri Mar 1 21:36:00 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 1 Mar 2024 21:36:00 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 18:44:17 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen The first `runLater` block is being invoked by the first nested event loop; that loop is on the call stack. In that block you call `exitNestedEventLoop` but don't allow the stack to unwind before calling `enterNestedEventLoop`. So on the stack the new event loop is indeed nested inside the previous one (the previous one is marked as LEAVING but it's still doing something). Since this is a stack there's only one way to unwind it which is in reverse order. The output I would expect would be: enter1 exit1 enter2 exit2 456 123 There is that bug in the invokeLaterDispatcher which will prevent the second `runLater` block from executing. And the documentation doesn't really address this case but it should. By the way, when I grab the code in the original bug report and run it agains this PR the innermost modal is not blocked and everything seems fine. But if I press the Close button exceptions start getting thrown. This is happening on both Mac and Windows. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1973953042 From mhanl at openjdk.org Fri Mar 1 22:17:10 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 1 Mar 2024 22:17:10 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 21:33:16 GMT, Martin Fox wrote: > The output I would expect would be: > > ``` > enter1 > exit1 > enter2 > exit2 > 456 > 123 > ``` You are right, this sounds correct. > By the way, when I grab the code in the original bug report and run it agains this PR the innermost modal is not blocked and everything seems fine. But if I press the Close button exceptions start getting thrown. This is happening on both Mac and Windows. Can you post the exception? I may know which one and I already fixed one locally, testing it currently. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1974005439 From kevin.rushforth at oracle.com Fri Mar 1 22:36:23 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 1 Mar 2024 14:36:23 -0800 Subject: Proposal: JavaFX Incubator Modules In-Reply-To: <2628f36b-abec-4114-85e5-12c9a0fec7b3@oracle.com> References: <4a9ad4ad-e665-4ec8-a8cc-eaf91cbb0209@oracle.com> <895bddbc-a33d-4bfe-9a9f-2f3144cdb8c8@oracle.com> <9607cefb-9d61-401e-983a-33a4ab00f729@oracle.com> <6118f676-c3d4-47f3-969a-d0516c36b126@oracle.com> <2628f36b-abec-4114-85e5-12c9a0fec7b3@oracle.com> Message-ID: <5156aee1-097d-4f9d-9070-679285eb265d@oracle.com> I updated the Incubator Modules proposal to address Phil's feedback, along with updating the example incubator module: https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md https://github.com/openjdk/jfx/pull/1375 -- Kevin On 2/22/2024 2:32 PM, Kevin Rushforth wrote: > Something like this might be reasonable as long as we also add "and > hasn't been modified in the current release". I could easily image the > case where an incubating feature goes into, say JavaFX 26 in March, > and by the time feedback comes in that prompts a change in the API, > it's July or August already, meaning that any changes will go into > JavaFX 28. > > The time between when a feature first released (in a GA release) and > the feature freeze for the next release is only a little over 3 months > (which is why most features will incubate for at least two releases). > > -- Kevin > > > On 2/22/2024 1:08 PM, Philip Race wrote: >> W.r.t to (3) perhaps we could include in the write up an expectation >> that continued incubation implies continued updates. >> Meaning if there are no updates in a release then that either means >> it is ready to be final next time round, or that the >> author is no longer actively pursuing it and this should inform the >> Project Lead as to what action should be taken next. >> >> -phil. >> >> On 2/21/24 1:55 PM, Kevin Rushforth wrote: >>> These are all good points. >>> >>> 1. I agree. This seems like a good idea for all the reasons you mention. >>> >>> 2. I'll add the additional information. And I like your suggestion >>> to require a JEP (*) to either drop or finalize an incubating feature. >>> >>> 3. Yes, I was deliberately vague on what constitutes a reasonable >>> amount of time. Given that we are changing the default to >>> "re-incubate" it does make sense to have a "soft timeout" so >>> incubating features don't incubate forever without an intentional >>> action to keep them alive. >>> >>> I'll update the proposal accordingly. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> (*) We don't exactly follow the JEP process as described in JEP 2, >>> but for larger features we expect a proposal that touches on the >>> important points in a JEP-like document and is discussed on the >>> mailing list. That's what we mean when we say "needs a JEP". >>> >>> >>> On 2/21/2024 9:47 AM, Philip Race wrote: >>>> 1) The first thing that jumps out at me is the namespace : >>>> javafx.incubator >>>> >>>> The JDK's JEP 11 says "An incubator module is identified by >>>> the|jdk.incubator.|prefix in its module name" >>>> It says the same about the packages inside the module. >>>> "An incubating API is identified by the|jdk.incubator.|prefix in >>>> its exported package names". >>>> >>>> This is to avoid using the standard namespace prefixes for JDK of >>>> java. and javax. used for final APIs/modules. >>>> >>>> So similarly I think JavaFX incubators should avoid the javafx. >>>> prefix and I suggest "jfx." be used instead. >>>> This closely mirrors the "jdk." used in JEP 11, taking "java" out >>>> of the prefix and making it entirely an acronym, >>>> for both module and package names. >>>> The pain of updating your code when the API goes final can be eased >>>> by IDEs and is something you would >>>> need to do anyway because "incubator" is in all the names in either >>>> case. >>>> >>>> 2) The second thing is you don't say what the steps are to promote >>>> the incubating module to final. >>>> JEP 11 says a new JEP is needed for that, but it also says a new >>>> JEP is needed to re-incubate >>>> which is something JavaFX will not require. >>>> So do you expect it will be a new JEP for that ? >>>> I think that would be best to do that as the JEP to propose the >>>> incubator could be several years old and stale by then. >>>> You also don't say what it takes to drop it. >>>> >>>> So how about the basic process is that the first JEP simply >>>> proposes the incubating module, once >>>> it is in as you say it evolves by normal RFEs across releases ? >>>> Then when it is EITHER ready to go final OR be removed, a new JEP >>>> must be proposed for that. >>>> A removal JEP should generally be quite short :-) >>>> >>>> So I suggest to add a sentence along those lines to the proposal. >>>> "To either make the API of an incubating module final, or to remove >>>> it, then a new JEP should be submitted, >>>> referencing the incubator JEP". >>>> >>>> 3) The "reasonably small number of JavaFX releases" is I am sure >>>> intentionally vague, but perhaps >>>> we could say >>>> (1) Incubators which span beyond a 24 month period and are not yet >>>> ready will need >>>> a simple public approval from the project lead to remain for some >>>> additiional period at the discretion >>>> of the Project Lead by adding a simple comment in the JEP, >>>> otherwise the Project Lead will submit a removal JEP and >>>> (2) the submitter of the JEP can propose to remove it at any time. >>>> >>>> -phil. >>>> >>>> On 2/21/24 9:37 AM, Kevin Rushforth wrote: >>>>> JEP 11 [1] defines a process for delivering non-final JDK APIs in >>>>> incubator modules. >>>>> >>>>> Similarly, some JavaFX APIs would benefit from spending a period >>>>> of time in a JavaFX release prior to being deemed stable. I >>>>> propose JavaFX incubator modules as a means of putting non-final >>>>> API in the hands of developers, while the API progresses towards >>>>> either finalization or removal in a future release. This is >>>>> especially useful for complex features with a large API surface. >>>>> >>>>> The JavaFX proposal is largely the same as the JDK one, but has >>>>> some important differences. >>>>> >>>>> Please take a look at the preliminary proposal [2]. I have also >>>>> created a Draft PR [3], for illustrative purposes only, to show >>>>> how this might work. >>>>> >>>>> Please reply to this message with any feedback. >>>>> >>>>> Thanks. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://openjdk.org/jeps/11 >>>>> [2] >>>>> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md >>>>> [3] https://github.com/openjdk/jfx/pull/1375 >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Mar 1 22:39:49 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 1 Mar 2024 14:39:49 -0800 Subject: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: All, Thank you to everyone who has provided feedback on the RichText proposal so far. If I could characterize the response, there are some developers who want at least a basic rich text control available as part of the JavaFX core and other developers who don't think that such a control should be in the JavaFX core at all. This doesn't really come as a surprise to me, since rich text is a complex feature, and we really don't have enough feedback to know how much of it -- if any -- belongs in the core of JavaFX, and if it does, what form the eventual API should take. I happen to think there is value in providing at least a basic rich text control. One of the main reasons for proposing this as an incubating feature in a separate, incubator module, is that we don't know whether and how application developers will want to use this, and whether this proposal hits the sweet spot of a sufficiently full-featured control without being too complex, especially in terms of API surface which is something I am concerned about. As an incubating feature, we have the ability to modify the API and implementation in incompatible ways in response to feedback, or to drop it from the core entirely, perhaps making it available some other way. Shipping this in an incubator module is a good way to get that feedback. That doesn't mean that it can go in before it is ready. Even as an incubator, this will require a fairly long review process; incubator modules are not a way to deliver features in early stages of development nor "experimental" features. If this goes in as an incubating feature in some future release of JavaFX, subsequent releases will do one of three things: 1) evolve the API in response to feedback; 2) finalize the API; 3) drop the API. As an aside, I hope that the updated incubator JEP makes this a little more clear. I'm sure Andy will welcome additional feedback, especially on the concepts and on the API. I haven't done a complete review of the API myself, and there are areas I am concerned about, but that's what the review process will discuss. -- Kevin On 2/21/2024 10:07 AM, Andy Goryachev wrote: > > Dear JavaFX developers: > > We would like to propose a new feature - rich text control, > RichTextArea, intended to bridge the functional gap with Swing and its > StyledEditorKit/JEditorPane.? The main design goal is to provide a > control that is complete enough to be useful out-of-the box, as well > as open to extension by the application developers. > > This is a complex feature with a large API surface that would be > nearly impossible to get right the first time, even after an extensive > review.? We are, therefore, introducing this in an incubating module, > *javafx.incubator.richtext*.?? This will allow us to evolve the API in > future releases without the strict compatibility constraints that > other JavaFX modules have. > > Please take a look at the proposal [0], a list of discussion points > [1], and the API Specification (javadoc) [2]. While the proposed API > is ready for review, it isn't complete nor set in stone. We are > looking for feedback, and will update the proposal based on the > suggestions we receive from the community.? We encourage you to > comment either in the mailing list, or by leaving comments inline in a > draft pull request [3].? For context, the links to the original RFE > [4] and a list of missing APIs related to rich text [5] are provided > below. > > Sincerely, > > Your friendly JavaFX development team. > > References > > [0] Proposal: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > [1] Discussion points: > https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md > > [2] API specification (javadoc): > https://cr.openjdk.org/~angorya/RichTextArea/javadoc > > [3] Draft Pull Request for API comments and feedback: > https://github.com/openjdk/jfx/pull/1374 > > [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > > [5] Missing APIs related to rich text control: > https://bugs.openjdk.org/browse/JDK-8300569 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Fri Mar 1 23:58:52 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 1 Mar 2024 23:58:52 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 18:44:17 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8285893-dialog-freezing-? > - Merge remote-tracking branch 'openjfx/master' into JDK-8285893-dialog-freezing-? > - JDK-8285893: Decrement nestedEventLoopCounter in leaveNestedEventLoop > - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen The top of the call stack when the exception is thrown: Exception in thread "JavaFX Application Thread" java.lang.IllegalStateException: Not in a nested event loop at javafx.graphics at 23-internal/com.sun.glass.ui.Application.leaveNestedEventLoop(Application.java:534) at javafx.graphics at 23-internal/com.sun.glass.ui.EventLoop.lambda$enter$0(EventLoop.java:122) at javafx.graphics at 23-internal/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at javafx.graphics at 23-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method) at javafx.graphics at 23-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(MacApplication.java:169) at javafx.graphics at 23-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:511) at javafx.graphics at 23-internal/com.sun.glass.ui.EventLoop.enter(EventLoop.java:107) at javafx.graphics at 23-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:656) at javafx.graphics at 23-internal/javafx.stage.Stage.showAndWait(Stage.java:469) at ApplicationModalSampleApp2$MainFx.showModal(ApplicationModalSampleApp2.java:42) at ApplicationModalSampleApp2$MainFx.lambda$start$0(ApplicationModalSampleApp2.java:25) at javafx.base at 23-internal/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base at 23-internal/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base at 23-internal/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base at 23-internal/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base at 23-internal/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base at 23-internal/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base at 23-internal/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base at 23-internal/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base at 23-internal/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base at 23-internal/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base at 23-internal/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base at 23-internal/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1974097962 From nlisker at gmail.com Sat Mar 2 15:28:17 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 2 Mar 2024 17:28:17 +0200 Subject: Validation Support In-Reply-To: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: Hi Dirk, JavaFX has some input validation support in terms of focus control and rejecting invalid characters. Can you explain what your proposal adds? Are there JBS issues asking for this? Thanks, Nir On Fri, Mar 1, 2024, 13:50 Dirk Lemmermann wrote: > Hi everyone, > > I updated the validation framework ValidatorFX today in our project to the > latest release and I really like it a lot. It is a small compact API and > works with any observable as opposed to the validation support provided by > ControlsFX. > > Using it made me wonder whether it would make sense to bundle it or > something like it directly with JavaFX. Developers often mention missing > validation support as a drawback of using JavaFX. Adding this would take > one item off from the list of arguments against using JavaFX. > > Many UI frameworks do have built-in validation support, e.g. Vaadin [0], > Angular, [1], or QT [2] > > What do you think? > > ?Dirk > > [0] > https://vaadin.com/docs/latest/binding-data/components-binder-validation > [1] https://angular.io/guide/form-validation > [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlemmermann at gmail.com Sat Mar 2 18:59:28 2024 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Sat, 2 Mar 2024 19:59:28 +0100 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: Ensuring that only valid characters are entered does not ensure that the entered value is correct. What developers require is data validation / form validation. Dirk > Am 02.03.2024 um 16:28 schrieb Nir Lisker : > > Hi Dirk, > > JavaFX has some input validation support in terms of focus control and rejecting invalid characters. Can you explain what your proposal adds? Are there JBS issues asking for this? > > Thanks, > Nir > > On Fri, Mar 1, 2024, 13:50 Dirk Lemmermann > wrote: >> Hi everyone, >> >> I updated the validation framework ValidatorFX today in our project to the latest release and I really like it a lot. It is a small compact API and works with any observable as opposed to the validation support provided by ControlsFX. >> >> Using it made me wonder whether it would make sense to bundle it or something like it directly with JavaFX. Developers often mention missing validation support as a drawback of using JavaFX. Adding this would take one item off from the list of arguments against using JavaFX. >> >> Many UI frameworks do have built-in validation support, e.g. Vaadin [0], Angular, [1], or QT [2] >> >> What do you think? >> >> ?Dirk >> >> [0] https://vaadin.com/docs/latest/binding-data/components-binder-validation >> [1] https://angular.io/guide/form-validation >> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlemmermann at gmail.com Sat Mar 2 19:00:53 2024 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Sat, 2 Mar 2024 20:00:53 +0100 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: <3D6F042F-5B77-4944-A88E-F06FD2D9B2E9@gmail.com> A quick look at the validator project readme should clarify things: https://github.com/effad/ValidatorFX Dirk > Am 02.03.2024 um 19:59 schrieb Dirk Lemmermann : > > Ensuring that only valid characters are entered does not ensure that the entered value is correct. What developers require is data validation / form validation. > > Dirk > > > >> Am 02.03.2024 um 16:28 schrieb Nir Lisker : >> >> Hi Dirk, >> >> JavaFX has some input validation support in terms of focus control and rejecting invalid characters. Can you explain what your proposal adds? Are there JBS issues asking for this? >> >> Thanks, >> Nir >> >> On Fri, Mar 1, 2024, 13:50 Dirk Lemmermann > wrote: >>> Hi everyone, >>> >>> I updated the validation framework ValidatorFX today in our project to the latest release and I really like it a lot. It is a small compact API and works with any observable as opposed to the validation support provided by ControlsFX. >>> >>> Using it made me wonder whether it would make sense to bundle it or something like it directly with JavaFX. Developers often mention missing validation support as a drawback of using JavaFX. Adding this would take one item off from the list of arguments against using JavaFX. >>> >>> Many UI frameworks do have built-in validation support, e.g. Vaadin [0], Angular, [1], or QT [2] >>> >>> What do you think? >>> >>> ?Dirk >>> >>> [0] https://vaadin.com/docs/latest/binding-data/components-binder-validation >>> [1] https://angular.io/guide/form-validation >>> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Sun Mar 3 01:10:10 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 3 Mar 2024 02:10:10 +0100 Subject: Validation Support In-Reply-To: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> Hi Dirk, That is a very nice framework, and although I wouldn't be against its inclusion in FX, I'm more wondering if JavaFX could do more to help make tools like ValidatorFX easy to build. I'm not quite sure how one can use not having validation as an argument against using FX, when there clearly are free alternatives available.? Surely not everything can or should be part of the base framework?? A line must be drawn somewhere, especially when there are very few core FX developers. I'd much rather see work being done on things that can't be provided by 3rd parties, preferably by opening up more parts of FX with well specified API's. --John On 01/03/2024 11:59, Dirk Lemmermann wrote: > Hi everyone, > > I updated the validation framework ValidatorFX today in our project to > the latest release and I really like it a lot. It is a small compact > API and works with any observable as opposed to the validation support > provided by ControlsFX. > > Using it made me wonder whether it would make sense to bundle it or > something like it directly with JavaFX. Developers often mention > missing validation support as a drawback of using JavaFX. Adding this > would take one item off from the list of arguments against using JavaFX. > > Many UI frameworks do have built-in validation support, e.g. Vaadin > [0], Angular, [1], or QT [2] > > What do you think? > > ?Dirk > > [0] > https://vaadin.com/docs/latest/binding-data/components-binder-validation > [1] https://angular.io/guide/form-validation > [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html > From nlisker at openjdk.org Sun Mar 3 22:52:18 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 3 Mar 2024 22:52:18 GMT Subject: RFR: 8327179: Update the 3D lighting application Message-ID: Update for the 3D lighting test tool as described in the JBS issue. ------------- Commit messages: - Whitespaces - Initial commit Changes: https://git.openjdk.org/jfx/pull/1387/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327179 Stats: 1733 lines in 15 files changed: 1021 ins; 708 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From r.lichtenberger at gmail.com Mon Mar 4 07:13:04 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 4 Mar 2024 08:13:04 +0100 Subject: Validation Support In-Reply-To: <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> Message-ID: <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> First off, as the original author of ValidatorFX I feel flattered by the suggestion of including it into the JavaFX core :-). Some thoughts / insights I gained from developing ValidatorFX: * ValidatorFX is (with the possible exception of GraphicDecoration.java) rather trivial code and also very small (< 1k lines of library code). But it seems to have filled a market gap according (a few thousand unique ip downloads every month, issues from ca. a dozen people so far, even a few PRs). These "market gaps" get filled rarely because they are not a commercially attractive opportunity. On the other hand if you decide (like I did with ValidatorFX) to take your closed source solution and make it open source, you are "rewarded" by increased overhead at first. But the market gaps exist and hinder broader JavaFX adoption. * ValidatorFX is probably only one part needed for application developers. The other part is a form library that allows to layout fields, have buttons (that are connected to field validation, etc.). It looks like this is written again and again by every application developer. * To answer John's question if JavaFX could do more to help make tools like ValidatorFX easy to build: ** There's the TooltipWrapper class in ValidatorFX which works around JDK-8090379. Not a big deal but something many application developers will probably be annoyed by. ** On a more general note, if I were the king of the JavaFX universe for one day, I would forbid anyone to make classes or methods final. As an application developer I prefer to be able to tweak things easily, even if they may break in the future (which they will anyway ...). Don't take that decision away from me, it's patronizing. But I guess this is one of those things that depend very much on which side of the equation you are, so don't take my troll bait :-). --Robert Am 03.03.24 um 02:10 schrieb John Hendrikx: > Hi Dirk, > > That is a very nice framework, and although I wouldn't be against its > inclusion in FX, I'm more wondering if JavaFX could do more to help > make tools like ValidatorFX easy to build. > > I'm not quite sure how one can use not having validation as an > argument against using FX, when there clearly are free alternatives > available.? Surely not everything can or should be part of the base > framework?? A line must be drawn somewhere, especially when there are > very few core FX developers. > > I'd much rather see work being done on things that can't be provided > by 3rd parties, preferably by opening up more parts of FX with well > specified API's. > > --John > > On 01/03/2024 11:59, Dirk Lemmermann wrote: >> Hi everyone, >> >> I updated the validation framework ValidatorFX today in our project >> to the latest release and I really like it a lot. It is a small >> compact API and works with any observable as opposed to the >> validation support provided by ControlsFX. >> >> Using it made me wonder whether it would make sense to bundle it or >> something like it directly with JavaFX. Developers often mention >> missing validation support as a drawback of using JavaFX. Adding this >> would take one item off from the list of arguments against using JavaFX. >> >> Many UI frameworks do have built-in validation support, e.g. Vaadin >> [0], Angular, [1], or QT [2] >> >> What do you think? >> >> ?Dirk >> >> [0] >> https://vaadin.com/docs/latest/binding-data/components-binder-validation >> [1] https://angular.io/guide/form-validation >> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html >> From michaelstrau2 at gmail.com Mon Mar 4 09:01:25 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 4 Mar 2024 10:01:25 +0100 Subject: Validation Support In-Reply-To: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: I would not be in favor of adding any particular data validation framework to JavaFX. Data validation comes in all kinds of different shapes and sizes, which makes it a good fit for (opinionated) third-party libraries. However, I fully agree with John that JavaFX should provide more APIs that can only realistically be implemented in FX. I've proposed a "significant interaction" API, which is crucial for many data validation scenarios: https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html On Fri, Mar 1, 2024 at 12:50?PM Dirk Lemmermann wrote: > > Hi everyone, > > I updated the validation framework ValidatorFX today in our project to the latest release and I really like it a lot. It is a small compact API and works with any observable as opposed to the validation support provided by ControlsFX. > > Using it made me wonder whether it would make sense to bundle it or something like it directly with JavaFX. Developers often mention missing validation support as a drawback of using JavaFX. Adding this would take one item off from the list of arguments against using JavaFX. > > Many UI frameworks do have built-in validation support, e.g. Vaadin [0], Angular, [1], or QT [2] > > What do you think? > > ?Dirk > > [0] https://vaadin.com/docs/latest/binding-data/components-binder-validation > [1] https://angular.io/guide/form-validation > [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html > From r.lichtenberger at gmail.com Mon Mar 4 10:39:44 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 4 Mar 2024 11:39:44 +0100 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: <7d64eee8-1665-4084-b293-9288a839d956@gmail.com> Am 04.03.24 um 10:01 schrieb Michael Strau?: > I would not be in favor of adding any particular data validation > framework to JavaFX. Data validation comes in all kinds of different > shapes and sizes, which makes it a good fit for (opinionated) > third-party libraries. I agree with that while at the same time trying to provide different options (opinions) with ValidatorFX. > However, I fully agree with John that JavaFX > should provide more APIs that can only realistically be implemented in > FX. I've proposed a "significant interaction" API, which is crucial > for many data validation scenarios: > https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html Shame on me, I totally missed that thread. It contains a lot of insight. Interestingly, ValidatorFX (since 0.5.0) supports these different modes at the moment: * immediate (which you call "Eager" in the thread above) * explicit (which you call "Submit") * immediate-after-submit: This leaves the user undisturbed until they first press the "submit" button. After that, the form changes into immediate mode, only then highlighting everything that has to be corrected. * explicit with immediate clearing: Validation happens on submit, but as soon as the user changes any of the validated properties, validation is reset so that the user has some "breathing space" when correcting their input An implementation of your "second" mode, which will redo validation on "significant user input" is missing at the moment. But I think this should be possible to do with sth. like a .checkedOn(ObservableValue userModifiedProperty) method. That will still leave the burden of defining the userModifiedProperty to the application but that is probably for the best: For a "required" check, getting and losing the focus is not a significant user input, while a field that requires either no input at all or a valid SSN may use the lost focus for that. To that end, I've just created https://github.com/effad/ValidatorFX/issues/37. --Robert From johan.vos at gluonhq.com Mon Mar 4 10:55:34 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 4 Mar 2024 11:55:34 +0100 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: I second what John and Michael say (provide more APIs in OpenJFX that can only realistically be implemented in OpenJFX). I believe the experience from Robert as the creator of ValidatorFX is extremely valuable to this. The key question that might help to see what we need here is: "What would have made it easier to create ValidatorFX (I hear the point of not using final everywhere)?" - Johan On Mon, Mar 4, 2024 at 10:03?AM Michael Strau? wrote: > I would not be in favor of adding any particular data validation > framework to JavaFX. Data validation comes in all kinds of different > shapes and sizes, which makes it a good fit for (opinionated) > third-party libraries. However, I fully agree with John that JavaFX > should provide more APIs that can only realistically be implemented in > FX. I've proposed a "significant interaction" API, which is crucial > for many data validation scenarios: > https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html > > > On Fri, Mar 1, 2024 at 12:50?PM Dirk Lemmermann > wrote: > > > > Hi everyone, > > > > I updated the validation framework ValidatorFX today in our project to > the latest release and I really like it a lot. It is a small compact API > and works with any observable as opposed to the validation support provided > by ControlsFX. > > > > Using it made me wonder whether it would make sense to bundle it or > something like it directly with JavaFX. Developers often mention missing > validation support as a drawback of using JavaFX. Adding this would take > one item off from the list of arguments against using JavaFX. > > > > Many UI frameworks do have built-in validation support, e.g. Vaadin [0], > Angular, [1], or QT [2] > > > > What do you think? > > > > ?Dirk > > > > [0] > https://vaadin.com/docs/latest/binding-data/components-binder-validation > > [1] https://angular.io/guide/form-validation > > [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Mon Mar 4 11:01:09 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Mar 2024 11:01:09 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add unit test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1323/files - new: https://git.openjdk.org/jfx/pull/1323/files/130587c9..7ef09bf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1323&range=15-16 Stats: 228 lines in 5 files changed: 218 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1323.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323 PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Mon Mar 4 11:07:57 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Mar 2024 11:07:57 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v16] In-Reply-To: References: <9S_DXHuxA1SFb1DQvsc5spkBkiwZfD2it6gX66ODIUY=.d69a6aeb-3caa-40f1-8ae2-010ebf68f1bf@github.com> Message-ID: <8xe4PzoDCh78ZHXXtK1rMdRqkMzCg7jIcN_gyPI51fA=.1b309f9f-9ee1-4381-9cae-ac30ba603f2a@github.com> On Thu, 29 Feb 2024 12:12:01 GMT, John Hendrikx wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1031: > >> 1029: if (runs.length != 0) { >> 1030: textRunStart = findFirstRunStart(runs); >> 1031: } > > Can you rewrite this to be: > > int textRunStart = findFirstRunStart(); > > The `runs` parameter doesn't need to be passed (`findFirstRunStart` can access it just as easily), and the length check can be moved inside that method as well. Updated `findFirstRunStart` method. I believe the length test is not really necessary here because even if the Text node is empty, a run will be created for it. So did not add length check. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1510984490 From kpk at openjdk.org Mon Mar 4 11:07:57 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 4 Mar 2024 11:07:57 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> Message-ID: <5noMmOmJBG6AXS4afUoy1ZvAuau1DY24m6v6PkD6_Y4=.d36e77e4-f287-48aa-b46e-adbe7a2ae9de@github.com> On Thu, 29 Feb 2024 17:33:14 GMT, John Hendrikx wrote: >> @hjohn how do you get this coverage diagram? >> >> The BreakIterator is a part of the existing code, we should probably have this discussion outside of this PR. I agree, there might be a situation when the app wants to select a specific locale for the text component instead of relying on the default locale. > > @andy-goryachev-oracle The coverage comes from EclEmma, an Eclipse plugin. Once installed, there is another way to run tests called `Coverage as...` just above `Run as...`. It's very useful to use it on a JUnit test to see if there are major branches you missed in testing that may require additional cases. Thank you @hjohn for providing the test. I have added this. Since we do not use scene in this test, I think it is difficult to test HitInfo in RTL mode. However these tests will be very useful in testing the HitInfo. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1510982462 From jvos at openjdk.org Mon Mar 4 11:11:00 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Mar 2024 11:11:00 GMT Subject: RFR: 8327177: Wrong GlobalRef deleted Message-ID: Explicitly remove old global ref value from menu->jCallback. This avoids the possibility of that value (which can be reused for other refs) to be deleted twice. ------------- Commit messages: - Explicitly remove old global ref value from menu->jCallback. Changes: https://git.openjdk.org/jfx/pull/1388/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327177 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1388.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1388/head:pull/1388 PR: https://git.openjdk.org/jfx/pull/1388 From kcr at openjdk.org Mon Mar 4 13:41:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Mar 2024 13:41:52 GMT Subject: RFR: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. Reviewer: @arapte @jayathirthrao you might also want to take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-1976604084 From kcr at openjdk.org Mon Mar 4 14:00:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Mar 2024 14:00:54 GMT Subject: RFR: 8327177: Wrong GlobalRef deleted In-Reply-To: References: Message-ID: <0s4Xffwv4fiuzsBP2XlUPNFqo09obMAdMr8GhvxbPug=.7527b25a-1882-4a1f-9ca6-a73e793df6d2@github.com> On Mon, 4 Mar 2024 11:07:07 GMT, Johan Vos wrote: > Explicitly remove old global ref value from menu->jCallback. > This avoids the possibility of that value (which can be reused for other refs) to be deleted twice. This is a safe fix that is clearly the right thing to do. I recommend changing the Bug title (and then the PR title to match) to add "macOS" and "GlassMenu" somewhere in the title to make it a little more informative, but I'll leave it up to you. This is a simple enough fix that a single reviewer is sufficient. Once integrated, I recommend backporting this to jfx22u for 22.0.1 (and possibly to earlier releases as you see fit). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1388#pullrequestreview-1914377783 From kcr at openjdk.org Mon Mar 4 14:19:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 4 Mar 2024 14:19:54 GMT Subject: RFR: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 11:07:07 GMT, Johan Vos wrote: > Explicitly remove old global ref value from menu->jCallback. > This avoids the possibility of that value (which can be reused for other refs) to be deleted twice. Updated title looks good. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1388#issuecomment-1976682668 From jvos at openjdk.org Mon Mar 4 14:25:56 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 4 Mar 2024 14:25:56 GMT Subject: Integrated: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 11:07:07 GMT, Johan Vos wrote: > Explicitly remove old global ref value from menu->jCallback. > This avoids the possibility of that value (which can be reused for other refs) to be deleted twice. This pull request has now been integrated. Changeset: 8114559e Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/8114559ed666fe272d238cdf1e531e5d8ec22226 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8327177: macOS: wrong GlobalRef deleted in GlassMenu Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1388 From angorya at openjdk.org Mon Mar 4 16:18:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 4 Mar 2024 16:18:02 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 11:01:09 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test a couple of very minor comments, I am ok with pushing this code as is. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 108: > 106: if (obj == null) > 107: return false; > 108: if (getClass() != obj.getClass()) any reason why this code uses getClass() != obj.getClass() ? perhaps a better choice might be the usual pattern if(x == this) { return true; } else if(x instanceof Hit h) { return charIndex == h.charIndex && ... } return false; modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1044: > 1042: private int findFirstRunStart() { > 1043: int start = Integer.MAX_VALUE; > 1044: for (GlyphList r: getRuns()) { the old code had a 0 check for getRuns.length, presumably to avoid the iterator creation. the new code is probably fine, because most of the time we'll have the need for the iterator anyway. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1914727360 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511416507 PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511420549 From jhendrikx at openjdk.org Mon Mar 4 17:12:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 4 Mar 2024 17:12:01 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 16:12:12 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add unit test > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 108: > >> 106: if (obj == null) >> 107: return false; >> 108: if (getClass() != obj.getClass()) > > any reason why this code uses getClass() != obj.getClass() ? > > perhaps a better choice might be the usual pattern > > if(x == this) { > return true; > } else if(x instanceof Hit h) { > return charIndex == h.charIndex && ... > } > return false; There are long discussions about this, and not really worth going into. They both have their place. Generally, the `getClass` versions are easier to get right without violating the `equals` contract. `instanceof` can be used, to allow comparisons with (trivial) subtypes, but then you must make `equals` final. Anything fancier violates the equals contract. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511498972 From jhendrikx at openjdk.org Mon Mar 4 17:16:56 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 4 Mar 2024 17:16:56 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: <7H67ZPEBLif_hSYo0uPhkMrhxdn8u_rfaIlUb950uJM=.3cec2166-e53f-4ffb-8346-d5eb19c32262@github.com> On Mon, 4 Mar 2024 11:01:09 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test I was gonna review, but I'm a contributor now... still allowed? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1977079190 From jhendrikx at openjdk.org Mon Mar 4 17:16:56 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 4 Mar 2024 17:16:56 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 16:15:02 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add unit test > > modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1044: > >> 1042: private int findFirstRunStart() { >> 1043: int start = Integer.MAX_VALUE; >> 1044: for (GlyphList r: getRuns()) { > > the old code had a 0 check for getRuns.length, presumably to avoid the iterator creation. > the new code is probably fine, because most of the time we'll have the need for the iterator anyway. `getRuns` returns an array, it won't create an `Iterator`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511503440 From jhendrikx at openjdk.org Mon Mar 4 17:22:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 4 Mar 2024 17:22:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: <5fxrdROWb-v8n_-jI-80jw0hmgfXxk29aRX76B78cMQ=.52ddd563-018b-4988-bc98-d2204116eada@github.com> On Mon, 4 Mar 2024 11:01:09 GMT, Karthik P K wrote: >> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. >> >> Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. >> >> Added system tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test LGTM ------------- Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1914883510 From jhendrikx at openjdk.org Mon Mar 4 17:22:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 4 Mar 2024 17:22:58 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v13] In-Reply-To: <5noMmOmJBG6AXS4afUoy1ZvAuau1DY24m6v6PkD6_Y4=.d36e77e4-f287-48aa-b46e-adbe7a2ae9de@github.com> References: <61-ClbWsYgXJLnEwrHGekPPZRGuJ-BJUkpTpRBTdErY=.a28d7a40-78b2-40a8-960e-c05910004667@github.com> <4r1fucmfdeNqsxxe_8yvXCcZRVFsWX9UystBKTcpc9c=.4c783286-55db-46ff-a497-8e6c63991c27@github.com> <5noMmOmJBG6AXS4afUoy1ZvAuau1DY24m6v6PkD6_Y4=.d36e77e4-f287-48aa-b46e-adbe7a2ae9de@github.com> Message-ID: On Mon, 4 Mar 2024 11:03:26 GMT, Karthik P K wrote: >> @andy-goryachev-oracle The coverage comes from EclEmma, an Eclipse plugin. Once installed, there is another way to run tests called `Coverage as...` just above `Run as...`. It's very useful to use it on a JUnit test to see if there are major branches you missed in testing that may require additional cases. > > Thank you @hjohn for providing the test. I have added this. > Since we do not use scene in this test, I think it is difficult to test HitInfo in RTL mode. However these tests will be very useful in testing the HitInfo. I think it's possible even in the JUnit test. You can call `setDirection` on `layout` to set mirroring. However, since we removed `isMirrored` check in `getHitInfo`, the code is no longer dependent on whether the text is mirrored or not, so extra tests won't catch anything new. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511512588 From angorya at openjdk.org Mon Mar 4 17:52:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 4 Mar 2024 17:52:59 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v17] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 17:13:01 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1044: >> >>> 1042: private int findFirstRunStart() { >>> 1043: int start = Integer.MAX_VALUE; >>> 1044: for (GlyphList r: getRuns()) { >> >> the old code had a 0 check for getRuns.length, presumably to avoid the iterator creation. >> the new code is probably fine, because most of the time we'll have the need for the iterator anyway. > > `getRuns` returns an array, it won't create an `Iterator`. you are right! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1511547919 From mhanl at openjdk.org Mon Mar 4 19:06:21 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 4 Mar 2024 19:06:21 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v4] In-Reply-To: References: Message-ID: <2y1xCETHChPWZfw-Syqz2J4BTZ1KdSy5HCzQXa1fNlc=.2d6a856b-879a-48d3-b43b-bb390003fc82@github.com> > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: do not attempt to leave eventloop after it is done ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/a4cce087..508e2569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=02-03 Stats: 20 lines in 1 file changed: 10 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From mhanl at openjdk.org Mon Mar 4 19:06:21 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 4 Mar 2024 19:06:21 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v3] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 23:56:19 GMT, Martin Fox wrote: > The top of the call stack when the exception is thrown: Yeah, had the same issue and fixed it locally. Now pushed. Problem as stated above remains though ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1977265143 From mhanl at openjdk.org Mon Mar 4 19:16:06 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 4 Mar 2024 19:16:06 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v5] In-Reply-To: References: Message-ID: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: do not attempt to leave eventloop after leaving another eventloop ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/508e2569..0bcda3a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From jpereda at openjdk.org Mon Mar 4 19:29:57 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 4 Mar 2024 19:29:57 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 09:30:14 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into 8319779-systemmenu > - Add additional test for IOOBE detection. > This test comes from JDK-8323787 > - Revert some of the conditional bindings. > Clear menu construction when an menuitem that is a menu needs to be removed > Add a test for the latter > - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu > - Cleanup test > - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. > Add a test to make sure those references are gone. > - Revert WeakInvalidationListeners and use new listener resource management approach. > - Fix more memoryleaks due to listeners never being unregistered. > - These changes are related to JBS-8318841 so we want to have that code in > as well. > > Merge branch 'master' into 8319779-systemmenu > - process reviewers comments > - ... and 1 more: https://git.openjdk.org/jfx/compare/a68c0a68...ec7308df modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 226: > 224: mb.textProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); > 225: mb.disableProperty().when(active).addListener(valueModel -> glassMenu.setEnabled(!mb.isDisable())); > 226: mb.mnemonicParsingProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); Since you are not calling `get()` from the `when` resulting observable (to allow for invalidation), these need to use a `ChangeListener` instead of an `InvalidationListener`, otherwise, while `active` doesn't change, any change in those menuBase properties will trigger just one notification. Alternative, just replace `addListener` with `subscribe` (as it internally uses a `ChangeListener`). @hjohn does this make sense to you? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1511687632 From angorya at openjdk.org Mon Mar 4 23:23:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 4 Mar 2024 23:23:00 GMT Subject: RFR: 8092102: Labeled: truncated property Message-ID: Adds Labeled.truncated property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. The new property reacts to changes in the following properties: - ellipsisString - font - text - width - wrapText For some reason, line 859 generates a javadoc "co comment" warning, despite the javadoc comment present at the property declaration in line 832. I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. **Alternative** The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? ------------- Commit messages: - 8092102 Labeled: truncated property Changes: https://git.openjdk.org/jfx/pull/1389/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8092102 Stats: 80 lines in 1 file changed: 59 ins; 17 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From psadhukhan at openjdk.org Tue Mar 5 02:44:50 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 5 Mar 2024 02:44:50 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> Message-ID: On Fri, 1 Mar 2024 17:11:00 GMT, Kevin Rushforth wrote: >> FYI: after merging this and #1384 together all I see in the build log are 4 native warnings (on macOS): >> >> >> /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:93:21: warning: 'lockFocusIfCanDraw' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] >> if ([nsView lockFocusIfCanDraw] == NO) { >> ^ >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:190:1: note: 'lockFocusIfCanDraw' has been explicitly marked deprecated here >> - (BOOL)lockFocusIfCanDraw API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); >> ^ >> /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:98:25: warning: 'unlockFocus' is deprecated: first deprecated in macOS 10.14 - To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view. [-Wdeprecated-declarations] >> [nsView unlockFocus]; >> ^ >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:189:1: note: 'unlockFocus' has been explicitly marked deprecated here >> - (void)unlockFocus API_DEPRECATED("To draw, subclass NSView and implement -drawRect:; AppKit's automatic deferred display mechanism will call -drawRect: as necessary to display the view.", macos(10.0,10.14)); >> ^ >> /Users/angorya/Projects/jfx-1/jfx/rt/modules/javafx.graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m:120:24: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations] >> [nsContext setView : nsView]; >> ^ >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is dec... > > That's because we don't enable javac lint warnings by default. I am getting ready to file a few JBS issues related to this. Stay tuned. > > In the mean time, if you want to see how many warnings we do have, try running with `gradle -PLINT=all`. Or rather, you'll see how many modules hit the 100 warnings limit. :) So, that @SuppressWarnings("serial") // Same-version serialization only would be addressed as javac lint warning JBS? Just thinking out aloud, I dont see this @SuppressWarnings("doclint:missing") in our java.desktop classes? what's the difference there? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1512059413 From psadhukhan at openjdk.org Tue Mar 5 03:14:53 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 5 Mar 2024 03:14:53 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> Message-ID: On Thu, 29 Feb 2024 23:56:06 GMT, Andy Goryachev wrote: >> Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments JFXPanel change ok to me.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1386#pullrequestreview-1915786485 From kpk at openjdk.org Tue Mar 5 04:06:56 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 5 Mar 2024 04:06:56 GMT Subject: Integrated: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 07:31:51 GMT, Karthik P K wrote: > In the `getHitInfo()` method of PrismTextLayout, RTL node orientation conditions were not considered, hence hit test values such as character index and insertion index values were incorrect. > > Added checks for RTL orientation of nodes and fixed the issue in `getHitInfo()` to calculate correct hit test values. > > Added system tests to validate the changes. This pull request has now been integrated. Changeset: 66d96818 Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/66d96818413f8ce5518cc20cff848eacd1a2d56c Stats: 1166 lines in 10 files changed: 1068 ins; 66 del; 32 mod 8319844: Text/TextFlow.hitTest() is incorrect in RTL orientation Co-authored-by: John Hendrikx Reviewed-by: angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1323 From kpk at openjdk.org Tue Mar 5 07:16:55 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 5 Mar 2024 07:16:55 GMT Subject: RFR: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations [v2] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 17:38:11 GMT, Marius Hanl wrote: >> `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. >> >> This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. >> >> It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). >> >> Checking the whole history, it looks like the following was happening: >> 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) >> 2. Check was removed as it caused bugs >> 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) >> 4. Forgotten for `TreeTableRow` inbetween this chaos. >> >> Added many tests for the case where an item should be changed and where it should not. >> Improved existing tests as well. Using `stageLoader`, as before the tests only created a stage when doing the assert. >> >> NOTE: The update logic is now the same as for all other 5 cell implementations. Especially `TreeCell` (since it is for a tree structure as well). > > Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8325402: remove labeled if > - JDK-8325402: Unit test improvements LGTM, tested in Mac 14.3.1. ------------- Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1360#pullrequestreview-1916024806 From jhendrikx at openjdk.org Tue Mar 5 07:39:51 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 5 Mar 2024 07:39:51 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 00:20:19 GMT, John Hendrikx wrote: >> No, the explicit goal of this construction is to set active to false (in case it exists) so that existing listeners can be released; followed by creating a new active property that is by default set to true until `setMenus` is called again (e.g. after unfocus/focus events). >> I noticed however that it is not as simple as that, and the current PR introduces regression, as the `SystemMenuBarTest.testMemoryLeak` test is now failing. Listeners are not only registered when `setMenus` is called, but also when menu(Item)s are added to menus. I'm not sure if a single `active` property can address this, as we don't want to remove all listeners for all menuitems in case a particular menuitem is added to a particular menu. >> @hjohn does that make sense? > > @johanvos I don't think what I wrote above (option 1) will work -- there will still be a reference from the `active` property that keeps the menu item alive; a reference is indeed removed when `hasParent` becomes `false`, but there is another (same reason we had to recreate the active property)... I will think on this some more over the weekend. I think you already solved the issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1512255445 From jhendrikx at openjdk.org Tue Mar 5 07:39:55 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 5 Mar 2024 07:39:55 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 19:26:37 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into 8319779-systemmenu >> - Add additional test for IOOBE detection. >> This test comes from JDK-8323787 >> - Revert some of the conditional bindings. >> Clear menu construction when an menuitem that is a menu needs to be removed >> Add a test for the latter >> - Merge remote-tracking branch 'upstream/master' into 8319779-systemmenu >> - Cleanup test >> - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. >> Add a test to make sure those references are gone. >> - Revert WeakInvalidationListeners and use new listener resource management approach. >> - Fix more memoryleaks due to listeners never being unregistered. >> - These changes are related to JBS-8318841 so we want to have that code in >> as well. >> >> Merge branch 'master' into 8319779-systemmenu >> - process reviewers comments >> - ... and 1 more: https://git.openjdk.org/jfx/compare/f65f11d2...ec7308df > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 226: > >> 224: mb.textProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); >> 225: mb.disableProperty().when(active).addListener(valueModel -> glassMenu.setEnabled(!mb.isDisable())); >> 226: mb.mnemonicParsingProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); > > Since you are not calling `get()` from the `when` resulting observable (to allow for invalidation), these need to use a `ChangeListener` instead of an `InvalidationListener`, otherwise, while `active` doesn't change, any change in those menuBase properties will trigger just one notification. > > Alternative, just replace `addListener` with `subscribe` (as it internally uses a `ChangeListener`). > > @hjohn does this make sense to you? This could be a problem normally, but I think in this case you won't be able to get this to produce incorrect results. `parseText` is accessing the property (and it calls `isMnemonicParsing`), but only if the text is not empty. It's sort of "safe" as an empty text can't contain a mnemonic anyway, and you'd need to change the text at a minimum first to see the effect of turning mnemonic parsing on/off. Changing the text would trigger the `textProperty` listener, which will call `parseText` and read the mnemonic property. A change listener would be more obviously correct, but it is not strictly needed here. (not all `subscribe`s use change listener, the one that takes a `Runnable` uses invalidation) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1512252882 From jvos at openjdk.org Tue Mar 5 08:20:03 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 08:20:03 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v11] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Update modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java Co-authored-by: John Hendrikx ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/ec7308df..c2fb8b1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Tue Mar 5 08:24:52 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 08:24:52 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 16:32:51 GMT, Andy Goryachev wrote: >> Johan Vos has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleanup test >> - Add shim class so that we can access the references to com.sun.glass.ui.Menu instances. >> Add a test to make sure those references are gone. > > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 254: > >> 252: return menuBar; >> 253: } >> 254: > > extra newline? Not sure I understand where you want to add or remove a newline? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1512320714 From jpereda at openjdk.org Tue Mar 5 08:57:57 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 5 Mar 2024 08:57:57 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 07:34:32 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 226: >> >>> 224: mb.textProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); >>> 225: mb.disableProperty().when(active).addListener(valueModel -> glassMenu.setEnabled(!mb.isDisable())); >>> 226: mb.mnemonicParsingProperty().when(active).addListener(valueModel -> glassMenu.setTitle(parseText(mb))); >> >> Since you are not calling `get()` from the `when` resulting observable (to allow for invalidation), these need to use a `ChangeListener` instead of an `InvalidationListener`, otherwise, while `active` doesn't change, any change in those menuBase properties will trigger just one notification. >> >> Alternative, just replace `addListener` with `subscribe` (as it internally uses a `ChangeListener`). >> >> @hjohn does this make sense to you? > > This could be a problem normally, but I think in this case you won't be able to get this to produce incorrect results. > > `parseText` is accessing the property (and it calls `isMnemonicParsing`), but only if the text is not empty. It's sort of "safe" as an empty text can't contain a mnemonic anyway, and you'd need to change the text at a minimum first to see the effect of turning mnemonic parsing on/off. Changing the text would trigger the `textProperty` listener, which will call `parseText` and read the mnemonic property. > > A change listener would be more obviously correct, but it is not strictly needed here. > > (not all `subscribe`s use change listener, the one that takes a `Runnable` uses invalidation) There is an issue using `when()`, because you add the listener to a new property, not to the original property. Therefore, using an invalidation listener doesn't trigger notifications if you changing values more than once to the original property. Simply run this test: BooleanProperty b = new SimpleBooleanProperty(); BooleanProperty active = new SimpleBooleanProperty(true); b.addListener(o -> System.out.println("b: " + b.get())); b.when(active).addListener(o -> System.out.println("when: " + b.get())); b.set(true); b.set(false); It prints: b: true when: true b: false so with `when` we miss the changes! (I can go into details of why this happens, but just notice we have a new property after all, and not calling `when.get()` it doesn't get validated anymore). This can happen in this SystemMenuBar case with the disabled property of any given `Menu` or `MenuItem`, if you simply change it twice, while the application is active. My proposal of using `subscribe` implied using the `Consumer` (therefore the "replacement"). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1512390742 From kpk at openjdk.org Tue Mar 5 09:54:52 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 5 Mar 2024 09:54:52 GMT Subject: RFR: 8092102: Labeled: truncated property In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 21:04:28 GMT, Andy Goryachev wrote: > Adds Labeled.truncated property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - text > - width > - wrapText > > For some reason, line 859 generates a javadoc "co comment" warning, despite the javadoc comment present at the property declaration in line 832. > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? Overall change looks good to me. Do you think change in `labelPaddingProperty`or `graphicProperty` should also trigger check in newly added truncated property? I believe the properties which are already bound should take care of this. Just wanted to confirm here. ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-1916415972 From jvos at openjdk.org Tue Mar 5 09:56:53 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 09:56:53 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511 > reverted accidental indentation chang @FlorianKirmaier I still think this would be a good addition. I believe there is only one open question (from Marius) so it would be great if you can answer that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1978365325 From kcr at openjdk.org Tue Mar 5 13:59:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 13:59:53 GMT Subject: RFR: 8270996: javadoc: missing comments in serialized classes [v3] In-Reply-To: References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> <-GeWbx9xjBzK4Woa-NUiTJAqp4aeAoyF7OR_zJ8YnWI=.d51d9f3b-f0e3-4e5b-a2c1-603c3f58dbb4@github.com> <4mR54XXE2lXa1-FCWfwkRJnpzkLrq_MPql1CKZfl_8U=.52e84a5d-a131-4ad9-804d-1b2e9d309a5f@github.com> Message-ID: On Tue, 5 Mar 2024 02:41:54 GMT, Prasanta Sadhukhan wrote: > So, that @SuppressWarnings("serial") // Same-version serialization only would be addressed as javac lint warning JBS? Yes. I filed [JDK-8327170](https://bugs.openjdk.org/browse/JDK-8327170) as an umbrella task to address javac lint warnings, and will file new linked blocking bugs to address individual warnings. > Just thinking out aloud, I dont see this @SuppressWarnings("doclint:missing") in our java.desktop classes? what's the difference there? We wanted to silence the warnings (so we can turn on `-Werror` once the last warning is gone), and didn't see any real benefit in actually documenting the private fields. We could revisit that later if there was a reason, but I suspect there isn't. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1386#discussion_r1512867661 From nlisker at openjdk.org Tue Mar 5 15:02:53 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 5 Mar 2024 15:02:53 GMT Subject: RFR: 8092102: Labeled: truncated property In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 21:04:28 GMT, Andy Goryachev wrote: > Adds Labeled.truncated property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - text > - width > - wrapText > > For some reason, line 859 generates a javadoc "co comment" warning, despite the javadoc comment present at the property declaration in line 832. > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? This enhancement should be discussed in the mailing list. I've never needed this myself, but it already had an old JBS ticket, so I can see that others did and for a legitimate reason (adding tooltips). I don't mind if it's added or not. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 823: > 821: /** > 822: * Truncated read-only property indicates whether the text has been truncated > 823: * when it cannot fit into the available width. No need to repeat the name and type in the first sentence as it's used in the summary table. Most phrasings opt (inconsistently) for: "Indicates whether..." or just "Whether..." (I prefer the former). I'm also not sure about the sole role of the width. Can the text not be truncated for a reason other than not fitting in the width, like not fitting in the height? modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 830: > 828: * > 829: * @since 23 > 830: * @defaultValue false I don't think that a default value is applicable here since it's completely dependent on other properties and can't be set. It's possible to call the `get` of this property for the first time and get `true`. The value here is the value used in the get method: return property == null ? DEFAULT_VALUE : property.get(); at least in all the cases I've seen. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 832: > 830: * @defaultValue false > 831: */ > 832: private ObservableBooleanValue truncated; The property name should probably be `textTruncated` to be in line with `textOverrun`, `textFill`, `wrapText`... Otherwise it could look like the labeled is truncated. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 834: > 832: private ObservableBooleanValue truncated; > 833: > 834: public final ObservableBooleanValue truncatedProperty() { `ObservableBooleanValue` is not a property, so it's odd to use it as the return type of one. Usually `ReadOnlyBooleanProperty` is used. This implementation through binding is also unique for read-only properties. A look in `Node` and `Labeled` show a different way of implementing read-only properties. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 850: > 848: protected boolean computeValue() { > 849: if (isWrapText()) { > 850: return false; Are you sure that allowing text to wrap necessarily means it won't be truncated? What if the max height doesn't allow another line? ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-1917119989 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1512963900 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1512912954 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1512968169 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1512956759 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1512898960 From angorya at openjdk.org Tue Mar 5 15:28:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 15:28:59 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v6] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 08:21:55 GMT, Johan Vos wrote: >> tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 254: >> >>> 252: return menuBar; >>> 253: } >>> 254: >> >> extra newline? > > Not sure I understand where you want to add or remove a newline? please remove extra newline. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1513023199 From angorya at openjdk.org Tue Mar 5 15:36:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 15:36:59 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v15] In-Reply-To: References: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> Message-ID: On Thu, 29 Feb 2024 05:38:04 GMT, Karthik P K wrote: >> Tested with the MonkeyTester, using different justification (left, right, center, justify) and node orientation, for both Text and TextFlow. Multiple Text instances, rich text, inline nodes, bidi, various line breaking scenarios. >> >> I could not find any issues! The new code also looks much cleaner and much, much easier to understand. I left a few non-essential suggestions inline. >> >> Overall, thank you @karthikpandelu and @hjohn. Good job guys! >> >> P.S. Tested on on macOS 14.3.1. The results on Windows/Linux should be identical, but if we can get some testing done on these two platforms that would be nice. > >> P.S. Tested on on macOS 14.3.1. The results on Windows/Linux should be identical, but if we can get some testing done on these two platforms that would be nice. > > I tested the changes in windows and do not see any issues. > I have executed the headful test using our headful test machines, no failures found in all platforms. > > Addressed inline comments. Please check. I would like to thank @karthikpandelu and @hjohn - this PR was a major effort and you guys finally solved the major issue in javafx RTL text. ?? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1979047718 From angorya at openjdk.org Tue Mar 5 15:40:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 15:40:58 GMT Subject: Integrated: 8270996: javadoc: missing comments in serialized classes In-Reply-To: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> References: <_2X57fGhmLyTFVKTuzw3sJ4AmWu1l8x46MwKloLaSPM=.2d5789c3-72fb-4fdb-af7e-af0b330b2759@github.com> Message-ID: On Thu, 29 Feb 2024 16:53:26 GMT, Andy Goryachev wrote: > Adding `@SuppressWarnings("doclint:missing")` to the lines in Serializable classes that generated javadoc's "missing comments" warning. This pull request has now been integrated. Changeset: 83012271 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/830122718d49c8c27a2ee3f44fdf34529f873753 Stats: 118 lines in 25 files changed: 96 ins; 0 del; 22 mod 8270996: javadoc: missing comments in serialized classes Reviewed-by: kcr, psadhukhan ------------- PR: https://git.openjdk.org/jfx/pull/1386 From angorya at openjdk.org Tue Mar 5 16:15:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 16:15:49 GMT Subject: RFR: 8092102: Labeled: truncated property In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 09:52:37 GMT, Karthik P K wrote: > Do you think change in `labelPaddingProperty`or `graphicProperty` should also trigger check good question! a change in these properties gets handled correctly - no need to add explicit binding. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-1979134552 From kcr at openjdk.org Tue Mar 5 16:27:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 16:27:57 GMT Subject: RFR: 8092102: Labeled: truncated property In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 21:04:28 GMT, Andy Goryachev wrote: > Adds Labeled.truncated property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - text > - width > - wrapText > > For some reason, line 859 generates a javadoc "co comment" warning, despite the javadoc comment present at the property declaration in line 832. > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? Presuming we go forward with this, I left a couple comments on the API. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 834: > 832: private ObservableBooleanValue truncated; > 833: > 834: public final ObservableBooleanValue truncatedProperty() { The return type should be `ReadOnlyBooleanProperty`. That almost certainly explains the other problem you are seeing, since javadoc does not recognize this as a boolean property. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 859: > 857: } > 858: // FIX why does this method emit "warning: no comment" javadoc warning? > 859: public final boolean isTruncated() { See above. ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-1915597929 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1511958192 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1511958471 From kcr at openjdk.org Tue Mar 5 16:27:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 16:27:57 GMT Subject: RFR: 8092102: Labeled: truncated property In-Reply-To: References: Message-ID: <6OtjMe_zfU7qewVGJHbDV0NpXchBVMg2JVW7712SyNQ=.3b7f04d2-6913-4668-bd95-094b6283ef45@github.com> On Tue, 5 Mar 2024 14:59:20 GMT, Nir Lisker wrote: > This enhancement should be discussed in the mailing list. I've never needed this myself, but it already had an old JBS ticket, so I can see that others did and for a legitimate reason (adding tooltips). I don't mind if it's added or not. Yes, this warrants a mailing list discussion, especially given the following comment in the PR Description: > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? I also don't mind one way or the other. If it is felt to be a useful convenience, especially to make it easier to optionally enable Tooltip generation, it seems OK to me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-1979157887 From arapte at openjdk.org Tue Mar 5 16:46:50 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 5 Mar 2024 16:46:50 GMT Subject: RFR: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. Couple quick comments: - Executing the LightingSample manually fails with an exception Caused by: java.lang.NullPointerException: Input stream must not be null at javafx.graphics at 23-internal/javafx.scene.image.Image.validateInputStream(Image.java:1140) at javafx.graphics at 23-internal/javafx.scene.image.Image.(Image.java:707) at lighting3D.Environment.(Environment.java:64) Steps: cd tests/performance/3DLighting/src/main/java javac lighting3D/*.java java lighting3D.LightingApplication - The copyright year new files should be 2024 only. Some new files have more than one copyright year. If you are moving any existing files then please use `git mv` so that the files are shown as moved. - Some files are missing copyright headers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-1979195208 From jvos at openjdk.org Tue Mar 5 16:51:02 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 16:51:02 GMT Subject: [jfx22u] RFR: 8327177: macOS: wrong GlobalRef deleted in GlassMenu Message-ID: 8327177: macOS: wrong GlobalRef deleted in GlassMenu ------------- Commit messages: - Backport 8114559ed666fe272d238cdf1e531e5d8ec22226 Changes: https://git.openjdk.org/jfx22u/pull/16/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=16&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327177 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/16.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/16/head:pull/16 PR: https://git.openjdk.org/jfx22u/pull/16 From jvos at openjdk.org Tue Mar 5 16:51:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 16:51:07 GMT Subject: [jfx21u] RFR: 8327177: macOS: wrong GlobalRef deleted in GlassMenu Message-ID: 8327177: macOS: wrong GlobalRef deleted in GlassMenu ------------- Commit messages: - Backport 8114559ed666fe272d238cdf1e531e5d8ec22226 Changes: https://git.openjdk.org/jfx21u/pull/49/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=49&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327177 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/49.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/49/head:pull/49 PR: https://git.openjdk.org/jfx21u/pull/49 From kcr at openjdk.org Tue Mar 5 16:52:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 16:52:01 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings Message-ID: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 That build fails with the expected error: 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment 2024-03-05T16:23:29.6265947Z private final String message; 2024-03-05T16:23:29.6266448Z ^ 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment 2024-03-05T16:23:29.6269004Z private final T data; 2024-03-05T16:23:29.6269667Z ^ 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. 2024-03-05T16:23:31.7940244Z 1 error 2024-03-05T16:23:31.7940590Z 91 warnings ------------- Commit messages: - 8325075: Enable -Werror for javadoc to fail on any warnings Changes: https://git.openjdk.org/jfx/pull/1390/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1390&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325075 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1390.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1390/head:pull/1390 PR: https://git.openjdk.org/jfx/pull/1390 From kcr at openjdk.org Tue Mar 5 16:52:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 16:52:01 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings Reviewer: @andy-goryachev-oracle Others are welcome to review as well. I'll wait until tomorrow to integrate it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979206816 From angorya at openjdk.org Tue Mar 5 17:47:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 17:47:50 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings When used with the PR #1389, the build generates a sole javadoc warning and fails: > Task :javadoc /Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java:859: warning: no comment public final boolean isTruncated() { ^ error: warnings found and -Werror specified 1 error 1 warning > Task :javadoc FAILED FAILURE: Build failed with an exception. Is there any way to selectively suppress certain javadoc warnings (now errors?) if so, could we document them, possibly in the wiki page https://wiki.openjdk.org/pages/viewpage.action?spaceKey=OpenJFX&title=Building+OpenJFX ? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1390#pullrequestreview-1917715966 From jvos at openjdk.org Tue Mar 5 18:04:51 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 5 Mar 2024 18:04:51 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: <0GgDhyxNmaH3hXBgsUZpVJgPFQCyTHAk2u-EkQ_EKbc=.40948639-1789-41d7-ab9c-317239d99219@github.com> On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings This is major progress. Building works perfect, and with the patch applied to an older state of the repository it fails as expected. This will enforce us to keep the JavaDoc clean (at least from a syntax point), good work. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1390#pullrequestreview-1917757644 From kcr at openjdk.org Tue Mar 5 18:09:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 18:09:50 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 17:45:01 GMT, Andy Goryachev wrote: > When used with the PR #1389, the build generates a sole javadoc warning and fails: Good. That's expected. > Is there any way to selectively suppress certain javadoc warnings (now errors?) if so, could we document them, possibly in the wiki page https://wiki.openjdk.org/pages/viewpage.action?spaceKey=OpenJFX&title=Building+OpenJFX > > ? You mean on the command line? Good question, I can check whether it is possible to turn off a single without turning off all errors (which is easy), but even better would be to add a flag to turn off `-Werror`. Maybe something like `-PDOC_WERROR=false` (defaults to true)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979347095 From angorya at openjdk.org Tue Mar 5 18:25:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 18:25:52 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 18:06:50 GMT, Kevin Rushforth wrote: > turn off a single without turning off all errors (which is easy) yes, this is the exact scenario. I wouldn't expect this will be a frequent operation - but imagine javadoc team adds a new check that generates a lot of warnings, for example. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979379522 From angorya at openjdk.org Tue Mar 5 18:34:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 18:34:48 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings Also worth noting that unfortunately, javadoc in Eclipse seems to work differently, resulting in 137 warnings: (see JDK-8324783) Description Resource Type Path Location Javadoc: Description expected after @return AudioClip.java Java Problem /media/src/main/java/com/sun/media/jfxmedia line 313 Javadoc: Description expected after @return D3DContext.java Java Problem /graphics/src/main/java/com/sun/prism/d3d line 76 Javadoc: Description expected after @return DefaultCancelButtonTestBase.java Java Problem /controls/src/test/java/test/javafx/scene/control line 93 Javadoc: Description expected after @return DefaultCancelButtonTestBase.java Java Problem /controls/src/test/java/test/javafx/scene/control line 152 Javadoc: Description expected after @return Direction.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/traversal line 56 Javadoc: Description expected after @return EmbeddedScene.java Java Problem /graphics/src/main/java/com/sun/javafx/tk/quantum line 225 Javadoc: Description expected after @return FilterEffect.java Java Problem /graphics/src/main/java/com/sun/scenario/effect line 155 Javadoc: Description expected after @return GeneralTransform3D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom/transform line 136 Javadoc: Description expected after @return InputMap.java Java Problem /controls/src/main/java/com/sun/javafx/scene/control/inputmap line 308 Javadoc: Description expected after @return InputMap.java Java Problem /controls/src/main/java/com/sun/javafx/scene/control/inputmap line 678 Javadoc: Description expected after @return Logging.java Java Problem /base/src/main/java/com/sun/javafx/binding line 44 Javadoc: Description expected after @return PickRay.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 240 Javadoc: Description expected after @return PluginListener.java Java Problem /web/src/main/java/com/sun/webkit/plugin line 49 Javadoc: Description expected after @return PropertyReference.java Java Problem /base/src/main/java/com/sun/javafx/property line 96 Javadoc: Description expected after @return QuantumClipboard.java Java Problem /graphics/src/main/java/com/sun/javafx/tk/quantum line 148 Javadoc: Description expected after @return QuantumClipboard.java Java Problem /graphics/src/main/java/com/sun/javafx/tk/quantum line 172 Javadoc: Description expected after @return SkinStub.java Java Problem /controls/src/test/java/test/javafx/scene/control line 81 Javadoc: Description expected after @return StyleManager.java Java Problem /graphics/src/main/java/com/sun/javafx/css line 1933 Javadoc: Description expected after @return StyleManager.java Java Problem /graphics/src/main/java/com/sun/javafx/css line 1948 Javadoc: Description expected after @return TableSkinShim.java Java Problem /controls/src/shims/java/javafx/scene/control/skin line 67 Javadoc: Description expected after @return TableSkinShim.java Java Problem /controls/src/shims/java/javafx/scene/control/skin line 79 Javadoc: Description expected after @return TraversalEngine.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/traversal line 136 Javadoc: Invalid param tag name LinearGradientContext.java Java Problem /graphics/src/main/java/com/sun/prism/impl/paint line 105 Javadoc: Invalid param tag name RadialGradientContext.java Java Problem /graphics/src/main/java/com/sun/prism/impl/paint line 151 Javadoc: Invalid param tag name RadialGradientPaintContext.java Java Problem /graphics/src/main/java/com/sun/prism/j2d/paint line 171 Javadoc: Invalid reference AndroidFontFinder.java Java Problem /graphics/src/main/java/com/sun/javafx/font line 52 Javadoc: Invalid reference package-info.java Java Problem /base/src/main/java/javafx/beans/binding line 27 Javadoc: Invalid tag TableViewTest.java Java Problem /controls/src/test/java/test/javafx/scene/control line 868 Javadoc: Invalid tag TableViewTest.java Java Problem /controls/src/test/java/test/javafx/scene/control line 2055 Javadoc: Malformed reference (missing end space separator) GradientColorMap.java Java Problem /graphics/src/main/java/com/sun/pisces line 33 Javadoc: Missing #: "applies(Styleable)} method except it also returns" Selector.java Java Problem /graphics/src/main/java/javafx/css line 119 Javadoc: Missing #: "close()" PickResultChooser.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/input line 108 Javadoc: Missing #: "Effect.filter()} operation and it is queried for" RenderState.java Java Problem /graphics/src/main/java/com/sun/scenario/effect/impl/state line 34 Javadoc: Missing #: "getSourceRegion(Rectangle, Rectangle, Rectangle)} method." EffectPeer.java Java Problem /graphics/src/main/java/com/sun/scenario/effect/impl line 205 Javadoc: Missing #: "getTextureCoordinates(float[],float,float,float,float,Rectangle,BaseTransform)}." EffectPeer.java Java Problem /graphics/src/main/java/com/sun/scenario/effect/impl line 277 Javadoc: Missing #: "managed()} method and support for sharing" BaseResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 32 Javadoc: Missing #: "managed()} method will only indicate the amount of the resource" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 37 Javadoc: Missing #: "max()}" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 34 Javadoc: Missing #: "max()} method, larger than the amount" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 131 Javadoc: Missing #: "max()} method, larger than the amount returned by the" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 110 Javadoc: Missing #: "max()} method." ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 121 Javadoc: Missing #: "origTarget()} method, and may change over time." ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 111 Javadoc: Missing #: "origTarget()} method." ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 132 Javadoc: Missing #: "Path2D(Shape, BaseTransform) Path2D}" Path2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 1995 Javadoc: Missing #: "Platform.exit()}." Util.java Java Problem /systemTests-test/java/test/util line 381 Javadoc: Missing #: "setCompositeRule(int), PiscesRenderer.setComposite(int, float)" RendererBase.java Java Problem /graphics/src/main/java/com/sun/pisces line 57 Javadoc: Missing #: "setCompositeRule(int), setComposite(int, float)" RendererBase.java Java Problem /graphics/src/main/java/com/sun/pisces line 44 Javadoc: Missing #: "setCompositeRule(int), setComposite(int, float)" RendererBase.java Java Problem /graphics/src/main/java/com/sun/pisces line 50 Javadoc: Missing #: "target()} method will return" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 38 Javadoc: Missing #: "used()}" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 92 Javadoc: Missing #: "used()} and {@link max()}" ResourcePool.java Java Problem /graphics/src/main/java/com/sun/prism/impl line 34 Javadoc: Missing closing brace for inline tag GlassRobot.java Java Problem /graphics/src/main/java/com/sun/glass/ui line 168 Javadoc: Missing closing brace for inline tag GlassRobot.java Java Problem /graphics/src/main/java/com/sun/glass/ui line 168 Javadoc: Missing closing brace for inline tag ListView.java Java Problem /controls/src/main/java/javafx/scene/control line 165 Javadoc: Missing closing brace for inline tag Path2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 811 Javadoc: Missing closing brace for inline tag Path2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 913 Javadoc: Missing closing brace for inline tag PhongMaterial.java Java Problem /graphics/src/main/java/javafx/scene/paint line 405 Javadoc: Missing closing brace for inline tag TableView.java Java Problem /controls/src/main/java/javafx/scene/control line 275 Javadoc: Missing closing brace for inline tag TreeTableView.java Java Problem /controls/src/main/java/javafx/scene/control line 302 Javadoc: Missing closing brace for inline tag TreeView.java Java Problem /controls/src/main/java/javafx/scene/control line 146 Javadoc: Unexpected tag Arc2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 202 Javadoc: Unexpected tag BackgroundPositionConverter.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/layout/region line 86 Javadoc: Unexpected tag BackgroundSizeConverter.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/layout/region line 83 Javadoc: Unexpected tag BorderConverter.java Java Problem /graphics/src/main/java/javafx/scene/layout line 196 Javadoc: Unexpected tag BorderImageSliceConverter.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/layout/region line 76 Javadoc: Unexpected tag BorderStyleConverter.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/layout/region line 159 Javadoc: Unexpected tag ClipShapeTest.java Java Problem /systemTests-test/java/test/com/sun/marlin line 91 Javadoc: Unexpected tag DashedRectTest.java Java Problem /systemTests-test/java/test/com/sun/marlin line 58 Javadoc: Unexpected tag FXCanvas.java Java Problem /swt/src/main/java/javafx/embed/swt line 275 Javadoc: Unexpected tag FXCanvas.java Java Problem /swt/src/main/java/javafx/embed/swt line 275 Javadoc: Unexpected tag HugePolygonClipTest.java Java Problem /systemTests-test/java/test/com/sun/marlin line 68 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 51 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 61 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 75 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 83 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 91 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 99 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 116 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 129 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 147 Javadoc: Unexpected tag IosApplication.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 161 Javadoc: Unexpected tag IosClipboardDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 33 Javadoc: Unexpected tag IosImageLoader.java Java Problem /graphics/src/main/java/com/sun/javafx/iio/ios line 206 Javadoc: Unexpected tag IosImageLoader.java Java Problem /graphics/src/main/java/com/sun/javafx/iio/ios line 218 Javadoc: Unexpected tag IosImageLoaderFactory.java Java Problem /graphics/src/main/java/com/sun/javafx/iio/ios line 57 Javadoc: Unexpected tag IosImageLoaderFactory.java Java Problem /graphics/src/main/java/com/sun/javafx/iio/ios line 65 Javadoc: Unexpected tag IosMenuBarDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 39 Javadoc: Unexpected tag IosMenuBarDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 48 Javadoc: Unexpected tag IosMenuBarDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 57 Javadoc: Unexpected tag IosMenuBarDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 66 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 40 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 49 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 58 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 67 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 76 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 85 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 94 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 103 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 112 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 121 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 130 Javadoc: Unexpected tag IosMenuDelegate.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 139 Javadoc: Unexpected tag IosPlatformFactory.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 37 Javadoc: Unexpected tag IosPlatformFactory.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 45 Javadoc: Unexpected tag IosPlatformFactory.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 53 Javadoc: Unexpected tag IosPlatformFactory.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 61 Javadoc: Unexpected tag IosPlatformFactory.java Java Problem /graphics/src/main/java/com/sun/glass/ui/ios line 69 Javadoc: Unexpected tag Line2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 133 Javadoc: Unexpected tag Line2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 139 Javadoc: Unexpected tag Line2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 145 Javadoc: Unexpected tag Line2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 151 Javadoc: Unexpected tag ListViewSkin.java Java Problem /controls/src/main/java/javafx/scene/control/skin line 451 Javadoc: Unexpected tag LocalStorageAccessTest.java Java Problem /systemTests-test/java/test/com/sun/webkit line 40 Javadoc: Unexpected tag MainThreadTest.java Java Problem /systemTests-test/java/test/com/sun/webkit line 37 Javadoc: Unexpected tag PNTMeshVertexBufferLengthTest.java Java Problem /systemTests-test/java/test/com/sun/prism/impl line 62 Javadoc: Unexpected tag Path2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 1432 Javadoc: Unexpected tag Path2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 1473 Javadoc: Unexpected tag Path2DGrowTest.java Java Problem /graphics/src/test/java/test/com/sun/javafx/geom line 34 Javadoc: Unexpected tag Platform.java Java Problem /graphics/src/main/java/javafx/application line 108 Javadoc: Unexpected tag PseudoClassImpl.java Java Problem /graphics/src/main/java/com/sun/javafx/css line 39 Javadoc: Unexpected tag PulseReceiver.java Java Problem /graphics/src/main/java/com/sun/scenario/animation/shared line 42 Javadoc: Unexpected tag QPathTest.java Java Problem /systemTests-test/java/test/com/sun/marlin line 62 Javadoc: Unexpected tag QuadCurve2D.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 138 Javadoc: Unexpected tag Rectangle.java Java Problem /3DViewer/src/main/java/com/javafx/experiments/utils3d/geom line 661 Javadoc: Unexpected tag Rectangle.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 639 Javadoc: Unexpected tag RepeatStructConverter.java Java Problem /graphics/src/main/java/com/sun/javafx/scene/layout/region line 66 Javadoc: Unexpected tag ScaleX0Test.java Java Problem /systemTests-test/java/test/com/sun/marlin line 63 Javadoc: Unexpected tag Shape.java Java Problem /graphics/src/main/java/com/sun/javafx/geom line 982 Javadoc: Unexpected tag ShapeCacheTest.java Java Problem /systemTests-test/java/test/com/sun/prism/impl/ps line 58 Javadoc: Unexpected tag TableViewSkin.java Java Problem /controls/src/main/java/javafx/scene/control/skin line 205 Javadoc: Unexpected tag TestNodeBase.java Java Problem /graphics/src/test/java/test/com/sun/javafx/css line 253 Javadoc: Unexpected tag TreeTableViewSkin.java Java Problem /controls/src/main/java/javafx/scene/control/skin line 256 Javadoc: Unexpected tag TriangleMesh.java Java Problem /graphics/src/main/java/javafx/scene/shape line 854 Javadoc: Unexpected tag Window.java Java Problem /graphics/src/main/java/javafx/stage line 821 Javadoc: Unexpected text Node.java Java Problem /graphics/src/main/java/javafx/scene line 1175 Javadoc: Unexpected text Node.java Java Problem /graphics/src/main/java/javafx/scene line 1235 Javadoc: Unexpected text Node.java Java Problem /graphics/src/main/java/javafx/scene line 1275 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979398643 From kcr at openjdk.org Tue Mar 5 20:39:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 20:39:55 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 20:32:29 GMT, Kevin Rushforth wrote: > clean merge of `jfx:jfx22`. These are the last expected changes from jfx22 --> jfx22u. This pull request has now been integrated. Changeset: 01f27f5b Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/01f27f5ba6f08a690cb0179f0844c608ad5359e2 Stats: 587 lines in 42 files changed: 480 ins; 38 del; 69 mod Merge ------------- PR: https://git.openjdk.org/jfx22u/pull/17 From kcr at openjdk.org Tue Mar 5 20:39:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 20:39:53 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 Message-ID: clean merge of `jfx:jfx22`. These are the last expected changes from jfx22 --> jfx22u. ------------- Commit messages: - Merge - 8314147: Updated the PhongMaterial documentation - 8325550: Grammatical error in AnchorPane.setLeftAnchor (and other setters) javadoc The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/17/files Stats: 587 lines in 42 files changed: 480 ins; 38 del; 69 mod Patch: https://git.openjdk.org/jfx22u/pull/17.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/17/head:pull/17 PR: https://git.openjdk.org/jfx22u/pull/17 From kcr at openjdk.org Tue Mar 5 20:55:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 20:55:51 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 18:31:46 GMT, Andy Goryachev wrote: > Also worth noting that unfortunately, javadoc in Eclipse seems to work differently, resulting in 137 warnings: Odd. Most of these are due to the fact that Eclipse is running javadoc on all public classes, not just the ones that we export as public API. But filtering out all of the com.sun.* classes, Eclipse is still complaining about a few things in the publicly exported classes. I'd guess this to be an Eclipse problem, but we can discuss that in JDK-8324783. It's unrelated to this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979615497 From kcr at openjdk.org Tue Mar 5 20:55:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 20:55:52 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 18:22:44 GMT, Andy Goryachev wrote: > > turn off a single without turning off all errors (which is easy) > > yes, this is the exact scenario. I wouldn't expect this will be a frequent operation - but imagine javadoc team adds a new check that generates a lot of warnings, for example. For this case, I think seeing the warnings, but locally disabling the `-Werror` would be ideal, but I'll still check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-1979617824 From angorya at openjdk.org Tue Mar 5 21:04:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 21:04:01 GMT Subject: RFR: 8092102: Labeled: truncated property [v2] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > **See Also** > > * [JDK-8091891](https://bugs.openjdk.org/browse/JDK-8091891) TreeView: There is no tooltip available on truncated node > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8092102.truncated - 8092102 Labeled: truncated property ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/7cbd46c7..8a5cb17e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=00-01 Stats: 1319 lines in 36 files changed: 1172 ins; 79 del; 68 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Tue Mar 5 21:04:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 5 Mar 2024 21:04:01 GMT Subject: RFR: 8092102: Labeled: truncated property [v2] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 14:16:59 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8092102.truncated >> - 8092102 Labeled: truncated property > > modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 850: > >> 848: protected boolean computeValue() { >> 849: if (isWrapText()) { >> 850: return false; > > Are you sure that allowing text to wrap necessarily means it won't be truncated? What if the max height doesn't allow another line? Good point. So the label will have its text truncated (by inserting the ellipsis string) when wrapText is on and the size is constrained by setting maxHeight. Interestingly, it will not truncate the text (again, ellipsis string) if the label is resized by the layout: ![Screenshot 2024-03-05 at 12 54 14](https://github.com/openjdk/jfx/assets/107069028/1ae47317-2d54-4bcd-942d-1a49ff9faeab) Using the latest MonkeyTester to test https://github.com/andy-goryachev-oracle/MonkeyTest uncomment the listener in LabelPage ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1513493586 From andy.goryachev at oracle.com Tue Mar 5 21:15:48 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 5 Mar 2024 21:15:48 +0000 Subject: Q: Labeled.textTruncated Property (RFE) Message-ID: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Mar 5 21:49:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 21:49:50 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 14:55:58 GMT, Johan Vos wrote: > The failure on Linux has an interesting cause. The GlassSystemMenu (in com.sun.javafx.tk.quantum) has this code: > > ``` > /* > * Leave the Apple menu in place > */ > for (int index = existingSize - 1; index >= 0; index--) { > Menu menu = existingMenus.get(index); > clearMenu(menu); > glassSystemMenuBar.remove(index); > } > ``` > > As a consequence, the first menu is not cleared -- regardless of the presence of an apple or not. There are plenty quick and dirty ways to fix this, but this platform-specific check probably does not belong in this package. @kevinrushforth what do you prefer to do in cases like these? I missed responding to this. Presuming this really does need to be different on Mac than on other platforms, I guess the cleanest thing would be to move that logic to a method that can be overridden on Mac. If that's not feasible, then checking PlatformUtil.isMac() would be the other way. One question, though: Why does this prevent the first menu from being cleared? Unless I'm missing something, doesn't that loop cover the whole range of menus? And since Linux doesn't even implement system menus, I wonder why this code is active for Linux at all? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1979690977 From kcr at openjdk.org Tue Mar 5 22:21:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 5 Mar 2024 22:21:53 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v11] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 08:20:03 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Update modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java > > Co-authored-by: John Hendrikx Answering my own questions... The existing for loop quoted above actually loops while `>= 1` rather than `>= 0`: for (int index = existingSize - 1; index >= 1; index--) { so indeed the last menu would be held. And I think that the answer to my other question (why is this even being used on Linux) is that the `createAndRefocusMenuBarStage()` method in the newly added test is calling `GlassSystemMenuBar::createMenuBar` unconditionally (via the Shim), when the actual logic in WindowStage qualifies by whether or not system menu is supported (which it only is for Mac). So I think this is a test bug. I might recommend adding something like the following to the test: assumeTrue(glassSystemMenu.isSupported()); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1979732823 From mhanl at openjdk.org Tue Mar 5 23:37:18 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Mar 2024 23:37:18 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v6] In-Reply-To: References: Message-ID: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [ ] Adjust copyright > - [ ] Write Systemtest Marius Hanl has updated the pull request incrementally with four additional commits since the last revision: - test for multiple nested event loops - try leave outer loop after finishing inner loop - update copyright - trigger an outer nested event loop leave attempt ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/0bcda3a2..a63b5254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=04-05 Stats: 86 lines in 12 files changed: 71 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From mhanl at openjdk.org Tue Mar 5 23:39:49 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 5 Mar 2024 23:39:49 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v5] In-Reply-To: References: Message-ID: On Mon, 4 Mar 2024 19:16:06 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [ ] Adjust copyright >> - [ ] Write Systemtest > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > do not attempt to leave eventloop after leaving another eventloop I may found a solution which fixes the dialog bug and passes my test above. It behaves exactly like @beldenfox said. enter1 exit1 enter2 exit2 456 123 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1979817144 From kpk at openjdk.org Wed Mar 6 05:10:56 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 6 Mar 2024 05:10:56 GMT Subject: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v15] In-Reply-To: References: <-4NgfbTauFOOdBXBc2P3YwGEU2Lht0Vhl4iGqYXUau0=.f1dca7c4-d449-488a-bdb3-921620845c5a@github.com> Message-ID: On Tue, 5 Mar 2024 15:34:36 GMT, Andy Goryachev wrote: >>> P.S. Tested on on macOS 14.3.1. The results on Windows/Linux should be identical, but if we can get some testing done on these two platforms that would be nice. >> >> I tested the changes in windows and do not see any issues. >> I have executed the headful test using our headful test machines, no failures found in all platforms. >> >> Addressed inline comments. Please check. > > I would like to thank @karthikpandelu and @hjohn - this PR was a major effort and you guys finally solved the major issue in javafx RTL text. ?? Thank you @andy-goryachev-oracle for helping out in reviewing the PR in detail and thanks to @hjohn for suggesting simpler approach and providing the unit tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1980097536 From daniel.peintner at gmail.com Wed Mar 6 07:53:38 2024 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 6 Mar 2024 08:53:38 +0100 Subject: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev wrote: > Dear colleagues: > > > > Do you think a new property, *ReadOnlyBooleanProperty textTruncated*, > should be added to the Labeled control? > > > > > > On one hand, we do have a couple of tickets in JBS requesting that: > > > > - JDK-8091891 TreeView: > There is no tooltip available on truncated node > - JDK-8205211 Ability to > show Tooltip only when text is shown with ellipsis (...) > > > > On the other hand, this functionality can in theory be implemented at the > application level, although the number of changes required might be > uncomfortably large in the case of Tree/TreeTable/TableView. > > > > JBS: > > - JDK-8092102 Labeled: > truncated property > > > > Pull Request: https://github.com/openjdk/jfx/pull/1389 > > > > What do you think? > > > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Wed Mar 6 07:59:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Mar 2024 07:59:10 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v12] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Ignore test in case the underlying GlassSystemMenu is not supported. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/c2fb8b1b..037328ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=10-11 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Wed Mar 6 08:01:52 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Mar 2024 08:01:52 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v12] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 07:59:10 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Ignore test in case the underlying GlassSystemMenu is not supported. I think the logic in GlassSystemMenu should ultimately be platform-independent. Hence, moving the Apple-menu specific code to a Mac-specific class (in glass) sounds the right thing to do. However, it might be more pragmatic that we wait with this refactory until we have a second (or third) platform implementation. I can imagine there will need to be more changes if we deal with different linux window management systems. Hence, for now I agree having an `assumeTrue(glassSystemMenu.isSupported())` is the easiest solution (and not an incorrect one). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-1980284312 From jvos at openjdk.org Wed Mar 6 08:21:23 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Mar 2024 08:21:23 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v13] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Remove whiteline and language error ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/037328ff..e687a9ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Wed Mar 6 12:25:13 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Mar 2024 12:25:13 GMT Subject: [jfx17u] RFR: 8271398: GTK3 drag view image swaps red and blue color channels Message-ID: 8271398: GTK3 drag view image swaps red and blue color channels ------------- Commit messages: - Backport b2ecfacf0d8c9512d0b4cc13c1ac6c104a20f396 Changes: https://git.openjdk.org/jfx17u/pull/180/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271398 Stats: 112 lines in 2 files changed: 93 ins; 18 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/180.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/180/head:pull/180 PR: https://git.openjdk.org/jfx17u/pull/180 From jvos at openjdk.org Wed Mar 6 12:52:52 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 6 Mar 2024 12:52:52 GMT Subject: [jfx17u] Integrated: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: <5JPK20AbDeIQC-pC2ATIZNeU1TucZjndhqfjTflp90Y=.b26ea9c4-ef5f-4038-ad43-b732d0b2f672@github.com> On Wed, 6 Mar 2024 12:20:12 GMT, Johan Vos wrote: > 8271398: GTK3 drag view image swaps red and blue color channels This pull request has now been integrated. Changeset: af405910 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/af4059107850e8c3d974753add6e666f1dd52e33 Stats: 112 lines in 2 files changed: 93 ins; 18 del; 1 mod 8271398: GTK3 drag view image swaps red and blue color channels Backport-of: b2ecfacf0d8c9512d0b4cc13c1ac6c104a20f396 ------------- PR: https://git.openjdk.org/jfx17u/pull/180 From hmeda at openjdk.org Wed Mar 6 14:56:07 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 6 Mar 2024 14:56:07 GMT Subject: RFR: 8326989 : Text selection issues on WebView after WebKit 617.1 Message-ID: Text Selection issue is observed due to a pending layout call. This issue is resolved by a call to the method "updateSelectionAppearanceNow". Verified Sanity testing and unit test verification looks fine. No issue seen. Note: Unit test in order to validate the fix, is in progress. Due to the robustness of the implementation to verify on all platforms, the test would be added in a followon bug-[JDK-8327478](https://bugs.openjdk.org/browse/JDK-8327478) ------------- Commit messages: - Space correction - Resolve text selection issue Changes: https://git.openjdk.org/jfx/pull/1391/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326989 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1391.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1391/head:pull/1391 PR: https://git.openjdk.org/jfx/pull/1391 From kcr at openjdk.org Wed Mar 6 15:41:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Mar 2024 15:41:49 GMT Subject: RFR: 8326989 : Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: <7pLVxaHe1I1tuaqMj-2fMV8Ay804RGHYAv-I3VLWoHU=.8a42c34c-0499-4c87-957a-5e7ea99acad2@github.com> On Wed, 6 Mar 2024 14:51:40 GMT, Hima Bindu Meda wrote: > Text Selection issue is observed due to a pending layout call. This issue is resolved by a call to the method "updateSelectionAppearanceNow". > Verified Sanity testing and unit test verification looks fine. No issue seen. > > Note: Unit test in order to validate the fix, is in progress. Due to the robustness of the implementation to verify on all platforms, the test would be added in a followon bug-[JDK-8327478](https://bugs.openjdk.org/browse/JDK-8327478) @jperedadnr Can you also review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1391#issuecomment-1981161443 From kcr at openjdk.org Wed Mar 6 15:52:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 6 Mar 2024 15:52:53 GMT Subject: RFR: 8326989 : Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 14:51:40 GMT, Hima Bindu Meda wrote: > Text Selection issue is observed due to a pending layout call. This issue is resolved by a call to the method "updateSelectionAppearanceNow". > Verified Sanity testing and unit test verification looks fine. No issue seen. > > Note: Unit test in order to validate the fix, is in progress. Due to the robustness of the implementation to verify on all platforms, the test would be added in a followon bug-[JDK-8327478](https://bugs.openjdk.org/browse/JDK-8327478) Looks good. I confirm that this fixes the problem. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1391#pullrequestreview-1920137036 From lkostyra at openjdk.org Wed Mar 6 15:55:11 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 6 Mar 2024 15:55:11 GMT Subject: RFR: 8307980: Rotate Transformation never invalidates inverseCache Message-ID: Fixed as described in the issue + added tests to check for this scenario with all Transform sub classes. Since the test scenario slightly exceeding the regular parametrized testing of `TransformOperationsTest` I decided to implement the tests in a separate class. I didn't manage to reproduce the issue with other Transform sub classes, so it seems to only affect `Rotate`. Also checked by looking at the code, only `Rotate` was affected by this bug. As such, without 08ba284 only `testTransformInverseCache_Rotate` fails, while others succeed. With the fix, all tests pass. Ran the whole test suite afterwards and didn't notice any changes to test results after introducing the fix. ------------- Commit messages: - Rotate: Invalidade inverse cache when transform changes - Add transform inverse tests Changes: https://git.openjdk.org/jfx/pull/1392/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1392&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307980 Stats: 121 lines in 2 files changed: 121 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1392.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/jfx/pull/1392 From arapte at openjdk.org Wed Mar 6 16:16:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 6 Mar 2024 16:16:53 GMT Subject: RFR: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. providing few more comments tests/performance/3DLighting/src/main/java/lighting3D/Benchmark.java line 49: > 47: stopGraphic.setBoundsType(TextBoundsType.VISUAL); > 48: stopGraphic.setFill(Color.RED); > 49: stopGraphic.setFont(Font.font(20)); Play and Stop button could be same size. It would be good to look at. Currently the Stop button seems lesser than half size of play button. tests/performance/3DLighting/src/main/java/lighting3D/Benchmark.java line 81: > 79: > 80: var sphere = new Button("Sphere"); > 81: sphere.setOnAction(e -> switchTo(Models.createSphere(SPHERE_RADIUS, (int) subdivisionSlider.getValue()))); In `Models.createSphere()` method second argument is used for z distance, and not for subdivisions.. Increasing the slider value reduces the size of Sphere and vanishes at 510. tests/performance/3DLighting/src/main/java/lighting3D/Benchmark.java line 179: > 177: totalElapsedFrames = 0; > 178: System.out.println(); > 179: System.out.println(" --------------------- "); May be print a message in addition to this. tests/performance/3DLighting/src/main/java/lighting3D/CaptureUtils.java line 29: > 27: } > 28: > 29: private static final Path FOLDER = Path.of("screenshots"); suggestion: FOLDER -> SCREENSHOT_DIR or DIRECTORY Using word directory would align with Java io/nio naming. tests/performance/3DLighting/src/main/java/lighting3D/LightingApplication.java line 62: > 60: Node lightsControls = environment.createLightsControls(); > 61: > 62: var controls = new VBox(perfControls, modelsControls, backgroundControls, screenshotControls, Recommend to provide some spacing. 5 looked good. -> var controls = new VBox(**5**, perfControls, modelsControls, backgroundControls, screenshotControls, ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1387#pullrequestreview-1917586203 PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1513164981 PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1513182318 PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1513870834 PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1513876778 PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1514693071 From arapte at openjdk.org Wed Mar 6 16:34:50 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 6 Mar 2024 16:34:50 GMT Subject: RFR: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. An observation out of scope of this PR. The effect of lighting on mesh vs a box is quite different. Notice the screenshot, left side is a Box and right side is Mesh, both have Magenta SpotLight. I think the effect of light should be same on a 2D surface, and the effect on Box seems correct to me. Another observation: The effect of light on Mesh is different with 100 divisions than 200+ divisions. Screenshot 2024-03-06 at 3 36 09?PM ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-1981277266 From andy.goryachev at oracle.com Wed Mar 6 17:10:20 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 6 Mar 2024 17:10:20 +0000 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Dear Daniel: Thank you for confirming the need for this enhancement. Your case is covered by this ticket (I included a wrong ticket in my previous message by mistake, sorry): JDK-8327483 TreeView: Allow for tooltip when cell text is truncated My only concern is that this functionality theoretically can be achieved by the application code just as easy, since the solution does not use any internal APIs, as can be seen here: https://github.com/openjdk/jfx/pull/1389 -andy From: Daniel Peintner Date: Tuesday, March 5, 2024 at 23:53 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Wed Mar 6 17:26:51 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 6 Mar 2024 17:26:51 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v6] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 23:37:18 GMT, Marius Hanl wrote: >> This PR fixes the dialog freeze problem once and for all. >> >> This one is a bit tricky to understand, here is how it works: >> This bug happens on every platform, although the implementation of nested event loops differs on every platform. >> E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. >> >> Funny enough, the reason why this bug happens is always the same: Timing. >> >> 1. When we hide a dialog, `_leaveNestedEventLoop` is called. >> 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. >> 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. >> 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. >> >> So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. >> >> I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. >> There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). >> Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. >> >> Lets see if this is the right approach (for all platforms). >> Testing appreciated. >> # >> - [x] Tested on Windows >> - [x] Tested on Linux >> - [x] Tested on Mac >> - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) >> - [x] Adjust copyright >> - [x] Write Systemtest >> - [ ] Document the new behaviour - in general, there shoul be more information what to expect > > Marius Hanl has updated the pull request incrementally with four additional commits since the last revision: > > - test for multiple nested event loops > - try leave outer loop after finishing inner loop > - update copyright > - trigger an outer nested event loop leave attempt The Mac is still failing the NestedEventLoop test. At the top of InvokeLaterDispatcher.java there's a long explanation on how it's trying to coordinate with the event loop. To do this it needs to have an accurate picture of what's happening at the platform level. In this PR you're telling the dispatcher that an event loop has exited before the platform has actually exited the loop (before enterNestedEventLoop has returned). This is causing the dispatcher to send runLater runnables to the platform earlier than expected. On Windows the runnables will get deferred to the next event loop cycle but on Mac the runnables might get executed in the current event loop cycle. I think this is one of the "native system limitations" mentioned in the comment in InvokeLaterDispatcher.java. I've created a branch with my proposed fix for this problem (https://github.com/beldenfox/jfx/tree/eventloopjam). The fix prevents the dispatcher from jamming when the event loop it thought was leaving enters a new loop instead. Over in the Mac Glass code I also added a comment with a few more details on what's going on. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1981400654 From jhendrikx at openjdk.org Wed Mar 6 17:48:54 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 6 Mar 2024 17:48:54 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v10] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 08:55:41 GMT, Jose Pereda wrote: >> This could be a problem normally, but I think in this case you won't be able to get this to produce incorrect results. >> >> `parseText` is accessing the property (and it calls `isMnemonicParsing`), but only if the text is not empty. It's sort of "safe" as an empty text can't contain a mnemonic anyway, and you'd need to change the text at a minimum first to see the effect of turning mnemonic parsing on/off. Changing the text would trigger the `textProperty` listener, which will call `parseText` and read the mnemonic property. >> >> A change listener would be more obviously correct, but it is not strictly needed here. >> >> (not all `subscribe`s use change listener, the one that takes a `Runnable` uses invalidation) > > @hjohn There is an important issue using `when()`, because the listener is added to a new property, not to the original property. > > Therefore, using an invalidation listener doesn't trigger any more notifications if you are changing values more than once to the original property. > > This can happen in this SystemMenuBar case with the disabled property of any given `Menu` or `MenuItem`, if you simply change it twice or more times, while the application is active. You will notice that it will remain always with the same first state. > > It is hard to add a system test in this case because the public Menu/MenuItem and the private peers MenuBase/MenuBaseItem are in sync, and only the communication to the native part is missing. But it can be easily viewed if you run it manually. > > Let me clarify it with a very simple test, that reproduces the case of the disabledProperty: > > mb.disableProperty().when(active).addListener(valueModel -> glassMenu.setEnabled(!mb.isDisable())); > > > Simply run this manually: > > BooleanProperty b = new SimpleBooleanProperty(); > BooleanProperty active = new SimpleBooleanProperty(true); > > b.addListener(o -> System.out.println("b: " + b.get())); > b.when(active).addListener(o -> System.out.println("when: " + b.get())); > b.set(true); > b.set(false); > > > while you probably would be expecting: > > > b: true > when: true > b: false > when: false > > > the test prints: > > > b: true > when: true > b: false > > > so using `when()` we miss the changes after the first invalidation. > > I could go into details of why this happens, but just notice that we have a _new property_ after all, and if you are not calling `when.getValue()`, it doesn't get validated anymore after the first change. > > I see three possible fixes to this issue. > > 1. If you change the sample to: > > BooleanProperty b = new SimpleBooleanProperty(); > BooleanProperty active = new SimpleBooleanProperty(true); > > b.addListener(o -> System.out.println("b: " + b.get())); > ObservableValue c = b.when(active); > c.addListener(o -> System.out.println("when: " + c.getValue())); > b.set(true); > b.set(false); > > then you get the expected result: > > > b: true > when: true > b: false > when: false > > > 2. Since this change implies some more refactoring, that is why I suggested using the change listener instead: > > > BooleanProperty b = new SimpleBooleanProperty(); > BooleanProperty active = new SimpleBooleanProperty(true); > > b.addListener(... Thanks, you are right. The property generated by `when` is not getting revalidated, because its specific `getValue` is never called when using an invalidation listener on it. This seems to be a bit of pitfall that applies to all such mapped properties (not exclusive to `when`). I'm fine with any of the options. Option 3 certainly is the most convenient. I'm more wondering if there should be some action taken in for the `map`, `flatMap`, `when`, `orElse` constructs to make them work better with invalidation listeners, or if that's not possible, a note explaining that adding an invalidation listener to such a construct probably is not doing what you think it is doing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1514914613 From jpereda at openjdk.org Wed Mar 6 17:56:55 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 6 Mar 2024 17:56:55 GMT Subject: RFR: 8326989 : Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: <8mE0eT8TKeZMFGT5fNmb1BJcsP0DvUkEQBXfO3NpsBQ=.12921f0a-edb7-428f-890a-48e4e54153b1@github.com> On Wed, 6 Mar 2024 14:51:40 GMT, Hima Bindu Meda wrote: > Text Selection issue is observed due to a pending layout call. This issue is resolved by a call to the method "updateSelectionAppearanceNow". > Verified Sanity testing and unit test verification looks fine. No issue seen. > > Note: Unit test in order to validate the fix, is in progress. Due to the robustness of the implementation to verify on all platforms, the test would be added in a followon bug-[JDK-8327478](https://bugs.openjdk.org/browse/JDK-8327478) I've built and tested the proposed change successfully on macOS, Linux, and Windows, selecting text loaded from both URL or local html content, via mouse dragging and mouse double-clicking. ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1391#pullrequestreview-1920439949 From hmeda at openjdk.org Thu Mar 7 04:59:02 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 7 Mar 2024 04:59:02 GMT Subject: Integrated: 8326989 : Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 14:51:40 GMT, Hima Bindu Meda wrote: > Text Selection issue is observed due to a pending layout call. This issue is resolved by a call to the method "updateSelectionAppearanceNow". > Verified Sanity testing and unit test verification looks fine. No issue seen. > > Note: Unit test in order to validate the fix, is in progress. Due to the robustness of the implementation to verify on all platforms, the test would be added in a followon bug-[JDK-8327478](https://bugs.openjdk.org/browse/JDK-8327478) This pull request has now been integrated. Changeset: 64af9875 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/64af987576214fc5483520ce8131895be74a641d Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8326989: Text selection issues on WebView after WebKit 617.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, jpereda ------------- PR: https://git.openjdk.org/jfx/pull/1391 From mariushanl at web.de Thu Mar 7 08:21:02 2024 From: mariushanl at web.de (Marius Hanl) Date: Thu, 7 Mar 2024 09:21:02 +0100 Subject: Aw: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jvos at openjdk.org Thu Mar 7 11:19:22 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 11:19:22 GMT Subject: [jfx21u] RFR: 8318614: Update WebKit to 617.1 Message-ID: Hi all, This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. Thanks! ------------- Commit messages: - Backport ba79e081547b7f15697bfaaac42ec2de1971935a Changes: https://git.openjdk.org/jfx21u/pull/50/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=50&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318614 Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod Patch: https://git.openjdk.org/jfx21u/pull/50.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/50/head:pull/50 PR: https://git.openjdk.org/jfx21u/pull/50 From jvos at openjdk.org Thu Mar 7 11:32:20 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 11:32:20 GMT Subject: [jfx17u] RFR: 8318387: Update GStreamer to 1.22.6 Message-ID: Almost clean backport of JDK-8318386. The original patch contains a fix to gstaacparse.c which is not in jfx17u because it does not have JDK-8277309 (JDK-8277309) ------------- Commit messages: - Backport 606878af275dbad551a10653c92a2deef61c10cd Changes: https://git.openjdk.org/jfx17u/pull/181/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=181&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318387 Stats: 45630 lines in 437 files changed: 19420 ins; 18926 del; 7284 mod Patch: https://git.openjdk.org/jfx17u/pull/181.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/181/head:pull/181 PR: https://git.openjdk.org/jfx17u/pull/181 From jvos at openjdk.org Thu Mar 7 11:34:58 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 11:34:58 GMT Subject: [jfx21u] Integrated: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 16:46:28 GMT, Johan Vos wrote: > 8327177: macOS: wrong GlobalRef deleted in GlassMenu This pull request has now been integrated. Changeset: 98293abf Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/98293abf8e9aa5db28d776c0391b46d1bf0951af Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8327177: macOS: wrong GlobalRef deleted in GlassMenu Backport-of: 8114559ed666fe272d238cdf1e531e5d8ec22226 ------------- PR: https://git.openjdk.org/jfx21u/pull/49 From jvos at openjdk.org Thu Mar 7 11:47:53 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 11:47:53 GMT Subject: [jfx17u] RFR: 8318614: Update WebKit to 617.1 Message-ID: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> Hi all, This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. Thanks! ------------- Commit messages: - Backport ba79e081547b7f15697bfaaac42ec2de1971935a Changes: https://git.openjdk.org/jfx17u/pull/182/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318614 Stats: 289458 lines in 6439 files changed: 170410 ins; 83308 del; 35740 mod Patch: https://git.openjdk.org/jfx17u/pull/182.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/182/head:pull/182 PR: https://git.openjdk.org/jfx17u/pull/182 From lkostyra at openjdk.org Thu Mar 7 11:47:10 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 7 Mar 2024 11:47:10 GMT Subject: RFR: 8307980: Rotate Transformation never invalidates inverseCache [v2] In-Reply-To: References: Message-ID: > Fixed as described in the issue + added tests to check for this scenario with all Transform sub classes. Since the test scenario slightly exceeding the regular parametrized testing of `TransformOperationsTest` I decided to implement the tests in a separate class. > > I didn't manage to reproduce the issue with other Transform sub classes, so it seems to only affect `Rotate`. Also checked by looking at the code, only `Rotate` was affected by this bug. As such, without 08ba284 only `testTransformInverseCache_Rotate` fails, while others succeed. With the fix, all tests pass. > > Ran the whole test suite afterwards and didn't notice any changes to test results after introducing the fix. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary imports from test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1392/files - new: https://git.openjdk.org/jfx/pull/1392/files/08ba2848..cd8fdde8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1392&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1392&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1392.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/jfx/pull/1392 From hmeda at openjdk.org Thu Mar 7 12:47:09 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 7 Mar 2024 12:47:09 GMT Subject: [jfx22u] RFR: 8326989: Text selection issues on WebView after WebKit 617.1 Message-ID: Clean Backport ------------- Commit messages: - Backport 64af987576214fc5483520ce8131895be74a641d Changes: https://git.openjdk.org/jfx22u/pull/18/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=18&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326989 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx22u/pull/18.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/18/head:pull/18 PR: https://git.openjdk.org/jfx22u/pull/18 From hmeda at openjdk.org Thu Mar 7 12:50:59 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 7 Mar 2024 12:50:59 GMT Subject: [jfx22u] Integrated: 8326989: Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 12:43:17 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: 419bad3a Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/419bad3a4053abe215329a5228789f2c876ab287 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8326989: Text selection issues on WebView after WebKit 617.1 Backport-of: 64af987576214fc5483520ce8131895be74a641d ------------- PR: https://git.openjdk.org/jfx22u/pull/18 From jvos at openjdk.org Thu Mar 7 13:23:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 13:23:07 GMT Subject: [jfx17u] Integrated: 8282386: JavaFX media stubs rely on libav.org Message-ID: 8282386: JavaFX media stubs rely on libav.org ------------- Commit messages: - Backport 357cd8563bd6ca47afd28dd1481afbe2d2458827 Changes: https://git.openjdk.org/jfx17u/pull/183/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282386 Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/183.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/183/head:pull/183 PR: https://git.openjdk.org/jfx17u/pull/183 From jvos at openjdk.org Thu Mar 7 13:23:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 13:23:07 GMT Subject: [jfx17u] Integrated: 8282386: JavaFX media stubs rely on libav.org In-Reply-To: References: Message-ID: <4G6i7cMrk2v5CFB-U7BimbjLY6fSChfB4_CdICCYtww=.7d4ce364-63f0-4cc3-80aa-f8b9b90b0f4b@github.com> On Thu, 7 Mar 2024 13:17:00 GMT, Johan Vos wrote: > 8282386: JavaFX media stubs rely on libav.org This pull request has now been integrated. Changeset: 9ac6fa52 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/9ac6fa5295af8e157c6d1ee8a75393731a426ee4 Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod 8282386: JavaFX media stubs rely on libav.org Backport-of: 357cd8563bd6ca47afd28dd1481afbe2d2458827 ------------- PR: https://git.openjdk.org/jfx17u/pull/183 From jvos at openjdk.org Thu Mar 7 13:30:47 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 13:30:47 GMT Subject: [jfx17u] RFR: 8318614: Update WebKit to 617.1 [v2] In-Reply-To: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> References: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> Message-ID: > Hi all, > > This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. > > Thanks! Johan Vos 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 two additional commits since the last revision: - Merge branch 'openjdk:master' into backport-johanvos-ba79e081 - Backport ba79e081547b7f15697bfaaac42ec2de1971935a ------------- Changes: - all: https://git.openjdk.org/jfx17u/pull/182/files - new: https://git.openjdk.org/jfx17u/pull/182/files/d97b8977..7ddc603e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx17u&pr=182&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx17u&pr=182&range=00-01 Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/182.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/182/head:pull/182 PR: https://git.openjdk.org/jfx17u/pull/182 From kcr at openjdk.org Thu Mar 7 13:33:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 7 Mar 2024 13:33:58 GMT Subject: [jfx22u] RFR: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 16:44:55 GMT, Johan Vos wrote: > 8327177: macOS: wrong GlobalRef deleted in GlassMenu This is ready to integrate. ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/16#issuecomment-1983514644 From jvos at openjdk.org Thu Mar 7 14:13:18 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 14:13:18 GMT Subject: [jfx17u] RFR: 8318387: Update GStreamer to 1.22.6 [v2] In-Reply-To: References: Message-ID: > Almost clean backport of JDK-8318386. > The original patch contains a fix to gstaacparse.c which is not in jfx17u because it does not have JDK-8277309 (JDK-8277309) Johan Vos 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 two additional commits since the last revision: - Merge branch 'openjdk:master' into backport-johanvos-606878af - Backport 606878af275dbad551a10653c92a2deef61c10cd ------------- Changes: - all: https://git.openjdk.org/jfx17u/pull/181/files - new: https://git.openjdk.org/jfx17u/pull/181/files/308fef0c..14193a97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx17u&pr=181&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx17u&pr=181&range=00-01 Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/181.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/181/head:pull/181 PR: https://git.openjdk.org/jfx17u/pull/181 From jvos at openjdk.org Thu Mar 7 14:06:59 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 7 Mar 2024 14:06:59 GMT Subject: [jfx22u] Integrated: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 16:44:55 GMT, Johan Vos wrote: > 8327177: macOS: wrong GlobalRef deleted in GlassMenu This pull request has now been integrated. Changeset: d70fa5f1 Author: Johan Vos URL: https://git.openjdk.org/jfx22u/commit/d70fa5f160c5a90f4c704ad514921d5421291bbf Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8327177: macOS: wrong GlobalRef deleted in GlassMenu Backport-of: 8114559ed666fe272d238cdf1e531e5d8ec22226 ------------- PR: https://git.openjdk.org/jfx22u/pull/16 From sykora at openjdk.org Thu Mar 7 14:40:06 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 7 Mar 2024 14:40:06 GMT Subject: [jfx17u] RFR: 8318614: Update WebKit to 617.1 [v2] In-Reply-To: References: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> Message-ID: On Thu, 7 Mar 2024 13:30:47 GMT, Johan Vos wrote: >> Hi all, >> >> This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. >> >> The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. >> >> Thanks! > > Johan Vos 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into backport-johanvos-ba79e081 > - Backport ba79e081547b7f15697bfaaac42ec2de1971935a Build and tests succeeded. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx17u/pull/182#pullrequestreview-1922613531 From daniel.peintner at gmail.com Thu Mar 7 15:07:32 2024 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 7 Mar 2024 16:07:32 +0100 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Andy, all, Some comments below: 1. Even if it is possible to do the same with public means I think it is useful. Anyhow we need to promote the solutions better (e.g., on StackOverflow) 2. I tried to achieve what you did in JavaFX core for my use-case, TableView cells. 1. In my real application I tried and failed since the boolean condition in https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 always reports false 2. Hence I tried to create a short self-contained TableView example to explore it further, see Gist https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf It still fails :-( 3. The Email field in the table ideally should report "true" once the text entered exceeds the visible view. Somehow it fails... getWidth() and prefWidth(-1) always return the same double value. Please try the Gist above to confirm. e.g., edit cell and extend the email text to longer than column width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < 182.0 --> false" 4. Hence I also added a *normal* MyLabel example which does work as intended Maybe I miss something obvious but TableCells seem to be special Labeled instances and behave differently. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev wrote: > Dear Daniel: > > > > Thank you for confirming the need for this enhancement. Your case is > covered by this ticket (I included a wrong ticket in my previous message by > mistake, sorry): > > > > JDK-8327483 TreeView: Allow > for tooltip when cell text is truncated > > > > My only concern is that this functionality theoretically can be achieved > by the application code just as easy, since the solution does not use any > internal APIs, as can be seen here: > https://github.com/openjdk/jfx/pull/1389 > > > > > -andy > > > > > > *From: *Daniel Peintner > *Date: *Tuesday, March 5, 2024 at 23:53 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: Q: Labeled.textTruncated Property (RFE) > > Hi Andy, all, > > > > Thank you for the effort which I very much appreciate. > > We have a similar use-case as the one mentioned in JDK-8205211. > > > > We would like to show a Tooltip with the corresponding text once the text > is shown with ellipsis for a TableCell. The *hacky* solution we are using > is sketched in [1] and requires us to calculate the width again. Moreover, > once different fonts come into the game it becomes even more brittle. > > > > Having an easy (easier?) way to detect and observe whether a label is > truncated is of importance for us and definitely improves the usability of > JavaFX. > > > > Thanks, > > > > -- Daniel > > > > [1] https://stackoverflow.com/a/52432862 > > > > > On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: > > Dear colleagues: > > > > Do you think a new property, *ReadOnlyBooleanProperty textTruncated*, > should be added to the Labeled control? > > > > > > On one hand, we do have a couple of tickets in JBS requesting that: > > > > - JDK-8091891 TreeView: > There is no tooltip available on truncated node > - JDK-8205211 Ability to > show Tooltip only when text is shown with ellipsis (...) > > > > On the other hand, this functionality can in theory be implemented at the > application level, although the number of changes required might be > uncomfortably large in the case of Tree/TreeTable/TableView. > > > > JBS: > > - JDK-8092102 Labeled: > truncated property > > > > Pull Request: https://github.com/openjdk/jfx/pull/1389 > > > > > What do you think? > > > > -andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sykora at openjdk.org Thu Mar 7 16:33:59 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 7 Mar 2024 16:33:59 GMT Subject: [jfx17u] RFR: 8318387: Update GStreamer to 1.22.6 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 14:13:18 GMT, Johan Vos wrote: >> Almost clean backport of JDK-8318386. >> The original patch contains a fix to gstaacparse.c which is not in jfx17u because it does not have JDK-8277309 (JDK-8277309) > > Johan Vos 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into backport-johanvos-606878af > - Backport 606878af275dbad551a10653c92a2deef61c10cd Build and tests succeeded. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx17u/pull/181#pullrequestreview-1922961943 From mariushanl at web.de Thu Mar 7 18:51:28 2024 From: mariushanl at web.de (Marius Hanl) Date: Thu, 7 Mar 2024 19:51:28 +0100 Subject: Aw: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Mar 7 18:53:49 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Mar 2024 18:53:49 +0000 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Daniel: Thank you for providing a sample app! You are right: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. Cheers, -andy From: Daniel Peintner Date: Thursday, March 7, 2024 at 07:11 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) Andy, all, Some comments below: 1. Even if it is possible to do the same with public means I think it is useful. Anyhow we need to promote the solutions better (e.g., on StackOverflow) 2. I tried to achieve what you did in JavaFX core for my use-case, TableView cells. * In my real application I tried and failed since the boolean condition in https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 always reports false * Hence I tried to create a short self-contained TableView example to explore it further, see Gist https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf It still fails :-( * The Email field in the table ideally should report "true" once the text entered exceeds the visible view. Somehow it fails... getWidth() and prefWidth(-1) always return the same double value. Please try the Gist above to confirm. e.g., edit cell and extend the email text to longer than column width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < 182.0 --> false" * Hence I also added a *normal* MyLabel example which does work as intended Maybe I miss something obvious but TableCells seem to be special Labeled instances and behave differently. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev > wrote: Dear Daniel: Thank you for confirming the need for this enhancement. Your case is covered by this ticket (I included a wrong ticket in my previous message by mistake, sorry): JDK-8327483 TreeView: Allow for tooltip when cell text is truncated My only concern is that this functionality theoretically can be achieved by the application code just as easy, since the solution does not use any internal APIs, as can be seen here: https://github.com/openjdk/jfx/pull/1389 -andy From: Daniel Peintner > Date: Tuesday, March 5, 2024 at 23:53 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Mar 7 18:55:52 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 7 Mar 2024 18:55:52 +0000 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Marius, got your email literally before I could hit "Send" on mine! You are right, of course, thank you for the effort. -andy From: Marius Hanl Date: Thursday, March 7, 2024 at 10:51 To: Daniel Peintner Cc: Andy Goryachev , openjfx-dev at openjdk.org Subject: Aw: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) The width of TableCells are bound to the column they belong to. Therefore, prefWidth(-1) will always return the width of the column and not what the cell should ideally have. See the computePrefWidth() method inside TableCellSkinBase. There is a flag which unfortunately can not be set: isDeferToParentForPrefWidth, which will enable the cell to not take the column width but the real preferred width. -- Marius Gesendet: Donnerstag, 07. M?rz 2024 um 16:07 Uhr Von: "Daniel Peintner" An: "Andy Goryachev" Cc: "openjfx-dev at openjdk.org" Betreff: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) Andy, all, Some comments below: 1. Even if it is possible to do the same with public means I think it is useful. Anyhow we need to promote the solutions better (e.g., on StackOverflow) 2. I tried to achieve what you did in JavaFX core for my use-case, TableView cells. * In my real application I tried and failed since the boolean condition in https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 always reports false * Hence I tried to create a short self-contained TableView example to explore it further, see Gist https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf It still fails :-( * The Email field in the table ideally should report "true" once the text entered exceeds the visible view. Somehow it fails... getWidth() and prefWidth(-1) always return the same double value. Please try the Gist above to confirm. e.g., edit cell and extend the email text to longer than column width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < 182.0 --> false" * Hence I also added a *normal* MyLabel example which does work as intended Maybe I miss something obvious but TableCells seem to be special Labeled instances and behave differently. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev > wrote: Dear Daniel: Thank you for confirming the need for this enhancement. Your case is covered by this ticket (I included a wrong ticket in my previous message by mistake, sorry): JDK-8327483 TreeView: Allow for tooltip when cell text is truncated My only concern is that this functionality theoretically can be achieved by the application code just as easy, since the solution does not use any internal APIs, as can be seen here: https://github.com/openjdk/jfx/pull/1389 -andy From: Daniel Peintner > Date: Tuesday, March 5, 2024 at 23:53 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Mar 7 19:03:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Mar 2024 19:03:31 GMT Subject: RFR: 8092102: Labeled: truncated property [v3] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > **See Also** > > * [JDK-8091891](https://bugs.openjdk.org/browse/JDK-8091891) TreeView: There is no tooltip available on truncated node > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) 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: - handle tree/table view cells - Merge remote-tracking branch 'origin/master' into 8092102.truncated - review comments - Merge remote-tracking branch 'origin/master' into 8092102.truncated - 8092102 Labeled: truncated property ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/8a5cb17e..72f170b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=01-02 Stats: 85 lines in 5 files changed: 72 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Thu Mar 7 19:37:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 7 Mar 2024 19:37:28 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v11] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - Merge remote-tracking branch 'origin/master' into 8299753.resize - undo merge - no new api - Merge remote-tracking branch 'origin/master' into 8299753.resize - ... and 20 more: https://git.openjdk.org/jfx/compare/00a51dbd...4071e2f6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/48a1bb5d..4071e2f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=09-10 Stats: 1505 lines in 101 files changed: 1289 ins; 75 del; 141 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From almatvee at openjdk.org Thu Mar 7 20:59:56 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Mar 2024 20:59:56 GMT Subject: [jfx17u] RFR: 8318387: Update GStreamer to 1.22.6 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 14:13:18 GMT, Johan Vos wrote: >> Almost clean backport of JDK-8318386. >> The original patch contains a fix to gstaacparse.c which is not in jfx17u because it does not have JDK-8277309 (JDK-8277309) > > Johan Vos 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into backport-johanvos-606878af > - Backport 606878af275dbad551a10653c92a2deef61c10cd Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jfx17u/pull/181#pullrequestreview-1923519946 From mhanl at openjdk.org Thu Mar 7 21:54:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 7 Mar 2024 21:54:58 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v6] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 17:24:10 GMT, Martin Fox wrote: > The Mac is still failing the NestedEventLoop test. Thanks for testing this on Mac. I always need to ask someone in order to test the changes, so really appreciating that. > I've created a branch with my proposed fix for this problem (https://github.com/beldenfox/jfx/tree/eventloopjam). The fix prevents the dispatcher from jamming when the event loop it thought was leaving enters a new loop instead. Over in the Mac Glass code I also added a comment with a few more details on what's going on. I tested your code and it looks good! So this seems to be the better approach here. While mine works for Windows and maybe Linux, it does not for Mac as you also specified. The return value of the native nested event loops are still not needed, so we can still think about keeping this change, but we should probably revert the EventLoop changes and take your fix instead. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1984564786 From mhanl at openjdk.org Thu Mar 7 22:32:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 7 Mar 2024 22:32:13 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v7] In-Reply-To: References: Message-ID: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [x] Adjust copyright > - [x] Write Systemtest > - [ ] Document the new behaviour - in general, there shoul be more information what to expect Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Integrate changes as outline by beldenfox ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1324/files - new: https://git.openjdk.org/jfx/pull/1324/files/a63b5254..bba7fc23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=05-06 Stats: 58 lines in 8 files changed: 39 ins; 13 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324 From mhanl at openjdk.org Thu Mar 7 22:44:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 7 Mar 2024 22:44:58 GMT Subject: RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v6] In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 17:24:10 GMT, Martin Fox wrote: >> Marius Hanl has updated the pull request incrementally with four additional commits since the last revision: >> >> - test for multiple nested event loops >> - try leave outer loop after finishing inner loop >> - update copyright >> - trigger an outer nested event loop leave attempt > > The Mac is still failing the NestedEventLoop test. > > At the top of InvokeLaterDispatcher.java there's a long explanation on how it's trying to coordinate with the event loop. To do this it needs to have an accurate picture of what's happening at the platform level. In this PR you're telling the dispatcher that an event loop has exited before the platform has actually exited the loop (before enterNestedEventLoop has returned). This is causing the dispatcher to send runLater runnables to the platform earlier than expected. On Windows the runnables will get deferred to the next event loop cycle but on Mac the runnables might get executed in the current event loop cycle. I think this is one of the "native system limitations" mentioned in the comment in InvokeLaterDispatcher.java. > > I've created a branch with my proposed fix for this problem (https://github.com/beldenfox/jfx/tree/eventloopjam). The fix prevents the dispatcher from jamming when the event loop it thought was leaving enters a new loop instead. Over in the Mac Glass code I also added a comment with a few more details on what's going on. Thanks! I feel like we are coming closer to the fix of this problem. I hopefully have time to test this much more tomorrow - I have at least "booked" myself a time slot for JavaFX. ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1984685350 From mariushanl at web.de Thu Mar 7 22:57:31 2024 From: mariushanl at web.de (Marius Hanl) Date: Thu, 7 Mar 2024 23:57:31 +0100 Subject: Aw: Validation Support In-Reply-To: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Thu Mar 7 23:30:50 2024 From: mariushanl at web.de (Marius Hanl) Date: Fri, 8 Mar 2024 00:30:50 +0100 Subject: Aw: Proposal: RichTextArea Control (Incubator) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Thu Mar 7 23:40:26 2024 From: mariushanl at web.de (Marius Hanl) Date: Fri, 8 Mar 2024 00:40:26 +0100 Subject: Aw: Re: Validation Support In-Reply-To: <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From john at status6.com Fri Mar 8 01:49:53 2024 From: john at status6.com (John Neffenger) Date: Thu, 7 Mar 2024 17:49:53 -0800 Subject: Aw: Re: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: On 3/7/24 3:40 PM, Marius Hanl wrote: > This design is mostly superior than e.g. Swing, where you can override > things and easily break something if not too careful. > Pretty sure that this were some lessons learned from the development > of Swing. That's what I remember, too, but I can't find any sources for it online, so maybe I'm just imagining things. ? Rather than subclasses breaking things, though, I remember reading that the decision to allow the Swing classes to be so extensible had made it difficult for Oracle to maintain and enhance Swing itself. The JavaFX developers decided early on not to repeat that mistake. Do I remember correctly? Does anyone have links or even first-hand knowledge? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.lichtenberger at gmail.com Fri Mar 8 06:37:11 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Fri, 8 Mar 2024 07:37:11 +0100 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: <279195d1-2e87-4096-ab0d-959bf6539edd@gmail.com> Am 08.03.24 um 00:40 schrieb Marius Hanl: > One note here regarding that a lot of things are final in JavaFX: > The problem is not that everything is final - this is intended and > makes sense, since we speak mostly of properties here. Overriding > those will not give you any benefit. > You mostly want to override e.g. Controls if you add something new to > it (a new property) or may just want to set another default skin. > This design is mostly superior than e.g. Swing, where you can override > things and easily break something if not too careful. > Pretty sure that this were some lessons learned from the development > of Swing. > The biggest problem is rather that a lot of methods are package > private or 'Accessors' are used to call specific methods, which is not > just a questionable design but also restrict the usage. > It is often not possible to override even a minor feature inside the skin. > So you may rather want to recreate the skin then, and copy the > existing skin and just change some stuff. But this will mostly not > work either, as there is a lot of internal API usage, e.g. Accessors > or some?com.sun.javafx.scene.control.skin.Utils usage. Yes, I had such a problem yesterday. TableView uses + as shortcut to toggle selection of current row. I want to use that key combination as a "global" shortcut however. I have a regular menu bar with a menu item that has + as accelerator. Now I need to remove that bit from the TableView's behavior. I've seen that there are efforts under way to make behavior public API. I would really welcome that :-). BTW, https://bugs.openjdk.org/browse/JDK-8088068 is also an issue concerning accelerators that I currently need a separate class as workaround. Other issues that I currently work around somehow (inconvenient, but no showstopper): JDK-8092315, JDK-8087981, maybe also JDK-8123117, but I think that on is correctly closed as? "not an issue", will have to check. To put this into perspective, we have a lot more references to JavaFX issues in our code, which have all been fixed :-). One major pain point that we have at the moment is CSS performance, I think (but did not investigate yet) that some kind of performance regression happened somewhere between 17 and 21. Overall speaking, with the ongoing efforts for a RichText-control and making behavior public API, I think JavaFX is definitely on the right track, at least from my perspective :-). --Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.peintner at gmail.com Fri Mar 8 08:29:59 2024 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 8 Mar 2024 09:29:59 +0100 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Andy, Marius, all, Thank you for your input and your insights. If I understand correctly we cannot purely do it with public methods for now (at least not for TableCells) This makes the argument to support https://github.com/openjdk/jfx/pull/1389 even stronger and maybe should be mentioned in the PR as well. Thanks, -- Daniel On Thu, Mar 7, 2024 at 7:53?PM Andy Goryachev wrote: > Daniel: > > > > Thank you for providing a sample app! > > > > You are right: turns out Labeled in a TableView (in a TreeTableView as > well) lives by different rules (TableCellSkinBase:152, > TreeTableCellSkin:126). > > > > The consequence of this is that the new functionality **cannot** be fully > implemented with the public APIs alone. > > > > Cheers, > > -andy > > > > > > > > *From: *Daniel Peintner > *Date: *Thursday, March 7, 2024 at 07:11 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) > > Andy, all, > > Some comments below: > > 1. Even if it is possible to do the same with public means I think it > is useful. Anyhow we need to promote the solutions better (e.g., on > StackOverflow) > 2. I tried to achieve what you did in JavaFX core for my use-case, > TableView cells. > > > 1. In my real application I tried and failed since the boolean > condition in > https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 > > always reports false > 2. Hence I tried to create a short self-contained TableView example > to explore it further, see Gist > https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf > > It still fails :-( > 3. The Email field in the table ideally should report "true" once > the text entered exceeds the visible view. Somehow it fails... getWidth() > and prefWidth(-1) always return the same double value. Please try the Gist > above to confirm. > e.g., edit cell and extend the email text to longer than column > width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < > 182.0 --> false" > 4. Hence I also added a *normal* MyLabel example which does work as > intended > > Maybe I miss something obvious but TableCells seem to be special Labeled > instances and behave differently. > > > > Thanks, > > > > -- Daniel > > > > [1] https://stackoverflow.com/a/52432862 > > > > > > > On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev > wrote: > > Dear Daniel: > > > > Thank you for confirming the need for this enhancement. Your case is > covered by this ticket (I included a wrong ticket in my previous message by > mistake, sorry): > > > > JDK-8327483 TreeView: Allow > for tooltip when cell text is truncated > > > > My only concern is that this functionality theoretically can be achieved > by the application code just as easy, since the solution does not use any > internal APIs, as can be seen here: > https://github.com/openjdk/jfx/pull/1389 > > > > > -andy > > > > > > *From: *Daniel Peintner > *Date: *Tuesday, March 5, 2024 at 23:53 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: Q: Labeled.textTruncated Property (RFE) > > Hi Andy, all, > > > > Thank you for the effort which I very much appreciate. > > We have a similar use-case as the one mentioned in JDK-8205211. > > > > We would like to show a Tooltip with the corresponding text once the text > is shown with ellipsis for a TableCell. The *hacky* solution we are using > is sketched in [1] and requires us to calculate the width again. Moreover, > once different fonts come into the game it becomes even more brittle. > > > > Having an easy (easier?) way to detect and observe whether a label is > truncated is of importance for us and definitely improves the usability of > JavaFX. > > > > Thanks, > > > > -- Daniel > > > > [1] https://stackoverflow.com/a/52432862 > > > > > On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: > > Dear colleagues: > > > > Do you think a new property, *ReadOnlyBooleanProperty textTruncated*, > should be added to the Labeled control? > > > > > > On one hand, we do have a couple of tickets in JBS requesting that: > > > > - JDK-8091891 TreeView: > There is no tooltip available on truncated node > - JDK-8205211 Ability to > show Tooltip only when text is shown with ellipsis (...) > > > > On the other hand, this functionality can in theory be implemented at the > application level, although the number of changes required might be > uncomfortably large in the case of Tree/TreeTable/TableView. > > > > JBS: > > - JDK-8092102 Labeled: > truncated property > > > > Pull Request: https://github.com/openjdk/jfx/pull/1389 > > > > > What do you think? > > > > -andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Fri Mar 8 08:42:03 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 08:42:03 GMT Subject: [jfx21u] Integrated: 8318614: Update WebKit to 617.1 In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 11:03:42 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: 5f1286f9 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/5f1286f9ff56aeb9af43328acda5c06459839c01 Stats: 289254 lines in 6439 files changed: 170206 ins; 83308 del; 35740 mod 8318614: Update WebKit to 617.1 Backport-of: ba79e081547b7f15697bfaaac42ec2de1971935a ------------- PR: https://git.openjdk.org/jfx21u/pull/50 From jvos at openjdk.org Fri Mar 8 09:16:06 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:16:06 GMT Subject: [jfx17u] Integrated: 8318614: Update WebKit to 617.1 In-Reply-To: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> References: <7_91tFhWQQoXqpcXXx0AJvP9iK-LcdP_uV2AukdbiLE=.7feaab47-9515-4f96-a47a-81b4d4795062@github.com> Message-ID: <5LuMN27C6Qdb9fuzY5W6_PGMKHs1ynx0q6QzcpaPyII=.f5d25f6c-b0f2-4f8a-bf7e-16a53a0cf6d4@github.com> On Thu, 7 Mar 2024 11:32:29 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [ba79e081](https://github.com/openjdk/jfx/commit/ba79e081547b7f15697bfaaac42ec2de1971935a) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 16 Jan 2024 and was reviewed by Joeri Sykora and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: ee0770c7 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/ee0770c7f986893e412bd50ffbd828fc0477c37c Stats: 289458 lines in 6439 files changed: 170410 ins; 83308 del; 35740 mod 8318614: Update WebKit to 617.1 Reviewed-by: sykora Backport-of: ba79e081547b7f15697bfaaac42ec2de1971935a ------------- PR: https://git.openjdk.org/jfx17u/pull/182 From jvos at openjdk.org Fri Mar 8 09:17:04 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:17:04 GMT Subject: [jfx17u] Integrated: 8318387: Update GStreamer to 1.22.6 In-Reply-To: References: Message-ID: <2q_g3OTZhYEe4L6XIF7cz75y31pYi0a8v6uzyLuP4nk=.5c78e128-4c68-427b-a85d-94fc1212a5af@github.com> On Thu, 7 Mar 2024 11:28:01 GMT, Johan Vos wrote: > Almost clean backport of JDK-8318386. > The original patch contains a fix to gstaacparse.c which is not in jfx17u because it does not have JDK-8277309 (JDK-8277309) This pull request has now been integrated. Changeset: 34922457 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/3492245782ebb117b02ceff2e4d1008a888af981 Stats: 45630 lines in 437 files changed: 19420 ins; 18926 del; 7284 mod 8318387: Update GStreamer to 1.22.6 8318386: Update Glib to 2.78.1 Reviewed-by: sykora, almatvee Backport-of: 606878af275dbad551a10653c92a2deef61c10cd ------------- PR: https://git.openjdk.org/jfx17u/pull/181 From jvos at openjdk.org Fri Mar 8 09:18:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:18:09 GMT Subject: [jfx17u] Integrated: 8327177: macOS: wrong GlobalRef deleted in GlassMenu In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 09:09:37 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 8114559e from the openjdk/jfx repository. > > The commit being backported was authored by Johan Vos on 4 Mar 2024 and was reviewed by Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: da5918ff Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/da5918fffe5e24457b159b9f714af2dce1e5d734 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8327177: macOS: wrong GlobalRef deleted in GlassMenu Backport-of: 8114559ed666fe272d238cdf1e531e5d8ec22226 ------------- PR: https://git.openjdk.org/jfx17u/pull/184 From jvos at openjdk.org Fri Mar 8 09:18:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:18:09 GMT Subject: [jfx17u] Integrated: 8327177: macOS: wrong GlobalRef deleted in GlassMenu Message-ID: Hi all, This pull request contains a backport of commit 8114559e from the openjdk/jfx repository. The commit being backported was authored by Johan Vos on 4 Mar 2024 and was reviewed by Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 8114559ed666fe272d238cdf1e531e5d8ec22226 Changes: https://git.openjdk.org/jfx17u/pull/184/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327177 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/184.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/184/head:pull/184 PR: https://git.openjdk.org/jfx17u/pull/184 From jvos at openjdk.org Fri Mar 8 09:34:19 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:34:19 GMT Subject: [jfx21u] RFR: 8324337: Cherry-pick WebKit 617.1 stabilization fixes Message-ID: 8324337: Cherry-pick WebKit 617.1 stabilization fixes ------------- Commit messages: - Backport 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f Changes: https://git.openjdk.org/jfx21u/pull/51/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=51&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324337 Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod Patch: https://git.openjdk.org/jfx21u/pull/51.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/51/head:pull/51 PR: https://git.openjdk.org/jfx21u/pull/51 From jvos at openjdk.org Fri Mar 8 09:59:04 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 09:59:04 GMT Subject: [jfx21u] Integrated: 8324337: Cherry-pick WebKit 617.1 stabilization fixes In-Reply-To: References: Message-ID: <26HrT0Mk-30mH4271MQYscdGflTiJzPtDgOmnTY2U0w=.ebfbf050-2d93-45b3-8073-5fb185d5e959@github.com> On Fri, 8 Mar 2024 09:29:55 GMT, Johan Vos wrote: > 8324337: Cherry-pick WebKit 617.1 stabilization fixes This pull request has now been integrated. Changeset: eec2c96b Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/eec2c96b8d35b65d6090496451114b00c9ecd3ca Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod 8324337: Cherry-pick WebKit 617.1 stabilization fixes Backport-of: 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f ------------- PR: https://git.openjdk.org/jfx21u/pull/51 From jvos at openjdk.org Fri Mar 8 10:10:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:10:33 GMT Subject: [jfx17u] Integrated: 8324337: Cherry-pick WebKit 617.1 stabilization fixes Message-ID: <5vWAxNnlEcLcMk2Fuu9F-_XU5FaanSJ6i9HaF0ZZiQE=.525c9d1c-09f1-4f4e-939a-46e854e7aa49@github.com> 8324337: Cherry-pick WebKit 617.1 stabilization fixes ------------- Commit messages: - Backport 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f Changes: https://git.openjdk.org/jfx17u/pull/185/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324337 Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod Patch: https://git.openjdk.org/jfx17u/pull/185.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/185/head:pull/185 PR: https://git.openjdk.org/jfx17u/pull/185 From jvos at openjdk.org Fri Mar 8 10:10:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:10:33 GMT Subject: [jfx17u] Integrated: 8324337: Cherry-pick WebKit 617.1 stabilization fixes In-Reply-To: <5vWAxNnlEcLcMk2Fuu9F-_XU5FaanSJ6i9HaF0ZZiQE=.525c9d1c-09f1-4f4e-939a-46e854e7aa49@github.com> References: <5vWAxNnlEcLcMk2Fuu9F-_XU5FaanSJ6i9HaF0ZZiQE=.525c9d1c-09f1-4f4e-939a-46e854e7aa49@github.com> Message-ID: On Fri, 8 Mar 2024 10:01:26 GMT, Johan Vos wrote: > 8324337: Cherry-pick WebKit 617.1 stabilization fixes This pull request has now been integrated. Changeset: 426f4eb0 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/426f4eb0001e9d1c747df0951446030c3d0adcec Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod 8324337: Cherry-pick WebKit 617.1 stabilization fixes Backport-of: 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f ------------- PR: https://git.openjdk.org/jfx17u/pull/185 From jvos at openjdk.org Fri Mar 8 10:12:12 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:12:12 GMT Subject: [jfx21u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Message-ID: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 ------------- Commit messages: - Backport a7f6de8d13fd7a7e37ca80b28badcb24566153d8 Changes: https://git.openjdk.org/jfx21u/pull/52/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=52&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325258 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod Patch: https://git.openjdk.org/jfx21u/pull/52.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/52/head:pull/52 PR: https://git.openjdk.org/jfx21u/pull/52 From jvos at openjdk.org Fri Mar 8 10:12:12 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:12:12 GMT Subject: [jfx21u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 10:03:29 GMT, Johan Vos wrote: > 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 This pull request has now been integrated. Changeset: b0ed455c Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/b0ed455c3bdb60b18427f568c609a89a8e88b4ed Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Backport-of: a7f6de8d13fd7a7e37ca80b28badcb24566153d8 ------------- PR: https://git.openjdk.org/jfx21u/pull/52 From jvos at openjdk.org Fri Mar 8 10:18:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:18:10 GMT Subject: [jfx17u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Message-ID: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 ------------- Commit messages: - Backport a7f6de8d13fd7a7e37ca80b28badcb24566153d8 Changes: https://git.openjdk.org/jfx17u/pull/186/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325258 Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod Patch: https://git.openjdk.org/jfx17u/pull/186.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/186/head:pull/186 PR: https://git.openjdk.org/jfx17u/pull/186 From jvos at openjdk.org Fri Mar 8 10:18:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:18:10 GMT Subject: [jfx17u] Integrated: 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 10:09:53 GMT, Johan Vos wrote: > 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 This pull request has now been integrated. Changeset: eb922637 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/eb9226375bdaa2edc0976d51f34337721ef0c9bb Stats: 1877 lines in 128 files changed: 1101 ins; 288 del; 488 mod 8325258: Additional WebKit 617.1 fixes from WebKitGTK 2.42.5 Backport-of: a7f6de8d13fd7a7e37ca80b28badcb24566153d8 ------------- PR: https://git.openjdk.org/jfx17u/pull/186 From jvos at openjdk.org Fri Mar 8 10:22:14 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:22:14 GMT Subject: [jfx21u] Integrated: 8326989: Text selection issues on WebView after WebKit 617.1 Message-ID: Hi all, This pull request contains a backport of commit 64af9875 from the openjdk/jfx repository. The commit being backported was authored by Hima Bindu Meda on 7 Mar 2024 and was reviewed by Kevin Rushforth and Jose Pereda. Thanks! ------------- Commit messages: - Backport 64af987576214fc5483520ce8131895be74a641d Changes: https://git.openjdk.org/jfx21u/pull/53/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=53&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326989 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/53.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/53/head:pull/53 PR: https://git.openjdk.org/jfx21u/pull/53 From jvos at openjdk.org Fri Mar 8 10:22:14 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:22:14 GMT Subject: [jfx21u] Integrated: 8326989: Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 10:13:27 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 64af9875 from the openjdk/jfx repository. > > The commit being backported was authored by Hima Bindu Meda on 7 Mar 2024 and was reviewed by Kevin Rushforth and Jose Pereda. > > Thanks! This pull request has now been integrated. Changeset: 6edbe2a2 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/6edbe2a2987dc451ebac5f799dd0df7a304ebfbc Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8326989: Text selection issues on WebView after WebKit 617.1 Backport-of: 64af987576214fc5483520ce8131895be74a641d ------------- PR: https://git.openjdk.org/jfx21u/pull/53 From jvos at openjdk.org Fri Mar 8 10:24:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:24:09 GMT Subject: [jfx17u] RFR: 8326989: Text selection issues on WebView after WebKit 617.1 Message-ID: Hi all, This pull request contains a backport of commit 64af9875 from the openjdk/jfx repository. The commit being backported was authored by Hima Bindu Meda on 7 Mar 2024 and was reviewed by Kevin Rushforth and Jose Pereda. Thanks! ------------- Commit messages: - Backport 64af987576214fc5483520ce8131895be74a641d Changes: https://git.openjdk.org/jfx17u/pull/187/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=187&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326989 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/187.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/187/head:pull/187 PR: https://git.openjdk.org/jfx17u/pull/187 From jvos at openjdk.org Fri Mar 8 10:32:00 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 8 Mar 2024 10:32:00 GMT Subject: [jfx17u] Integrated: 8326989: Text selection issues on WebView after WebKit 617.1 In-Reply-To: References: Message-ID: <5mLXMPD6biF6W7NTWKdcPjOspsaQPe_5BEuefQbmB24=.c7563d0e-39ea-4fb8-a554-1ae7d3df9e73@github.com> On Fri, 8 Mar 2024 10:18:21 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 64af9875 from the openjdk/jfx repository. > > The commit being backported was authored by Hima Bindu Meda on 7 Mar 2024 and was reviewed by Kevin Rushforth and Jose Pereda. > > Thanks! This pull request has now been integrated. Changeset: 09491994 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/094919941f4cd131d89f9691e1e0f02a70e0b27e Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8326989: Text selection issues on WebView after WebKit 617.1 Backport-of: 64af987576214fc5483520ce8131895be74a641d ------------- PR: https://git.openjdk.org/jfx17u/pull/187 From mhanl at openjdk.org Fri Mar 8 16:02:08 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 16:02:08 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Message-ID: This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the `-fx-show-delay` was set to another value. The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehvaiour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. Added a bunch of headful tests for the behaviour since there were none before. ------------- Commit messages: - JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Changes: https://git.openjdk.org/jfx/pull/1394/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296387 Stats: 300 lines in 3 files changed: 277 ins; 5 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Fri Mar 8 16:10:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 16:10:26 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/6d40b527..a4a1a49f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Fri Mar 8 16:25:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 16:25:14 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v2] In-Reply-To: References: Message-ID: <0Q5GFAmuflGWCc0YEggzeTiEEACxkaLyW3TT8b0TpfY=.5a4bf8c0-ea8f-43d3-873b-fc12fb10acdb@github.com> > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8326619: Improve tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1382/files - new: https://git.openjdk.org/jfx/pull/1382/files/bc607409..bbdb4db7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=00-01 Stats: 22 lines in 2 files changed: 5 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From mhanl at openjdk.org Fri Mar 8 16:42:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 16:42:57 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: <7LjY-L_C524gn6wWz8zJYWbzRQKZNz2SxKK8QFcLYN8=.f17c8e93-dc9b-4c76-878a-39bcdbc7768f@github.com> References: <7LjY-L_C524gn6wWz8zJYWbzRQKZNz2SxKK8QFcLYN8=.f17c8e93-dc9b-4c76-878a-39bcdbc7768f@github.com> Message-ID: On Wed, 28 Feb 2024 23:43:40 GMT, Kevin Rushforth wrote: > This seems like a reasonable fix and spec change. Have you tested the case of calling sizeToScene before setting full-screen or maximzed? Since the pending flag will still be set in that case, I want to make sure that case is tested as well. I thought about this as well but could not find any problem at least on Windows. If we want to be perfectly safe, we may still want to set the flag when `sizeToScene()` is called. What do you think? I used the following code to test this, and it didn't matter when `sizeToScene()` was called: @Override public void start(Stage primaryStage) throws Exception { StackPane root = new StackPane(); Button wss = new Button("Wss"); wss.setPrefSize(50, 50); root.getChildren().add(wss); Scene scene = new Scene(root); Stage stage = new Stage(); stage.setWidth(500); stage.setMaximized(true); stage.sizeToScene(); stage.setScene(scene); stage.show(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-1986030015 From angorya at openjdk.org Fri Mar 8 18:00:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 18:00:04 GMT Subject: Withdrawn: 8314968: Public InputMap In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Fri Mar 8 18:08:59 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 18:08:59 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Fri Mar 8 18:11:04 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 8 Mar 2024 18:11:04 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Mar 8 18:49:02 2024 From: duke at openjdk.org (duke) Date: Fri, 8 Mar 2024 18:49:02 GMT Subject: Withdrawn: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1330 From andy.goryachev at oracle.com Fri Mar 8 19:20:06 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 8 Mar 2024 19:20:06 +0000 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: * Offtopic: Maybe we should collect the things which should be public in our opinion at one point to (better) get this started as well? My sentiment exactly! Marius, would you like to create a new thread? Thanks! -andy From: openjfx-dev on behalf of Marius Hanl Date: Thursday, March 7, 2024 at 15:40 To: Robert Lichtenberger Cc: openjfx-dev at openjdk.org Subject: Aw: Re: Validation Support One note here regarding that a lot of things are final in JavaFX: The problem is not that everything is final - this is intended and makes sense, since we speak mostly of properties here. Overriding those will not give you any benefit. You mostly want to override e.g. Controls if you add something new to it (a new property) or may just want to set another default skin. This design is mostly superior than e.g. Swing, where you can override things and easily break something if not too careful. Pretty sure that this were some lessons learned from the development of Swing. The biggest problem is rather that a lot of methods are package private or 'Accessors' are used to call specific methods, which is not just a questionable design but also restrict the usage. It is often not possible to override even a minor feature inside the skin. So you may rather want to recreate the skin then, and copy the existing skin and just change some stuff. But this will mostly not work either, as there is a lot of internal API usage, e.g. Accessors or some com.sun.javafx.scene.control.skin.Utils usage. Want to set the width of a TableColumn? Well, the internal com.sun.javafx.scene.control.TableColumnBaseHelper.TableColumnBaseAccessor can do that, you can not. Get the width of a text String? Well, you can use com.sun.javafx.scene.control.skin.Utils.computeTextWidth... Offtopic: Maybe we should collect the things which should be public in our opinion at one point to (better) get this started as well? -- Marius Gesendet: Montag, 04. M?rz 2024 um 08:13 Uhr Von: "Robert Lichtenberger" An: openjfx-dev at openjdk.org Betreff: Re: Validation Support First off, as the original author of ValidatorFX I feel flattered by the suggestion of including it into the JavaFX core :-). Some thoughts / insights I gained from developing ValidatorFX: * ValidatorFX is (with the possible exception of GraphicDecoration.java) rather trivial code and also very small (< 1k lines of library code). But it seems to have filled a market gap according (a few thousand unique ip downloads every month, issues from ca. a dozen people so far, even a few PRs). These "market gaps" get filled rarely because they are not a commercially attractive opportunity. On the other hand if you decide (like I did with ValidatorFX) to take your closed source solution and make it open source, you are "rewarded" by increased overhead at first. But the market gaps exist and hinder broader JavaFX adoption. * ValidatorFX is probably only one part needed for application developers. The other part is a form library that allows to layout fields, have buttons (that are connected to field validation, etc.). It looks like this is written again and again by every application developer. * To answer John's question if JavaFX could do more to help make tools like ValidatorFX easy to build: ** There's the TooltipWrapper class in ValidatorFX which works around JDK-8090379. Not a big deal but something many application developers will probably be annoyed by. ** On a more general note, if I were the king of the JavaFX universe for one day, I would forbid anyone to make classes or methods final. As an application developer I prefer to be able to tweak things easily, even if they may break in the future (which they will anyway ...). Don't take that decision away from me, it's patronizing. But I guess this is one of those things that depend very much on which side of the equation you are, so don't take my troll bait :-). --Robert Am 03.03.24 um 02:10 schrieb John Hendrikx: > Hi Dirk, > > That is a very nice framework, and although I wouldn't be against its > inclusion in FX, I'm more wondering if JavaFX could do more to help > make tools like ValidatorFX easy to build. > > I'm not quite sure how one can use not having validation as an > argument against using FX, when there clearly are free alternatives > available. Surely not everything can or should be part of the base > framework? A line must be drawn somewhere, especially when there are > very few core FX developers. > > I'd much rather see work being done on things that can't be provided > by 3rd parties, preferably by opening up more parts of FX with well > specified API's. > > --John > > On 01/03/2024 11:59, Dirk Lemmermann wrote: >> Hi everyone, >> >> I updated the validation framework ValidatorFX today in our project >> to the latest release and I really like it a lot. It is a small >> compact API and works with any observable as opposed to the >> validation support provided by ControlsFX. >> >> Using it made me wonder whether it would make sense to bundle it or >> something like it directly with JavaFX. Developers often mention >> missing validation support as a drawback of using JavaFX. Adding this >> would take one item off from the list of arguments against using JavaFX. >> >> Many UI frameworks do have built-in validation support, e.g. Vaadin >> [0], Angular, [1], or QT [2] >> >> What do you think? >> >> ?Dirk >> >> [0] >> https://vaadin.com/docs/latest/binding-data/components-binder-validation >> [1] https://angular.io/guide/form-validation >> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Mar 8 21:08:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 21:08:25 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. > > **See Also** > > * [JDK-8091891](https://bugs.openjdk.org/browse/JDK-8091891) TreeView: There is no tooltip available on truncated node > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: labeled helper ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1389/files - new: https://git.openjdk.org/jfx/pull/1389/files/72f170b6..cf9a2e0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=02-03 Stats: 138 lines in 5 files changed: 86 ins; 45 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From andy.goryachev at oracle.com Fri Mar 8 21:40:49 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 8 Mar 2024 21:40:49 +0000 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Daniel: Thank you, both the PR and the code have been updated. This change provides an illustration of the problem we have with JavaFX - it is nearly impossible to talk about custom skin development when most of the essential machinery is hidden behind accessors and non-public classes. In this particular case, TableCellSkin and TreeTableCellSkins use what appears to be a "hack" - Properties.DEFER_TO_PARENT_PREF_WIDTH to irreversibly override the behavior of computePrefWidth() methods. So anyone who wants to modify these skins, or to change Labeled skin to work nicely inside a tree/table is going to hit a brick wall in the form of com.sun.javafx.scene.control.Properties. This is a separate issue that was raised many times in this forum. There is currently no easy solution - making every class public and extendable is out of the question (by design and by general consensus of the maintainers), the next best thing we can do is to identify missing APIs - APIs that **can** be made public to achieve extensibility, in each particular case. This is too not an easy task, as anyone who reads this forum regularly can see. Still, our goal is to make JavaFX a viable and powerful platform, and I agree with Marius that we might want to start collecting info on the APIs that either missing or need to be made public (something like https://bugs.openjdk.org/browse/JDK-8300569 ? Missing APIs related to rich text control ?) -andy From: Daniel Peintner Date: Friday, March 8, 2024 at 00:30 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) Andy, Marius, all, Thank you for your input and your insights. If I understand correctly we cannot purely do it with public methods for now (at least not for TableCells) This makes the argument to support https://github.com/openjdk/jfx/pull/1389 even stronger and maybe should be mentioned in the PR as well. Thanks, -- Daniel On Thu, Mar 7, 2024 at 7:53?PM Andy Goryachev > wrote: Daniel: Thank you for providing a sample app! You are right: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. Cheers, -andy From: Daniel Peintner > Date: Thursday, March 7, 2024 at 07:11 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) Andy, all, Some comments below: 1. Even if it is possible to do the same with public means I think it is useful. Anyhow we need to promote the solutions better (e.g., on StackOverflow) 2. I tried to achieve what you did in JavaFX core for my use-case, TableView cells. * In my real application I tried and failed since the boolean condition in https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 always reports false * Hence I tried to create a short self-contained TableView example to explore it further, see Gist https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf It still fails :-( * The Email field in the table ideally should report "true" once the text entered exceeds the visible view. Somehow it fails... getWidth() and prefWidth(-1) always return the same double value. Please try the Gist above to confirm. e.g., edit cell and extend the email text to longer than column width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < 182.0 --> false" * Hence I also added a *normal* MyLabel example which does work as intended Maybe I miss something obvious but TableCells seem to be special Labeled instances and behave differently. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev > wrote: Dear Daniel: Thank you for confirming the need for this enhancement. Your case is covered by this ticket (I included a wrong ticket in my previous message by mistake, sorry): JDK-8327483 TreeView: Allow for tooltip when cell text is truncated My only concern is that this functionality theoretically can be achieved by the application code just as easy, since the solution does not use any internal APIs, as can be seen here: https://github.com/openjdk/jfx/pull/1389 -andy From: Daniel Peintner > Date: Tuesday, March 5, 2024 at 23:53 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Mar 8 22:38:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 22:38:57 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: <6JwGurSV6EqhpcoWYB0oJRsYSsZ55om0yHDS_UaNPfg=.cb300060-1a48-443a-8aa4-dcf376d1d09d@github.com> On Fri, 8 Mar 2024 16:10:26 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Testing the combined (this PR merged with the latest master) on macOS 14.3.1 M1 Pro (though this is probably not important), using the latest MonkeyTester https://github.com/andy-goryachev-oracle/MonkeyTest - select Tooltip page - open the Tools -> CSS Playground tool - type `.tooltip { -fx-show-delay:1ms; }` into Custom CSS text area, press Update button. (this updates the stylesheet in all the open windows) - hover over the tooltip page What I see is the very first time the tooltip appears it's using the old show-delay value of 1000ms. Any subsequent attempts the new delay is in effect. Then, change back to 1000ms. Same thing happens: the first time the old timeout value is used instead of the new. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986520680 From angorya at openjdk.org Fri Mar 8 22:45:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 22:45:01 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 16:10:26 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed There is also another problem (though it is a separate issue as it can be seen with the master branch): - set the -fx-show-delay to 1ms as described in the previous comment - set the Graphic: to "Image" Notice how sometimes, when slowly entering the tooltip page from the left side, the tooltip appears and then disappears. Async code is hard! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986525324 From angorya at openjdk.org Fri Mar 8 22:49:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 22:49:57 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 16:10:26 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed video: https://github.com/openjdk/jfx/assets/107069028/02589ed0-d359-4811-8843-de1109fd23c9 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986529982 From angorya at openjdk.org Fri Mar 8 23:01:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 8 Mar 2024 23:01:58 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 16:10:26 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed This is another, unrelated issue: If I specify a number instead of duration like `-fx-show-delay: 1;` we'll get an exception every time the tooltip is about to be shown. Exception in thread "JavaFX Application Thread" java.lang.ClassCastException: class java.lang.Double cannot be cast to class javafx.util.Duration (java.lang.Double is in module java.base of loader 'bootstrap'; javafx.util.Duration is in module javafx.base of loader 'app') at javafx.controls/javafx.scene.control.Tooltip.getShowDelay(Tooltip.java:334) at javafx.controls/javafx.scene.control.Tooltip$TooltipBehavior.lambda$0(Tooltip.java:1015) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:199) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3987) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1893) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2711) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:128) Once that happens, the exception will get thrown every time, even after the correct CSS is entered. The app must be restarted. But we don't get an exception for a boolean value: `-fx-wrap-text:"yo";` or a double value like `.tooltip { -fx-graphic-text-gap:"true"; }`. The latter will correctly issue a warning WARNING: Failed to set css [-fx-graphic-text-gap] on [DoubleProperty [bean: javafx.scene.control.Tooltip at 468235b3, name: graphicTextGap, value: 4.0]] due to 'class java.lang.Boolean cannot be cast to class java.lang.Number (java.lang.Boolean and java.lang.Number are in module java.base of loader 'bootstrap')' ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986540225 From angorya at openjdk.org Sat Mar 9 00:06:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Sat, 9 Mar 2024 00:06:59 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> On Sun, 25 Feb 2024 22:28:12 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Optimize performance of OpenAddressed Set just in case it is ever used modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 96: > 94: : maximumCapacity == 2 ? new Duo<>() > 95: : maximumCapacity < 10 ? new Hashless<>(maximumCapacity) // will reject negative values > 96: : new OpenAddressed<>(maximumCapacity); I wonder if standard HashSet should be used instead of OpenAddressed one, or should there be another threshold which results in a HashSet, to support large sets? Or we can reasonably guarantee that these sets are always small? modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 135: > 133: protected final void ensureNotFrozen() { > 134: if (frozen) { > 135: throw new UnsupportedOperationException(); should we explain why? "the set is frozen" or something like that. modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 207: > 205: > 206: for (T element : c) { > 207: modified |= add(element); is there a reason we are overriding the superclass with essentially the same implementation (and this implementation executes OR on every element, while the superclass one is more efficient). not that it's important in the case of Single... modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 215: > 213: @Override > 214: public int hashCode() { > 215: return element == null ? 0 : element.hashCode(); very minor: should we mix in the class hashCode? ex: `return Objects.hashCode(Single.class, element);` modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 290: > 288: > 289: @Override > 290: public boolean addAll(Collection c) { same concern about overriding the superclass method modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 391: > 389: > 390: @Override > 391: public boolean addAll(Collection c) { and here modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 570: > 568: T element = elements[i]; > 569: > 570: h += element == null ? 0 : element.hashCode(); - is there a reason not to use the standard hashCode pattern of `result = 31 * result + (element == null ? 0 : element.hashCode());`? - should we also mix in the class hash code? modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/BitSetTest.java line 160: > 158: // > 159: // assertNotEquals(set1, set2); > 160: // } should we remove the dead code? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518416160 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518402302 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518407964 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518403624 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518412187 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518412908 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518414743 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518422248 From jhendrikx at openjdk.org Sat Mar 9 04:10:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 04:10:01 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 16:10:26 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Although the change is an improvement, I think a similar problem will still be present when CSS changes. The `cssForced` flag I think needs to reset to `false` whenever a CSS styleable property of the tool tip is modified. That would include all such properties... This is a bit of a general issue in JavaFX (it really shouldn't be possible for any `Node` to be shown that hasn't had CSS processed for it), yet this can easily happen, and depending on how different the default style is versus the intended style, this can lead to a visual artifact (most noticable is for example a white background, when it is supposed to be black or transparent). Perhaps we should open an issue to solve this for all controls in one go? A solution that would prevent **any** `Node` from being displayed without CSS applied? ------------- PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-1926087206 From john.hendrikx at gmail.com Sat Mar 9 04:46:22 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 9 Mar 2024 05:46:22 +0100 Subject: Aw: Re: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: <2d6cc334-b360-26dc-3aa9-cef03ff620c7@gmail.com> I think there is definitely room for improvement here, but I think most controls can currently be build externally, if you are willing to do all the work.? Your control may suffer however when you need to integrate with event, focus handling or keyboard navigation.? Skins and Behaviors are not something that are a requirement to use to build a custom control, although they can make it easier to adapt existing controls, up to a point. The problem with making things public is that this means they must be specified, and that we must be **very** sure that it is a solid API that will stand the test of time. That's often a significant time investment that could seriously delay building a complicated control like TableView. I think Skins especially are very hard to design in such a way that they have sensible public/protected methods. They often deal with very specific layout or design problems, that could restrict the evolution of the control if there is a fundamental change in how the Skin is constructed. Just imagine if the very first TableViewSkin had all its methods public, and that they couldn't be changed up to this day because the Skin may have been subclassed by 3rd parties. This is why I would advocate instead to make it easier to replace Skins entirely (by being able to copy the code). The biggest issue there is that Skins contain many non-public helpers, primarily their Behaviors.? Making Behaviors public would first require unblurring the lines between what is Skin and what is Behavior (not doing so will just make it a bad API that will cause many bugs and problems over the coming years).? That would also mean that some controls need some rework to divide the work over their Skin and Behavior correctly, as for many controls the split is there only in name, and is discarded as soon as it was inconvenient. With Behaviors public and some helpful API's (like Font measurement) having a public equivalent, the route to just copy only a Behavior or Skin opens up.? Being able to copy them means that you don't need to fully open up and specify every private method in Skins/Behaviors (designing API's is hard, but designing API's that can be sub classed while not restricting an endless set of possibilities that a Skin subclass may need is impossible). --John On 08/03/2024 00:40, Marius Hanl wrote: > One note here regarding that a lot of things are final in JavaFX: > The problem is not that everything is final - this is intended and > makes sense, since we speak mostly of properties here. Overriding > those will not give you any benefit. > You mostly want to override e.g. Controls if you add something new to > it (a new property) or may just want to set another default skin. > This design is mostly superior than e.g. Swing, where you can override > things and easily break something if not too careful. > Pretty sure that this were some lessons learned from the development > of Swing. > The biggest problem is rather that a lot of methods are package > private or 'Accessors' are used to call specific methods, which is not > just a questionable design but also restrict the usage. > It is often not possible to override even a minor feature inside the skin. > So you may rather want to recreate the skin then, and copy the > existing skin and just change some stuff. But this will mostly not > work either, as there is a lot of internal API usage, e.g. Accessors > or some?com.sun.javafx.scene.control.skin.Utils usage. > Want to set the width of a TableColumn? Well, the internal > com.sun.javafx.scene.control.TableColumnBaseHelper.TableColumnBaseAccessor?can > do that, you can not. > Get the width of a text String? Well, you can use > com.sun.javafx.scene.control.skin.Utils.computeTextWidth... > Offtopic: Maybe we should collect the things which should be public in > our opinion at one point to (better) get this started as well? > -- Marius > *Gesendet:*?Montag, 04. M?rz 2024 um 08:13 Uhr > *Von:*?"Robert Lichtenberger" > *An:* openjfx-dev at openjdk.org > *Betreff:*?Re: Validation Support > First off, as the original author of ValidatorFX I feel flattered by the > suggestion of including it into the JavaFX core :-). > > Some thoughts / insights I gained from developing ValidatorFX: > > * ValidatorFX is (with the possible exception of GraphicDecoration.java) > rather trivial code and also very small (< 1k lines of library code). > But it seems to have filled a market gap according (a few thousand > unique ip downloads every month, issues from ca. a dozen people so far, > even a few PRs). These "market gaps" get filled rarely because they are > not a commercially attractive opportunity. On the other hand if you > decide (like I did with ValidatorFX) to take your closed source solution > and make it open source, you are "rewarded" by increased overhead at > first. But the market gaps exist and hinder broader JavaFX adoption. > > * ValidatorFX is probably only one part needed for application > developers. The other part is a form library that allows to layout > fields, have buttons (that are connected to field validation, etc.). It > looks like this is written again and again by every application developer. > > * To answer John's question if JavaFX could do more to help make tools > like ValidatorFX easy to build: > > ** There's the TooltipWrapper class in ValidatorFX which works around > JDK-8090379. Not a big deal but something many application developers > will probably be annoyed by. > > ** On a more general note, if I were the king of the JavaFX universe for > one day, I would forbid anyone to make classes or methods final. As an > application developer I prefer to be able to tweak things easily, even > if they may break in the future (which they will anyway ...). Don't take > that decision away from me, it's patronizing. But I guess this is one of > those things that depend very much on which side of the equation you > are, so don't take my troll bait :-). > > > --Robert > > > Am 03.03.24 um 02:10 schrieb John Hendrikx: > > Hi Dirk, > > > > That is a very nice framework, and although I wouldn't be against its > > inclusion in FX, I'm more wondering if JavaFX could do more to help > > make tools like ValidatorFX easy to build. > > > > I'm not quite sure how one can use not having validation as an > > argument against using FX, when there clearly are free alternatives > > available.? Surely not everything can or should be part of the base > > framework?? A line must be drawn somewhere, especially when there are > > very few core FX developers. > > > > I'd much rather see work being done on things that can't be provided > > by 3rd parties, preferably by opening up more parts of FX with well > > specified API's. > > > > --John > > > > On 01/03/2024 11:59, Dirk Lemmermann wrote: > >> Hi everyone, > >> > >> I updated the validation framework ValidatorFX today in our project > >> to the latest release and I really like it a lot. It is a small > >> compact API and works with any observable as opposed to the > >> validation support provided by ControlsFX. > >> > >> Using it made me wonder whether it would make sense to bundle it or > >> something like it directly with JavaFX. Developers often mention > >> missing validation support as a drawback of using JavaFX. Adding this > >> would take one item off from the list of arguments against using > JavaFX. > >> > >> Many UI frameworks do have built-in validation support, e.g. Vaadin > >> [0], Angular, [1], or QT [2] > >> > >> What do you think? > >> > >> ?Dirk > >> > >> [0] > >> > https://vaadin.com/docs/latest/binding-data/components-binder-validation > >> [1] https://angular.io/guide/form-validation > >> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Sat Mar 9 05:19:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 05:19:01 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Fri, 8 Mar 2024 18:08:15 GMT, Marius Hanl wrote: > Tested with a big application, did not find any regression. All listeners still work as expected, tested especially a lot of 'if something is selected, this button should be enabled/disabled' and the like. I did not checked the code yet, just a little bit. One question: Should I test something special/do you see a case which could cause a problem here? I think testing it with a big application is excellent (I do the same here with my own large application), and I'm happy to hear you did not spot any regressions! This change does change (unspecified) behavior a little bit, although I think well within the documented contract of how change listeners operate (ie. applications should not be relying on the unspecified behavior). It will be hard to notice any change directly, as the changes are all related to advanced usage of listeners (adding/removing listeners during listener callbacks) or nested changes (the same property gets changed **during** a callback, directly or indirectly). 1. During a listener callback, you remove a listener that is currently being notified (ie. yourself, or any listener that may have triggered your callback that is further up the call stack) - Before this change, there is a chance that such a removed listener may still be called a few more times, despite it being removed in nested cases; its doubtful anyone is relying on that behavior, and (IMHO) these extra callbacks are more likely to break things, because things have been cleaned up (who assumes that their listener might still get called after removal?) 2. During a listener callback, you add a listener that is currently being notified (this can't be yourself, but it could be a listener on a property that triggered your callback that is further up the stack) - Before this change, this newly added listener may start participating in the current nested listener notification (ie. it would start participating halfway during a chain of nested changes). After this change, such a newly added listener would only be notified on the **next** top level change. It's unlikely anyone is relying on this behavior. 3. During a listener callback, you change the value the property it is attached to (or any property that may have led to your callback being called further up the callstack). - The most "common" scenario for this is veto-ing changes. For example, a property that can't be empty may get set to a non-empty value (or its original value) in a listener, triggering another notification. Your listener would not notice any differences (it would get called immediately with the change that you just did), but any listeners added after yours may not "see" the empty value because it was changed to something else before they were called. They will only see the new value (and the corresponding **correct** old value since last they were called -- they may also be not called at all if the value was changed back to its original, and so they would be completely unaware of the temporary change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1986734228 From jhendrikx at openjdk.org Sat Mar 9 05:29:00 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 05:29:00 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Fri, 8 Mar 2024 23:14:12 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize performance of OpenAddressed Set just in case it is ever used > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 135: > >> 133: protected final void ensureNotFrozen() { >> 134: if (frozen) { >> 135: throw new UnsupportedOperationException(); > > should we explain why? "the set is frozen" or something like that. I'm not against adding an explanation, but it's not needed as this is part of the `Set` contract (sets that can't be modified are specified to throw `UnsupportedOperationException`), for example for `add` in `Set`: * @throws UnsupportedOperationException if the {@code add} operation * is not supported by this set The concept of "freezing" the set is not visible to any users, it's just there to avoid having to make a final copy of the set. It's modifiable by the code that created it, but if they freeze it before exposing it to the outside world, then for all intents and purposes it is a read only set for anyone else. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518482571 From jhendrikx at openjdk.org Sat Mar 9 05:31:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 05:31:59 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Fri, 8 Mar 2024 23:17:28 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize performance of OpenAddressed Set just in case it is ever used > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 215: > >> 213: @Override >> 214: public int hashCode() { >> 215: return element == null ? 0 : element.hashCode(); > > very minor: should we mix in the class hashCode? ex: > `return Objects.hashCode(Single.class, element);` We can't, `hashCode` for `Set`s are specified: > The hash code of a set is defined to be the sum of the hash codes of the elements in the set, where the hash code of a {@code null} element is defined to be zero This is done so that using a set as a key would hash to the same value regardless of what type of set it is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518482891 From jhendrikx at openjdk.org Sat Mar 9 05:40:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 05:40:02 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Fri, 8 Mar 2024 23:26:05 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize performance of OpenAddressed Set just in case it is ever used > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 207: > >> 205: >> 206: for (T element : c) { >> 207: modified |= add(element); > > is there a reason we are overriding the superclass with essentially the same implementation (and this implementation executes OR on every element, while the superclass one is more efficient). > not that it's important in the case of Single... You are right, I hadn't noticed this, probably when I was splitting the sets in different capacities, but the above implementation is indeed the same as in `AbstractCollection#addAll`. I will remove it. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 570: > >> 568: T element = elements[i]; >> 569: >> 570: h += element == null ? 0 : element.hashCode(); > > - is there a reason not to use the standard hashCode pattern of `result = 31 * result + (element == null ? 0 : element.hashCode());`? > - should we also mix in the class hash code? This can't be changed, see other comment, but in short, `Set`s have a specified implementation for `hashCode` to make them interoperable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518483390 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518483590 From jhendrikx at openjdk.org Sat Mar 9 06:10:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 06:10:59 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: <9jWgk42Ew2Du-RG7F63lAcT6ZI7R9SFtClV6VPyc28k=.d904c263-57ee-4bf1-9838-d617e722db85@github.com> On Fri, 8 Mar 2024 23:46:16 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize performance of OpenAddressed Set just in case it is ever used > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 96: > >> 94: : maximumCapacity == 2 ? new Duo<>() >> 95: : maximumCapacity < 10 ? new Hashless<>(maximumCapacity) // will reject negative values >> 96: : new OpenAddressed<>(maximumCapacity); > > I wonder if standard HashSet should be used instead of OpenAddressed one, or should there be another threshold which results in a HashSet, to support large sets? > > Or we can reasonably guarantee that these sets are always small? It's possible to use the standard `HashSet` as a final fallback (or even to replace `OpenAddressed`), although it would need to be wrapped so support the `freeze` method (or we need to implement this differently). There are a few reasons however not to do so: - `HashSet` doesn't support `freeze` so we'd need to copy it after it is created; we can't use `Set.of` as this would also require making a copy of the entries first (the entries are added one by one because empty values are filtered) -- the solution in this PR carefully avoids all unnecessary copying and allocations to achieve the better performance - The sets are indeed in almost all cases very small (hence the optimizations for small sets) -- they contain style classes that apply to a single node or a single selector. Nodes with many style classes applied to them (ie. 10 or more) I think rarely occurs in practice. Same goes for selectors; you'd have to have something like `a > b c d e f g h i > j` as selector -- remember that this doesn't apply to something like `a, b, c, d, e, f, g, h, i, j`, as they are actually 10 different selectors with 1 style each. - `HashSet` is less memory efficient (between 21.5 to 26.7 bytes per entry with the load factor varying between 0.75 and 0.75 * 0.5 and a base cost of 16 bytes per entry) vs `OpenAddressed` which requires between 5.7 and 13.3 bytes per entry (due to its load factor variation between 0.3 and 0.7 with a base cost of 0 bytes per entry) -- why isn't the JDK using open addressed then you may wonder? Well, it actually does in its `Set.of` implementation, but not for `HashSet`, primarily because `HashSet` has less worse edge cases when hash codes are poor, and it has to be more generally usable (open addressed tables degrade easier and require more maintenance when under constant modification, which doesn't apply for us here). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518487561 From jhendrikx at openjdk.org Sat Mar 9 06:19:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 06:19:58 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Sat, 9 Mar 2024 00:04:04 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize performance of OpenAddressed Set just in case it is ever used > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/BitSetTest.java line 160: > >> 158: // >> 159: // assertNotEquals(set1, set2); >> 160: // } > > should we remove the dead code? Yeah, I guess we can -- it's unlikely we'll ever make another implementation of `BitSet` -- it's more likely that after this PR we may also do a similar change for `PseudoClassState` and remove `BitSet` completely :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518488573 From jhendrikx at openjdk.org Sat Mar 9 06:48:25 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 06:48:25 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v6] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Remove commented code in BitSetTest - Remove unnecessary addAll overrides ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/c388f23d..dc59c4db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=04-05 Stats: 65 lines in 2 files changed: 0 ins; 65 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From mhanl at openjdk.org Sat Mar 9 09:12:56 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 09:12:56 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: <6JwGurSV6EqhpcoWYB0oJRsYSsZ55om0yHDS_UaNPfg=.cb300060-1a48-443a-8aa4-dcf376d1d09d@github.com> References: <6JwGurSV6EqhpcoWYB0oJRsYSsZ55om0yHDS_UaNPfg=.cb300060-1a48-443a-8aa4-dcf376d1d09d@github.com> Message-ID: On Fri, 8 Mar 2024 22:36:19 GMT, Andy Goryachev wrote: > What I see is the very first time the tooltip appears it's using the old show-delay value of 1000ms. Any subsequent attempts the new delay is in effect. > > Then, change back to 1000ms. Same thing happens: the first time the old timeout value is used instead of the new. There seems to be a difference when using `setStyle` and a global stylesheet. I'm investigating. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986802288 From mhanl at openjdk.org Sat Mar 9 09:16:56 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 09:16:56 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Sat, 9 Mar 2024 04:07:45 GMT, John Hendrikx wrote: > Perhaps we should open an issue to solve this for all controls in one go? A solution that would prevent **any** `Node` from being displayed without CSS applied? Yes, that sounds like a good idea. Checking the calls to `applyCss`, it is mostly in table related classes and I remember that I already asked myself the question whether they are really needed there. > Although the change is an improvement, I think a similar problem will still be present when CSS changes. The cssForced flag I think needs to reset to false whenever a CSS styleable property of the tool tip is modified. That would include all such properties... Will check. `Tooltip` is unfortunately a corner case where we to get some CSS properties BEFORE we show it in order to correctly setup the animation timeline. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986803140 From mhanl at openjdk.org Sat Mar 9 10:27:21 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 10:27:21 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v3] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/a4a1a49f..093b36f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=01-02 Stats: 59 lines in 3 files changed: 39 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Sat Mar 9 10:35:03 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 10:35:03 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v3] In-Reply-To: References: Message-ID: On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 175: > 173: > 174: @Override > 175: protected void show() { Another idea I was trying that worked fine is to have a new method inside `PopupWindow`, which we can call rather than `show()`: protected final void applySceneStylesFromOwner(Window owner) { Scene sceneValue = getScene(); final Scene ownerScene = getRootWindow(owner).getScene(); if (ownerScene != null) { if (ownerScene.getUserAgentStylesheet() != null) { sceneValue.setUserAgentStylesheet(ownerScene.getUserAgentStylesheet()); } sceneValue.getStylesheets().setAll(ownerScene.getStylesheets()); if (sceneValue.getCursor() == null) { sceneValue.setCursor(ownerScene.getCursor()); } } } The `show()` method inside `PopupWindow` is also doing excactly the code above, thats why I ended up calling it. But we can also think about just calling that code directly and not `show`, we just need to extract that part of the code and create a `protected` method with it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1518551314 From mhanl at openjdk.org Sat Mar 9 12:23:01 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 12:23:01 GMT Subject: RFR: JDK-8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v2] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 22:59:42 GMT, Andy Goryachev wrote: > This is another, unrelated issue: If I specify a number instead of duration like `-fx-show-delay: 1;` we'll get an exception every time the tooltip is about to be shown. This is because the CSS implementation thinks it is a PX value and therefore parse it wrong. You can check the CssParser to see why this happens. Fix might be simple, but the code in the parser is very error prone for this kind of stuff. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-1986842087 From nlisker at openjdk.org Sat Mar 9 12:37:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 9 Mar 2024 12:37:57 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v6] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <1gFAZoAMcetzGeaUyvgvZS-mcwcLL5qcBxwE99nHuRE=.1a77c7ec-726a-4df7-a28b-53bdb420f1d1@github.com> On Sat, 9 Mar 2024 06:48:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 32: > 30: * @deprecated for removal > 31: */ > 32: public final class StyleClass { Needs the `@Deprecated(forRemoval = true)` annotation on the class, and the doc tag needs an explanation of why it's being removed ("erroneously exposed", "no longer needed", "flawed from the start"...) and what should be used instead, if at all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518566872 From jhendrikx at openjdk.org Sat Mar 9 13:46:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 13:46:08 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v7] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add @Deprecated tag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/dc59c4db..16da6eb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Sat Mar 9 13:46:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 13:46:08 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v6] In-Reply-To: <1gFAZoAMcetzGeaUyvgvZS-mcwcLL5qcBxwE99nHuRE=.1a77c7ec-726a-4df7-a28b-53bdb420f1d1@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <1gFAZoAMcetzGeaUyvgvZS-mcwcLL5qcBxwE99nHuRE=.1a77c7ec-726a-4df7-a28b-53bdb420f1d1@github.com> Message-ID: On Sat, 9 Mar 2024 12:35:22 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove commented code in BitSetTest >> - Remove unnecessary addAll overrides > > modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 32: > >> 30: * @deprecated for removal >> 31: */ >> 32: public final class StyleClass { > > Needs the `@Deprecated(forRemoval = true)` annotation on the class, and the doc tag needs an explanation of why it's being removed ("erroneously exposed", "no longer needed", "flawed from the start"...) and what should be used instead, if at all. I added it. Technically, we could leave this class in, but it would just be a dead class that serves no purpose within FX, at least, once the `SimpleSelector` and `CompoundSelector` classes have been moved to internal packages. I'm wondering if I should add any deprecations in this PR at all, as now it requires a CSR. This could be all handled in the PR that moves these classes to internal packages. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1518575434 From mhanl at openjdk.org Sat Mar 9 16:01:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 16:01:58 GMT Subject: Integrated: JDK-8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 18:55:54 GMT, Marius Hanl wrote: > `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all other implementations of the cell. > > This also means that the `TreeTableRow` always updates the item, although it should not, resulting in a performance loss as a `TreeTableRow` will always call `updateItem(..)`. > > It looks like that this was forgotten in [JDK-8092593](https://bugs.openjdk.org/browse/JDK-8092593). > > Checking the whole history, it looks like the following was happening: > 1. There was a check if the item is the same in all cell implementations (with `.equals(..)`) > 2. Check was removed as it caused bugs > 3. Check was readded, but instead we first check the index (same index) and then if we also have the same item (this time with `.isItemChanged(..)`, to allow developers to subclass it) > 4. Forgotten for `TreeTableRow` inbetween this chaos. > > Added many tests for the case where an item should be changed and where it should not. > Improved existing tests as well. Using `stageLoader`, as before the tests only created a stage when doing the assert. > > NOTE: The update logic is now the same as for all other 5 cell implementations. Especially `TreeCell` (since it is for a tree structure as well). This pull request has now been integrated. Changeset: 11305843 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/11305843300cdbfed9bfa2120da1c7ecd361df39 Stats: 539 lines in 11 files changed: 511 ins; 2 del; 26 mod 8325402: TreeTableRow updateItem() does not check item with isItemChanged(..) unlike all other cell implementations Reviewed-by: angorya, kpk ------------- PR: https://git.openjdk.org/jfx/pull/1360 From mariushanl at web.de Sat Mar 9 18:24:59 2024 From: mariushanl at web.de (Marius Hanl) Date: Sat, 9 Mar 2024 19:24:59 +0100 Subject: Aw: Re: Re: Validation Support In-Reply-To: <2d6cc334-b360-26dc-3aa9-cef03ff620c7@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> <2d6cc334-b360-26dc-3aa9-cef03ff620c7@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Sat Mar 9 18:30:30 2024 From: mariushanl at web.de (Marius Hanl) Date: Sat, 9 Mar 2024 19:30:30 +0100 Subject: Aw: Re: Re: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Sat Mar 9 18:35:47 2024 From: mariushanl at web.de (Marius Hanl) Date: Sat, 9 Mar 2024 19:35:47 +0100 Subject: Aw: Re: Validation Support In-Reply-To: <279195d1-2e87-4096-ab0d-959bf6539edd@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> <279195d1-2e87-4096-ab0d-959bf6539edd@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Sat Mar 9 18:41:10 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 18:41:10 GMT Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v3] In-Reply-To: References: Message-ID: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: improve tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1382/files - new: https://git.openjdk.org/jfx/pull/1382/files/bbdb4db7..e58a2fda Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From mhanl at openjdk.org Sat Mar 9 19:56:18 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 19:56:18 GMT Subject: RFR: JDK-8327727: Changing the row factory of a TableView does not recreate the rows Message-ID: The fix is very straightfoward. We request a recreation of all cells in the `VirtualFlow` by calling `flow.recreateCells()` when the `tableRowFactory` was changed. Funny enough, this was done in the `TreeTableViewSkin` again, hence it did not suffer from this bug. Removed as the table row factory is already handled in the `TableViewSkinBase`, now with the correct recreation. ------------- Commit messages: - JDK-8327727: Changing the row factory of a TableView does not recreate the rows Changes: https://git.openjdk.org/jfx/pull/1396/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327727 Stats: 98 lines in 4 files changed: 93 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1396.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1396/head:pull/1396 PR: https://git.openjdk.org/jfx/pull/1396 From mhanl at openjdk.org Sat Mar 9 20:44:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 9 Mar 2024 20:44:57 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner Note that I found out something interesting which can MAY help us here to solve the problem in another way. What I found out: If I set the the opacity of the clip rect to something under 1, this bug disappears. ![image](https://github.com/openjdk/jfx/assets/66004280/e8c02bf5-e16b-4ca4-96ed-36a0ede72094) So something in the low level clip rendering is different when an opacity is set. Will investigate if there could be another solution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1986971595 From john.hendrikx at gmail.com Sat Mar 9 22:04:47 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 9 Mar 2024 23:04:47 +0100 Subject: Validation Support In-Reply-To: <279195d1-2e87-4096-ab0d-959bf6539edd@gmail.com> References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> <279195d1-2e87-4096-ab0d-959bf6539edd@gmail.com> Message-ID: <8ecdd27c-6412-6ac5-57f1-de0308fbac0a@gmail.com> On 08/03/2024 07:37, Robert Lichtenberger wrote: > > One major pain point that we have at the moment is CSS performance, I > think (but did not investigate yet) that some kind of performance > regression happened somewhere between 17 and 21. > I think this was addressed already, see here: https://github.com/openjdk/jfx/pull/1314 The fix is in JFX22, not sure if it should perhaps be back ported to JFX21. While I was looking at that regression, I also checked if there was more performance to be gained.? You can find those changes in https://github.com/openjdk/jfx/pull/1316 --John From jhendrikx at openjdk.org Sat Mar 9 22:05:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 9 Mar 2024 22:05:57 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 18:33:29 GMT, Kevin Rushforth wrote: >> The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. >> >> As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. >> >> I've tested this solution with the JFXCentral application locally and the regression seems resolved. > >> As this is a regression fix, I've kept the fix as small as reasonable > > Thanks. That seems like the best solution. @kevinrushforth should this perhaps be backported to 21? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1314#issuecomment-1986992136 From pedro.duquevieira at gmail.com Sat Mar 9 22:40:40 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 9 Mar 2024 22:40:40 +0000 Subject: Aw: Re: Validation Support Message-ID: Regarding the comment that the design of JavaFX is vastly superior to Swing.. I would argue against bluntly stating that (not criticizing who said that). There are obviously cons and pros to each approach. On the one side Swing was much easier for developers to extend and to add functionality on top whereas JavaFX is harder. JavaFX on the other hand can evolve in a more safe way since the implementation details are less exposed to developers. I wouldn't say one is better than the other, I guess it depends on the scenario you're in. There are pros and cons to each. There are certainly lots of developers that preferred the Swing approach (myself included) and others would probably prefer the JavaFX one (not sure which one the majority prefers). When the JavaFX team first made this decision there were some conditions that don't hold true anymore, so the underlying scenario has changed. Back then it was assumed that the user would be the one responsible for installing and updating the JRE that was going to be used in the app (so you were never sure which jre the user was on). That's no longer the case as almost all apps ship with its own JRE. More importantly, back then the javafx team was much bigger, so changes could be made at a faster pace. Yes JavaFX was closed but if the JavaFX team saw there was a need from developers for some feature/API it could be added much more quickly while still not exposing too much of the implementation. I wonder if in some parts we can compromise if we see there's a need. Like exposing some parts but adding a annotation or something saying that we're still experimenting or/and some scenarios might not be supported, so be careful using this, etc... (that's somewhat already happened in javafx 8 with the @treatAsPrivate annotation) Just some food for thought... I like the compromise that John Hendrikx suggested of copy pasting code and changing the copy pasted code (given the internal API usage is solved). I have done that sometimes. I just have one question though: does the license of JavaFX permit a commercial app to have that in its own app (copy pasted code from the JavaFX SDK)? I have already said that, but what I really would like JavaFX to provide would be more points of extension, things like the possibility to extend the CSS parser and add more CSS primitives, etc... Bottom line: make the API more powerful in terms of what the developer can do. Right now if you want to do something slightly less standard you're likely to hit a bunch of hurdles... My 2 cents.. -- Pedro Duque Vieira - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at status6.com Sun Mar 10 03:00:42 2024 From: john at status6.com (John Neffenger) Date: Sat, 9 Mar 2024 19:00:42 -0800 Subject: Validation Support In-Reply-To: References: <15CE144A-E590-4085-A0F6-6AD660AC407F@gmail.com> <26b676f0-b83e-f873-3273-c22859aeebc1@gmail.com> <6ccccb6e-fb8b-407f-bc1f-78fcc0bd58f9@gmail.com> Message-ID: <011230af-9bb8-4d8d-8939-a7a48569fc4d@status6.com> On 3/9/24 10:30 AM, Marius Hanl wrote: > However, I found this old email thread. Two answers which reflect what > we said: > https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html > https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010094.html Wow, good find! Thank you, Marius. I am pleasantly surprised to see some of the same people in that old discussion now participating in this one. In reading the thread, it seems the decision to keep the JavaFX API so closed was made primarily by Richard Bair based on his own experience, and is perhaps best explained in Item 19 of /Effective Java, Third Edition./ by Joshua Bloch. Summary: inheritance violates encapsulation, so designing a class for inheritance "is not a decision to be undertaken lightly." I don't have the experience to offer my own opinion, but with all the talk of opening things up, I thought it might be a good time to revisit the history. You know, "Those who cannot remember the past are condemned to repeat it," and all that. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Sun Mar 10 13:32:58 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 10 Mar 2024 13:32:58 GMT Subject: RFR: JDK-8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: <_kDXEiA5mxJ3YW5ecxBovaSsjDOZ_Mgu_LOay56T7wM=.77dacdf9-392d-4d93-8529-05b3429c5b17@github.com> On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote: > This PR fixes the border glitch/gap as explained in both linked tickets. > > I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that. > > So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin). > And this also fixes the issue, while behaving the same as before. > > In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas. > > Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place: > Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell` > After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell` > > To better understand this, the container structure (tree) is shown below: > > - ScrollPane > - viewRect -> `setClip` -> clipRect (viewContent size) > - viewContent -> `setLayoutX` > - Content > - vsb > - hsb > - corner > > --- > - VirtualFlow > - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size) > - clippedContainer/clipView -> `setLayoutX` (when scrolling) > - sheet > - Cell > - vsb > - hsb > - corner Ok, so I found out the following: When a `Rectangle` is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the opacity to `0.99` fixes the issue - another route will be used for the rendering. This happens at the low level (`NGNode`) side of JavaFX. See here `NGNode`: ![image](https://github.com/openjdk/jfx/assets/66004280/6755574e-79e0-43a9-9830-93ea04715628) `renderRectClip` seems to be doing something wrong. I see that the clip rect is floored there, which seems to be the cause. Rounding it is fixing this for me. The bug always appears when I scroll and the clip `RectBounds` are something like: `RectBounds { minX:6.999996, minY:37.0, maxX:289.00003, maxY:194.0} (w:282.00003, h:157.0)` while this does not happen when the value is something like: `RectBounds { minX:7.000004, minY:37.0, maxX:289.0, maxY:194.0} (w:282.0, h:157.0)` Note that the `minX` is floored down, that explains the 1px gap. And now I fully understand why this only happens for the `VirtualFlow`: This is the only container and location where the clip is layouted as well! (`setLayoutX`/`setLayoutY`). In `ScrollPaneSkin`, there was the decision, that the clip is set and the content is layouted only, not the clip. It may still make sense to me to actually imrpove the `VirtualFlow` here - it seems like a good choice to just set the clip and never touch it again and only change the underlying content layout, might be even a bit faster. But there is obviously a bug on the low level `NGNode` side as well. Not sure where to go from here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-1987232133 From jvos at openjdk.org Mon Mar 11 10:23:03 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 11 Mar 2024 10:23:03 GMT Subject: RFR: JDK-8322795 CSS performance regression up to 10x In-Reply-To: References: Message-ID: <-JvcokbcATeAE8KeAz28LlrwUhNehxPiFan-fXuxvqo=.dea952a1-c535-4f23-a3c7-0277d1f69088@github.com> On Wed, 3 Jan 2024 01:14:13 GMT, John Hendrikx wrote: > The regression is caused by the `Collections.unmodifiableSet` wrapper not being recognized by `BitSet`, and a fall back is done to a less optimized version of `containsAll`. > > As this is a regression fix, I've kept the fix as small as reasonable. I'll provide a further optimized version as part of https://bugs.openjdk.org/browse/JDK-8322964 which eliminates the need for `BitSet` and `StyleClass` in the hot code paths which should result in a further CSS performance improvement. > > I've tested this solution with the JFXCentral application locally and the regression seems resolved. that's a good candidate indeed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1314#issuecomment-1988065903 From andy.goryachev at oracle.com Mon Mar 11 15:22:28 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 11 Mar 2024 15:22:28 +0000 Subject: Proposal: Public InputMap (v2) Message-ID: Dear JavaFX developers: Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7]. There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back. Some of the objections were: * desire for some static behavior to avoid the per-instance penalty * clearer separation of concerns between controls, skins, and behaviors * desire to have some sort of public API for behaviors * need for addressing an issue with the event handler execution order between application and skins I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier. The new proposal retains the idea of allowing wider customization of key mappings via the InputMap. The new features include: * separation of SkinInputMap from the control's InputMap * enabling static skin input maps for stateless behaviors * explicit priority levels for event handlers and key mappings created by the application and by the skin The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls: * complex popup-like controls: ComboBox, ColorPicker, DatePicker * complex text input controls: PasswordField, TextArea, TextField * control with a stateless behavior: TabPane as well as a brand new RichTextArea control being incubated [8]. Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community. We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3]. For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below. What do you think? -andy References [0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md [1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md [2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ [3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395 [4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968 [5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior [6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md [7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html [8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Mar 11 16:32:35 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 11 Mar 2024 16:32:35 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 09:53:23 GMT, Marius Hanl wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511 >> reverted accidental indentation chang > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1556: > >> 1554: if (targetCell != null) { >> 1555: if (targetIndex < 0) { >> 1556: T cell = getCell(targetIndex); > > Is there a reason you call `getCell` here, but `getAvailableCell` below? As I was also involved in fixing this error, I can answer. The `getAvailableCell()` method creates a new cell if none exists for the specified index (-1). The `getCell()` returns the `accumCell` in this case, which is completely sufficient for our case, because we only need the dimensions of the cell here. The cell itself will not be added to the scene-graph. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1519900760 From angorya at openjdk.org Mon Mar 11 16:32:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Mar 2024 16:32:34 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Sat, 9 Mar 2024 05:26:33 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 135: >> >>> 133: protected final void ensureNotFrozen() { >>> 134: if (frozen) { >>> 135: throw new UnsupportedOperationException(); >> >> should we explain why? "the set is frozen" or something like that. > > I'm not against adding an explanation, but it's not needed as this is part of the `Set` contract (sets that can't be modified are specified to throw `UnsupportedOperationException`), for example for `add` in `Set`: > > * @throws UnsupportedOperationException if the {@code add} operation > * is not supported by this set > > The concept of "freezing" the set is not visible to any users, it's just there to avoid having to make a final copy of the set. It's modifiable by the code that created it, but if they freeze it before exposing it to the outside world, then for all intents and purposes it is a read only set for anyone else. But it is somewhat visible: **public** `void freeze();` (although it cannot be invoked directly). Edit: While I accept your reasoning that the functionality is effectively hidden from the user, I still think that the exception should always explain "why", if only to reduce the cognitive load. Think of all the countless man hours saved collectively over the years. Yes, the answer can be found by googling, stackoverflowing, and reading RTFM, but if the answer is right there it is so much better. Wouldn't you agree? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1519862160 From jhendrikx at openjdk.org Mon Mar 11 16:32:35 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 16:32:35 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Mon, 11 Mar 2024 14:54:45 GMT, Andy Goryachev wrote: >> I'm not against adding an explanation, but it's not needed as this is part of the `Set` contract (sets that can't be modified are specified to throw `UnsupportedOperationException`), for example for `add` in `Set`: >> >> * @throws UnsupportedOperationException if the {@code add} operation >> * is not supported by this set >> >> The concept of "freezing" the set is not visible to any users, it's just there to avoid having to make a final copy of the set. It's modifiable by the code that created it, but if they freeze it before exposing it to the outside world, then for all intents and purposes it is a read only set for anyone else. > > But it is somewhat visible: **public** `void freeze();` (although it cannot be invoked directly). > > Edit: While I accept your reasoning that the functionality is effectively hidden from the user, I still think that the exception should always explain "why", if only to reduce the cognitive load. Think of all the countless man hours saved collectively over the years. Yes, the answer can be found by googling, stackoverflowing, and reading RTFM, but if the answer is right there it is so much better. Wouldn't you agree? I'd like someone else to weigh in on this. If this were a `Set` that eventually would be publicly accessible somewhere (by normal FX users) I'd definitely not want this. In this case however, it is (for now at least) only used internally, so I don't care much if it has a message -- just be aware the users might see this if this class ever **does** get exposed (like `BitSet` was). I also don't understand your point about man hours saved and cognitive load. The message is perfectly clear, you can't call that method, and the reason is clearly documented, and in the context of collections, it means the set cannot be mutated (by you). The creator of the set should be well aware that the set is read only after being frozen. Any external class that it is being exposed to does not need to be aware of how this is achieved (the method that you get it from will clearly say it is an "immutable set" or some such). A message about the set being frozen will just be confusing (What does frozen mean? How do I unfreeze it? Who froze it? Why is this `Set` special from other unmodifiable sets which don't mention this?) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1519973968 From angorya at openjdk.org Mon Mar 11 16:32:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Mar 2024 16:32:35 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Mon, 11 Mar 2024 16:01:13 GMT, John Hendrikx wrote: >> But it is somewhat visible: **public** `void freeze();` (although it cannot be invoked directly). >> >> Edit: While I accept your reasoning that the functionality is effectively hidden from the user, I still think that the exception should always explain "why", if only to reduce the cognitive load. Think of all the countless man hours saved collectively over the years. Yes, the answer can be found by googling, stackoverflowing, and reading RTFM, but if the answer is right there it is so much better. Wouldn't you agree? > > I'd like someone else to weigh in on this. If this were a `Set` that eventually would be publicly accessible somewhere (by normal FX users) I'd definitely not want this. In this case however, it is (for now at least) only used internally, so I don't care much if it has a message -- just be aware the users might see this if this class ever **does** get exposed (like `BitSet` was). > > I also don't understand your point about man hours saved and cognitive load. The message is perfectly clear, you can't call that method, and the reason is clearly documented, and in the context of collections, it means the set cannot be mutated (by you). The creator of the set should be well aware that the set is read only after being frozen. Any external class that it is being exposed to does not need to be aware of how this is achieved (the method that you get it from will clearly say it is an "immutable set" or some such). A message about the set being frozen will just be confusing (What does frozen mean? How do I unfreeze it? Who froze it? Why is this `Set` special from other unmodifiable sets which don't mention this?) It's a very minor point, John. The exception by itself answers the question of "what" happened, but not "why". All I suggest is to explain "why". But again, it's just a minor suggestion. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520017611 From kcr at openjdk.org Mon Mar 11 16:43:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Mar 2024 16:43:14 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v7] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Sat, 9 Mar 2024 13:46:08 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add @Deprecated tag modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 82: > 80: * @deprecated use {@link #getStyleClassNames()} instead > 81: */ > 82: @Deprecated(forRemoval = true) Given that the class itself is deprecated for removal, marking this method as deprecated is unnecessary. modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 93: > 91: */ > 92: @Deprecated(forRemoval = true) > 93: public Set getStyleClassSet() { Given that the class itself is deprecated for removal, marking this method as deprecated is unnecessary. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520042680 PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520037406 From kcr at openjdk.org Mon Mar 11 16:43:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Mar 2024 16:43:13 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> Message-ID: On Mon, 11 Mar 2024 16:23:46 GMT, Andy Goryachev wrote: >> I'd like someone else to weigh in on this. If this were a `Set` that eventually would be publicly accessible somewhere (by normal FX users) I'd definitely not want this. In this case however, it is (for now at least) only used internally, so I don't care much if it has a message -- just be aware the users might see this if this class ever **does** get exposed (like `BitSet` was). >> >> I also don't understand your point about man hours saved and cognitive load. The message is perfectly clear, you can't call that method, and the reason is clearly documented, and in the context of collections, it means the set cannot be mutated (by you). The creator of the set should be well aware that the set is read only after being frozen. Any external class that it is being exposed to does not need to be aware of how this is achieved (the method that you get it from will clearly say it is an "immutable set" or some such). A message about the set being frozen will just be confusing (What does frozen mean? How do I unfreeze it? Who froze it? Why is this `Set` special from other unmodifiable sets which don't mention this?) > > It's a very minor point, John. The exception by itself answers the question of "what" happened, but not "why". All I suggest is to explain "why". > > But again, it's just a minor suggestion. I'm not sure there is a need, but if text is added, it should be something simple like "Unmodifiable set". I would _not_ use the word "freeze" since there is no such concept in the API. From the POV of the application, the set is unmodifiable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520031043 From kcr at openjdk.org Mon Mar 11 16:43:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Mar 2024 16:43:14 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v6] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <1gFAZoAMcetzGeaUyvgvZS-mcwcLL5qcBxwE99nHuRE=.1a77c7ec-726a-4df7-a28b-53bdb420f1d1@github.com> Message-ID: On Sat, 9 Mar 2024 13:42:55 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 32: >> >>> 30: * @deprecated for removal >>> 31: */ >>> 32: public final class StyleClass { >> >> Needs the `@Deprecated(forRemoval = true)` annotation on the class, and the doc tag needs an explanation of why it's being removed ("erroneously exposed", "no longer needed", "flawed from the start"...) and what should be used instead, if at all. > > I added it. > > Technically, we could leave this class in, but it would just be a dead class that serves no purpose within FX, at least, once the `SimpleSelector` and `CompoundSelector` classes have been moved to internal packages. > > I'm wondering if I should add any deprecations in this PR at all, as now it requires a CSR. This could be all handled in the PR that moves these classes to internal packages. Ideally, you would not need any deprecations in this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520046722 From jhendrikx at openjdk.org Mon Mar 11 16:47:14 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 16:47:14 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v8] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Remove deprecations ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/16da6eb0..2392d8db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=06-07 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Mon Mar 11 16:54:25 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 16:54:25 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v9] In-Reply-To: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: > Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Move getStyleClassNames to location it was introduced to reduce diff ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/2392d8db..e4e3a7ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=07-08 Stats: 16 lines in 1 file changed: 5 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316 From jhendrikx at openjdk.org Mon Mar 11 16:54:25 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 16:54:25 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v8] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <13zHV0JmFWOzirhZdBaD7kTe0fGZmkruMjuXftLRKzI=.cd851421-fab8-4c78-a100-ff11ef36e1fc@github.com> On Mon, 11 Mar 2024 16:47:14 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Remove deprecations I think this PR now no longer needs a CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1988941299 From angorya at openjdk.org Mon Mar 11 17:00:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Mar 2024 17:00:00 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff looks good to me. how do we undo the csr command? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-1928419119 From angorya at openjdk.org Mon Mar 11 17:00:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Mar 2024 17:00:00 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v5] In-Reply-To: <9jWgk42Ew2Du-RG7F63lAcT6ZI7R9SFtClV6VPyc28k=.d904c263-57ee-4bf1-9838-d617e722db85@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <40V0uZSdMHES8pZeCt_dZIhmb6FWIcRauCorbkEhGeI=.c6aefa54-7c3e-429e-aa54-1d6db93b164e@github.com> <9jWgk42Ew2Du-RG7F63lAcT6ZI7R9SFtClV6VPyc28k=.d904c263-57ee-4bf1-9838-d617e722db85@github.com> Message-ID: On Sat, 9 Mar 2024 06:08:34 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 96: >> >>> 94: : maximumCapacity == 2 ? new Duo<>() >>> 95: : maximumCapacity < 10 ? new Hashless<>(maximumCapacity) // will reject negative values >>> 96: : new OpenAddressed<>(maximumCapacity); >> >> I wonder if standard HashSet should be used instead of OpenAddressed one, or should there be another threshold which results in a HashSet, to support large sets? >> >> Or we can reasonably guarantee that these sets are always small? > > It's possible to use the standard `HashSet` as a final fallback (or even to replace `OpenAddressed`), although it would need to be wrapped so support the `freeze` method (or we need to implement this differently). > > There are a few reasons however not to do so: > - `HashSet` doesn't support `freeze` so we'd need to copy it after it is created; we can't use `Set.of` as this would also require making a copy of the entries first (the entries are added one by one because empty values are filtered) -- the solution in this PR carefully avoids all unnecessary copying and allocations to achieve the better performance > - The sets are indeed in almost all cases very small (hence the optimizations for small sets) -- they contain style classes that apply to a single node or a single selector. Nodes with many style classes applied to them (ie. 10 or more) I think rarely occurs in practice. Same goes for selectors; you'd have to have something like `a > b c d e f g h i > j` as selector -- remember that this doesn't apply to something like `a, b, c, d, e, f, g, h, i, j`, as they are actually 10 different selectors with 1 style each. > - `HashSet` is less memory efficient (between 21.5 to 26.7 bytes per entry with the load factor varying between 0.75 and 0.75 * 0.5; `16 + 4 / lf` bytes per entry) vs `OpenAddressed` which requires between 5.7 and 13.3 bytes per entry (due to its load factor variation between 0.3 and 0.7; `4 / lf` per entry) -- why isn't the JDK using open addressed then you may wonder? Well, it actually does in its `Set.of` implementation, but not for `HashSet`, primarily because `HashSet` has less worse edge cases when hash codes are poor, and it has to be more generally usable (open addressed tables degrade easier and require more maintenance when under constant modification, which doesn't apply for us here). makes sense, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1520069263 From jhendrikx at openjdk.org Mon Mar 11 17:27:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 17:27:59 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: <45NcThPE7wQ0iKTwITL21sK9i5TbAXVEHxBUei5-0x0=.a4ea0965-ca7f-492c-850c-ecd11ae651b0@github.com> On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff I think its /csroff or something... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1989020682 From kcr at openjdk.org Mon Mar 11 19:33:20 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 11 Mar 2024 19:33:20 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v9] In-Reply-To: References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> Message-ID: On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case) as it was not sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the improvements in this PR, the fastest refresh had become 89 ms. The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Move getStyleClassNames to location it was introduced to reduce diff I was about to reply, but I see that the Skara bot beat me to it. :) I'll double-check later (or Andy can), and if there are no public API implications, issue the `/csr unneeded` command. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1989272855 From jhendrikx at openjdk.org Mon Mar 11 19:50:20 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 11 Mar 2024 19:50:20 GMT Subject: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v15] In-Reply-To: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com> <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com> Message-ID: On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx wrote: >> There are a number of tickets open related to text rendering: >> >> https://bugs.openjdk.org/browse/JDK-8314215 >> >> https://bugs.openjdk.org/browse/JDK-8145496 >> >> https://bugs.openjdk.org/browse/JDK-8129014 >> >> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap. This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments. Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA BBB CCC` (note the **double** spaces) gets split up into `AAA `, `BBB ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA ` doesn't, so the engine wraps it to `AA` + `A ` or something). >> >> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space). With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit). >> >> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's. >> >> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS. >> >> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped. In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move. The spaces are all getting appended to the previous line. When you cursor through these spaces, the cursor can be rendered out of the control's bounds. To illustrate, if you have the text `AAA BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up. If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`. >> >> The above behavior has NOT changed, is pretty standard for wrapped text controls,... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Change test to use the more common Arial font and add assumptions Keep open ------------- PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1989306284 From angorya at openjdk.org Mon Mar 11 19:54:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 11 Mar 2024 19:54:18 GMT Subject: RFR: JDK-8322964 Optimize performance of CSS selector matching [v9] In-Reply-To: <45NcThPE7wQ0iKTwITL21sK9i5TbAXVEHxBUei5-0x0=.a4ea0965-ca7f-492c-850c-ecd11ae651b0@github.com> References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com> <45NcThPE7wQ0iKTwITL21sK9i5TbAXVEHxBUei5-0x0=.a4ea0965-ca7f-492c-850c-ecd11ae651b0@github.com> Message-ID: On Mon, 11 Mar 2024 17:25:26 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Move getStyleClassNames to location it was introduced to reduce diff > > I think its /csroff or something... @hjohn is right - no public API changes remain in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1989313144 From mhanl at openjdk.org Mon Mar 11 22:06:17 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 11 Mar 2024 22:06:17 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 21:08:25 GMT, Andy Goryachev wrote: >> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. >> >> The new property reacts to changes in the following properties: >> - ellipsisString >> - font >> - height >> - text >> - width >> - wrapText >> >> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. >> >> **Alternative** >> >> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? >> >> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. >> >> **See Also** >> >> * [JDK-8091891](https://bugs.openjdk.org/browse/JDK-8091891) TreeView: There is no tooltip available on truncated node >> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > labeled helper Changes requested by mhanl (Committer). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 133: > 131: protected double computePrefWidth(double height, double topInset, double rightInset, double bottomInset, > 132: double leftInset) { > 133: if (LabeledHelper.isUseContentWidth() || isDeferToParentForPrefWidth) { I'm not conviced that this is the correct solution here. First of all I would keep this PR simple and ONLY add the truncated Property. Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. In order to move this forward, I would like to see only the necessary changes, which is the truncated property. Some tests for it would be good as well. ------------- PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-1929489141 PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1520481720 From mariushanl at web.de Mon Mar 11 22:49:27 2024 From: mariushanl at web.de (Marius Hanl) Date: Mon, 11 Mar 2024 23:49:27 +0100 Subject: Aw: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Mon Mar 11 23:19:58 2024 From: mariushanl at web.de (Marius Hanl) Date: Tue, 12 Mar 2024 00:19:58 +0100 Subject: Skin ListenerHelper Message-ID: An HTML attachment was scrubbed... URL: From r.lichtenberger at gmail.com Tue Mar 12 06:23:42 2024 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 12 Mar 2024 07:23:42 +0100 Subject: Proposal: Public InputMap (v2) In-Reply-To: References: Message-ID: <7b20df6b-8c58-4356-8e86-30233eb46d0a@gmail.com> I've had a look into the proposal and I like it a lot. I've had numerous encounters with "little tweaks" to keyboard handling and/or behaviour that I had to work around, all of which would (as far as I can tell) have been avoidable, if this API were in existence. So while there is quite some "API surface", as an application developer I can't wait to see this happening. It will go a long way to make JavaFX more easily usable. --Robert Am 11.03.24 um 16:22 schrieb Andy Goryachev: > > Dear JavaFX developers: > > Thank you all for your feedback on my earlier Behavior/InputMap > proposal [6], [7].? There was some positive reaction to the idea of > allowing for easy customization of JavaFX controls behavior, as well > as some push back.? Some of the objections were: > > * desire for some static behavior to avoid the per-instance penalty > * clearer separation of concerns between controls, skins, and behaviors > * desire to have some sort of public API for behaviors > * need for addressing an issue with the event handler execution > order between application and skins > > I would like to restart the discussion by submitting the updated > proposal [0] which addresses the issues raised earlier.? The new > proposal retains the idea of allowing wider customization of key > mappings via the InputMap.? The new features include: > > * separation of SkinInputMap from the control's InputMap > * enabling static skin input maps for stateless behaviors > * explicit priority levels for event handlers and key mappings > created by the application and by the skin > > The ideas put forth in this proposal have been validated with the > proof-of-concept migration of some non-trivial controls: > > * complex popup-like controls: ComboBox, ColorPicker, DatePicker > * complex text input controls: PasswordField, TextArea, TextField > * control with a stateless behavior: TabPane > > as well as a brand new RichTextArea control being incubated [8]. > > Please take a look at the proposal [0], a list of discussion points > [1], and the API Specification (javadoc) [2]. While the proposed API > is ready for review, it isn't complete nor set in stone. We are > looking for feedback, and will update the proposal based on the > suggestions we receive from the community.? We encourage you to > comment either in the mailing list, or by leaving comments inline in a > draft pull request [3]. > > For context, the links to the original RFE [4] and the earlier > proposals [6], [7] are provided below. > > What do you think? > > -andy > > *References* > > [0] > Proposal:https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md > > > [1] Discussion > points:https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md > > > [2] API specification > (javadoc):https://cr.openjdk.org/~angorya/InputMapV2/javadoc/ > > > [3] Draft Pull Request for API comments and > feedback:https://github.com/openjdk/jfx/pull/1395 > > > [4] Public InputMap RFE:https://bugs.openjdk.org/browse/JDK-8314968 > > > [5] Documenting behaviors > (WIP):https://github.com/openjdk/jfx/tree/master/doc-files/behavior > > > [6] Earlier > proposal:https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md > > > [7] Earlier proposal in the OpenJFX mailing > list:https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html > > > [8] RichTextArea > (Incubator)https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Mar 12 08:39:56 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 12 Mar 2024 09:39:56 +0100 Subject: Skin ListenerHelper In-Reply-To: References: Message-ID: <04f9bede-3244-08c8-6bae-6f9ca6051f3e@gmail.com> With subscriptions these kinds of helpers are really not needed anymore. Just do: ???? Subscription combined = Subscription.combine( ???????? property1.subscribe( ... ), ???????? property2.subscribe( ... ) ???? ); And clean it up with `combined.unsubscribe` in `dispose`. For non-property clean-ups, you can add additional cleanup like this: ???? Subscription combined = subscription.and(() -> { extra clean-up code }); Alternatively, you can use `when(skinActive)` on most of your observers, and set `skinActive` to `false` in dispose. SkinBase was a mistake IMHO.? Helper methods that require state are better placed in an instanced utility, not in a base class. What does it mean that a "TableViewSkin" is-a "SkinBase". Using inheritance to get access to such helpers (which need a little bit of state) is really a classic mistake and misuse of inheritance. ListenerHelper is much better in that regard, much more generally usable (since it uses composition), and stores its state in its own instance. --John On 12/03/2024 00:19, Marius Hanl wrote: > Since I see multiple discussions about the behaviour API and the > RichTextControl, I want to ask another, still important question: > What is about the Skin cleanup ListenerHelper? > We now have 2 implementations of such utility - the > LambdaMultiplePropertyChangeListenerHandler > and the > ListenerHelper > I would really see that this topic is closed and cleaned up, with all > TODOs that emerged from this than 2-3 new other open implemention > changes on different topics. > The class is also not public, so extending from something else than > SkinBase makes it hard to write your own skin as there is no proper > help to register and dispose your listener. > -- Marius -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Tue Mar 12 09:36:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 12 Mar 2024 09:36:33 GMT Subject: [jfx21u] RFR: 8322795: CSS performance regression up to 10x Message-ID: 8322795: CSS performance regression up to 10x ------------- Commit messages: - Backport 1dff7a1618a945a9a10ad2168f78aad3658e91a9 Changes: https://git.openjdk.org/jfx21u/pull/54/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=54&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322795 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx21u/pull/54.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/54/head:pull/54 PR: https://git.openjdk.org/jfx21u/pull/54 From kcr at openjdk.org Tue Mar 12 13:51:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Mar 2024 13:51:31 GMT Subject: [jfx22u] RFR: 8327979: Change JavaFX release version to 22.0.2 in jfx22u Message-ID: Bump version number to 22.0.2 ------------- Commit messages: - 8327979: Change JavaFX release version to 22.0.2 in jfx22u Changes: https://git.openjdk.org/jfx22u/pull/19/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=19&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327979 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx22u/pull/19.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/19/head:pull/19 PR: https://git.openjdk.org/jfx22u/pull/19 From kcr at openjdk.org Tue Mar 12 15:36:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Mar 2024 15:36:32 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:45:06 GMT, Hima Bindu Meda wrote: > Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms I haven't looked at it detail or tested it yet, but I did spot one thing that raises a question. @johanvos or @tiainen can one of you be the second reviewer? modules/javafx.web/src/main/native/Source/ThirdParty/icu/CMakeLists.txt line 593: > 591: > 592: # Get just file name without extension > 593: set(ICU_DATA_FILE_NAME "icudt74l") Shouldn't this be 742? ------------- PR Review: https://git.openjdk.org/jfx/pull/1398#pullrequestreview-1931321499 PR Comment: https://git.openjdk.org/jfx/pull/1398#issuecomment-1991854992 PR Review Comment: https://git.openjdk.org/jfx/pull/1398#discussion_r1521623658 From hmeda at openjdk.org Tue Mar 12 15:36:32 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 12 Mar 2024 15:36:32 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 Message-ID: Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms ------------- Commit messages: - Revert file permissions similar to master - Tab correction - Resolve PR error - Tab Correction - Merge branch 'master' into icu-74 - updated LICENSE - white space corrections - Add missing header files - Update ICU to v74.2 Changes: https://git.openjdk.org/jfx/pull/1398/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324326 Stats: 10765 lines in 123 files changed: 3601 ins; 1545 del; 5619 mod Patch: https://git.openjdk.org/jfx/pull/1398.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1398/head:pull/1398 PR: https://git.openjdk.org/jfx/pull/1398 From kcr at openjdk.org Tue Mar 12 15:36:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Mar 2024 15:36:32 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:56:55 GMT, Kevin Rushforth wrote: >> Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms > > modules/javafx.web/src/main/native/Source/ThirdParty/icu/CMakeLists.txt line 593: > >> 591: >> 592: # Get just file name without extension >> 593: set(ICU_DATA_FILE_NAME "icudt74l") > > Shouldn't this be 742? Never mind. I see now that's an `l` not a `1` after the `74. Sorry for the noise. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1398#discussion_r1521633912 From hmeda at openjdk.org Tue Mar 12 15:36:32 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 12 Mar 2024 15:36:32 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 15:02:48 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/ThirdParty/icu/CMakeLists.txt line 593: >> >>> 591: >>> 592: # Get just file name without extension >>> 593: set(ICU_DATA_FILE_NAME "icudt74l") >> >> Shouldn't this be 742? > > Never mind. I see now that's an `l` not a `1` after the `74. Sorry for the noise. icu4c-74_2-data-bin-l contains the dat file named as icudt74l.dat. Hence, this is correct. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1398#discussion_r1521671716 From angorya at openjdk.org Tue Mar 12 15:53:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 12 Mar 2024 15:53:18 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 22:03:49 GMT, Marius Hanl wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> labeled helper > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 133: > >> 131: protected double computePrefWidth(double height, double topInset, double rightInset, double bottomInset, >> 132: double leftInset) { >> 133: if (LabeledHelper.isUseContentWidth() || isDeferToParentForPrefWidth) { > > I'm not conviced that this is the correct solution here. > First of all I would keep this PR simple and ONLY add the truncated Property. > Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. > > IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. > > In order to move this forward, I would like to see only the necessary changes, which is the truncated property. Some tests for it would be good as well. Thank you for the feedback! The property is being added to Labeled, which happens to be a base class for the cells' skins. The truncated property therefore must work in all the subclasses, even those where computePrefWidth is hacked via `Properties.DEFER_TO_PARENT_PREF_WIDTH`. > Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. This is a much more difficult task: First, it needs a careful discussion on which APIs to add, if any (there is a possibility that some people might say that no new APIs are needed as one can always create an instance of Text or Label and use it to get the sizing). There might be a need to undo the hacks made by the founding father such as `Properties.DEFER_TO_PARENT_PREF_WIDTH`. I would say all this is out of scope for this PR, as it achieves its goal without introducing the new APIs. > IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. Why cells are controls is slightly beyond me, but who am I to ask? I would say there should be one control in this picture, and that is TableView (or any other cell-based control) whose job is to size and lay out its various parts. The current design is different, and it is out of scope for this PR to change the design. > In order to move this forward, I would like to see only the necessary changes And that 's exactly what you see here - only the necessary changes (that unfortunately include undoing the earlier hacks in cells). As for tests - I certainly agree, but that would be a manual test. The behavior can be verified with the examples in JDK-8205211, I just felt the value of a manual test is rather low. What I would rather see is an automated test that actually verifies the new property behavior down to a pixel. Any ideas how to make one? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1521720911 From arapte at openjdk.org Tue Mar 12 16:47:19 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 12 Mar 2024 16:47:19 GMT Subject: [jfx22u] RFR: 8327979: Change JavaFX release version to 22.0.2 in jfx22u In-Reply-To: References: Message-ID: <5YTDEsG8JTGiKSqDI_7-dOZeA7aMK5Se7w6T4TBNT5g=.0b89406a-42f9-4409-82e3-0dac25b3c0c0@github.com> On Tue, 12 Mar 2024 13:44:48 GMT, Kevin Rushforth wrote: > Bump version number to 22.0.2 Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/19#pullrequestreview-1931624966 From kcr at openjdk.org Tue Mar 12 17:00:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 12 Mar 2024 17:00:24 GMT Subject: [jfx22u] Integrated: 8327979: Change JavaFX release version to 22.0.2 in jfx22u In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 13:44:48 GMT, Kevin Rushforth wrote: > Bump version number to 22.0.2 This pull request has now been integrated. Changeset: fdb2002b Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/fdb2002bad9fb3d1e36c0542182bdf4d1d0dd32f Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8327979: Change JavaFX release version to 22.0.2 in jfx22u Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx22u/pull/19 From mariushanl at web.de Tue Mar 12 18:27:36 2024 From: mariushanl at web.de (Marius Hanl) Date: Tue, 12 Mar 2024 19:27:36 +0100 Subject: =?UTF-8?Q?Aw=3A=C2=A0Re=3A_Skin_ListenerHelper?= In-Reply-To: <04f9bede-3244-08c8-6bae-6f9ca6051f3e@gmail.com> References: <04f9bede-3244-08c8-6bae-6f9ca6051f3e@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Mar 12 18:51:08 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 12 Mar 2024 18:51:08 +0000 Subject: =?utf-8?B?UmU6IEF3OsKgUmU6IFNraW4gTGlzdGVuZXJIZWxwZXI=?= In-Reply-To: References: <04f9bede-3244-08c8-6bae-6f9ca6051f3e@gmail.com> Message-ID: The chapter with leaking skins is almost completed: memory leaks are plugged, the testing framework is in place, switching is fully supported. The only open ticket under umbrella JDK-8241364 ? Cleanup skin implementations to allow switching is due to InputMap https://bugs.openjdk.org/browse/JDK-8245303 , which can be extracted into a separate issue (and which will be solved by design if the InputMap v2 proposal is accepted). As far as the removal goes, we do have JDK-8296076 Remove internal class LambdaMultiplePropertyChangeListenerHandler which is waiting its turn. -andy From: openjfx-dev on behalf of Marius Hanl Date: Tuesday, March 12, 2024 at 11:27 To: openjfx-dev at openjdk.org , John Hendrikx Subject: Aw: Re: Skin ListenerHelper Thanks for providing the examples with the Subscription API. Note though that I rather want to talk about that we have 2 different components taking care of the listeners and both are mixed up. ListenerHelper is totally fine for me, but that should be the only one. It would be nice to complete the chapter of leaking skins completely before tackling the next big changes. My opinion though. -- Marius Am 12.03.24, 09:40 schrieb John Hendrikx : With subscriptions these kinds of helpers are really not needed anymore. Just do: Subscription combined = Subscription.combine( property1.subscribe( ... ), property2.subscribe( ... ) ); And clean it up with `combined.unsubscribe` in `dispose`. For non-property clean-ups, you can add additional cleanup like this: Subscription combined = subscription.and(() -> { extra clean-up code }); Alternatively, you can use `when(skinActive)` on most of your observers, and set `skinActive` to `false` in dispose. SkinBase was a mistake IMHO. Helper methods that require state are better placed in an instanced utility, not in a base class. What does it mean that a "TableViewSkin" is-a "SkinBase". Using inheritance to get access to such helpers (which need a little bit of state) is really a classic mistake and misuse of inheritance. ListenerHelper is much better in that regard, much more generally usable (since it uses composition), and stores its state in its own instance. --John On 12/03/2024 00:19, Marius Hanl wrote: Since I see multiple discussions about the behaviour API and the RichTextControl, I want to ask another, still important question: What is about the Skin cleanup ListenerHelper? We now have 2 implementations of such utility - the LambdaMultiplePropertyChangeListenerHandler and the ListenerHelper I would really see that this topic is closed and cleaned up, with all TODOs that emerged from this than 2-3 new other open implemention changes on different topics. The class is also not public, so extending from something else than SkinBase makes it hard to write your own skin as there is no proper help to register and dispose your listener. -- Marius -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Mar 12 21:36:03 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 12 Mar 2024 21:36:03 +0000 Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) In-Reply-To: References: Message-ID: Thank you for the feedback! The property is being added to Labeled, which happens to be a base class for the cells' skins. The truncated property therefore must work in all the subclasses, even those where computePrefWidth is hacked via `Properties.DEFER_TO_PARENT_PREF_WIDTH`. > Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. This is a much more difficult task: First, it needs a careful discussion on which APIs to add, if any (there is a possibility that some people might say that no new APIs are needed as one can always create an instance of Text or Label and use it to get the sizing). There might be a need to undo the hacks made by the founding father such as `Properties.DEFER_TO_PARENT_PREF_WIDTH`. I would say all this is out of scope for this PR, as it achieves its goal without introducing the new APIs. > IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. Why cells are controls is slightly beyond me, but who am I to ask? I would say there should be one control in this picture, and that is TableView (or any other cell-based control) whose job is to size and lay out its various parts. The current design is different, and it is out of scope for this PR to change the design. > In order to move this forward, I would like to see only the necessary changes And that 's exactly what you see here - only the necessary changes (that unfortunately include undoing the earlier hacks in cells). As for tests - I certainly agree, but that would be a manual test. The behavior can be verified with the examples in JDK-8205211, I just felt the value of a manual test is rather low. What I would rather see is an automated test that actually verifies the new property behavior down to a pixel. Any ideas how to make one? -andy From: Marius Hanl Date: Monday, March 11, 2024 at 15:49 To: Daniel Peintner Cc: Andy Goryachev , openjfx-dev at openjdk.org Subject: Aw: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) I think this can still be implemented for cells without any special handling. It is rather unexpected that a cell does not give the correct pref width, so we need to think about how to improve the current situation. In my opinion, it should not be the concern of the Cell to give the actual width of the column it belongs to, but the pref width, as we would expect. We need to check where this is called. -- Marius Gesendet: Donnerstag, 07. M?rz 2024 um 16:07 Uhr Von: "Daniel Peintner" An: "Andy Goryachev" Cc: "openjfx-dev at openjdk.org" Betreff: Re: [External] : Re: Q: Labeled.textTruncated Property (RFE) Andy, all, Some comments below: 1. Even if it is possible to do the same with public means I think it is useful. Anyhow we need to promote the solutions better (e.g., on StackOverflow) 2. I tried to achieve what you did in JavaFX core for my use-case, TableView cells. * In my real application I tried and failed since the boolean condition in https://github.com/openjdk/jfx/blob/8a5cb17ed6525b0a218595865ead3e399e3b29dd/modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java#L838-L841 always reports false * Hence I tried to create a short self-contained TableView example to explore it further, see Gist https://gist.github.com/danielpeintner/9b561eb57261e8c5bc608f1346df74cf It still fails :-( * The Email field in the table ideally should report "true" once the text entered exceeds the visible view. Somehow it fails... getWidth() and prefWidth(-1) always return the same double value. Please try the Gist above to confirm. e.g., edit cell and extend the email text to longer than column width --> results in System.out "Table-Email-Cell !isWrapText: 182.0 < 182.0 --> false" * Hence I also added a *normal* MyLabel example which does work as intended Maybe I miss something obvious but TableCells seem to be special Labeled instances and behave differently. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Wed, Mar 6, 2024 at 6:10?PM Andy Goryachev > wrote: Dear Daniel: Thank you for confirming the need for this enhancement. Your case is covered by this ticket (I included a wrong ticket in my previous message by mistake, sorry): JDK-8327483 TreeView: Allow for tooltip when cell text is truncated My only concern is that this functionality theoretically can be achieved by the application code just as easy, since the solution does not use any internal APIs, as can be seen here: https://github.com/openjdk/jfx/pull/1389 -andy From: Daniel Peintner > Date: Tuesday, March 5, 2024 at 23:53 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: [External] : Re: Q: Labeled.textTruncated Property (RFE) Hi Andy, all, Thank you for the effort which I very much appreciate. We have a similar use-case as the one mentioned in JDK-8205211. We would like to show a Tooltip with the corresponding text once the text is shown with ellipsis for a TableCell. The *hacky* solution we are using is sketched in [1] and requires us to calculate the width again. Moreover, once different fonts come into the game it becomes even more brittle. Having an easy (easier?) way to detect and observe whether a label is truncated is of importance for us and definitely improves the usability of JavaFX. Thanks, -- Daniel [1] https://stackoverflow.com/a/52432862 On Tue, Mar 5, 2024 at 10:15?PM Andy Goryachev > wrote: Dear colleagues: Do you think a new property, ReadOnlyBooleanProperty textTruncated, should be added to the Labeled control? On one hand, we do have a couple of tickets in JBS requesting that: * JDK-8091891 TreeView: There is no tooltip available on truncated node * JDK-8205211 Ability to show Tooltip only when text is shown with ellipsis (...) On the other hand, this functionality can in theory be implemented at the application level, although the number of changes required might be uncomfortably large in the case of Tree/TreeTable/TableView. JBS: * JDK-8092102 Labeled: truncated property Pull Request: https://github.com/openjdk/jfx/pull/1389 What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpk at openjdk.org Wed Mar 13 05:21:39 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 13 Mar 2024 05:21:39 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux Message-ID: Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. ------------- Commit messages: - RTL text test fix Changes: https://git.openjdk.org/jfx/pull/1399/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327471 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1399.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1399/head:pull/1399 PR: https://git.openjdk.org/jfx/pull/1399 From jvos at openjdk.org Wed Mar 13 08:35:18 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 13 Mar 2024 08:35:18 GMT Subject: [jfx21u] Integrated: 8322795: CSS performance regression up to 10x In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 09:27:37 GMT, Johan Vos wrote: > 8322795: CSS performance regression up to 10x This pull request has now been integrated. Changeset: c2600685 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/c2600685dbba9f33e01b9b0fcf2346df9b5e0011 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8322795: CSS performance regression up to 10x Backport-of: 1dff7a1618a945a9a10ad2168f78aad3658e91a9 ------------- PR: https://git.openjdk.org/jfx21u/pull/54 From fkirmaier at openjdk.org Wed Mar 13 08:58:20 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 13 Mar 2024 08:58:20 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 09:54:43 GMT, Johan Vos wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511 >> reverted accidental indentation chang > > @FlorianKirmaier I still think this would be a good addition. I believe there is only one open question (from Marius) so it would be great if you can answer that. @johanvos Great to see you would like to see it merged! I've worked on this topic together with @eduardsdv , So consider his response to be my answer to the question. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-1993853327 From jdv at openjdk.org Wed Mar 13 09:00:28 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 13 Mar 2024 09:00:28 GMT Subject: RFR: 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color Message-ID: <7AkAsjDvu9obdMli3ug5Prcc08k2AGaReL06-rUdD9Y=.6c5a0892-0bba-4281-933e-317d70d687a9@github.com> Updated test to get screen capture in different platforms to see how we are picking colors. Found that this test fails because it assumes that red,green & blue bands in the test image are of equal size and picks color based on that assumption. If we take 20 * 20 aligned image, each scanline is 3 red pixels -> 3 green pixels -> 8 blue pixels -> 3 green pixels -> 3 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. If we 48 * 48 unaligned image, each scanline is 7 red pixels -> 8 green pixels -> 19 blue pixels -> 7 green pixels -> 7 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. So when this 48 * 48 image is scaled to 336 * 336 in case of unalignedImage_Cover, we are calculating picking point for green color in such a way that it is hitting border of green and blue bands and test is failing. Only in this specific scenario we are scaling by large amount and the inappropriate color picking logic is failing. Updated color picking logic in such a way that appropriate weightage is given to each color and we pick that color properly even when we have large scaling. With this change test is passing on all platforms and there are no regressions seen in all test run. ------------- Commit messages: - Initial change Changes: https://git.openjdk.org/jfx/pull/1400/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255679 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1400.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1400/head:pull/1400 PR: https://git.openjdk.org/jfx/pull/1400 From fkirmaier at openjdk.org Wed Mar 13 09:16:16 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 13 Mar 2024 09:16:16 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com> References: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com> Message-ID: <8uL76ch06rlwD6XRJdQWkcZIGUR0zwTGCtgdTBwrbaM=.d5b55532-adf6-4f0d-baee-40ce343fce4e@github.com> On Tue, 23 Jan 2024 11:51:52 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > reverted accidental change in the .idea folder *push* It's still a important bug. If someone can guide me on how to write tests for this, i would put in the effort. Maybe we could make snapshot based tests? That should work on all platforms, right? (Like testing whether a specific RGB value appears) Has something in this direction been done somewhere? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1993885343 From lkostyra at openjdk.org Wed Mar 13 09:30:21 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 13 Mar 2024 09:30:21 GMT Subject: RFR: 8322619 Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: <8uL76ch06rlwD6XRJdQWkcZIGUR0zwTGCtgdTBwrbaM=.d5b55532-adf6-4f0d-baee-40ce343fce4e@github.com> References: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com> <8uL76ch06rlwD6XRJdQWkcZIGUR0zwTGCtgdTBwrbaM=.d5b55532-adf6-4f0d-baee-40ce343fce4e@github.com> Message-ID: On Wed, 13 Mar 2024 09:13:20 GMT, Florian Kirmaier wrote: > Maybe we could make snapshot based tests? That should work on all platforms, right? We have a whole suite of tests which use similar methods to perform checks, called robot tests. Since you want to check if a node was properly updated, and the best way to do that seems to be checking RGB values, I think a test for this case belongs right there. You could use robot utility to check color values of specific pixels on the screen. I think the best way to go about it would be to do something similar to what your test bug apps do (the ones attached to the JBS issue). Ideally I would try and look for first some form of confidence check (if correct controls are "on" and "off"), then progressing the animation and seeing if controls updated as intended. All robot tests are located in `tests/system/src/test/java/test/robot` and then they follow package names. I'm not 100% sure where this test should go though (I assume `.../javafx/scene`?). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-1993911947 From fkirmaier at openjdk.org Wed Mar 13 13:36:28 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 13 Mar 2024 13:36:28 GMT Subject: RFR: 8299423: JavaFX Mac system menubar leaks Message-ID: Based on my previous PR: https://github.com/openjdk/jfx/pull/987 This one only contains the test. Because it was fixed in some other PR. But i would like to see the Test being merged, to ensure it never breaks again. ------------- Commit messages: - Added test for JDK-8299423 Changes: https://git.openjdk.org/jfx/pull/1401/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299423 Stats: 112 lines in 1 file changed: 112 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1401.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1401/head:pull/1401 PR: https://git.openjdk.org/jfx/pull/1401 From angorya at openjdk.org Wed Mar 13 16:33:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 13 Mar 2024 16:33:20 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 05:17:40 GMT, Karthik P K wrote: > Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. > > Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 116: > 114: static volatile Scene scene; > 115: > 116: static final int WIDTH = 600; one suggestion: maybe we can reduce the font size from 48 to something smaller. that might also speed up the test as the cursor wouldn't have to traverse a lot of pixels. watch out for change in line breaks though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1399#discussion_r1523581496 From nlisker at openjdk.org Wed Mar 13 21:39:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Mar 2024 21:39:08 GMT Subject: RFR: 8327179: Update the 3D lighting application [v2] In-Reply-To: References: Message-ID: <3AT40woeft1L6RMd1dBVxRtp29BB83-2QVPQ2IMa49c=.5559d58e-2574-4528-9e3c-92803552e4f3@github.com> > Update for the 3D lighting test tool as described in the JBS issue. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Undo files move ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1387/files - new: https://git.openjdk.org/jfx/pull/1387/files/7f0e562f..2646489d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=00-01 Stats: 12 lines in 8 files changed: 2 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From nlisker at openjdk.org Wed Mar 13 21:44:52 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Mar 2024 21:44:52 GMT Subject: RFR: 8327179: Update the 3D lighting application [v3] In-Reply-To: References: Message-ID: > Update for the 3D lighting test tool as described in the JBS issue. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: copyright headers ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1387/files - new: https://git.openjdk.org/jfx/pull/1387/files/2646489d..3f2994ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=01-02 Stats: 80 lines in 8 files changed: 75 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From nlisker at openjdk.org Wed Mar 13 21:48:43 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Mar 2024 21:48:43 GMT Subject: RFR: 8327179: Update the 3D lighting application [v3] In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 16:49:28 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright headers > > tests/performance/3DLighting/src/main/java/lighting3D/Benchmark.java line 49: > >> 47: stopGraphic.setBoundsType(TextBoundsType.VISUAL); >> 48: stopGraphic.setFill(Color.RED); >> 49: stopGraphic.setFont(Font.font(20)); > > Play and Stop button could be same size. It would be good to look at. Currently the Stop button seems lesser than half size of play button. As you will see, the font sizes and visual sizes don't render as you would expect. Not sure why, but this way they look better. Perhaps small adjustments are in order, but if you match the sizes it comes out off. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1387#discussion_r1523953194 From nlisker at openjdk.org Wed Mar 13 22:32:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Mar 2024 22:32:59 GMT Subject: RFR: 8327179: Update the 3D lighting application [v4] In-Reply-To: References: Message-ID: > Update for the 3D lighting test tool as described in the JBS issue. Nir Lisker has updated the pull request incrementally with five additional commits since the last revision: - Added spacing - Renamed constant - Updated benchmark reset message - Simplified models creation - Revert resource package ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1387/files - new: https://git.openjdk.org/jfx/pull/1387/files/3f2994ff..9b3f0c5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=02-03 Stats: 48 lines in 6 files changed: 9 ins; 5 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From nlisker at openjdk.org Wed Mar 13 22:36:42 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 13 Mar 2024 22:36:42 GMT Subject: RFR: 8327179: Update the 3D lighting application In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 16:44:00 GMT, Ambarish Rapte wrote: > Executing the LightingSample manually fails with an exception I think the package names of the main and resources weren't aligned. > The copyright year new files should be 2024 only. Some new files have more than one copyright year. If you are moving any existing files then please use git mv so that the files are shown as moved. For now, for the ease of reviewing, I reverted the package name change. > The effect of lighting on mesh vs a box is quite different. I think this is the same issue you submitted in the past: https://bugs.openjdk.org/browse/JDK-8269133 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-1996005413 From angorya at openjdk.org Wed Mar 13 22:44:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 13 Mar 2024 22:44:44 GMT Subject: RFR: 8299423: JavaFX Mac system menubar leaks In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 13:32:32 GMT, Florian Kirmaier wrote: > Based on my previous PR: https://github.com/openjdk/jfx/pull/987 > This one only contains the test. > Because it was fixed in some other PR. > But i would like to see the Test being merged, to ensure it never breaks again. Changes requested by angorya (Reviewer). tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. 2023, 2024, tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 39: > 37: import org.junit.jupiter.api.BeforeAll; > 38: import org.junit.jupiter.api.AfterAll; > 39: import test.com.sun.javafx.pgstub.StubToolkit; please remove stub toolkit import tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 46: > 44: import java.util.concurrent.TimeUnit; > 45: > 46: import static org.junit.Assert.assertTrue; are we mixing junit4 and junit5? tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 68: > 66: * > 67: */ > 68: JMemoryBuddy.memoryTest((checker) -> { Thank you for explaining what the test attempts to do! minor: move javadoc above the `@Test`, and possibly rephrase the description, maybe something like this: "Tests whether the ActionListener associated with the system menu gets collected after said menu is removed." tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 93: > 91: new Thread(() -> { > 92: try { > 93: Thread.sleep(1000); can be replaced by Util.sleep() which throws nothing tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 107: > 105: assertTrue("Timeout waiting for setOnShown", latch.await(15, TimeUnit.SECONDS)); > 106: } catch (InterruptedException e) { > 107: e.printStackTrace(); why are we catching this exception? tests/system/src/test/java/test/javafx/scene/control/SystemMenuBarTest.java line 111: > 109: }); > 110: } > 111: please remove empty line ------------- PR Review: https://git.openjdk.org/jfx/pull/1401#pullrequestreview-1934750222 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523994355 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523992375 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523631028 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523989867 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523993493 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523994102 PR Review Comment: https://git.openjdk.org/jfx/pull/1401#discussion_r1523990184 From kcr at openjdk.org Wed Mar 13 23:01:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Mar 2024 23:01:42 GMT Subject: RFR: 8299423: JavaFX Mac system menubar leaks In-Reply-To: References: Message-ID: <7rlT1qn8hKYccN_G0AjUGwR3GYjS7wWiazn8RxBaIEk=.fe1394e8-05c6-4f96-9da6-5332e6ed8f5d@github.com> On Wed, 13 Mar 2024 13:32:32 GMT, Florian Kirmaier wrote: > Because it was fixed in some other PR. Which other PR fixed this? The JBS bug should be linked to that bug, and possibly reference it in the title. Speaking of which, the current title is not accurate and should be changed to reflect the fact that this is a testbug for the purpose of adding a test for a problem that is already fixed. Often we use a summary like one of the following: [testbug] Add a test for JDK-nnnnnnn [testbug] Add a test for macOS system menubar leaks ------------- PR Comment: https://git.openjdk.org/jfx/pull/1401#issuecomment-1996046830 From kcr at openjdk.org Wed Mar 13 23:20:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Mar 2024 23:20:47 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 Message-ID: Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. The following filter was used to produce the list of issues fixed in JavaFX 22: https://bugs.openjdk.org/issues/?filter=45407 Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. ------------- Commit messages: - 8328136: Create release notes for JavaFX 22 Changes: https://git.openjdk.org/jfx/pull/1402/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1402&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328136 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1402.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/jfx/pull/1402 From kcr at openjdk.org Wed Mar 13 23:20:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 13 Mar 2024 23:20:47 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: <0qpfV4jKcymsIBIidvMUzOAVl2fUzAV-wkkl0Eq9NgQ=.a659468b-0700-4f20-800c-b259f398859b@github.com> On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. @johanvos @abhinayagarwal can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1996065262 From angorya at openjdk.org Wed Mar 13 23:44:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 13 Mar 2024 23:44:41 GMT Subject: RFR: JDK-8327727: Changing the row factory of a TableView does not recreate the rows In-Reply-To: References: Message-ID: On Sat, 9 Mar 2024 19:52:25 GMT, Marius Hanl wrote: > The fix is very straightfoward. We request a recreation of all cells in the `VirtualFlow` by calling `flow.recreateCells()` when the `tableRowFactory` was changed. > > Funny enough, this was done in the `TreeTableViewSkin` again, hence it did not suffer from this bug. Removed as the table row factory is already handled in the `TableViewSkinBase`, now with the correct recreation. Verified with the updated Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest (TableView -> Row Factory:) on macOS 14.3.1 M1 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1396#pullrequestreview-1935402562 From duke at openjdk.org Thu Mar 14 07:35:46 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Thu, 14 Mar 2024 07:35:46 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. The filter mentioned in the description is private. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1996739167 From duke at openjdk.org Thu Mar 14 07:41:44 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Thu, 14 Mar 2024 07:41:44 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. Is it correct to include the following issue in release notes? > [JDK-8314147](https://bugs.openjdk.org/browse/JDK-8314147)|Updated the PhongMaterial documentation|graphics ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1996746344 From quizynox at gmail.com Thu Mar 14 09:05:43 2024 From: quizynox at gmail.com (Maxim Maximov) Date: Thu, 14 Mar 2024 13:05:43 +0400 Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: Just an opinion. Consider adding a Features or New API category to highlight related contributions and the fact that the platform is moving forward with new possibilities. It's hard work and imho Platform Preferences is long overdue and much more important to be sorted like enhancement. ??, 14 ???. 2024??. ? 11:41, Abhinay Agarwal : > On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > > > Release notes for the JavaFX 22 release. This will first go into > `master` and then be backported to the `jfx22` branch so it will be > available in that branch when JavaFX 22 is published, and from there also > synced into the `jfx22u` repo. > > > > The following filter was used to produce the list of issues fixed in > JavaFX 22: > > > > https://bugs.openjdk.org/issues/?filter=45407 > > > > Additionally, we had one issue, [JDK-8324658]( > https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` > label. That release note is included in the list of important changes. > > Is it correct to include the following issue in release notes? > > > [JDK-8314147](https://bugs.openjdk.org/browse/JDK-8314147)|Updated the > PhongMaterial documentation|graphics > > ------------- > > PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1996746344 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sykora at openjdk.org Thu Mar 14 09:22:50 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 14 Mar 2024 09:22:50 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:45:06 GMT, Hima Bindu Meda wrote: > Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms Builds and tests all ran fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1398#pullrequestreview-1936125774 From aghaisas at openjdk.org Thu Mar 14 09:57:43 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 14 Mar 2024 09:57:43 GMT Subject: RFR: 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color In-Reply-To: <7AkAsjDvu9obdMli3ug5Prcc08k2AGaReL06-rUdD9Y=.6c5a0892-0bba-4281-933e-317d70d687a9@github.com> References: <7AkAsjDvu9obdMli3ug5Prcc08k2AGaReL06-rUdD9Y=.6c5a0892-0bba-4281-933e-317d70d687a9@github.com> Message-ID: On Wed, 13 Mar 2024 08:56:13 GMT, Jayathirth D V wrote: > Updated test to get screen capture in different platforms to see how we are picking colors. Found that this test fails because it assumes that red,green & blue bands in the test image are of equal size and picks color based on that assumption. > > If we take 20 * 20 aligned image, each scanline is 3 red pixels -> 3 green pixels -> 8 blue pixels -> 3 green pixels -> 3 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. > > If we 48 * 48 unaligned image, each scanline is 7 red pixels -> 8 green pixels -> 19 blue pixels -> 7 green pixels -> 7 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. > > So when this 48 * 48 image is scaled to 336 * 336 in case of unalignedImage_Cover, we are calculating picking point for green color in such a way that it is hitting border of green and blue bands and test is failing. Only in this specific scenario we are scaling by large amount and the inappropriate color picking logic is failing. > > Updated color picking logic in such a way that appropriate weightage is given to each color and we pick that color properly even when we have large scaling. With this change test is passing on all platforms and there are no regressions seen in all test run. The fix looks good. Verified that if enabled, the test fails without this fix and passes with it. Tested on macOS 14. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1400#pullrequestreview-1936203035 From kpk at openjdk.org Thu Mar 14 10:37:26 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 14 Mar 2024 10:37:26 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: > Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. > > Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1399/files - new: https://git.openjdk.org/jfx/pull/1399/files/cdf341fc..06c81170 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1399&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1399&range=00-01 Stats: 19 lines in 1 file changed: 1 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1399.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1399/head:pull/1399 PR: https://git.openjdk.org/jfx/pull/1399 From craigraw at gmail.com Thu Mar 14 11:05:56 2024 From: craigraw at gmail.com (Craig Raw) Date: Thu, 14 Mar 2024 13:05:56 +0200 Subject: How to run an app headless? In-Reply-To: References: Message-ID: To pick up on this old thread - is a Linux x86-64 Monocle build a possibility for a future JavaFX release? AFAIK the last JavaFX release with this platform supported on Monocle was JavaFX 18. Thanks, Craig On Fri, Jun 9, 2023 at 9:30?AM Johan Vos wrote: > The monocle classes are not included in the default > distributions/artifact. In our downloads on > https://gluonhq.com/products/javafx/ we have specific SDK's that include > the Monocle classes. Note that we currently don't have automated builds for > Linux x86-64, since we use a devkit compiled from JDK-alike sources, see > https://github.com/gluonhq/devtoolskit/ for more info. That devkit > unfortunately doesn't yet compile some of the native classes in monocle. > > The usecase where Monocle is used because users want to run an app > headless is something I see very often. And it works. However, Monocle > isn't really created for this, as it is more a solution for embedded > systems. > I think there is real value in a separate, small, first-class Glass > platform that works headless (at the same level as gtk/mac/win) and that is > explicitly targeting running apps in headless mode. > > - Johan > > > > > On Thu, Jun 8, 2023 at 8:07?PM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > >> Hi, >> >> I'm building javafx with: >> ./gradlew -PincludeMonocle build >> >> And trying to test with: >> java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle >> -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java >> >> But it seems monocle was not included: >> java.lang.ClassNotFoundException: >> com.sun.glass.ui.monocle.MonoclePlatformFactory >> >> Any obvious mistake? >> >> -- Thiago >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Thu Mar 14 11:44:38 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 14 Mar 2024 12:44:38 +0100 Subject: How to run an app headless? In-Reply-To: References: Message-ID: Hi Craig, If you want JavaFX with a headless platform, have a look at https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless and provide feedback. - Johan On Thu, Mar 14, 2024 at 12:06?PM Craig Raw wrote: > To pick up on this old thread - is a Linux x86-64 Monocle build a > possibility for a future JavaFX release? AFAIK the last JavaFX release with > this platform supported on Monocle was JavaFX 18. > > Thanks, > Craig > > On Fri, Jun 9, 2023 at 9:30?AM Johan Vos wrote: > >> The monocle classes are not included in the default >> distributions/artifact. In our downloads on >> https://gluonhq.com/products/javafx/ we have specific SDK's that include >> the Monocle classes. Note that we currently don't have automated builds for >> Linux x86-64, since we use a devkit compiled from JDK-alike sources, see >> https://github.com/gluonhq/devtoolskit/ for more info. That devkit >> unfortunately doesn't yet compile some of the native classes in monocle. >> >> The usecase where Monocle is used because users want to run an app >> headless is something I see very often. And it works. However, Monocle >> isn't really created for this, as it is more a solution for embedded >> systems. >> I think there is real value in a separate, small, first-class Glass >> platform that works headless (at the same level as gtk/mac/win) and that is >> explicitly targeting running apps in headless mode. >> >> - Johan >> >> >> >> >> On Thu, Jun 8, 2023 at 8:07?PM Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> wrote: >> >>> Hi, >>> >>> I'm building javafx with: >>> ./gradlew -PincludeMonocle build >>> >>> And trying to test with: >>> java @/home/tsayao/jfx/build/run.args -Dglass.platform=Monocle >>> -Dmonocle.platform=Headless -Dprism.order=sw WindowTest.java >>> >>> But it seems monocle was not included: >>> java.lang.ClassNotFoundException: >>> com.sun.glass.ui.monocle.MonoclePlatformFactory >>> >>> Any obvious mistake? >>> >>> -- Thiago >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdv at openjdk.org Thu Mar 14 12:28:59 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 14 Mar 2024 12:28:59 GMT Subject: Integrated: 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color In-Reply-To: <7AkAsjDvu9obdMli3ug5Prcc08k2AGaReL06-rUdD9Y=.6c5a0892-0bba-4281-933e-317d70d687a9@github.com> References: <7AkAsjDvu9obdMli3ug5Prcc08k2AGaReL06-rUdD9Y=.6c5a0892-0bba-4281-933e-317d70d687a9@github.com> Message-ID: On Wed, 13 Mar 2024 08:56:13 GMT, Jayathirth D V wrote: > Updated test to get screen capture in different platforms to see how we are picking colors. Found that this test fails because it assumes that red,green & blue bands in the test image are of equal size and picks color based on that assumption. > > If we take 20 * 20 aligned image, each scanline is 3 red pixels -> 3 green pixels -> 8 blue pixels -> 3 green pixels -> 3 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. > > If we 48 * 48 unaligned image, each scanline is 7 red pixels -> 8 green pixels -> 19 blue pixels -> 7 green pixels -> 7 red pixels. So the blue pixels actually acquire more space in a scanline. Even in y direction pattern is same. > > So when this 48 * 48 image is scaled to 336 * 336 in case of unalignedImage_Cover, we are calculating picking point for green color in such a way that it is hitting border of green and blue bands and test is failing. Only in this specific scenario we are scaling by large amount and the inappropriate color picking logic is failing. > > Updated color picking logic in such a way that appropriate weightage is given to each color and we pick that color properly even when we have large scaling. With this change test is passing on all platforms and there are no regressions seen in all test run. This pull request has now been integrated. Changeset: c196454e Author: Jayathirth D V Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/c196454e76dec1cbcd028e12d99f052981a63a4e Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod 8255679: RegionBackgroundImageUITest.unalignedImage_Cover fails because of wrong color Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1400 From kpk at openjdk.org Thu Mar 14 13:05:43 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 14 Mar 2024 13:05:43 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: <1t3azTJQnh0Jdb7CaydgjKH9UEz9efhUxiekaN5O0g0=.372aa0cd-fbbc-4f2a-8fca-9df4014a4015@github.com> On Wed, 13 Mar 2024 16:30:27 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > tests/system/src/test/java/test/robot/javafx/scene/RTLTextFlowCharacterIndexTest.java line 116: > >> 114: static volatile Scene scene; >> 115: >> 116: static final int WIDTH = 600; > > one suggestion: maybe we can reduce the font size from 48 to something smaller. > that might also speed up the test as the cursor wouldn't have to traverse a lot of pixels. watch out for change in line breaks though. Thanks for suggesting this @andy-goryachev-oracle. I have made the changes in the test. I reduced the font size little bit only to make sure that the multiline text are not displayed in a single line. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1399#discussion_r1524832327 From kcr at openjdk.org Thu Mar 14 13:43:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 14 Mar 2024 13:43:43 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 07:32:54 GMT, Abhinay Agarwal wrote: > The filter mentioned in the description is private. Fixed. > Is it correct to include the following issue in release notes? > > > [JDK-8314147](https://bugs.openjdk.org/browse/JDK-8314147)|Updated the PhongMaterial documentation|graphics Yes, we usually list API doc changes (there are a few others in these release notes as well). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1997487948 From angorya at openjdk.org Thu Mar 14 15:05:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 14 Mar 2024 15:05:45 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: <7GTQjuXlRhXKWuNRUfSB8EuJ2mX-NEiHyL5X_TcnRdM=.22368a75-71a3-4700-957e-4e4f6dd2450d@github.com> On Thu, 14 Mar 2024 10:37:26 GMT, Karthik P K wrote: >> Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. >> >> Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments the changes look good. could we get the jenkins run passing ( I think the latest one failed - No 119)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1399#issuecomment-1997667698 From lkostyra at openjdk.org Thu Mar 14 16:12:01 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 14 Mar 2024 16:12:01 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations Message-ID: There were two different problems with this test's stability and HiDPI and both were fixed with this change. The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. ------------- Commit messages: - RobotTest: Stabilize testScreenCapture - Reactivate RobotTest.testScreenCapture Changes: https://git.openjdk.org/jfx/pull/1403/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8207379 Stats: 25 lines in 1 file changed: 15 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1403.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/jfx/pull/1403 From duke at openjdk.org Fri Mar 15 06:36:42 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Fri, 15 Mar 2024 06:36:42 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: <7vuACPe5yFLl2-sqKi7S9eKacHF1Qp2aWmCpxDlH9MU=.06f7f260-86bf-4dc7-a53c-13fd3be9332a@github.com> On Fri, 15 Mar 2024 02:12:36 GMT, Maxim Maximov wrote: > Consider adding a Features or New API category to. highlight related contributions and the fact that the platform is moving forward with new possibilities We do this at openjfx.io: https://openjfx.io/highlights/21/ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1999027291 From mhanl at openjdk.org Fri Mar 15 09:45:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 15 Mar 2024 09:45:45 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: References: Message-ID: <2HCtXcOo2J51kkvJAOuofqZu2c1f_Z-9EaNIhichZdY=.6b452172-e25e-4d1a-ad0b-47700e3a2ec7@github.com> On Tue, 12 Mar 2024 15:50:21 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 133: >> >>> 131: protected double computePrefWidth(double height, double topInset, double rightInset, double bottomInset, >>> 132: double leftInset) { >>> 133: if (LabeledHelper.isUseContentWidth() || isDeferToParentForPrefWidth) { >> >> I'm not conviced that this is the correct solution here. >> First of all I would keep this PR simple and ONLY add the truncated Property. >> Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. >> >> IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. >> >> In order to move this forward, I would like to see only the necessary changes, which is the truncated property. Some tests for it would be good as well. > > Thank you for the feedback! > > The property is being added to Labeled, which happens to be a base class for the cells' skins. The truncated property therefore must work in all the subclasses, even those where computePrefWidth is hacked via `Properties.DEFER_TO_PARENT_PREF_WIDTH`. > >> Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. > > This is a much more difficult task: First, it needs a careful discussion on which APIs to add, if any (there is a possibility that some people might say that no new APIs are needed as one can always create an instance of Text or Label and use it to get the sizing). There might be a need to undo the hacks made by the founding father such as `Properties.DEFER_TO_PARENT_PREF_WIDTH`. I would say all this is out of scope for this PR, as it achieves its goal without introducing the new APIs. > >> IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. > > Why cells are controls is slightly beyond me, but who am I to ask? I would say there should be one control in this picture, and that is TableView (or any other cell-based control) whose job is to size and lay out its various parts. The current design is different, and it is out of scope for this PR to change the design. > >> In order to move this forward, I would like to see only the necessary changes > > And that 's exactly what you see here - only the necessary changes (that unfortunately include undoing the earlier hacks in cells). > > As for tests - I certainly agree, but that would be a manual test. The behavior can be verified with the examples in JDK-8205211, I just felt the value of a manual test is rather low. What I would rather see is an automated test that actually verifies the new property behavior down to a pixel. Any ideas how to make one? Okay. Tests: Well, there are some properties we can test here: - wrapText = true -> height should be used -> check truncated - width changed -> check truncated - text changed -> check truncated ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1526007604 From mhanl at openjdk.org Fri Mar 15 09:45:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 15 Mar 2024 09:45:45 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: <2HCtXcOo2J51kkvJAOuofqZu2c1f_Z-9EaNIhichZdY=.6b452172-e25e-4d1a-ad0b-47700e3a2ec7@github.com> References: <2HCtXcOo2J51kkvJAOuofqZu2c1f_Z-9EaNIhichZdY=.6b452172-e25e-4d1a-ad0b-47700e3a2ec7@github.com> Message-ID: On Fri, 15 Mar 2024 09:41:25 GMT, Marius Hanl wrote: >> Thank you for the feedback! >> >> The property is being added to Labeled, which happens to be a base class for the cells' skins. The truncated property therefore must work in all the subclasses, even those where computePrefWidth is hacked via `Properties.DEFER_TO_PARENT_PREF_WIDTH`. >> >>> Second, I would rather want to see if this can be changed without adding some flags which once again will not help application developers that may want to extend something like this. >> >> This is a much more difficult task: First, it needs a careful discussion on which APIs to add, if any (there is a possibility that some people might say that no new APIs are needed as one can always create an instance of Text or Label and use it to get the sizing). There might be a need to undo the hacks made by the founding father such as `Properties.DEFER_TO_PARENT_PREF_WIDTH`. I would say all this is out of scope for this PR, as it achieves its goal without introducing the new APIs. >> >>> IMO, the separation of concern is wrong. A Cell should always give back the prefWidth, other callers should think if they want to use the pref width or the table column width. >> >> Why cells are controls is slightly beyond me, but who am I to ask? I would say there should be one control in this picture, and that is TableView (or any other cell-based control) whose job is to size and lay out its various parts. The current design is different, and it is out of scope for this PR to change the design. >> >>> In order to move this forward, I would like to see only the necessary changes >> >> And that 's exactly what you see here - only the necessary changes (that unfortunately include undoing the earlier hacks in cells). >> >> As for tests - I certainly agree, but that would be a manual test. The behavior can be verified with the examples in JDK-8205211, I just felt the value of a manual test is rather low. What I would rather see is an automated test that actually verifies the new property behavior down to a pixel. Any ideas how to make one? > > Okay. > > Tests: Well, there are some properties we can test here: > - wrapText = true -> height should be used -> check truncated > - width changed -> check truncated > - text changed -> check truncated You can check here how I manipulated the size of the stage of the `StageLoader`. https://github.com/openjdk/jfx/pull/1396 Than we can check and set some properties on any `Labeled`, probably the `Label` is good here. And on the stage if needed (width, height). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1526010108 From kpk at openjdk.org Fri Mar 15 11:40:44 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 15 Mar 2024 11:40:44 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 16:06:55 GMT, Lukasz Kostyra wrote: > There were two different problems with this test's stability and HiDPI and both were fixed with this change. > > The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. > > When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. > > Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. > > I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. > > Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. Tested the changes in Mac, Windows and Linux. The changes fixes the issues in Mac and Windows. I ran the test in Linux VM and it failed with and without the fix with error: RobotTest > testScreenCapture FAILED junit.framework.AssertionFailedError: expected: rgba(255,0,255,255) but was: rgba(0,0,0,255) at test.robot.javafx.scene.RobotTest.assertColorEquals(RobotTest.java:848) at test.robot.javafx.scene.RobotTest.testScreenCapture(RobotTest.java:774) Changing the scale also did not make any difference. Not sure if it is related to anything in VM. It is a Ubuntu 22.04 VM Added a minor comment inline. tests/system/src/test/java/test/robot/javafx/scene/RobotTest.java line 758: > 756: // Below calculations follow how getScreenCapture should calculate screen capture dimensions. This > 757: // is to make this code consistent and stable on HiDPI systems. > 758: int stageX = (int)stage.getX(); Minor: Do you think space should be added after `(int)` similar to `(double)`? ------------- PR Review: https://git.openjdk.org/jfx/pull/1403#pullrequestreview-1938661604 PR Review Comment: https://git.openjdk.org/jfx/pull/1403#discussion_r1526104191 From angorya at openjdk.org Fri Mar 15 15:12:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Mar 2024 15:12:22 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. I second the idea to point to the new APIs in a separate section. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1999863430 From jvos at openjdk.org Fri Mar 15 15:32:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 15 Mar 2024 15:32:07 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1402#pullrequestreview-1939231566 From kcr at openjdk.org Fri Mar 15 15:32:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 15 Mar 2024 15:32:07 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 15:05:23 GMT, Andy Goryachev wrote: > I second the idea to point to the new APIs in a separate section. This is something we could consider for JavaFX 23 -- separating out "features" from (other) "enhancements", but I'd rather not for the JavaFX 22 release, which is on Tuesday of next week (so this PR needs to be integrated no later than Monday). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1402#issuecomment-1999909330 From angorya at openjdk.org Fri Mar 15 15:32:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 15 Mar 2024 15:32:07 GMT Subject: RFR: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: <_lLWslGT8mDLfupmIfAFyWwn59NfEsePmBUastJXL2w=.b78d4ab3-045c-4d50-a5e7-ccc7cd145980@github.com> On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. sounds good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1402#pullrequestreview-1939243765 From kpk at openjdk.org Sat Mar 16 22:30:26 2024 From: kpk at openjdk.org (Karthik P K) Date: Sat, 16 Mar 2024 22:30:26 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 10:37:26 GMT, Karthik P K wrote: >> Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. >> >> Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Yes it was the build which failed. I'm facing some issue in running the tests on lab machine, I will update here once it is done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1399#issuecomment-2001823915 From kcr at openjdk.org Sat Mar 16 22:30:21 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Mar 2024 22:30:21 GMT Subject: RFR: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:45:06 GMT, Hima Bindu Meda wrote: > Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1398#pullrequestreview-1941048050 From mhanl at openjdk.org Sat Mar 16 22:30:30 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 16 Mar 2024 22:30:30 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic Message-ID: This PR fixes the issue that the initial column autosizing is wrong under some circumstances. The following things will break the initial autosizing: - Bold Column text (that is where I initially found this problem) - Another font / font size - Graphic The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well. It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me. The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text. I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy). ------------- Commit messages: - JDK-8186188: TableColumHeader: initial auto-size broken if has graphic Changes: https://git.openjdk.org/jfx/pull/1405/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8186188 Stats: 372 lines in 4 files changed: 369 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1405.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1405/head:pull/1405 PR: https://git.openjdk.org/jfx/pull/1405 From mhanl at openjdk.org Sat Mar 16 22:30:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 16 Mar 2024 22:30:26 GMT Subject: Integrated: JDK-8327727: Changing the row factory of a TableView does not recreate the rows In-Reply-To: References: Message-ID: <_77SBVJg1znQxMu5QEHkoHBwFHO8P13blGzPjE5FQw0=.bf90c995-f33b-4173-81b7-4e727874c1a2@github.com> On Sat, 9 Mar 2024 19:52:25 GMT, Marius Hanl wrote: > The fix is very straightfoward. We request a recreation of all cells in the `VirtualFlow` by calling `flow.recreateCells()` when the `tableRowFactory` was changed. > > Funny enough, this was done in the `TreeTableViewSkin` again, hence it did not suffer from this bug. Removed as the table row factory is already handled in the `TableViewSkinBase`, now with the correct recreation. This pull request has now been integrated. Changeset: d0642d0a Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/d0642d0a94814ad093966ae70f476c195e219703 Stats: 98 lines in 4 files changed: 93 ins; 4 del; 1 mod 8327727: Changing the row factory of a TableView does not recreate the rows Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1396 From kcr at openjdk.org Sat Mar 16 22:30:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Mar 2024 22:30:35 GMT Subject: Integrated: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 23:15:05 GMT, Kevin Rushforth wrote: > Release notes for the JavaFX 22 release. This will first go into `master` and then be backported to the `jfx22` branch so it will be available in that branch when JavaFX 22 is published, and from there also synced into the `jfx22u` repo. > > The following filter was used to produce the list of issues fixed in JavaFX 22: > > https://bugs.openjdk.org/issues/?filter=45407 > > Additionally, we had one issue, [JDK-8324658](https://bugs.openjdk.org/browse/JDK-8324658), with a `release-note=yes` label. That release note is included in the list of important changes. This pull request has now been integrated. Changeset: 8cb078a2 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/8cb078a2f81c2ced15abdc348b9c8373fabaa7c6 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod 8328136: Create release notes for JavaFX 22 Reviewed-by: jvos, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1402 From kcr at openjdk.org Sat Mar 16 22:32:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Mar 2024 22:32:31 GMT Subject: [jfx22] Integrated: 8328136: Create release notes for JavaFX 22 Message-ID: This is a necessary backport of the JavaFX 22 release notes to the `jfx22` branch. NOTE: We will _not_ tag `jfx22` nor rebuild JavaFX 22 as a result of this commit. ------------- Commit messages: - Backport 8cb078a2f81c2ced15abdc348b9c8373fabaa7c6 Changes: https://git.openjdk.org/jfx/pull/1404/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1404&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328136 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1404.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1404/head:pull/1404 PR: https://git.openjdk.org/jfx/pull/1404 From kcr at openjdk.org Sat Mar 16 22:32:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Mar 2024 22:32:39 GMT Subject: [jfx22] Integrated: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 16:36:57 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 22 release notes to the `jfx22` branch. > > NOTE: We will _not_ tag `jfx22` nor rebuild JavaFX 22 as a result of this commit. @johanvos please review this clean backport. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1404#issuecomment-2000039127 From jvos at openjdk.org Sat Mar 16 22:32:35 2024 From: jvos at openjdk.org (Johan Vos) Date: Sat, 16 Mar 2024 22:32:35 GMT Subject: [jfx22] Integrated: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 16:36:57 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 22 release notes to the `jfx22` branch. > > NOTE: We will _not_ tag `jfx22` nor rebuild JavaFX 22 as a result of this commit. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1404#pullrequestreview-1939837442 From kcr at openjdk.org Sat Mar 16 22:32:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 16 Mar 2024 22:32:44 GMT Subject: [jfx22] Integrated: 8328136: Create release notes for JavaFX 22 In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 16:36:57 GMT, Kevin Rushforth wrote: > This is a necessary backport of the JavaFX 22 release notes to the `jfx22` branch. > > NOTE: We will _not_ tag `jfx22` nor rebuild JavaFX 22 as a result of this commit. This pull request has now been integrated. Changeset: 71182b43 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/71182b4319c1d3e1b0dba00095339e3172929945 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod 8328136: Create release notes for JavaFX 22 Reviewed-by: jvos Backport-of: 8cb078a2f81c2ced15abdc348b9c8373fabaa7c6 ------------- PR: https://git.openjdk.org/jfx/pull/1404 From jvos at openjdk.org Sun Mar 17 18:01:39 2024 From: jvos at openjdk.org (Johan Vos) Date: Sun, 17 Mar 2024 18:01:39 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 15:18:51 GMT, eduardsdv wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1556: >> >>> 1554: if (targetCell != null) { >>> 1555: if (targetIndex < 0) { >>> 1556: T cell = getCell(targetIndex); >> >> Is there a reason you call `getCell` here, but `getAvailableCell` below? > > As I was also involved in fixing this error, I can answer. > > The `getAvailableCell()` method creates a new cell if none exists for the specified index (-1). > The `getCell()` returns the `accumCell` in this case, which is completely sufficient for our case, because we only need the dimensions of the cell here. The cell itself will not be added to the scene-graph. That sounds right. @Maran23 does this answer your question? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1527573232 From jvos at openjdk.org Sun Mar 17 18:10:34 2024 From: jvos at openjdk.org (Johan Vos) Date: Sun, 17 Mar 2024 18:10:34 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: <6vVM9tR1fUAQkL3sKDVzCJ8p72ONodVYPeIBcEA_gS0=.e91f5f8e-edfa-4aef-b19e-f70909d59c31@github.com> On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511 > reverted accidental indentation chang modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 142: > 140: int index = firstVisibleCell.getIndex(); > 141: if (newValue < oldValue) { > 142: index = Math.max(0, index - 1); Why are the boundary checks (Math.max/min) removed here? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1527574978 From kpk at openjdk.org Mon Mar 18 05:29:32 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 18 Mar 2024 05:29:32 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 10:37:26 GMT, Karthik P K wrote: >> Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. >> >> Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I can confirm that the tests runs in all the platforms. Successfully ran the headful tests in our lab machines. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1399#issuecomment-2002956250 From duke at openjdk.org Mon Mar 18 09:46:39 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 18 Mar 2024 09:46:39 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: <6vVM9tR1fUAQkL3sKDVzCJ8p72ONodVYPeIBcEA_gS0=.e91f5f8e-edfa-4aef-b19e-f70909d59c31@github.com> References: <6vVM9tR1fUAQkL3sKDVzCJ8p72ONodVYPeIBcEA_gS0=.e91f5f8e-edfa-4aef-b19e-f70909d59c31@github.com> Message-ID: On Sun, 17 Mar 2024 18:07:35 GMT, Johan Vos wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511 >> reverted accidental indentation chang > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 142: > >> 140: int index = firstVisibleCell.getIndex(); >> 141: if (newValue < oldValue) { >> 142: index = Math.max(0, index - 1); > > Why are the boundary checks (Math.max/min) removed here? The ``Math.max(0, index - 1)`` was introduced to fix an IndesOutOfBoundsException ([JDK-8311983](https://bugs.openjdk.org/browse/JDK-8311983)) for mouse clicks above the thumb, but it also introduced this bug (different scroll amount for clicks above and below thumb). This change fixes the handling of -1 cell indexes in a different way, but for that we have to pass it to ``VirtualFlow.scrollTo(int index)`` and then to ``VirtualFlow.tryScrollOneCell(int targetIndex, boolean downOrRight)``. Therefore it is necessary to remove this ``Math.max(..)`` call. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1528208036 From angorya at openjdk.org Mon Mar 18 15:05:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 18 Mar 2024 15:05:34 GMT Subject: RFR: 8327471: RTLTextFlowCharacterIndexTest fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 10:37:26 GMT, Karthik P K wrote: >> Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. >> >> Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Review comments looks good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1399#pullrequestreview-1943358032 From kpk at openjdk.org Mon Mar 18 15:15:34 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 18 Mar 2024 15:15:34 GMT Subject: Integrated: 8327471: RTLTextFlowCharacterIndexTest fails on Linux In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 05:17:40 GMT, Karthik P K wrote: > Because of the difference in the size of characters in default fonts in different OS, 2 tests were failing in `RTLTextFlowCharacterIndexTest`. > > Increased the scene width to accommodate all the characters as required for the test to validate HitInfo values in all the platforms. This pull request has now been integrated. Changeset: 4e2216bf Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/4e2216bfef7f7c542957af01de01662e7060a06b Stats: 20 lines in 1 file changed: 1 ins; 0 del; 19 mod 8327471: RTLTextFlowCharacterIndexTest fails on Linux Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1399 From hmeda at openjdk.org Mon Mar 18 16:24:35 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 18 Mar 2024 16:24:35 GMT Subject: Integrated: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:45:06 GMT, Hima Bindu Meda wrote: > Updated icu to v74.2. Sanity testing looks fine. Verified build on all platforms This pull request has now been integrated. Changeset: ad3d44e2 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/ad3d44e27f8ffb90aad81497f0bba2b00f7a49aa Stats: 10765 lines in 123 files changed: 3601 ins; 1545 del; 5619 mod 8324326: Update ICU4C to 74.2 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1398 From mstrauss at openjdk.org Mon Mar 18 17:39:57 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 18 Mar 2024 17:39:57 GMT Subject: RFR: 8311895: CSS Transitions [v10] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: - Merge branch 'master' into feature/css-transitions - Merge branch 'master' into feature/css-transitions - Add TransitionMediator - Test whether two Interpolatable instances are compatible - Merge branch 'master' into feature/css-transitions - Added documentation - Review changes - Review changes - Make interpolator fields final - Review changes - ... and 36 more: https://git.openjdk.org/jfx/compare/ad3d44e2...b76568c3 ------------- Changes: https://git.openjdk.org/jfx/pull/870/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=09 Stats: 4434 lines in 42 files changed: 4395 ins; 1 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Mon Mar 18 18:14:47 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 18 Mar 2024 18:14:47 GMT Subject: RFR: 8311895: CSS Transitions [v11] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Changes per review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/b76568c3..22aa4d64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=09-10 Stats: 17 lines in 1 file changed: 4 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Mon Mar 18 18:14:47 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 18 Mar 2024 18:14:47 GMT Subject: RFR: 8311895: CSS Transitions [v9] In-Reply-To: References: Message-ID: On Tue, 14 Nov 2023 09:41:08 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Test whether two Interpolatable instances are compatible > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 179: > >> 177: if (newTimer.delay < 0) { >> 178: double adjustedDelay = nanosToMillis(newTimer.delay) * newTimer.reversingShorteningFactor; >> 179: newTimer.startTime = now + millisToNanos(adjustedDelay); > > I don't see the value of converting these back and forth to milliseconds. Why not just: > > Suggestion: > > newTimer.startTime = now + newTimer.delay * newTimer.reversingShorteningFactor; > > I checked the calculations, and it makes no difference (the millis aren't rounded or anything), so you're just moving the decimal point before/after doing a multiplication that doesn't care where the decimal point is. > > If there is a reason that I missed, then I think this really needs a comment. I've removed the conversions. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 196: > >> 194: double frac = (double)(nanos - (millis * 1_000_000L)) / 1_000_000D; >> 195: return (double)millis + frac; >> 196: } > > This function seems to want to preserve extra decimals in some way. If the original long has a magnitude that is so large that some least significant digits get lost in the double conversion, then trying to add them later (`millis + frac`) will not restore them. > > In other words, you can just do: > > Suggestion: > > private static double nanosToMillis(long nanos) { > return nanos / 1_000_000.0; > } > > > Or avoiding the (generally slower) division completely: > > Suggestion: > > private static double nanosToMillis(long nanos) { > return nanos * 0.000_001; > } > > > All the extra operations are only likely to introduce small errors. Changed as suggested. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 207: > >> 205: long wholeMillis = (long)millis; >> 206: double frac = millis - (double)wholeMillis; >> 207: return wholeMillis * 1_000_000L + (long)(frac * 1_000_000D); > > I'd recommend keeping this simple (it seems to want to recover extra significant digits, but that's not possible): > > Suggestion: > > return ((long)(millis * 1_000_000.0); Changed as suggested. > modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 234: > >> 232: >> 233: Node node = (Node)timer.getProperty().getBean(); >> 234: node.fireEvent(new TransitionEvent(eventType, timer.getProperty(), elapsedTime)); > > minor: > Suggestion: > > long elapsedTime; > > // Elapsed time specification: https://www.w3.org/TR/css-transitions-1/#event-transitionevent > if (eventType == TransitionEvent.RUN || eventType == TransitionEvent.START) { > elapsedTime = Math.min(Math.max(-timer.delay, 0), timer.duration); > } else if (eventType == TransitionEvent.CANCEL) { > elapsedTime = Math.max(0, timer.currentTime - timer.startTime); > } else if (eventType == TransitionEvent.END) { > elapsedTime = timer.duration; > } else { > throw new IllegalArgumentException("eventType"); > } > > Node node = (Node)timer.getProperty().getBean(); > node.fireEvent(new TransitionEvent(eventType, timer.getProperty(), Duration.millis(nanosToMillis(elapsedTime)))); Changed as suggested. > modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 111: > >> 109: private TransitionTimer timer = null; >> 110: >> 111: private static class TransitionTimerImpl extends TransitionTimer { > > I think you can simplify this. TransitionTimer does not need any of its generic parameters if you provide an abstract method to get the property (just the general interface), which is sufficient for the `getBean` call you do on it, and for passing it along as the source of events. > > The constructor, `onUpdate` and `onStop` don't need the property parameter at all if you make the `TransistionTimerImpl` non-static. > > I also have the feeling that instead of subclassing `TransitionTimer`, implementing an interface, which acts as the adapter you need between the general timer infrastructure and a specific property, would be more clean. My main reason for thinking so is the akward way the timer is put to use: > > TransitionTimer.run(new TransitionTimerImpl(this, v), transition) > > ...calling a static method on `TransitionTimer` while providing a subclass instance of it. > > It could then look something like this: > > class InternalTransitionAdapter implements TransitionAdapter { > InternalTransitionAdapter(Number value) { > this.oldValue = property.get(); > this.newValue = value != null ? value.doubleValue() : 0; > } > > @Override > protected void onUpdate(double progress) { > set(progress < 1 ? oldValue + (newValue - oldValue) * progress : newValue); > } > > @Override > public void onStop() { > timer = null; > } > > @Override > public Property getProperty() { > return StyleableDoubleProperty.this; > } > > @Override > protected boolean equalsTargetValue(TransitionAdapter adapter) { > return newValue == ((InternalTransitionTimerImpl)adapter).newValue; > } > } > > I also think the `equalsTargetValue` stuff can be done inside this property itself (see other comment) This is now implemented with `TransitionMediator`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1529033318 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1529033525 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1529033615 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1529033418 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1529033655 From mstrauss at openjdk.org Mon Mar 18 18:27:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 18 Mar 2024 18:27:39 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 13:44:28 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Make TransitionEvent final > > Some early feedback, it's a lot of code :) I've implemented @hjohn's suggestion of an interface between `TransitionTimer` and `StyleableProperty` with the new `TransitionMediator` class. This cleans up the code and separates the interacting components. This PR is now again ready for review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2004638297 From mhanl at openjdk.org Tue Mar 19 12:04:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 19 Mar 2024 12:04:28 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: <17ch4-1VTrFnRlCOk4sqcCzXhsSWeonNyCfLlj5nqJ0=.472f43d9-fa7f-4ffb-bee1-26417a8cd540@github.com> On Sun, 17 Mar 2024 17:59:07 GMT, Johan Vos wrote: >> As I was also involved in fixing this error, I can answer. >> >> The `getAvailableCell()` method creates a new cell if none exists for the specified index (-1). >> The `getCell()` returns the `accumCell` in this case, which is completely sufficient for our case, because we only need the dimensions of the cell here. The cell itself will not be added to the scene-graph. > > That sounds right. > @Maran23 does this answer your question? Yes. But is it possible to scroll to an index that is negative? (<0) And what do we estimate then? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1530233902 From lkostyra at openjdk.org Tue Mar 19 13:12:25 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 19 Mar 2024 13:12:25 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 11:37:53 GMT, Karthik P K wrote: >> There were two different problems with this test's stability and HiDPI and both were fixed with this change. >> >> The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. >> >> When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. >> >> Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. >> >> I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. >> >> Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. > > Tested the changes in Mac, Windows and Linux. The changes fixes the issues in Mac and Windows. > I ran the test in Linux VM and it failed with and without the fix with error: > > RobotTest > testScreenCapture FAILED > junit.framework.AssertionFailedError: expected: rgba(255,0,255,255) but was: rgba(0,0,0,255) > at test.robot.javafx.scene.RobotTest.assertColorEquals(RobotTest.java:848) > at test.robot.javafx.scene.RobotTest.testScreenCapture(RobotTest.java:774) > > > Changing the scale also did not make any difference. Not sure if it is related to anything in VM. > It is a Ubuntu 22.04 VM > > Added a minor comment inline. @karthikpandelu I just tried this on Ubuntu 22.04 VM and everything seems to work fine. (0,0,0,255) returned from capture suggests capture failed - could it be your VM is running on Wayland instead of X11? > tests/system/src/test/java/test/robot/javafx/scene/RobotTest.java line 758: > >> 756: // Below calculations follow how getScreenCapture should calculate screen capture dimensions. This >> 757: // is to make this code consistent and stable on HiDPI systems. >> 758: int stageX = (int)stage.getX(); > > Minor: Do you think space should be added after `(int)` similar to `(double)`? It would be good for consistent formatting. I'll add those. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1403#issuecomment-2007138448 PR Review Comment: https://git.openjdk.org/jfx/pull/1403#discussion_r1530334956 From lkostyra at openjdk.org Tue Mar 19 13:16:48 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 19 Mar 2024 13:16:48 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: > There were two different problems with this test's stability and HiDPI and both were fixed with this change. > > The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. > > When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. > > Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. > > I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. > > Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Fix cast formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1403/files - new: https://git.openjdk.org/jfx/pull/1403/files/da7c97e4..6c14114b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1403&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1403.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/jfx/pull/1403 From duke at openjdk.org Tue Mar 19 13:39:29 2024 From: duke at openjdk.org (eduardsdv) Date: Tue, 19 Mar 2024 13:39:29 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: <17ch4-1VTrFnRlCOk4sqcCzXhsSWeonNyCfLlj5nqJ0=.472f43d9-fa7f-4ffb-bee1-26417a8cd540@github.com> References: <17ch4-1VTrFnRlCOk4sqcCzXhsSWeonNyCfLlj5nqJ0=.472f43d9-fa7f-4ffb-bee1-26417a8cd540@github.com> Message-ID: On Tue, 19 Mar 2024 12:02:14 GMT, Marius Hanl wrote: > But is it possible to scroll to an index that is negative? Yes, both the negative value (``-1``) and the positive value, which is greater than the items count (to be precise ``last item index + 1``), are possible and indicate the direction in which the scrolling takes place. The ``last item index + 1`` is already handled correctly. We only need to fix the handling of ``-1`` index. Can you explain your second question in more detail? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1530382582 From angorya at openjdk.org Tue Mar 19 15:44:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Mar 2024 15:44:34 GMT Subject: RFR: 8328399: Add hs_err_pid* to .gitignore Message-ID: Add hs_err_pid* to .gitignore Q: Any other files? ------------- Commit messages: - 8328399: Add hs_err_pid* to .gitignore Changes: https://git.openjdk.org/jfx/pull/1408/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328399 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1408.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1408/head:pull/1408 PR: https://git.openjdk.org/jfx/pull/1408 From angorya at openjdk.org Tue Mar 19 15:44:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Mar 2024 15:44:38 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL the scenes Message-ID: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. This simplifies the tests and ensures a clean shutdown. ------------- Commit messages: - copy - 8325566: [TestBug] Util.shutdown() to hide ALL the scenes Changes: https://git.openjdk.org/jfx/pull/1407/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325566 Stats: 124 lines in 59 files changed: 1 ins; 6 del; 117 mod Patch: https://git.openjdk.org/jfx/pull/1407.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/jfx/pull/1407 From lkostyra at openjdk.org Tue Mar 19 16:09:36 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 19 Mar 2024 16:09:36 GMT Subject: RFR: 8327482: Fix missing image resource in HelloImage toy app Message-ID: Replaced existing `slowImageURL` address to a new image (+ some extra bits related to it). Image has been taken from open-source repository of Duke images and licensed under BSD license: https://wiki.openjdk.org/display/duke/Gallery ------------- Commit messages: - Change slow image link to new one Changes: https://git.openjdk.org/jfx/pull/1410/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327482 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1410.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1410/head:pull/1410 PR: https://git.openjdk.org/jfx/pull/1410 From aghaisas at openjdk.org Tue Mar 19 16:15:31 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 19 Mar 2024 16:15:31 GMT Subject: RFR: 8328399: Add hs_err_pid* to .gitignore In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 23:31:03 GMT, Andy Goryachev wrote: > Q: Any other files? May be `.DS_Store` file ------------- PR Comment: https://git.openjdk.org/jfx/pull/1408#issuecomment-2007598297 From aghaisas at openjdk.org Tue Mar 19 16:23:23 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 19 Mar 2024 16:23:23 GMT Subject: RFR: 8328399: Add hs_err_pid* to .gitignore In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 23:31:03 GMT, Andy Goryachev wrote: > Add hs_err_pid* to .gitignore > > Q: Any other files? Marked as reviewed by aghaisas (Reviewer). Oops... I saw the JBS Description now. It is already ignored. ------------- PR Review: https://git.openjdk.org/jfx/pull/1408#pullrequestreview-1946762826 PR Comment: https://git.openjdk.org/jfx/pull/1408#issuecomment-2007612920 From hmeda at openjdk.org Tue Mar 19 16:39:42 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 19 Mar 2024 16:39:42 GMT Subject: [jfx22u] Integrated: 8324326: Update ICU4C to 74.2 Message-ID: Clean Backport ------------- Commit messages: - Backport ad3d44e27f8ffb90aad81497f0bba2b00f7a49aa Changes: https://git.openjdk.org/jfx22u/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324326 Stats: 10765 lines in 123 files changed: 3601 ins; 1545 del; 5619 mod Patch: https://git.openjdk.org/jfx22u/pull/20.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/20/head:pull/20 PR: https://git.openjdk.org/jfx22u/pull/20 From hmeda at openjdk.org Tue Mar 19 16:39:43 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 19 Mar 2024 16:39:43 GMT Subject: [jfx22u] Integrated: 8324326: Update ICU4C to 74.2 In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 16:32:55 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: 32378354 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx22u/commit/323783541140bea2119e2e59d0bb2d8d1fb37c8a Stats: 10765 lines in 123 files changed: 3601 ins; 1545 del; 5619 mod 8324326: Update ICU4C to 74.2 Backport-of: ad3d44e27f8ffb90aad81497f0bba2b00f7a49aa ------------- PR: https://git.openjdk.org/jfx22u/pull/20 From kcr at openjdk.org Tue Mar 19 18:59:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 19 Mar 2024 18:59:23 GMT Subject: RFR: 8327482: Fix missing image resource in HelloImage toy app In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 16:05:50 GMT, Lukasz Kostyra wrote: > Replaced existing `slowImageURL` address to a new image (+ some extra bits related to it). Image has been taken from open-source repository of Duke images and licensed under BSD license: https://wiki.openjdk.org/display/duke/Gallery Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1410#pullrequestreview-1947122603 From mennen at openjdk.org Tue Mar 19 20:00:25 2024 From: mennen at openjdk.org (Michael Ennen) Date: Tue, 19 Mar 2024 20:00:25 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 13:16:48 GMT, Lukasz Kostyra wrote: >> There were two different problems with this test's stability and HiDPI and both were fixed with this change. >> >> The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. >> >> When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. >> >> Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. >> >> I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. >> >> Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Fix cast formatting Thanks for fixing this - was a thorn in my side when developing the Robot API. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1403#issuecomment-2008008533 From kcr at openjdk.org Tue Mar 19 21:41:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 19 Mar 2024 21:41:25 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 11:37:53 GMT, Karthik P K wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix cast formatting > > Tested the changes in Mac, Windows and Linux. The changes fixes the issues in Mac and Windows. > I ran the test in Linux VM and it failed with and without the fix with error: > > RobotTest > testScreenCapture FAILED > junit.framework.AssertionFailedError: expected: rgba(255,0,255,255) but was: rgba(0,0,0,255) > at test.robot.javafx.scene.RobotTest.assertColorEquals(RobotTest.java:848) > at test.robot.javafx.scene.RobotTest.testScreenCapture(RobotTest.java:774) > > > Changing the scale also did not make any difference. Not sure if it is related to anything in VM. > It is a Ubuntu 22.04 VM > > Added a minor comment inline. > @karthikpandelu I just tried this on Ubuntu 22.04 VM and everything seems to work fine. (0,0,0,255) returned from capture suggests capture failed - could it be your VM is running on Wayland instead of X11? I also just ran this, and it runs fine for me on an Ubuntu 22.04 VM. Since Wayland is the default in 22.04, I also suspect that Karthik was running in that mode. You can check the value of the `XDG_SESSION_TYPE` env var to see. All robot tests that read the screen will fail on Wayland until [JDK-8326712](https://bugs.openjdk.org/browse/JDK-8326712) is fixed (should be done reasonably soon, sometime in the JavaFX 23 time frame). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1403#issuecomment-2008178337 From kcr at openjdk.org Tue Mar 19 21:41:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 19 Mar 2024 21:41:25 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 13:16:48 GMT, Lukasz Kostyra wrote: >> There were two different problems with this test's stability and HiDPI and both were fixed with this change. >> >> The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. >> >> When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. >> >> Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. >> >> I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. >> >> Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Fix cast formatting Fix looks good to me. I confirm that the test no longer fails on my Windows system (running at 1.25x scale). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1403#pullrequestreview-1947446088 From kcr at openjdk.org Tue Mar 19 21:54:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 19 Mar 2024 21:54:23 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows In-Reply-To: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Mon, 18 Mar 2024 22:53:03 GMT, Andy Goryachev wrote: > Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. > This simplifies the tests and ensures a clean shutdown. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1407#pullrequestreview-1947463852 From nlisker at openjdk.org Tue Mar 19 22:26:23 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 19 Mar 2024 22:26:23 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows In-Reply-To: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Mon, 18 Mar 2024 22:53:03 GMT, Andy Goryachev wrote: > Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. > This simplifies the tests and ensures a clean shutdown. tests/system/src/test/java/test/util/Util.java line 383: > 381: runAndWait(() -> { > 382: for (Window w : new ArrayList<>(Window.getWindows())) { > 383: w.hide(); I think you can use `List.copyOf` instead of an `ArrayList` since it doesn't get modified (it's a one-time copy). The iteration can also be List.copyOf(Window.getWindows()).forEach(Window::hide); if you want. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1407#discussion_r1531195323 From angorya at openjdk.org Tue Mar 19 22:31:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Mar 2024 22:31:33 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows [v2] In-Reply-To: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: > Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. > This simplifies the tests and ensures a clean shutdown. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: for each ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1407/files - new: https://git.openjdk.org/jfx/pull/1407/files/2887d654..5773ebfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1407&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1407&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1407.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1407/head:pull/1407 PR: https://git.openjdk.org/jfx/pull/1407 From angorya at openjdk.org Tue Mar 19 22:31:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Mar 2024 22:31:33 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows [v2] In-Reply-To: References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Tue, 19 Mar 2024 22:23:46 GMT, Nir Lisker wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> for each > > tests/system/src/test/java/test/util/Util.java line 383: > >> 381: runAndWait(() -> { >> 382: for (Window w : new ArrayList<>(Window.getWindows())) { >> 383: w.hide(); > > I think you can use `List.copyOf` instead of an `ArrayList` since it doesn't get modified (it's a one-time copy). > The iteration can also be > > List.copyOf(Window.getWindows()).forEach(Window::hide); > > if you want. The only issue with this style is - it's hard to set breakpoints. In this case it's not that important. Thank you! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1407#discussion_r1531200964 From nlisker at openjdk.org Tue Mar 19 22:36:24 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 19 Mar 2024 22:36:24 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows [v2] In-Reply-To: References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Tue, 19 Mar 2024 22:28:54 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/util/Util.java line 383: >> >>> 381: runAndWait(() -> { >>> 382: for (Window w : new ArrayList<>(Window.getWindows())) { >>> 383: w.hide(); >> >> I think you can use `List.copyOf` instead of an `ArrayList` since it doesn't get modified (it's a one-time copy). >> The iteration can also be >> >> List.copyOf(Window.getWindows()).forEach(Window::hide); >> >> if you want. > > The only issue with this style is - it's hard to set breakpoints. > In this case it's not that important. > Thank you! It's a matter of style mostly, so I don't really mind it. The debug issue can be remedied by adding breakpoints inside Lambdas, which all IDEs support I think (Eclipse and IntelliJ for sure). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1407#discussion_r1531207452 From angorya at openjdk.org Tue Mar 19 22:42:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 19 Mar 2024 22:42:22 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows [v2] In-Reply-To: References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Tue, 19 Mar 2024 22:34:17 GMT, Nir Lisker wrote: >> The only issue with this style is - it's hard to set breakpoints. >> In this case it's not that important. >> Thank you! > > It's a matter of style mostly, so I don't really mind it. The debug issue can be remedied by adding breakpoints inside Lambdas, which all IDEs support I think (Eclipse and IntelliJ for sure). "inside lambdas" - inside the referenced methods you mean? yes, but if that method is frequently called it's not what I want. There is no way to set a breakpoint at the moment of lambda invocation, I think, at least not in Eclipse. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1407#discussion_r1531211388 From kpk at openjdk.org Wed Mar 20 06:54:28 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 20 Mar 2024 06:54:28 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 13:16:48 GMT, Lukasz Kostyra wrote: >> There were two different problems with this test's stability and HiDPI and both were fixed with this change. >> >> The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. >> >> When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. >> >> Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. >> >> I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. >> >> Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Fix cast formatting Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1403#pullrequestreview-1948052893 From kpk at openjdk.org Wed Mar 20 06:54:29 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 20 Mar 2024 06:54:29 GMT Subject: RFR: 8207379: Robot screen capture test fails with HiDPI at some screen locations [v2] In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 21:37:50 GMT, Kevin Rushforth wrote: > I also suspect that Karthik was running in that mode. You can check the value of the `XDG_SESSION_TYPE` env var to see. All robot tests that read the screen will fail on Wayland until [JDK-8326712](https://bugs.openjdk.org/browse/JDK-8326712) is fixed (should be done reasonably soon, sometime in the JavaFX 23 time frame). Yes it was because of Wayland. The test looks good now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1403#issuecomment-2008766427 From lkostyra at openjdk.org Wed Mar 20 08:22:28 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 20 Mar 2024 08:22:28 GMT Subject: Integrated: 8207379: Robot screen capture test fails with HiDPI at some screen locations In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 16:06:55 GMT, Lukasz Kostyra wrote: > There were two different problems with this test's stability and HiDPI and both were fixed with this change. > > The whole reason for this tests lack of stability comes with how Windows calculates window position when using HiDPI. When window's X/Y coordinates are not provided by the application, they are (generally speaking) randomly selected by Windows. X/Y are picked as two integers, and afterwards the HiDPI scaling is applied. With fractional scaling like 125% this can cause X/Y coordinates to have fractional values. > > When performing a screen capture, Robot takes a generous estimate of window's position and dimensions. This is done by taking provided X/Y coordinates (in case of this test, stage's X/Y coords), multiplying them by scaling (ex. 1.25) and then flooring the result. Similar estimation is done to opposite coordinates - we take X/Y coords, add width/height to them respectively, multiply them by scaling and ceiling them. As a result, we have minX/Y and maxX/Y coords of capture region, which is used to calculate capture region's width and height. The first problem with test's stability is right here - the test did not take this calculation and floor/ceil operations into account, which with appropriately randomized window coordinates could cause discrepancy between expected width/height and actual. This logic that is used by `getScreenCapture()` seems to be necessary and good, so to remedy the problem I replicated those calculations on test side. > > Another problem came after that - fractional X/Y values caused capture to not always line up with pixel layout, which made the 1-pixel border of capture sometimes incorrect (an average of stage's MAGENTA color and whatever background happened to be under the displayed stage). This means we cannot exactly expect those pixels to have exactly MAGENTA color when the system has fractional HiDPI enabled. To help that, the test now doesn't check for correctness of the 1-pixel border of captured image. I feel this still gives us enough confidence that the Robot screen capture works properly, while stabilizing the test on all systems. > > I briefly considered an alternative approach to hard-set X/Y values but doing it this way gives us a bit more robustness, makes the test independent of Stage's X/Y coordinates which matter quite a lot. > > Verified this change on macOS and especially on Windows - ran the test on Windows 50 times each on 125% and 100% scaling and noticed no intermittent failures. This pull request has now been integrated. Changeset: c3396bf0 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/c3396bf0c3c436458d523119227023fb957cc279 Stats: 25 lines in 1 file changed: 15 ins; 4 del; 6 mod 8207379: Robot screen capture test fails with HiDPI at some screen locations Reviewed-by: kpk, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1403 From lkostyra at openjdk.org Wed Mar 20 08:24:27 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 20 Mar 2024 08:24:27 GMT Subject: Integrated: 8327482: Fix missing image resource in HelloImage toy app In-Reply-To: References: Message-ID: <7tblKazX8B831WjGlOULh6nD5yOE2ZcG88zUvRWgRdk=.3eaffba7-c77c-4bb9-a8bd-87d56a1f674a@github.com> On Tue, 19 Mar 2024 16:05:50 GMT, Lukasz Kostyra wrote: > Replaced existing `slowImageURL` address to a new image (+ some extra bits related to it). Image has been taken from open-source repository of Duke images and licensed under BSD license: https://wiki.openjdk.org/display/duke/Gallery This pull request has now been integrated. Changeset: 32b452b6 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/32b452b6007703add2b460872d363dfb3640878c Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8327482: Fix missing image resource in HelloImage toy app Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1410 From jpereda at openjdk.org Wed Mar 20 11:00:33 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 20 Mar 2024 11:00:33 GMT Subject: RFR: 8324939: Editable TableView loses focus after commit Message-ID: This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly. For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before). By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before). Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix). ------------- Commit messages: - Refactor ControlUtils, check focus before owner is gone, and include tests Changes: https://git.openjdk.org/jfx/pull/1411/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324939 Stats: 459 lines in 9 files changed: 438 ins; 5 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1411.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1411/head:pull/1411 PR: https://git.openjdk.org/jfx/pull/1411 From mhanl at openjdk.org Wed Mar 20 11:50:47 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 20 Mar 2024 11:50:47 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic [v2] In-Reply-To: References: Message-ID: > This PR fixes the issue that the initial column autosizing is wrong under some circumstances. > The following things will break the initial autosizing: > - Bold Column text (that is where I initially found this problem) > - Another font / font size > - Graphic > > The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well. > > _It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me._ > **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)** > > The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text. > > I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy). Marius Hanl has updated the pull request incrementally with three additional commits since the last revision: - JDK-8186188: prefWidth(-1) for TreeTableView as well - JDK-8186188: fix tests by considering the system font (was always mixed with Amble) - JDK-8186188: Use label prefWidth(-1) instead of manually calculating the width ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1405/files - new: https://git.openjdk.org/jfx/pull/1405/files/63a74adc..a8d26a24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=00-01 Stats: 46 lines in 4 files changed: 16 ins; 15 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1405.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1405/head:pull/1405 PR: https://git.openjdk.org/jfx/pull/1405 From kcr at openjdk.org Wed Mar 20 12:53:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Mar 2024 12:53:25 GMT Subject: RFR: 8325566: [TestBug] Util.shutdown() to hide ALL Windows [v2] In-Reply-To: References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: <_iI-vLL7JEXgObfYpxhqY9MbhDOSSosHU4i6s12XfVM=.85176b8c-3ff6-4d84-89db-afda31e2a13c@github.com> On Tue, 19 Mar 2024 22:31:33 GMT, Andy Goryachev wrote: >> Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. >> This simplifies the tests and ensures a clean shutdown. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > for each Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1407#pullrequestreview-1948793872 From kcr at openjdk.org Wed Mar 20 13:33:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Mar 2024 13:33:32 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 Message-ID: <0pBwxydYQQ8KPxFNmPA__WVI-vn94uPBbtbWuGrXAi8=.045b5509-7ca6-4d48-ad64-66d2a779188e@github.com> Clean merge of `jfx:jfx22` to `jfx22u:master` ------------- Commit messages: - Merge - 8328136: Create release notes for JavaFX 22 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/21/files Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/21.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/21/head:pull/21 PR: https://git.openjdk.org/jfx22u/pull/21 From kcr at openjdk.org Wed Mar 20 13:33:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Mar 2024 13:33:33 GMT Subject: [jfx22u] Integrated: Merge jfx:jfx22 In-Reply-To: <0pBwxydYQQ8KPxFNmPA__WVI-vn94uPBbtbWuGrXAi8=.045b5509-7ca6-4d48-ad64-66d2a779188e@github.com> References: <0pBwxydYQQ8KPxFNmPA__WVI-vn94uPBbtbWuGrXAi8=.045b5509-7ca6-4d48-ad64-66d2a779188e@github.com> Message-ID: <_VK20Gc8UYnjUgmNeINP_vQZ21uyRmZcFWeaqSddGWY=.76e25567-533c-498a-87ba-3a6069bffb0c@github.com> On Wed, 20 Mar 2024 13:25:55 GMT, Kevin Rushforth wrote: > Clean merge of `jfx:jfx22` to `jfx22u:master` This pull request has now been integrated. Changeset: f76aaf50 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/f76aaf509c1048b7a90049becac9f3989668fca4 Stats: 123 lines in 1 file changed: 123 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.org/jfx22u/pull/21 From angorya at openjdk.org Wed Mar 20 14:34:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 14:34:26 GMT Subject: Integrated: 8325566: [TestBug] Util.shutdown() to hide ALL Windows In-Reply-To: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> References: <0seyYslg4Jnph0454twM0spn7msFz4w8EXDOBys2QDY=.13e3e624-4bf4-4b61-94df-4c7c53128a8b@github.com> Message-ID: On Mon, 18 Mar 2024 22:53:03 GMT, Andy Goryachev wrote: > Changing `Util.shutdown()` to hide **all** showing Windows and then call `Platform.exit()`. > This simplifies the tests and ensures a clean shutdown. This pull request has now been integrated. Changeset: a71b70f0 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/a71b70f0bc20e3656cd66bf3193c0d66386ea331 Stats: 125 lines in 59 files changed: 1 ins; 6 del; 118 mod 8325566: [TestBug] Util.shutdown() to hide ALL Windows Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1407 From angorya at openjdk.org Wed Mar 20 14:40:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 14:40:36 GMT Subject: Integrated: 8328399: Add hs_err_pid* to .gitignore In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 23:31:03 GMT, Andy Goryachev wrote: > Add hs_err_pid* to .gitignore > > Q: Any other files? This pull request has now been integrated. Changeset: dcb894c7 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/dcb894c7ffd1d14365a0ef691362f2e7232d20d5 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8328399: Add hs_err_pid* to .gitignore Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1408 From angorya at openjdk.org Wed Mar 20 14:54:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 14:54:32 GMT Subject: RFR: 8328400: Minor Cleanup Message-ID: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> - PrismTextLayout:325 misspelled 'sliptCaretOffset' - DatePicker System.err.println L 125, 139, 172, 256 - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin, DatePickerTest, FocusTest, and a few more) - Labeled:821 obsolete comment Some more typos: - occuring -> occurring (e.g. CellBehaviourBase) - ButtonTest - conextMenuShouldntShowOnAction -> context... - ControlResources - translateable -> translatable - DateCellSkin - Pirvate -> Private - totaly -> totally (e.g. LineChart) - MenuItem - programatically -> programmatically - Tooltip - invaildated -> invalidated (thank you @Maran23 ) ------------- Commit messages: - 2024 - more typos - 8328400: Minor Cleanup Changes: https://git.openjdk.org/jfx/pull/1409/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1409&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328400 Stats: 68 lines in 25 files changed: 0 ins; 11 del; 57 mod Patch: https://git.openjdk.org/jfx/pull/1409.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1409/head:pull/1409 PR: https://git.openjdk.org/jfx/pull/1409 From mhanl at openjdk.org Wed Mar 20 14:54:32 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 20 Mar 2024 14:54:32 GMT Subject: RFR: 8328400: Minor Cleanup In-Reply-To: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> References: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> Message-ID: On Tue, 19 Mar 2024 15:18:09 GMT, Andy Goryachev wrote: > - PrismTextLayout:325 misspelled 'sliptCaretOffset' > - DatePicker System.err.println L 125, 139, 172, 256 > - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin, DatePickerTest, FocusTest, and a few more) > - Labeled:821 obsolete comment > > Some more typos: > - occuring -> occurring (e.g. CellBehaviourBase) > - ButtonTest - conextMenuShouldntShowOnAction -> context... > - ControlResources - translateable -> translatable > - DateCellSkin - Pirvate -> Private > - totaly -> totally (e.g. LineChart) > - MenuItem - programatically -> programmatically > - Tooltip - invaildated -> invalidated > > (thank you @Maran23 ) The draft looks good to me so far. modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 126: > 124: //System.err.println("Restoring value to " + > 125: // ((lastValidDate == null) ? "null" : getConverter().toString(lastValidDate))); > 126: setValue(lastValidDate); FYI I found it very weird that `DatePicker` tries to 'recover' itself when wrong values are set. I think this is the only? `Control` that does this behaviour ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1409#pullrequestreview-1948506901 PR Review Comment: https://git.openjdk.org/jfx/pull/1409#discussion_r1531848246 From angorya at openjdk.org Wed Mar 20 15:02:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 15:02:37 GMT Subject: RFR: 8328400: Minor Cleanup In-Reply-To: References: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> Message-ID: On Wed, 20 Mar 2024 10:40:19 GMT, Marius Hanl wrote: >> - PrismTextLayout:325 misspelled 'sliptCaretOffset' >> - DatePicker System.err.println L 125, 139, 172, 256 >> - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin, DatePickerTest, FocusTest, and a few more) >> - Labeled:821 obsolete comment >> >> Some more typos: >> - occuring -> occurring (e.g. CellBehaviourBase) >> - ButtonTest - conextMenuShouldntShowOnAction -> context... >> - ControlResources - translateable -> translatable >> - DateCellSkin - Pirvate -> Private >> - totaly -> totally (e.g. LineChart) >> - MenuItem - programatically -> programmatically >> - Tooltip - invaildated -> invalidated >> >> (thank you @Maran23 ) > > modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 126: > >> 124: //System.err.println("Restoring value to " + >> 125: // ((lastValidDate == null) ? "null" : getConverter().toString(lastValidDate))); >> 126: setValue(lastValidDate); > > FYI I found it very weird that `DatePicker` tries to 'recover' itself when wrong values are set. I think this is the only? `Control` that does this behaviour I think ComboBox:243 also does that. Basically, if we have a free-form text field as an input to a constrained value property, there must be a way to enforce the constraint. Note that all this is not needed in e.g. ColorPicker because its "editor" always produces a valid value. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1409#discussion_r1532243353 From mhanl at openjdk.org Wed Mar 20 15:37:36 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 20 Mar 2024 15:37:36 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic [v3] In-Reply-To: References: Message-ID: > This PR fixes the issue that the initial column autosizing is wrong under some circumstances. > The following things will break the initial autosizing: > - Bold Column text (that is where I initially found this problem) > - Another font / font size > - Graphic > > The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well. > > _It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me._ > **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)** > > The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text. > > I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: JDK-8186188: add more tests, fix existing tests which were failing as the font is now always there ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1405/files - new: https://git.openjdk.org/jfx/pull/1405/files/a8d26a24..9423af03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=01-02 Stats: 136 lines in 5 files changed: 126 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1405.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1405/head:pull/1405 PR: https://git.openjdk.org/jfx/pull/1405 From angorya at openjdk.org Wed Mar 20 18:54:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 18:54:47 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 Message-ID: Further changes to the MonkeyTester application: - remember split pane divider ? - use 'private' instead of 'protected' in many cases ? - added more scripts to the 'writing systems' text sample ? - added RTL window control menu ? - added embedded swing/fx in tools ? - added copy popup menu in clipboard viewer ? - added the custom css field to the css playground tool ? - added many new pages ? - split XYChartPage into separate pages ? - switched to use property sheets (some choices might be incomplete) ? https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md ------------- Commit messages: - whitespace - tool bar - Merge branch 'master' into 8316372.monkey - whitespace - whitespace - whitespace - 8316372: Monkey Tester Application Part 3 Changes: https://git.openjdk.org/jfx/pull/1406/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316372 Stats: 10052 lines in 103 files changed: 5842 ins; 3338 del; 872 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From angorya at openjdk.org Wed Mar 20 18:54:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 18:54:47 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 21:02:54 GMT, Andy Goryachev wrote: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md ![Screenshot 2024-03-18 at 13 30 11](https://github.com/openjdk/jfx/assets/107069028/e6a1080d-3465-428d-9848-02d184a6d6be) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2007529934 From mhanl at openjdk.org Wed Mar 20 19:53:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 20 Mar 2024 19:53:40 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic [v4] In-Reply-To: References: Message-ID: > This PR fixes the issue that the initial column autosizing is wrong under some circumstances. > The following things will break the initial autosizing: > - Bold Column text (that is where I initially found this problem) > - Another font / font size > - Graphic > > The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well. > > _It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me._ > **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)** > > The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text. > > I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy). Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: - JDK-8186188: copyright - JDK-8186188: fix tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1405/files - new: https://git.openjdk.org/jfx/pull/1405/files/9423af03..554c8edb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1405&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1405.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1405/head:pull/1405 PR: https://git.openjdk.org/jfx/pull/1405 From kcr at openjdk.org Wed Mar 20 23:24:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Mar 2024 23:24:25 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 21:02:54 GMT, Andy Goryachev wrote: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md As this is a fairly large change it would be good to get two reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2010891934 From kcr at openjdk.org Wed Mar 20 23:42:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 20 Mar 2024 23:42:26 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 In-Reply-To: References: Message-ID: On Mon, 18 Mar 2024 21:02:54 GMT, Andy Goryachev wrote: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md I added one convenience suggestion inline. Unrelated to the suggestion, I get a compilation error. You have a problem with a mismatch in the case of one filename versus its class name. $ ant -Djavafx.home=../../../build/sdk Buildfile: jfx/tests/manual/monkey/build.xml ... compile: [javac] Compiling 105 source files to jfx/tests/manual/monkey/build/classes [javac] jfx/tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/HtmlEditorPage.java:39: error: class HTMLEditorPage is public, should be declared in a file named HTMLEditorPage.java [javac] public class HTMLEditorPage extends TestPaneBase implements HasSkinnable { [javac] ^ [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 error BUILD FAILED jfx/tests/manual/monkey/build.xml:45: Compile failed; see the compiler error output for details. Total time: 2 seconds tests/manual/monkey/build.xml line 6: > 4: ant -Djavafx.home=

> 5: --> > 6: If you add the following property as a default for `javafx.home`, then you can build it using just "ant" without having to specify it on the command line: ------------- PR Review: https://git.openjdk.org/jfx/pull/1406#pullrequestreview-1950443223 PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1533046067 From angorya at openjdk.org Wed Mar 20 23:47:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 23:47:22 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 In-Reply-To: References: Message-ID: <5xhAPEURwClE-0b4R4cJvZPe97MY3Fl56YLZ7_uz9uc=.1d841617-804a-43ca-acef-4c23b3e253e2@github.com> On Wed, 20 Mar 2024 23:40:04 GMT, Kevin Rushforth wrote: > HTMLEditorPage it was renamed, but this operation of case-insensitive filesystems may fail. please delete the source and pull again. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2010918218 From angorya at openjdk.org Wed Mar 20 23:56:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 20 Mar 2024 23:56:50 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md 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/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/b6db646a..2c23ca57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=00-01 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From kpk at openjdk.org Thu Mar 21 07:22:32 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 21 Mar 2024 07:22:32 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests Message-ID: Enabled a test in `SpinnerTest` class. Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. ------------- Commit messages: - Enable Spinner tests Changes: https://git.openjdk.org/jfx/pull/1414/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328667 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1414.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1414/head:pull/1414 PR: https://git.openjdk.org/jfx/pull/1414 From kcr at openjdk.org Thu Mar 21 12:56:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 12:56:27 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 07:18:28 GMT, Karthik P K wrote: > Enabled a test in `SpinnerTest` class. > Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. > Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 341: > 339: **************************************************************************/ > 340: > 341: @Ignore("Need KeyboardEventFirer. Listener not invoked on changing value using setText method") Please file a bug for this and change the String to that bug ID, e.g., `@Ignore("JDK-nnnnnnn")` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1414#discussion_r1533852943 From kpk at openjdk.org Thu Mar 21 13:40:37 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 21 Mar 2024 13:40:37 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: > Enabled a test in `SpinnerTest` class. > Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. > Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add bug id to ignore comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1414/files - new: https://git.openjdk.org/jfx/pull/1414/files/8e7b318f..85d726a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1414&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1414&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1414.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1414/head:pull/1414 PR: https://git.openjdk.org/jfx/pull/1414 From kpk at openjdk.org Thu Mar 21 13:40:37 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 21 Mar 2024 13:40:37 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 12:54:05 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add bug id to ignore comment > > modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 341: > >> 339: **************************************************************************/ >> 340: >> 341: @Ignore("Need KeyboardEventFirer. Listener not invoked on changing value using setText method") > > Please file a bug for this and change the String to that bug ID, e.g., `@Ignore("JDK-nnnnnnn")` Created [JDK-8328701](https://bugs.openjdk.org/browse/JDK-8328701) and updated `@Ignore` comment ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1414#discussion_r1533927324 From kcr at openjdk.org Thu Mar 21 14:54:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 14:54:29 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 13:40:37 GMT, Karthik P K wrote: >> Enabled a test in `SpinnerTest` class. >> Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. >> Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add bug id to ignore comment Marked as reviewed by kcr (Lead). Looks good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1414#pullrequestreview-1952471541 PR Comment: https://git.openjdk.org/jfx/pull/1414#issuecomment-2012513510 From angorya at openjdk.org Thu Mar 21 15:00:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 15:00:27 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 13:40:37 GMT, Karthik P K wrote: >> Enabled a test in `SpinnerTest` class. >> Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. >> Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add bug id to ignore comment modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 341: > 339: **************************************************************************/ > 340: > 341: @Ignore("JDK-8328701") the spinner is not editable and no commitValue() is issued (please see my comment in the ticket) https://bugs.openjdk.org/browse/JDK-8328701?focusedId=14659352&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14659352 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1414#discussion_r1534088412 From angorya at openjdk.org Thu Mar 21 15:07:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 15:07:33 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 13:40:37 GMT, Karthik P K wrote: >> Enabled a test in `SpinnerTest` class. >> Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. >> Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add bug id to ignore comment however, [JDK-8328701](https://bugs.openjdk.org/browse/JDK-8328701) is still an issue that needs investigation, so the changes are ok. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1414#pullrequestreview-1952510914 From kcr at openjdk.org Thu Mar 21 15:07:34 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 15:07:34 GMT Subject: RFR: 8328667: [Testbug] Enable ignored Spinner unit tests [v2] In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 14:58:15 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add bug id to ignore comment > > modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 341: > >> 339: **************************************************************************/ >> 340: >> 341: @Ignore("JDK-8328701") > > the spinner is not editable and no commitValue() is issued (please see my comment in the ticket) > > https://bugs.openjdk.org/browse/JDK-8328701?focusedId=14659352&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14659352 In that case, maybe you can repurpose that JBS bug ID into a test bug? Either way, using that bug ID to skip this test seems good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1414#discussion_r1534100642 From angorya at openjdk.org Thu Mar 21 16:12:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 16:12:38 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests Message-ID: ## ManualTestWindow This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons. A simple test would look like this: public class SampleManualTest { public static void main(String[] args) throws Exception { ManualTestWindow.builder(). title("Sample Manual Test"). instructions( """ Provide multi-line instructions here. """ ). ui(() -> createTestUI()). buildAndRun(); } private static Node createTestUI() { return new Label("Test UI"); } } Resulting application window: ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7) Readme: https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project and moved sources to src/, still using the default package). Q: Do we want to avoid using the default package? Q: What other features can be added to the test window? ------------- Commit messages: - whitespace - Merge branch 'master' into 8319555.manual - manual test window - fixed text manual test setup Changes: https://git.openjdk.org/jfx/pull/1413/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319555 Stats: 535 lines in 15 files changed: 426 ins; 107 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1413.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1413/head:pull/1413 PR: https://git.openjdk.org/jfx/pull/1413 From kcr at openjdk.org Thu Mar 21 18:04:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 18:04:42 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings [v2] In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings Kevin Rushforth 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: - Add DOC_WERROR flag (default="true") to allow javadoc -Werror to be disabled - Merge branch 'master' into 8325075-javadoc-werror - 8325075: Enable -Werror for javadoc to fail on any warnings ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1390/files - new: https://git.openjdk.org/jfx/pull/1390/files/42a329dd..64d434ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1390&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1390&range=00-01 Stats: 11716 lines in 200 files changed: 4354 ins; 1563 del; 5799 mod Patch: https://git.openjdk.org/jfx/pull/1390.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1390/head:pull/1390 PR: https://git.openjdk.org/jfx/pull/1390 From kcr at openjdk.org Thu Mar 21 18:04:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 18:04:42 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: <-jYAIAS2tv3fv-vxEqFf8Bvb9twKvCdaA9KyoVKtUcQ=.ac16799e-0140-4186-98e1-d58a15d9661c@github.com> On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings I added a gradle property to suppress `javadoc -Werror`. To do this: gradle -PDOC_WERROR=false javadoc ------------- PR Comment: https://git.openjdk.org/jfx/pull/1390#issuecomment-2013190406 From angorya at openjdk.org Thu Mar 21 18:25:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 18:25:24 GMT Subject: RFR: 8325075: Enable -Werror for javadoc to fail on any warnings [v2] In-Reply-To: References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Thu, 21 Mar 2024 18:04:42 GMT, Kevin Rushforth wrote: >> Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. >> >> You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: >> >> https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 >> >> That build fails with the expected error: >> >> >> 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment >> 2024-03-05T16:23:29.6265947Z private final String message; >> 2024-03-05T16:23:29.6266448Z ^ >> 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment >> 2024-03-05T16:23:29.6269004Z private final T data; >> 2024-03-05T16:23:29.6269667Z ^ >> 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified >> 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. >> 2024-03-05T16:23:31.7940244Z 1 error >> 2024-03-05T16:23:31.7940590Z 91 warnings > > Kevin Rushforth 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: > > - Add DOC_WERROR flag (default="true") to allow javadoc -Werror to be disabled > - Merge branch 'master' into 8325075-javadoc-werror > - 8325075: Enable -Werror for javadoc to fail on any warnings works as designed on macOS, with and without -PDOC_WERROR=false, with a simple `gradle javadoc` command as well as the full build (rm -rf ./build ; gradle clean sdk apps javadoc 2>&1) | tee ~/`date +"build-%Y-%m%d-%H%M%S"`.log ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1390#pullrequestreview-1953077357 From angorya at openjdk.org Thu Mar 21 19:14:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 19:14:33 GMT Subject: RFR: 8328718: Remove unused imports in javafx.controls Message-ID: Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024. Using wildcard for more than 10 static imports. This is a trivial change, 1 reviewer is probably enough. ------------- Commit messages: - static imports 10 - 8328718: Remove unused imports in javafx.controls Changes: https://git.openjdk.org/jfx/pull/1416/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328718 Stats: 160 lines in 14 files changed: 47 ins; 81 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1416.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1416/head:pull/1416 PR: https://git.openjdk.org/jfx/pull/1416 From angorya at openjdk.org Thu Mar 21 19:23:34 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 19:23:34 GMT Subject: RFR: 8328739: Remove unused imports in javafx.graphics Message-ID: Using Eclipse IDE to remove unused imports in **javafx.graphics** and update the copyright year to 2024. Using wildcard for more than 10 static imports. **PROBLEM** The code in `graphics/build/gensrc/jsl-decora/` is generated and cannot be fixed. This means this warning **must be suppressed** in IDEs until the generator script is changed not to emit unused imports. -- This is a trivial change, 1 reviewer is probably enough. ------------- Commit messages: - 8328739: Remove unused imports in javafx.graphics Changes: https://git.openjdk.org/jfx/pull/1417/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1417&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328739 Stats: 36 lines in 6 files changed: 7 ins; 20 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1417.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1417/head:pull/1417 PR: https://git.openjdk.org/jfx/pull/1417 From kcr at openjdk.org Thu Mar 21 19:51:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 19:51:24 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 23:56:50 GMT, Andy Goryachev wrote: >> Further changes to the MonkeyTester application: >> >> - remember split pane divider ? >> - use 'private' instead of 'protected' in many cases ? >> - added more scripts to the 'writing systems' text sample ? >> - added RTL window control menu ? >> - added embedded swing/fx in tools ? >> - added copy popup menu in clipboard viewer ? >> - added the custom css field to the css playground tool ? >> - added many new pages ? >> - split XYChartPage into separate pages ? >> - switched to use property sheets (some choices might be incomplete) ? >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments @karthikpandelu Can you also review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2013532396 From kcr at openjdk.org Thu Mar 21 19:58:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 19:58:24 GMT Subject: RFR: 8328400: Minor Cleanup In-Reply-To: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> References: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> Message-ID: On Tue, 19 Mar 2024 15:18:09 GMT, Andy Goryachev wrote: > - PrismTextLayout:325 misspelled 'sliptCaretOffset' > - DatePicker System.err.println L 125, 139, 172, 256 > - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin, DatePickerTest, FocusTest, and a few more) > - Labeled:821 obsolete comment > > Some more typos: > - occuring -> occurring (e.g. CellBehaviourBase) > - ButtonTest - conextMenuShouldntShowOnAction -> context... > - ControlResources - translateable -> translatable > - DateCellSkin - Pirvate -> Private > - totaly -> totally (e.g. LineChart) > - MenuItem - programatically -> programmatically > - Tooltip - invaildated -> invalidated > > (thank you @Maran23 ) Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1409#pullrequestreview-1953274847 From angorya at openjdk.org Thu Mar 21 21:10:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 21:10:27 GMT Subject: Integrated: 8328400: Minor Cleanup In-Reply-To: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> References: <8cwOtp6YzNOjtrQGYhpsToy9mleYlREl-IWpFJvuhKw=.7aab4bda-1d54-4262-ab63-bf828c2e6dea@github.com> Message-ID: On Tue, 19 Mar 2024 15:18:09 GMT, Andy Goryachev wrote: > - PrismTextLayout:325 misspelled 'sliptCaretOffset' > - DatePicker System.err.println L 125, 139, 172, 256 > - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin, DatePickerTest, FocusTest, and a few more) > - Labeled:821 obsolete comment > > Some more typos: > - occuring -> occurring (e.g. CellBehaviourBase) > - ButtonTest - conextMenuShouldntShowOnAction -> context... > - ControlResources - translateable -> translatable > - DateCellSkin - Pirvate -> Private > - totaly -> totally (e.g. LineChart) > - MenuItem - programatically -> programmatically > - Tooltip - invaildated -> invalidated > > (thank you @Maran23 ) This pull request has now been integrated. Changeset: 18eba73c Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/18eba73cff4aa91ab38ccab64303641388994e21 Stats: 68 lines in 25 files changed: 0 ins; 11 del; 57 mod 8328400: Minor Cleanup Reviewed-by: mhanl, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1409 From angorya at openjdk.org Thu Mar 21 21:14:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 21:14:31 GMT Subject: RFR: 8328742: Remove unused imports in manual tests Message-ID: Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports. **PROBLEM** The code in `graphics/build/gensrc/jsl-decora/` is generated and cannot be fixed. This means this warning **must be suppressed** in IDEs until the generator script is changed not to emit unused imports. -- This is a trivial change, 1 reviewer is probably enough. ------------- Commit messages: - undo unrelated change - 8328742: Remove unused imports in manual tests Changes: https://git.openjdk.org/jfx/pull/1418/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1418&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328742 Stats: 130 lines in 14 files changed: 35 ins; 68 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1418.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1418/head:pull/1418 PR: https://git.openjdk.org/jfx/pull/1418 From kcr at openjdk.org Thu Mar 21 21:14:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 21:14:31 GMT Subject: RFR: 8328742: Remove unused imports in manual tests In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 19:38:38 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > **PROBLEM** > The code in `graphics/build/gensrc/jsl-decora/` is generated and cannot be fixed. > This means this warning **must be suppressed** in IDEs until the generator script is changed not to emit unused imports. > > -- > > This is a trivial change, 1 reviewer is probably enough. I recommend to revert the change to the swing class. Also, you have a copy/paste error in the description regarding generated source files. modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java line 45: > 43: import com.sun.javafx.application.PlatformImpl; > 44: import com.sun.javafx.collections.ObservableListWrapper; > 45: import com.sun.javafx.scene.input.ExtendedInputMethodRequests; Probably better to do this one separately. It seems OK to combine with another module, but I'd prefer it separate from what is otherwise a test-only change. ------------- PR Review: https://git.openjdk.org/jfx/pull/1418#pullrequestreview-1953259841 PR Review Comment: https://git.openjdk.org/jfx/pull/1418#discussion_r1534574442 From angorya at openjdk.org Thu Mar 21 21:32:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 21:32:46 GMT Subject: RFR: 8328742: Remove unused imports in manual tests In-Reply-To: References: Message-ID: <73CpLmCHD-fDLLKycVuuKCWauREE-JnIA0FkYUf8VAk=.e1e6bd85-2fa5-42ac-a6cb-820aca61383a@github.com> On Thu, 21 Mar 2024 19:50:17 GMT, Kevin Rushforth wrote: > Probably better to do this one separately. will do separately. can I at least combine swing and web modules (there is only one file in swing that needs an update)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1418#discussion_r1534692541 From mhanl at openjdk.org Thu Mar 21 22:11:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 21 Mar 2024 22:11:28 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support Message-ID: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. The current implementation has the following shortcomings: - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine - Another consequence of this is, that the font size is always estimated with 0, as it is not detected - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold Some tests were failing for the following reasons: - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. - `StackedBarChartTest.java` - since we now calculate correctly, the path changed - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it - The default System font is considered a `Regular` one (style) I wrote tests and documented the stub behaviour. I did some minor changes here: - System font is now detected, also in bold and italic - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that Note: This only changes test setup, no 'production' code. ------------- Commit messages: - improve (stub) font support Changes: https://git.openjdk.org/jfx/pull/1422/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328750 Stats: 316 lines in 8 files changed: 203 ins; 14 del; 99 mod Patch: https://git.openjdk.org/jfx/pull/1422.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1422/head:pull/1422 PR: https://git.openjdk.org/jfx/pull/1422 From angorya at openjdk.org Thu Mar 21 22:23:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 22:23:20 GMT Subject: RFR: 8328745: Remove unused imports in system tests Message-ID: Using Eclipse IDE to remove unused imports in **system tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports. -- This is a trivial change (though fairly large), 1 reviewer is probably enough. ------------- Commit messages: - 8328745: Remove unused imports in system tests Changes: https://git.openjdk.org/jfx/pull/1419/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1419&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328745 Stats: 853 lines in 89 files changed: 206 ins; 480 del; 167 mod Patch: https://git.openjdk.org/jfx/pull/1419.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1419/head:pull/1419 PR: https://git.openjdk.org/jfx/pull/1419 From angorya at openjdk.org Thu Mar 21 22:24:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 22:24:39 GMT Subject: RFR: 8328746: Remove unused imports in demo apps Message-ID: Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. -- This is a trivial change (though fairly large), 1 reviewer is probably enough. ------------- Commit messages: - 8328746: Remove unused imports in demo apps Changes: https://git.openjdk.org/jfx/pull/1420/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328746 Stats: 399 lines in 75 files changed: 98 ins; 189 del; 112 mod Patch: https://git.openjdk.org/jfx/pull/1420.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1420/head:pull/1420 PR: https://git.openjdk.org/jfx/pull/1420 From kcr at openjdk.org Thu Mar 21 22:39:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 21 Mar 2024 22:39:27 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change (though fairly large), 1 reviewer is probably enough. I spot-checked a few files and left a couple inline questions. They apply to all of the cleanup PRs. apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java line 35: > 33: > 34: import static ensemble.samplepage.SamplePage.INDENT; > 35: import static ensemble.samplepage.SamplePageContent.title; I see that the static imports (for ensemble.xxx) were moved up to the top. Is that deliberate? apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java line 55: > 53: import ensemble.SampleInfo; > 54: import ensemble.SampleInfo.URL; > 55: import ensemble.generated.Samples; I see that `ensemble.xxx` is moved after `javafx.xxx`; similarly, elsewhere I see `com.sun.xxx` imports moved after. What's the algorithm your IDE uses to sort imports? sort stuff that starts with "java" first and then everything else alphabetically? apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics2d/puzzle/Piece.java line 48: > 46: /** > 47: * Node that represents a puzzle piece > 48: */ Hmm. This is more than just fixing imports. Were these lines reformatted because they were touching the modified import lines? Anything other than changes to the import statements will require extra time / mental energy to review. ------------- PR Review: https://git.openjdk.org/jfx/pull/1420#pullrequestreview-1953540892 PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534760606 PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534761136 PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534762593 From angorya at openjdk.org Thu Mar 21 22:39:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 22:39:27 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 22:23:44 GMT, Kevin Rushforth wrote: >> Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. >> >> >> -- >> >> This is a trivial change (though fairly large), 1 reviewer is probably enough. > > apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java line 35: > >> 33: >> 34: import static ensemble.samplepage.SamplePage.INDENT; >> 35: import static ensemble.samplepage.SamplePageContent.title; > > I see that the static imports (for ensemble.xxx) were moved up to the top. Is that deliberate? it's how the formatter is currently configured. do we have a preferred order? > apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java line 55: > >> 53: import ensemble.SampleInfo; >> 54: import ensemble.SampleInfo.URL; >> 55: import ensemble.generated.Samples; > > I see that `ensemble.xxx` is moved after `javafx.xxx`; similarly, elsewhere I see `com.sun.xxx` imports moved after. What's the algorithm your IDE uses to sort imports? sort stuff that starts with "java" first and then everything else alphabetically? this is how the IDE formatter is currently configured - it should not matter, especially since it dos not use wildcards (except for static imports). > apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics2d/puzzle/Piece.java line 48: > >> 46: /** >> 47: * Node that represents a puzzle piece >> 48: */ > > Hmm. This is more than just fixing imports. Were these lines reformatted because they were touching the modified import lines? Anything other than changes to the import statements will require extra time / mental energy to review. this is just one spot that bothered me. reformatted since I have to delete a blank line. won't happen again, I promise. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534768134 PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534769787 PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1534771453 From angorya at openjdk.org Thu Mar 21 23:34:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 21 Mar 2024 23:34:23 GMT Subject: RFR: 8328751: Fix missing @Overrides in modules except javafx.web Message-ID: <4jnhMepIzb3qxSyf2S24Bh5jiqzywacZBD8SrJTMcrY=.b0ebb141-78aa-44b6-b518-e19ac45fc51e@github.com> Fix missing `@Override`s in - javafx.base - javafx.controls - javafx.graphics This is still a trivial change since all the spots are identified by the IDE. 1 reviewer is probably enough. ------------- Commit messages: - 8328751: Fix missing @Overrides in modules except javafx.web Changes: https://git.openjdk.org/jfx/pull/1423/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328751 Stats: 30 lines in 9 files changed: 22 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1423.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1423/head:pull/1423 PR: https://git.openjdk.org/jfx/pull/1423 From kpk at openjdk.org Fri Mar 22 05:57:29 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 22 Mar 2024 05:57:29 GMT Subject: Integrated: 8328667: [Testbug] Enable ignored Spinner unit tests In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 07:18:28 GMT, Karthik P K wrote: > Enabled a test in `SpinnerTest` class. > Added comment to the editing test, why it can not be enabled. When Spinner value is set using `getEditor` `setText` method, the listener added to the spinner is not invoked. There is no bug for this issue. I'm not sure about the expectation in this case. > Other set of tests which are ignored are `LocalTimeSpinnerValueFactory` tests. Since these tests are unstable and fail only at certain time of the day, not enabling this test as well. This pull request has now been integrated. Changeset: 47c6193c Author: Karthik P K URL: https://git.openjdk.org/jfx/commit/47c6193c7ef264e204ba36fb4ae9f76eb0dce318 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8328667: [Testbug] Enable ignored Spinner unit tests Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1414 From kpk at openjdk.org Fri Mar 22 13:02:34 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 22 Mar 2024 13:02:34 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: References: Message-ID: <9-g1nL3aF3_DBCsnBVH9i7_7CrzPjlQLWvC2BMRyGB4=.29d18a64-9f2d-4756-8815-b5648a72e87d@github.com> On Wed, 20 Mar 2024 23:56:50 GMT, Andy Goryachev wrote: >> Further changes to the MonkeyTester application: >> >> - remember split pane divider ? >> - use 'private' instead of 'protected' in many cases ? >> - added more scripts to the 'writing systems' text sample ? >> - added RTL window control menu ? >> - added embedded swing/fx in tools ? >> - added copy popup menu in clipboard viewer ? >> - added the custom css field to the css playground tool ? >> - added many new pages ? >> - split XYChartPage into separate pages ? >> - switched to use property sheets (some choices might be incomplete) ? >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thanks @andy-goryachev-oracle for adding all these options to MonkeyTester. This will definitely help in testing many aspects of controls easily. I sanity tested few pages. My observations are listed below. - In all the pages, under Region option, if we select MAX_VALUE for Min Height or Min Width, the application hangs or whole window becomes white. I observed this issue if we select MIN_VALUE or POSITIVE_INFINITY as well. - In Bubble Chart, when multiple series are present, clear option under XYChart clears all but one series. - In colour picker, if editable option is selected, should we be able to change the colour value manually? If yes, I'm not able to edit the colour value. Added few inline comments as well. I will complete the review soon and update here if I have anymore comments. tests/manual/monkey/src/com/oracle/tools/fx/monkey/options/FontOption.java line 2: > 1: /* > 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. Minor: 2023 can be removed tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/DemoPage.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. Minor: Add 2024 here? tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/HTMLEditor_Page.java line 2: > 1: /* > 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. Minor: 2022 is not required here right? tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/TableViewPage.java line 385: > 383: s.addChoiceSupplier("20 Equal", () -> { > 384: var cs = columnBuilder(); > 385: for(int i=1; i<20; i++) { Minor: add space after `=` and `<`. Same comment for ln.no.392 tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/TreeTableViewPage.java line 142: > 140: TreeTableColumn c = newColumn(); > 141: c.setText("C" + System.currentTimeMillis()); > 142: //c.setCellValueFactory((f) -> new SimpleStringProperty(describe(c))); Minor: Commented line can be removed? tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/TreeTableViewPage.java line 400: > 398: s.addChoice("AUTO_RESIZE_NEXT_COLUMN", TreeTableView.CONSTRAINED_RESIZE_POLICY_NEXT_COLUMN); > 399: s.addChoice("AUTO_RESIZE_SUBSEQUENT_COLUMNS", TreeTableView.CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS); > 400: //s.addChoice("CONSTRAINED_RESIZE_POLICY", TreeTableView.CONSTRAINED_RESIZE_POLICY); Is there any particular reason why this line is commented? tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/XYChartPageBase.java line 2: > 1: /* > 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. Minor: Remove 2023? tests/manual/monkey/src/com/oracle/tools/fx/monkey/settings/ISettingsProvider.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. Minor: Any particular reason why only 2022 is retained here? tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/EmbeddedJTextAreaWindow.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Minor: Change 2023 -> 2024 tests/manual/monkey/src/com/oracle/tools/fx/monkey/util/ShowCharacterRuns.java line 73: > 71: HitInfo hit = owner.hitTest(new Point2D(x, y)); > 72: Path p = new Path(owner.rangeShape(hit.getCharIndex(), hit.getCharIndex() + 1)); > 73: //System.err.println(i + " " + cs); // FIX Do we still need this commented line? tests/manual/monkey/src/com/oracle/tools/fx/monkey/util/Utils.java line 44: > 42: > 43: public static void fromPairs(Object[] pairs, BiConsumer client) { > 44: for(int i=0; i Fix missing @Overrides in **javafx.web**. This is still a trivial change since all the spots are identified by the IDE. ------------- Commit messages: - part 2 - 8328752: Fix missing @Overrides in javafx.web Changes: https://git.openjdk.org/jfx/pull/1424/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328752 Stats: 1060 lines in 103 files changed: 956 ins; 0 del; 104 mod Patch: https://git.openjdk.org/jfx/pull/1424.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1424/head:pull/1424 PR: https://git.openjdk.org/jfx/pull/1424 From kcr at openjdk.org Fri Mar 22 15:44:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 22 Mar 2024 15:44:35 GMT Subject: RFR: 8328752: Fix missing @Overrides in javafx.web In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 23:48:40 GMT, Andy Goryachev wrote: > Fix missing @Overrides in **javafx.web**. > > This is still a trivial change since all the spots are identified by the IDE. There are special considerations when touching files under `modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java`, so it will need an extra pair of eyes. Also, this will need to be backported to earlier release trains to keep `modules/javafx.web/src/main/native/` identical for all releases. Reviewers: @kevinrushforth @HimaBinduMeda ------------- PR Comment: https://git.openjdk.org/jfx/pull/1424#issuecomment-2015368894 From kcr at openjdk.org Fri Mar 22 16:00:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 22 Mar 2024 16:00:52 GMT Subject: RFR: 8328749: Remove unused imports in javafx.swing, javafx.web In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:57:46 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **javafx.swing** and **javafx.web** modules, and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change, 1 reviewer is probably enough. The change to WebWorkerTest can remain, though. As noted in PR #1424 : There are special considerations when touching files under `modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java`, so it will need an extra pair of eyes. Also, this will need to be backported to earlier release trains to keep `modules/javafx.web/src/main/native/` identical for all releases. Reviewers: @kevinrushforth @HimaBinduMeda ------------- PR Comment: https://git.openjdk.org/jfx/pull/1421#issuecomment-2015393595 PR Comment: https://git.openjdk.org/jfx/pull/1421#issuecomment-2015396312 From angorya at openjdk.org Fri Mar 22 16:00:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:00:51 GMT Subject: RFR: 8328749: Remove unused imports in javafx.swing, javafx.web Message-ID: Using Eclipse IDE to remove unused imports in **javafx.swing** and **javafx.web** modules, and update the copyright year to 2024. Using wildcard for more than 10 static imports. -- This is a trivial change, 1 reviewer is probably enough. ------------- Commit messages: - 8328749: Remove unused imports in javafx.swing, javafx.web Changes: https://git.openjdk.org/jfx/pull/1421/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328749 Stats: 38 lines in 4 files changed: 11 ins; 22 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1421.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1421/head:pull/1421 PR: https://git.openjdk.org/jfx/pull/1421 From kcr at openjdk.org Fri Mar 22 16:00:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 22 Mar 2024 16:00:51 GMT Subject: RFR: 8328749: Remove unused imports in javafx.swing, javafx.web In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 15:52:02 GMT, Andy Goryachev wrote: > I suppose I'd need to extract swing into a separate PR, right @kevinrushforth ? Yes. I was just getting ready to write this: It looks like I spoke too soon when I said it was OK to combine the change to `javafx.swing` into this PR. You will need to separate it out. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1421#issuecomment-2015392567 From angorya at openjdk.org Fri Mar 22 16:00:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:00:51 GMT Subject: RFR: 8328749: Remove unused imports in javafx.swing, javafx.web In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:57:46 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **javafx.swing** and **javafx.web** modules, and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change, 1 reviewer is probably enough. I suppose I'd need to extract swing into a separate PR, right @kevinrushforth ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1421#issuecomment-2015387718 From angorya at openjdk.org Fri Mar 22 16:11:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:11:52 GMT Subject: RFR: 8328749: Remove unused imports in javafx.web [v2] In-Reply-To: References: Message-ID: > Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change, 1 reviewer is probably enough. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: removed swing file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1421/files - new: https://git.openjdk.org/jfx/pull/1421/files/b75bbf83..8fe2b264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1421&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1421&range=00-01 Stats: 17 lines in 1 file changed: 9 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1421.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1421/head:pull/1421 PR: https://git.openjdk.org/jfx/pull/1421 From angorya at openjdk.org Fri Mar 22 16:11:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:11:52 GMT Subject: RFR: 8328749: Remove unused imports in javafx.web In-Reply-To: References: Message-ID: <18uZ3VDwMAr0IBM4RbpvIXkBFdm6md8uin7NFqMsqFg=.37906b0f-9056-4fc5-be05-b08d21d618a7@github.com> On Thu, 21 Mar 2024 21:57:46 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change, 1 reviewer is probably enough. removed swing file from this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1421#issuecomment-2015423993 From angorya at openjdk.org Fri Mar 22 16:13:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:13:39 GMT Subject: RFR: 8328818: Fix Decora JSL to remove missing @Override warnings Message-ID: <8h2a6nwx1jUD2E6hPLghY2NpJnwV73t35gCpUBETlL4=.860c1daa-d2a4-4877-8415-7c3dfde605d6@github.com> Updating the JSL files to remove the "missing @ override" warning. ------------- Commit messages: - 8328818: Fix Decora JSL to remove missing @Override warnings Changes: https://git.openjdk.org/jfx/pull/1425/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328818 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1425.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1425/head:pull/1425 PR: https://git.openjdk.org/jfx/pull/1425 From angorya at openjdk.org Fri Mar 22 16:13:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:13:55 GMT Subject: RFR: 8328754: Fix missing @Overrides in test Message-ID: Fixing missing @ OVERRIDES in tests. This is still a trivial change since all the spots are identified by the IDE. ------------- Commit messages: - 8328754: Fix missing @Overrides in test Changes: https://git.openjdk.org/jfx/pull/1427/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1427&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328754 Stats: 87 lines in 23 files changed: 64 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jfx/pull/1427.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1427/head:pull/1427 PR: https://git.openjdk.org/jfx/pull/1427 From angorya at openjdk.org Fri Mar 22 16:15:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:15:05 GMT Subject: RFR: 8328811: Fix missing @Overrides in demos Message-ID: <8C4J9vD6DiRWdXCA6nH3SE5wd9fuH6hgvCR4iNhaA1Y=.dfd9409b-47f0-4d7a-af50-f40c965844d8@github.com> Fixing missing @Overrides in demo apps. This is still a trivial change since all the spots are identified by the IDE. ------------- Commit messages: - part 3 - part 2 - part 1 Changes: https://git.openjdk.org/jfx/pull/1426/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328811 Stats: 530 lines in 82 files changed: 442 ins; 0 del; 88 mod Patch: https://git.openjdk.org/jfx/pull/1426.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1426/head:pull/1426 PR: https://git.openjdk.org/jfx/pull/1426 From duke at openjdk.org Fri Mar 22 16:21:33 2024 From: duke at openjdk.org (drmarmac) Date: Fri, 22 Mar 2024 16:21:33 GMT Subject: RFR: 8267565: Support "@1x" and "@3x" high-density image naming convention Message-ID: This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than "@2x". Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. I tested this manually on Windows with "300%" UI scale factor, and verified "@x2" still works on macOS. ------------- Commit messages: - Add extended high-dpi image support Changes: https://git.openjdk.org/jfx/pull/1429/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1429&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267565 Stats: 49 lines in 5 files changed: 19 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jfx/pull/1429.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1429/head:pull/1429 PR: https://git.openjdk.org/jfx/pull/1429 From angorya at openjdk.org Fri Mar 22 16:33:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 16:33:58 GMT Subject: RFR: 8328820: Remove unused imports in javafx.swing Message-ID: Removed unused imports in javafx.swing (1 change) module. See the discussion in [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379) ------------- Commit messages: - 8328820: Remove unused imports in javafx.swing Changes: https://git.openjdk.org/jfx/pull/1428/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1428&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328820 Stats: 17 lines in 1 file changed: 7 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1428.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1428/head:pull/1428 PR: https://git.openjdk.org/jfx/pull/1428 From angorya at openjdk.org Fri Mar 22 18:31:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 18:31:26 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: <9-g1nL3aF3_DBCsnBVH9i7_7CrzPjlQLWvC2BMRyGB4=.29d18a64-9f2d-4756-8815-b5648a72e87d@github.com> References: <9-g1nL3aF3_DBCsnBVH9i7_7CrzPjlQLWvC2BMRyGB4=.29d18a64-9f2d-4756-8815-b5648a72e87d@github.com> Message-ID: On Fri, 22 Mar 2024 13:00:02 GMT, Karthik P K wrote: > * In all the pages, under Region option, if we select MAX_VALUE for Min Height or Min Width, the application hangs or whole window becomes white. I observed this issue if we select MIN_VALUE or POSITIVE_INFINITY as well. works as designed, doesn't it? it's unlikely that an app developer would set this value, but a double property does accept this value, so MT allows us to test the behavior. > * In Bubble Chart, when multiple series are present, clear option under XYChart clears all but one series. this button clears the points in the first series. I've added tooltips that explain the function. > * In colour picker, if editable option is selected, should we be able to change the colour value manually? If yes, I'm not able to edit the colour value. the `ditable` property affects text fields in the "Custom Color..." dialog, and it works correctly. It probably makes little sense to have the editable property for this control. Thanks for pointing this out - even though I did notice that when implementing the page, but did not investigate. > tests/manual/monkey/src/com/oracle/tools/fx/monkey/options/FontOption.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. > > Minor: 2023 can be removed The code also lives in a separate repository where it's copyrighted correctly (since I constantly add things to it), so no change. https://github.com/andy-goryachev-oracle/MonkeyTest > tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/DemoPage.java line 2: > >> 1: /* >> 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > > Minor: Add 2024 here? thanks for noticing (here and elsewhere)! > tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/TreeTableViewPage.java line 400: > >> 398: s.addChoice("AUTO_RESIZE_NEXT_COLUMN", TreeTableView.CONSTRAINED_RESIZE_POLICY_NEXT_COLUMN); >> 399: s.addChoice("AUTO_RESIZE_SUBSEQUENT_COLUMNS", TreeTableView.CONSTRAINED_RESIZE_POLICY_SUBSEQUENT_COLUMNS); >> 400: //s.addChoice("CONSTRAINED_RESIZE_POLICY", TreeTableView.CONSTRAINED_RESIZE_POLICY); > > Is there any particular reason why this line is commented? old code, CONSTRAINED_RESIZE_POLICY is an alias for CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN. will clean up. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2015670932 PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1536018201 PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1536018745 PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1536020410 From angorya at openjdk.org Fri Mar 22 18:36:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 18:36:45 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v3] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - review comments - Merge branch 'master' into 8316372.monkey - review comments - whitespace - tool bar - Merge branch 'master' into 8316372.monkey - whitespace - whitespace - whitespace - 8316372: Monkey Tester Application Part 3 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/2c23ca57..c472fd0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=01-02 Stats: 224 lines in 49 files changed: 32 ins; 77 del; 115 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From angorya at openjdk.org Fri Mar 22 18:50:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 18:50:26 GMT Subject: RFR: 8328718: Remove unused imports in javafx.controls In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > This is a trivial change, 1 reviewer is probably enough. @Maran23 @nlisker would you like to review this PR and its relatives? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1416#issuecomment-2015710063 From nlisker at openjdk.org Fri Mar 22 19:01:30 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 22 Mar 2024 19:01:30 GMT Subject: RFR: 8328718: Remove unused imports in javafx.controls In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > This is a trivial change, 1 reviewer is probably enough. I can, but it will take me some time to get to it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1416#issuecomment-2015727802 From andy.goryachev at oracle.com Fri Mar 22 20:49:03 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 22 Mar 2024 20:49:03 +0000 Subject: RFC: Screen capturing utility (for failed headful tests) Message-ID: Dear colleagues: What do you think of the following idea: The Problem =========== Automated headful tests might fail intermittently or on specific platform(s). After the fact, it's nearly impossible to understand why this happened. Solution ======== Implement a JUnit5 TestWatcher which captures the primary screen pixels and dumps them as base64-encoded PNG images in stderr (or stdout). The logs are typically preserved, so the screenshots can be analyzed after the fact. As far as I know, there is no way to configure JUnit to apply this to each test using command line option, so each test needs to have the following annotation added: @ExtendWith(ScreenCaptureTestWatcher.class) For more details please see this ticket [0] and the draft PR [1]. Possible Issues =============== * the size of the image can be quite large, for example retina mac increases the size of the log by approximately 4MB (for each image). * a misconfiguration might cause every test to fail, resulting in very large logs References ========== [0] https://bugs.openjdk.org/browse/JDK-8328716 [1] https://github.com/openjdk/jfx/pull/1415 What do you think? Cheerio, -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Fri Mar 22 21:33:05 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Mar 2024 14:33:05 -0700 Subject: RFC: Screen capturing utility (for failed headful tests) In-Reply-To: References: Message-ID: <3a79aa68-ca5c-4cd8-9177-f4491979a54a@oracle.com> I like this idea in general. It would be a good thing to consider for a future test sprint. I have a few high-level questions on the specifics: 1. I've not used JUnit5 TestWatcher at all, but it seems like it might do what we want. Does anyone else have practical experience with it? For cases where a test passes or is skipped, is there any impact on the report? 2. Even if we do annotate all our JUnit5 headful robot tests with this, I would want to qualify that on a system property -- probably off by default. I presume this should be as easy as having the "onFailed" (or whatever it's called) method of the watcher check this property and do nothing if it isn't enabled? 3. Depending on how the test exits, it's quite possible that the JavaFX runtime has shutdown. It might be a bit tricky to do this in a robust manner without doing an exec of a new Java process. Any thoughts on this? 4. In answer to the problem of what happens if all too many tests fail (flooding the log), maybe you could have a system property that sets a max number of images to log? That might be hard to implement, though, unless you store some information in the build directory of the system tests, since each system test necessarily runs in a separate Java process. 5. Is writing to the log (e.g., System.err) the best way to capture the data? Whatever we do, we will want some easy way to extract and display the screenshots. If we do move forward with this, and use the JUnit5 TestWatcher facility, this will be one more motivation to drive the conversion of tests from JUnit4 to JUnit5 -- at least in the system tests project. See JDK-8328629 [2]. -- Kevin [2] https://bugs.openjdk.org/browse/JDK-8328629 On 3/22/2024 1:49 PM, Andy Goryachev wrote: > > Dear colleagues: > > What do you think of the following idea: > > The Problem > > =========== > > Automated headful tests might fail intermittently or on specific > platform(s).? After the fact, it's nearly impossible to understand why > this happened. > > Solution > > ======== > > Implement a JUnit5 TestWatcher which captures the primary screen > pixels and dumps them as base64-encoded PNG images in stderr (or > stdout).? The logs are typically preserved, so the screenshots can be > analyzed after the fact. > > As far as I know, there is no way to configure JUnit to apply this to > each test using command line option, so each test needs to have the > following annotation added: > > @ExtendWith(ScreenCaptureTestWatcher.class) > > For more details please see this ticket [0] and the draft PR [1]. > > Possible Issues > > =============== > > * the size of the image can be quite large, for example retina mac > increases the size of the log by approximately 4MB (for each image). > * a misconfiguration might cause every test to fail, resulting in > very large logs > > References > > ========== > > [0] https://bugs.openjdk.org/browse/JDK-8328716 > > [1] https://github.com/openjdk/jfx/pull/1415 > > What do you think? > > Cheerio, > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Mar 22 22:40:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 22:40:26 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Thu, 21 Mar 2024 22:06:42 GMT, Marius Hanl wrote: > In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. > > The current implementation has the following shortcomings: > - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine > - Another consequence of this is, that the font size is always estimated with 0, as it is not detected > - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold > > Some tests were failing for the following reasons: > - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. > - `StackedBarChartTest.java` - since we now calculate correctly, the path changed > - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it > - The default System font is considered a `Regular` one (style) > > I wrote tests and documented the stub behaviour. > I did some minor changes here: > - System font is now detected, also in bold and italic > - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that > > Note: This only changes test setup, no 'production' code. modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 538: > 536: .map(lineTo -> new Point2D( > 537: Math.ceil(xAxis.getValueForDisplay(lineTo.getX()).doubleValue()), > 538: Math.ceil(yAxis.getValueForDisplay(lineTo.getY()).doubleValue())) would it make more sense to either do a Math.round(), or better yet - write a utility that computes array equality of Point2D's with some non-zero tolerance? Do we have more tests like this that might warrant a new utility? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/StubFontContractTest.java line 21: > 19: * @see test.com.sun.javafx.pgstub.StubFontLoader > 20: * @see test.com.sun.javafx.pgstub.StubTextLayout > 21: */ thank you for explaining what the test is trying to do (and not trying to do)! modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 57: > 55: case "system italic" -> FontHelper.setNativeFont(font, nativeFont, font.getName(), "System", "Italic"); > 56: case "system bold italic" -> > 57: FontHelper.setNativeFont(font, nativeFont, font.getName(), "System", "Bold Italic"); minor suggestions: font -> f nativeFont -> nf this will nicely fit each case on a single line (and reduce clutter) modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 76: > 74: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Regular"); > 75: case "amble light condensed italic" -> > 76: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Italic"); does it make sense to handle/log the default case, or this is indeed the desired code (i.e. a no-op)? modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java line 102: > 100: boolean bold = font.getStyle().toLowerCase().contains("bold"); > 101: if (bold) { > 102: fontSize++; should this only apply to width computation (line 128)? in other words, the height of for bold text of size 12 should have the same height as plain text size 12, shouldn't it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1536280082 PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1536280361 PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1536281156 PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1536281935 PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1536284428 From angorya at openjdk.org Fri Mar 22 23:10:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 22 Mar 2024 23:10:31 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic [v4] In-Reply-To: References: Message-ID: <5Hi4OhAPKSoj0yU24tddC8IOJtoefOEaqAMJiMBPIc4=.f28aa0b1-f717-4e38-a887-5bda483b9cd5@github.com> On Wed, 20 Mar 2024 19:53:40 GMT, Marius Hanl wrote: >> This PR fixes the issue that the initial column autosizing is wrong under some circumstances. >> The following things will break the initial autosizing: >> - Bold Column text (that is where I initially found this problem) >> - Another font / font size >> - Graphic >> >> The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well. >> >> _It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me._ >> **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)** >> >> The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text. >> >> I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy). > > Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8186188: copyright > - JDK-8186188: fix tests the main question is whether this PR depends on #1422, or whether the unrelated changes need to be removed. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 686: > 684: TableColumnHeader header = tableSkin.getTableHeaderRow().getColumnHeaderFor(tc); > 685: header.applyCss(); > 686: double headerWidth = header.label.prefWidth(-1) + 10; should we extract this magic constant (along with the comment)? although this might be outside of the scope of this PR, lines 651, 744. modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 537: > 535: .map(pathElement -> (LineTo) pathElement) > 536: .map(lineTo -> new Point2D( > 537: Math.round(xAxis.getValueForDisplay(lineTo.getX()).doubleValue()), please revert the unrelated changes (moved to #1422) modules/javafx.controls/src/test/java/test/javafx/scene/chart/StackedBarChartTest.java line 111: > 109: String bounds = computeBoundsString((Region)childrenList.get(0), (Region)childrenList.get(1), > 110: (Region)childrenList.get(2)); > 111: assertEquals("10 453 218 35 238 409 218 79 465 355 218 133 ", bounds); unrelated modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 158: > 156: Scene s = new Scene(textInput); > 157: textInput.applyCss(); > 158: assertEquals(Font.font("Amble", 24), textInput.getFont()); unrelated modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTreeTableTest.java line 48: > 46: import javafx.scene.layout.HBox; > 47: import javafx.scene.text.Text; > 48: import org.junit.After; this is a new test - should we use JUnit5? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTreeTableTest.java line 64: > 62: private TableColumnHeader firstColumnHeader; > 63: private TreeTableView tableView; > 64: private StageLoader sl; minor: this field should probably be named `stageLoader` modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTreeTableTest.java line 153: > 151: > 152: assertEquals("Width must be the same", > 153: width, column.getWidth(), 0.001); maybe a constant, here and elsewhere private static final double EPSILON = 0.001; ? modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 53: > 51: if (name.equals("system regular")) { > 52: FontHelper.setNativeFont(font, nativeFont, font.getName(), "System", "Regular"); > 53: } else if (name.equals("system bold")) { does this mean this PR requires #1422 to be integrated first? ------------- PR Review: https://git.openjdk.org/jfx/pull/1405#pullrequestreview-1955910101 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536295365 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536296972 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536297127 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536297778 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536298798 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536299480 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536300462 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1536315771 From tsayao at openjdk.org Sun Mar 24 12:15:31 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 24 Mar 2024 12:15:31 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > 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 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 Would be nice if IME users could provide feedback on this. I can provide test binaries if necessary. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2016789460 From thiago.sayao at gmail.com Sun Mar 24 12:26:39 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 24 Mar 2024 09:26:39 -0300 Subject: Project Wakefield Message-ID: Hi, I watched the presentation of Project Wakefield: https://youtu.be/5gfZDx6IOD4?si=vusIcnKGFLzO8IfG Doing it on JavaFX would be much much easier. Rendering thru es2 works by just replacing GLX with EGL. Then the glass events we just replace GTK with Wayland-client. Project Wakefield came with the same conclusion - gtk4 is a no-go - mostly because sharing the rendering with GTK is hard. -- Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Mar 24 15:14:42 2024 From: duke at openjdk.org (drmarmac) Date: Sun, 24 Mar 2024 15:14:42 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed Message-ID: This PR removes potentially incorrect usages of Stream.peek(). The changed code should be covered by the tests that are already present. ------------- Commit messages: - Remove Stream.peek() operation Changes: https://git.openjdk.org/jfx/pull/1430/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8273349 Stats: 21 lines in 2 files changed: 10 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1430.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1430/head:pull/1430 PR: https://git.openjdk.org/jfx/pull/1430 From duke at openjdk.org Sun Mar 24 15:15:36 2024 From: duke at openjdk.org (drmarmac) Date: Sun, 24 Mar 2024 15:15:36 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases Message-ID: This PR should fix the issue and cover all relevant cases with new tests. ------------- Commit messages: - Fixed wrap-around behavior for SpinnerValueFactory - Add failing tests Changes: https://git.openjdk.org/jfx/pull/1431/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1431&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8242553 Stats: 221 lines in 4 files changed: 184 ins; 12 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/1431.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1431/head:pull/1431 PR: https://git.openjdk.org/jfx/pull/1431 From duke at openjdk.org Sun Mar 24 15:15:48 2024 From: duke at openjdk.org (drmarmac) Date: Sun, 24 Mar 2024 15:15:48 GMT Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values Message-ID: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown. ------------- Commit messages: - TransformationList.getSourceIndex/getViewIndex should throw IOOBE - Add failing test Changes: https://git.openjdk.org/jfx/pull/1432/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271865 Stats: 53 lines in 5 files changed: 37 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1432.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1432/head:pull/1432 PR: https://git.openjdk.org/jfx/pull/1432 From kpk at openjdk.org Mon Mar 25 07:15:27 2024 From: kpk at openjdk.org (Karthik P K) Date: Mon, 25 Mar 2024 07:15:27 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: References: <9-g1nL3aF3_DBCsnBVH9i7_7CrzPjlQLWvC2BMRyGB4=.29d18a64-9f2d-4756-8815-b5648a72e87d@github.com> Message-ID: <_XEVIlhx9JMeOPJkfyggSUcR2ave4I3mnXGnaKdzAhM=.4dcf650a-6a1c-4049-a133-242d15caeb0c@github.com> On Fri, 22 Mar 2024 18:23:41 GMT, Andy Goryachev wrote: > > * In all the pages, under Region option, if we select MAX_VALUE for Min Height or Min Width, the application hangs or whole window becomes white. I observed this issue if we select MIN_VALUE or POSITIVE_INFINITY as well. > > works as designed, doesn't it? it's unlikely that an app developer would set this value, but a double property does accept this value, so MT allows us to test the behavior. > Yes the functionality is correct but I'm not sure how it affects MT application. I tried to set MAX_VALUE few times for width and height in different pages and now the MT window is not launching itself. I can see the MT app process getting created but no window is showing up. I'm not sure if there will be any side effects similar to this if someone tries to test it. I'm running MT on Mac 14.3 in IntelliJ IDEA CE. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2017362160 From jdv at openjdk.org Mon Mar 25 12:28:37 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 25 Mar 2024 12:28:37 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently Message-ID: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> This test has failed once and we are not seeing its failure after that instance in our test systems. This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. We are making this test robust to make sure we don't see any of these single instance failures. Test is updated to: 1) To always show on top, so that we pick proper color. 2) Add additional sleep so that we give more time for test to be visible. 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. ------------- Commit messages: - 8306322: JDK8130122Test fails intermittently Changes: https://git.openjdk.org/jfx/pull/1433/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306322 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1433.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1433/head:pull/1433 PR: https://git.openjdk.org/jfx/pull/1433 From jdv at openjdk.org Mon Mar 25 12:58:30 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 25 Mar 2024 12:58:30 GMT Subject: RFR: 8327179: Update the 3D lighting application [v4] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 22:32:59 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with five additional commits since the last revision: > > - Added spacing > - Renamed constant > - Updated benchmark reset message > - Simplified models creation > - Revert resource package Even after reverting package name i continue to see that 3DLighting throws exception when we manually launch it: javafx.graphics at 23-internal/javafx.scene.image.Image.validateInputStream(Image.java:1140) at javafx.graphics at 23-internal/javafx.scene.image.Image.(Image.java:707) at attenuation.Environment.(Environment.java:64) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2017939695 From mstrauss at openjdk.org Mon Mar 25 13:34:36 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 25 Mar 2024 13:34:36 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Fri, 9 Jun 2023 12:00:06 GMT, John Hendrikx wrote: >> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. >> >> # Behavior >> >> |Listener...|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| >> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| >> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| >> >> ## Nested notifications: >> >> | |ExpressionHelper|ListenerManager| >> |---|---|---| >> |Type|Depth first (call stack increases for each nested level)|(same)| >> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| >> |Vetoing Possible?|No|Yes| >> |Old Value correctness|Only for listeners called before listeners making nested changes|Always| >> >> # Performance >> >> |Listener|ExpressionHelper|ListenerManager| >> |---|---|---| >> |Addition|Array based, append in empty slot, resize as needed|(same)| >> |Removal|Array based, shift array, resize as needed|(same)| >> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| >> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| >> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| >> |Notifying Invalidation Listeners|1 ns each|(same)| >> |Notifying Change Listeners|1 ns each (*)|2-3 ns each| >> >> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values >> >> # Memory Use >> >> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. >> >> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| >> |---|---|---|---| >> |No Listeners|none|none|none| >> |Single InvalidationListener|16 bytes overhead|none|none| >> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| >> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| >> >> # About nested changes >> >> Nested changes are simply changes... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix generic warnings `ListenerManager` is an obvious improvement, as it fixes incorrect behavior and allows listeners to veto changes. However, the behavior of `ListenerManager` is also an implementation detail and not documented anywhere. This leads me to the following questions: 1. How will users know that they can now do all of the things that were previously broken? Do we need a specification for what is allowed and what's not allowed? 2. Should this behavior be required for all valid `ObservableValue` implementations? (This would render many existing implementations defective.) 3. If `ObservableValue` implementations are not required to replicate the `ListenerManager` behavior, we should probably make it easily discoverable whether any particular implementation (most of them are properties) supports nested changes/vetoing. In most of the public API, there's no obvious way to see (without looking at the source code) whether a property implementation extends one of the `*PropertyBase` classes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2018017130 From kcr at openjdk.org Mon Mar 25 14:31:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 14:31:30 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently In-Reply-To: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: <3BjQWCzigQM9uh1XGU-2ys8tM-V30Ga12q6bhuaWnrA=.50ea520e-aab8-4724-bfd7-aff76ca63432@github.com> On Mon, 25 Mar 2024 12:25:33 GMT, Jayathirth D V wrote: > This test has failed once and we are not seeing its failure after that instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. The changes look fine, except for the redundant call to `setAlwaysOnTop` (it already is). tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 87: > 85: testScene.setFill(Color.WHITE); > 86: testStage.setScene(testScene); > 87: testStage.setAlwaysOnTop(true); This is redundant. `getStage()` already sets `alwaysOnTop`. If the window currently isn't always on top then we have a bigger problem. ------------- PR Review: https://git.openjdk.org/jfx/pull/1433#pullrequestreview-1957898714 PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1537684648 From angorya at openjdk.org Mon Mar 25 14:49:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 14:49:27 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v2] In-Reply-To: <_XEVIlhx9JMeOPJkfyggSUcR2ave4I3mnXGnaKdzAhM=.4dcf650a-6a1c-4049-a133-242d15caeb0c@github.com> References: <9-g1nL3aF3_DBCsnBVH9i7_7CrzPjlQLWvC2BMRyGB4=.29d18a64-9f2d-4756-8815-b5648a72e87d@github.com> <_XEVIlhx9JMeOPJkfyggSUcR2ave4I3mnXGnaKdzAhM=.4dcf650a-6a1c-4049-a133-242d15caeb0c@github.com> Message-ID: On Mon, 25 Mar 2024 07:13:18 GMT, Karthik P K wrote: > I can see the MT app process getting created but no window is showing up. Oh I see - it stored the user choice. Delete the folder `~/.MonkeyTester` (or `\Users....MonkeyTester` and all should be well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1406#issuecomment-2018173557 From nlisker at openjdk.org Mon Mar 25 14:53:29 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 25 Mar 2024 14:53:29 GMT Subject: RFR: 8327179: Update the 3D lighting application [v4] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 22:32:59 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with five additional commits since the last revision: > > - Added spacing > - Renamed constant > - Updated benchmark reset message > - Simplified models creation > - Revert resource package I can't reproduce the exception. The path to the image is correct. Both the class and the image are under the `attenuation` package. Here is my launch command: C:\Program Files\Java\jdk-21\bin\javaw.exe "-Djava.library.path=C:\Users\Nir\git\jfx\modules\javafx.graphics\build\module-lib" --add-modules=javafx.controls,javafx.swing -Dfile.encoding=UTF-8 -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8 -p "C:\Users\Nir\git\jfx\modules\javafx.controls\bin;C:\Users\Nir\git\jfx\modules\javafx.graphics\bin;C:\Users\Nir\git\jfx\modules\javafx.base\bin;C:\Users\Nir\git\jfx\modules\javafx.swing\bin" -classpath "C:\Users\Nir\git\jfx\tests\performance\3DLighting\bin" -XX:+ShowCodeDetailsInExceptionMessages --add-exports javafx.graphics/test.com.sun.javafx.pgstub=javafx.controls --add-exports javafx.base/test.com.sun.javafx.binding=javafx.controls --add-exports javafx.base/test.util.memory=javafx.controls --add-exports javafx.base/test.javafx.collections=javafx.controls --add-exports javafx.base/com.sun.javafx.property=javafx.graphics --add-exports javafx.base/test.javafx.collections=javafx.graphics --add-exports javafx.base/test.util.memory=javafx.graphics --add-exports java.base/sun.security.util=javafx.graphics --add-reads javafx.base=java.management --add-reads javafx.base=jdk.management attenuation.LightingApplication Perhaps it's a platform-dependent path issue? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2018183992 From angorya at openjdk.org Mon Mar 25 15:03:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 15:03:52 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v4] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/c472fd0c..4109791e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From angorya at openjdk.org Mon Mar 25 16:44:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 16:44:28 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently In-Reply-To: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: On Mon, 25 Mar 2024 12:25:33 GMT, Jayathirth D V wrote: > This test has failed once and we are not seeing its failure after that instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 102: > 100: horizontalListView.setVisible(true); > 101: }); > 102: sleep(1000); we still have JDK-8176902 open, but perhaps here we could add a new method to VisualTestBase similar to waitNextFrame(), with an appropriate parameter? Something like protected void waitForIdle() { frameWait(100); } instead of 1 second sleep() ? What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1537896499 From kcr at openjdk.org Mon Mar 25 18:26:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 18:26:30 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. Reviewers @andy-goryachev-oracle @karthikpandelu ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2018637699 From kcr at openjdk.org Mon Mar 25 18:31:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 18:31:27 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. @drmarmac It is generally best to ask whether an assigned bug is actively being worked on before submitting a PR. In this case, I suspect it wasn't being worked on. I've asked the assignee (Karthik) to be one of the reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2018645322 From kcr at openjdk.org Mon Mar 25 18:33:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 18:33:26 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:10:22 GMT, drmarmac wrote: > This PR removes potentially incorrect usages of Stream.peek(). > The changed code should be covered by the tests that are already present. Reviewers: @andy-goryachev-oracle @karthikpandelu ------------- PR Comment: https://git.openjdk.org/jfx/pull/1430#issuecomment-2018647835 From kcr at openjdk.org Mon Mar 25 18:34:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 18:34:26 GMT Subject: RFR: 8267565: Support "@1x" and "@3x" high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2018650301 From duke at openjdk.org Mon Mar 25 18:45:26 2024 From: duke at openjdk.org (drmarmac) Date: Mon, 25 Mar 2024 18:45:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. ok, thanks for the notice! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2018667963 From kcr at openjdk.org Mon Mar 25 18:57:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 18:57:32 GMT Subject: RFR: 8267565: Support "@1x" and "@3x" high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. The title of this enhancement (and, thus, the PR) should be updated to indicate that `@4x` is also supported. Related to this, I don't see logic for supporting `@1x`, so either we should add this support (carefully, because unlike the other resolutions, we do _not_ want to go looking for `@1x` unless the file without any `@` suffix is not found, since the vast majority of cases will have only a single image without any `@` suffix and even where the `@2x` convention is used, the base resolution image typically has no suffix), or else remove `@1x` from the title and file a separate issue to consider adding support for the `@1x` naming convention. I would favor the latter (split out any support for `@1x` into a separate Enhancement request), meaning a possible title for _this_ JBS issue and PR might be: Support "@3x" and greater high-density image naming convention ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2018688462 From kcr at openjdk.org Mon Mar 25 20:07:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 20:07:29 GMT Subject: RFR: 8328818: Fix Decora JSL to remove missing @Override warnings In-Reply-To: <8h2a6nwx1jUD2E6hPLghY2NpJnwV73t35gCpUBETlL4=.860c1daa-d2a4-4877-8415-7c3dfde605d6@github.com> References: <8h2a6nwx1jUD2E6hPLghY2NpJnwV73t35gCpUBETlL4=.860c1daa-d2a4-4877-8415-7c3dfde605d6@github.com> Message-ID: On Fri, 22 Mar 2024 15:53:14 GMT, Andy Goryachev wrote: > Updating the JSL files to remove the "missing @ override" warning. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1425#pullrequestreview-1958676563 From kcr at openjdk.org Mon Mar 25 20:09:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 20:09:27 GMT Subject: RFR: 8328751: Fix missing @Overrides in modules except javafx.web In-Reply-To: <4jnhMepIzb3qxSyf2S24Bh5jiqzywacZBD8SrJTMcrY=.b0ebb141-78aa-44b6-b518-e19ac45fc51e@github.com> References: <4jnhMepIzb3qxSyf2S24Bh5jiqzywacZBD8SrJTMcrY=.b0ebb141-78aa-44b6-b518-e19ac45fc51e@github.com> Message-ID: <4pXTQS2rliEovBWfA66TxWD5KkjHNrpy6lj8QfpDkiE=.65e94d7b-5ff1-442f-9070-266e709848a4@github.com> On Thu, 21 Mar 2024 22:43:38 GMT, Andy Goryachev wrote: > Fix missing `@Override`s in > - javafx.base > - javafx.controls > - javafx.graphics > > This is still a trivial change since all the spots are identified by the IDE. > > 1 reviewer is probably enough. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1423#pullrequestreview-1958678783 From kcr at openjdk.org Mon Mar 25 20:14:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 20:14:29 GMT Subject: RFR: 8324939: Editable TableView loses focus after commit In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 10:55:56 GMT, Jose Pereda wrote: > This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly. > > For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before). > > By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before). > > Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix). @andy-goryachev-oracle Can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1411#issuecomment-2018826207 From angorya at openjdk.org Mon Mar 25 20:17:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 20:17:26 GMT Subject: RFR: 8324939: Editable TableView loses focus after commit In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 20:11:21 GMT, Kevin Rushforth wrote: > Can you review this? in the queue; yes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1411#issuecomment-2018832489 From kcr at openjdk.org Mon Mar 25 20:39:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 20:39:30 GMT Subject: RFR: 8327179: Update the 3D lighting application [v4] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 22:32:59 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with five additional commits since the last revision: > > - Added spacing > - Renamed constant > - Updated benchmark reset message > - Simplified models creation > - Revert resource package I can reproduce the exception if I compile the test program from the command line in the `.../src/main/java` dir using javac and run the program from there. The reason that happens is the separation of the resources into a separate directory tree. One way to solve this, so we can still easily compile and run it from the command line, is to provide an "ant" or "gradle" script as was done for `MonkeyTester` and `FXMediaPlayer` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2018870284 From jhendrikx at openjdk.org Mon Mar 25 21:47:30 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 25 Mar 2024 21:47:30 GMT Subject: RFR: JDK-8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v11] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.7107724a-fb24-4f68-90fe-042e69e320b5@github.com> Message-ID: On Mon, 25 Mar 2024 13:32:11 GMT, Michael Strau? wrote: > `ListenerManager` is an obvious improvement, as it fixes incorrect behavior and allows listeners to veto changes. However, the behavior of `ListenerManager` is also an implementation detail and not documented anywhere. This leads me to the following questions: > > 1. How will users know that they can now do all of the things that were previously broken? Do we need a specification for what is allowed and what's not allowed? Currently the specification is vague enough that there's a lot of wiggle room. For example, we don't specify whether invalidation listeners are called before change listeners, yet a lot of code will be relying on that unknowingly. We also don't specify whether successive change listener calls should always be a change (ie. never get `A -> A`), or that it should match with what the previous change reported (ie. if called with `? -> B`, then the next call must be `B -> ?`). IMHO we should though. I would specify for example that: - Invalidation listeners are called before Change listeners (reason: invalidation listeners are a lower level concept defined in a higher level interface). They definitely should not be mixed (they're defined by two different interfaces). - Change listeners should (obviously as this MR fixes this) guarantee the old value makes sense: - Old value will be equal to previous new value (essential for patterns that use the old value to unregister a related listener) - Never called when old value equals new value (it's not a change then) -- this allows vetoing, and generally saves unnecessary calls We should probably also specify the order of calls (as code will again unknowingly be relying on this already): - A listener registered after a listener of the same type will always be called after earlier registered listeners (code relies on this in various ways, even in FX itself) - Listeners of different types follow a fixed order: invalidation first, changes second (code relies on this already) - The behavior of `ObservableValue`s that contain mutable values (ie. lists/sets/maps/atomics) will be undefined if those values are mutated while held by an observable (same as when you mutate keys that are currently part of a `Set`). We can also specify some behavior with regards to when an event can be received when adding and removing listeners, although I think that's less of an issue. > 2. Should this behavior be required for all valid `ObservableValue` implementations? (This would render many existing implementations defective.) It's hard to require anything in an interface, but I think the interface should specify this regardless. Just look at an interface like `Set` that requires a specific way of implementing `hashCode`. You can violate it easily, but you will suffer the consequences when comparing sets of different types. Same with custom implementations of `ObservableValue`. You take a risk when using some unvetted 3rd party implementation. At a minimum all implementations in JavaFX should follow the specification. This will likely cover most implementations of `ObservableValue`, leaving only a few custom implementations that are not 100% spec compliant (note: a lot of the problems only occur with nested changes, which occur only in complicated code that triggers a cascade of changes, usually layout/skin/css related). A problem there are the Set/List/Map `ObservableValue` implementations. They are not observable values, they are observable collections that deserve their own interface. Invalidation listeners are fine, but value listeners make no sense. I've looked into these before, and all I can say is that they take great liberties with what is considered a "change" (ignoring even the most basic specifications). I'd recommend deprecating the observable value parts of these, and moving users towards either invalidation or the collection specific change listeners. > 3. If `ObservableValue` implementations are not required to replicate the `ListenerManager` behavior, we should probably make it easily discoverable whether any particular implementation (most of them are properties) supports nested changes/vetoing. In most of the public API, there's no obvious way to see (without looking at the source code) whether a property implementation extends one of the `*PropertyBase` classes. I think if the implementation is in `javafx.*` it should be correct. Anyone can violate any interface (just look at custom collection implementations which often fail to follow the spec). We could provide a more lenient abstract base class or helper to make it easier to conform to the spec. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2018972993 From angorya at openjdk.org Mon Mar 25 21:47:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 21:47:43 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v5] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: spinner page ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/4109791e..b39ef153 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=03-04 Stats: 340 lines in 12 files changed: 179 ins; 55 del; 106 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From angorya at openjdk.org Mon Mar 25 21:49:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 21:49:25 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. @karthikpandelu I've updated the spinner page in the monkey tester #1406 so we can use it to test this PR (totally missed that this page was incomplete). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2018975476 From angorya at openjdk.org Mon Mar 25 21:51:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 21:51:50 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v6] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/b39ef153..5f234e78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From angorya at openjdk.org Mon Mar 25 22:00:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 22:00:45 GMT Subject: RFR: 8092102: Labeled: truncated property [v5] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone. > > **See Also** > > * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated > * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...) Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into 8092102.truncated - labeled helper - handle tree/table view cells - Merge remote-tracking branch 'origin/master' into 8092102.truncated - review comments - Merge remote-tracking branch 'origin/master' into 8092102.truncated - 8092102 Labeled: truncated property ------------- Changes: https://git.openjdk.org/jfx/pull/1389/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=04 Stats: 189 lines in 4 files changed: 161 ins; 19 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1389.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389 PR: https://git.openjdk.org/jfx/pull/1389 From angorya at openjdk.org Mon Mar 25 22:00:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 22:00:45 GMT Subject: RFR: 8092102: Labeled: truncated property [v4] In-Reply-To: References: <2HCtXcOo2J51kkvJAOuofqZu2c1f_Z-9EaNIhichZdY=.6b452172-e25e-4d1a-ad0b-47700e3a2ec7@github.com> Message-ID: On Fri, 15 Mar 2024 09:43:26 GMT, Marius Hanl wrote: >> Okay. >> >> Tests: Well, there are some properties we can test here: >> - wrapText = true -> height should be used -> check truncated >> - width changed -> check truncated >> - text changed -> check truncated > > You can check here how I manipulated the size of the stage of the `StageLoader`. > https://github.com/openjdk/jfx/pull/1396 > Than we can check and set some properties on any `Labeled`, probably the `Label` is good here. And on the stage if needed (width, height). thanks, tests are coming. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1538284627 From angorya at openjdk.org Mon Mar 25 22:09:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 22:09:26 GMT Subject: Integrated: 8328751: Fix missing @Overrides in modules except javafx.web In-Reply-To: <4jnhMepIzb3qxSyf2S24Bh5jiqzywacZBD8SrJTMcrY=.b0ebb141-78aa-44b6-b518-e19ac45fc51e@github.com> References: <4jnhMepIzb3qxSyf2S24Bh5jiqzywacZBD8SrJTMcrY=.b0ebb141-78aa-44b6-b518-e19ac45fc51e@github.com> Message-ID: On Thu, 21 Mar 2024 22:43:38 GMT, Andy Goryachev wrote: > Fix missing `@Override`s in > - javafx.base > - javafx.controls > - javafx.graphics > > This is still a trivial change since all the spots are identified by the IDE. > > 1 reviewer is probably enough. This pull request has now been integrated. Changeset: 93e3bb2c Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/93e3bb2ce8c756f84ca23dc2e96b37c20936c1df Stats: 30 lines in 9 files changed: 22 ins; 0 del; 8 mod 8328751: Fix missing @Overrides in modules except javafx.web Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1423 From angorya at openjdk.org Mon Mar 25 22:11:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 22:11:27 GMT Subject: Integrated: 8328818: Fix Decora JSL to remove missing @Override warnings In-Reply-To: <8h2a6nwx1jUD2E6hPLghY2NpJnwV73t35gCpUBETlL4=.860c1daa-d2a4-4877-8415-7c3dfde605d6@github.com> References: <8h2a6nwx1jUD2E6hPLghY2NpJnwV73t35gCpUBETlL4=.860c1daa-d2a4-4877-8415-7c3dfde605d6@github.com> Message-ID: <1z4Fg7WsP6AylFV3H6pgbclZiw0YVc0r7-fbIPZAf4U=.af17304e-ed89-4fe5-a628-50e63e0f07f7@github.com> On Fri, 22 Mar 2024 15:53:14 GMT, Andy Goryachev wrote: > Updating the JSL files to remove the "missing @ override" warning. This pull request has now been integrated. Changeset: 611555ee Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/611555eedbdc50f00ff1c050e6972df1e922e3cd Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8328818: Fix Decora JSL to remove missing @Override warnings Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1425 From kcr at openjdk.org Mon Mar 25 22:28:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 25 Mar 2024 22:28:26 GMT Subject: Integrated: 8325075: Enable -Werror for javadoc to fail on any warnings In-Reply-To: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> References: <0m_dSN_yxnyNwcWPhIgVbXQIw-iLcZExoU-oBcIHUn0=.fa9c61dd-68c6-442d-8591-63a51fdd64c6@github.com> Message-ID: On Tue, 5 Mar 2024 16:47:45 GMT, Kevin Rushforth wrote: > Now that the last of the javadoc warnings are fixed or suppressed, it is time to enable `-Werror` so that new javadoc warnings don't creep into our code base. The GHA run was successful. > > You can see the `-Werror` doing its job in the following GHA workflow run on my [bad-8325075-javadoc-werror](https://github.com/kevinrushforth/jfx/tree/bad-8325075-javadoc-werror) branch, which has the patch from this PR applied on a base without Andy's fix for the last of the javadoc warnings: > > https://github.com/kevinrushforth/jfx/actions/runs/8159524643/job/22304043414 > > That build fails with the expected error: > > > 2024-03-05T16:23:29.6264357Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebErrorEvent.java:125: warning: no comment > 2024-03-05T16:23:29.6265947Z private final String message; > 2024-03-05T16:23:29.6266448Z ^ > 2024-03-05T16:23:29.6267675Z /home/runner/work/jfx/jfx/jfx/modules/javafx.web/src/main/java/javafx/scene/web/WebEvent.java:80: warning: no comment > 2024-03-05T16:23:29.6269004Z private final T data; > 2024-03-05T16:23:29.6269667Z ^ > 2024-03-05T16:23:31.7938955Z error: warnings found and -Werror specified > 2024-03-05T16:23:31.7939652Z Problems generating Javadoc. > 2024-03-05T16:23:31.7940244Z 1 error > 2024-03-05T16:23:31.7940590Z 91 warnings This pull request has now been integrated. Changeset: 4beeb89f Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/4beeb89f864ccf1424db36c9739a7f6999adeecc Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8325075: Enable -Werror for javadoc to fail on any warnings Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1390 From angorya at openjdk.org Mon Mar 25 22:36:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 22:36:48 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v7] In-Reply-To: References: Message-ID: > Further changes to the MonkeyTester application: > > - remember split pane divider ? > - use 'private' instead of 'protected' in many cases ? > - added more scripts to the 'writing systems' text sample ? > - added RTL window control menu ? > - added embedded swing/fx in tools ? > - added copy popup menu in clipboard viewer ? > - added the custom css field to the css playground tool ? > - added many new pages ? > - split XYChartPage into separate pages ? > - switched to use property sheets (some choices might be incomplete) ? > > https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md > > These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: spinner ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1406/files - new: https://git.openjdk.org/jfx/pull/1406/files/5f234e78..014e3796 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1406&range=05-06 Stats: 12 lines in 1 file changed: 5 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1406.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/jfx/pull/1406 From mhanl at openjdk.org Mon Mar 25 22:50:25 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 25 Mar 2024 22:50:25 GMT Subject: RFR: 8328718: Remove unused imports in javafx.controls In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > This is a trivial change, 1 reviewer is probably enough. Sure. I may also need a little more time, as my free time is somewhat limited. ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1416#issuecomment-2019053109 From mhanl at openjdk.org Mon Mar 25 22:52:27 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 25 Mar 2024 22:52:27 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> On Fri, 22 Mar 2024 22:29:32 GMT, Andy Goryachev wrote: >> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. >> >> The current implementation has the following shortcomings: >> - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine >> - Another consequence of this is, that the font size is always estimated with 0, as it is not detected >> - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold >> >> Some tests were failing for the following reasons: >> - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. >> - `StackedBarChartTest.java` - since we now calculate correctly, the path changed >> - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it >> - The default System font is considered a `Regular` one (style) >> >> I wrote tests and documented the stub behaviour. >> I did some minor changes here: >> - System font is now detected, also in bold and italic >> - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that >> >> Note: This only changes test setup, no 'production' code. > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 538: > >> 536: .map(lineTo -> new Point2D( >> 537: Math.ceil(xAxis.getValueForDisplay(lineTo.getX()).doubleValue()), >> 538: Math.ceil(yAxis.getValueForDisplay(lineTo.getY()).doubleValue())) > > would it make more sense to either do a Math.round(), or better yet - write a utility that computes array equality of Point2D's with some non-zero tolerance? > > Do we have more tests like this that might warrant a new utility? AFAIK, we do not have other tests with that problem. I tried to keep the diff small, but nothing against writing a better method to compare the points here with a delta. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1538332039 From mhanl at openjdk.org Mon Mar 25 22:55:27 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 25 Mar 2024 22:55:27 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Fri, 22 Mar 2024 22:37:09 GMT, Andy Goryachev wrote: >> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. >> >> The current implementation has the following shortcomings: >> - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine >> - Another consequence of this is, that the font size is always estimated with 0, as it is not detected >> - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold >> >> Some tests were failing for the following reasons: >> - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. >> - `StackedBarChartTest.java` - since we now calculate correctly, the path changed >> - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it >> - The default System font is considered a `Regular` one (style) >> >> I wrote tests and documented the stub behaviour. >> I did some minor changes here: >> - System font is now detected, also in bold and italic >> - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that >> >> Note: This only changes test setup, no 'production' code. > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java line 102: > >> 100: boolean bold = font.getStyle().toLowerCase().contains("bold"); >> 101: if (bold) { >> 102: fontSize++; > > should this only apply to width computation (line 128)? > > in other words, the height of for bold text of size 12 should have the same height as plain text size 12, shouldn't it? good question! I checked some fonts and they do look to me that they have the same height regular as well as bold. So it's probably better to use the normal size for the height here? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1538334347 From mhanl at openjdk.org Mon Mar 25 23:03:25 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 25 Mar 2024 23:03:25 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Fri, 22 Mar 2024 22:32:25 GMT, Andy Goryachev wrote: >> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. >> >> The current implementation has the following shortcomings: >> - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine >> - Another consequence of this is, that the font size is always estimated with 0, as it is not detected >> - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold >> >> Some tests were failing for the following reasons: >> - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. >> - `StackedBarChartTest.java` - since we now calculate correctly, the path changed >> - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it >> - The default System font is considered a `Regular` one (style) >> >> I wrote tests and documented the stub behaviour. >> I did some minor changes here: >> - System font is now detected, also in bold and italic >> - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that >> >> Note: This only changes test setup, no 'production' code. > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 76: > >> 74: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Regular"); >> 75: case "amble light condensed italic" -> >> 76: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Italic"); > > does it make sense to handle/log the default case, or this is indeed the desired code (i.e. a no-op)? Right now, if we try to load a font that is not known by the test setup, the font will not have a 'native font' since no branch will get executed. With that, the width calculation will return 0. Just checked the Prism font code, there the code will fallback to the system font if it can not load the specified font (family). That would also be an idea here, not sure if it will have consequences on some tests. Also okay for me. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1538339248 From mhanl at openjdk.org Mon Mar 25 23:04:25 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 25 Mar 2024 23:04:25 GMT Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if has graphic [v4] In-Reply-To: <5Hi4OhAPKSoj0yU24tddC8IOJtoefOEaqAMJiMBPIc4=.f28aa0b1-f717-4e38-a887-5bda483b9cd5@github.com> References: <5Hi4OhAPKSoj0yU24tddC8IOJtoefOEaqAMJiMBPIc4=.f28aa0b1-f717-4e38-a887-5bda483b9cd5@github.com> Message-ID: On Fri, 22 Mar 2024 22:59:34 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: >> >> - JDK-8186188: copyright >> - JDK-8186188: fix tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTreeTableTest.java line 48: > >> 46: import javafx.scene.layout.HBox; >> 47: import javafx.scene.text.Text; >> 48: import org.junit.After; > > this is a new test - should we use JUnit5? I copied the other test class, but sure, is probably better to switch this to JUnit 5 then. > modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 53: > >> 51: if (name.equals("system regular")) { >> 52: FontHelper.setNativeFont(font, nativeFont, font.getName(), "System", "Regular"); >> 53: } else if (name.equals("system bold")) { > > does this mean this PR requires #1422 to be integrated first? Yes, that would be easier for reviewing this. Once merged, I will update this branch. :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1538339702 PR Review Comment: https://git.openjdk.org/jfx/pull/1405#discussion_r1538340259 From angorya at openjdk.org Mon Mar 25 23:13:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 25 Mar 2024 23:13:25 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> Message-ID: On Mon, 25 Mar 2024 22:49:22 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 538: >> >>> 536: .map(lineTo -> new Point2D( >>> 537: Math.ceil(xAxis.getValueForDisplay(lineTo.getX()).doubleValue()), >>> 538: Math.ceil(yAxis.getValueForDisplay(lineTo.getY()).doubleValue())) >> >> would it make more sense to either do a Math.round(), or better yet - write a utility that computes array equality of Point2D's with some non-zero tolerance? >> >> Do we have more tests like this that might warrant a new utility? > > AFAIK, we do not have other tests with that problem. > I tried to keep the diff small, but nothing against writing a better method to compare the points here with a delta. I am not sure why this is needed here, so my concern stems from the fact that `ceil()` might introduce a large bias (0.000001 -> 1.0), and `rnd()` _seems_ to be a better choice. But then again, ceil() or rnd() might be a wrong thing to do if we are dealing with scaled coordinates and we don't expect the whole integers, but instead are dealing with small differences between expected and obtained values (in which case a better comparison is required). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1538353288 From jdv at openjdk.org Tue Mar 26 06:16:27 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 26 Mar 2024 06:16:27 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently In-Reply-To: <3BjQWCzigQM9uh1XGU-2ys8tM-V30Ga12q6bhuaWnrA=.50ea520e-aab8-4724-bfd7-aff76ca63432@github.com> References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> <3BjQWCzigQM9uh1XGU-2ys8tM-V30Ga12q6bhuaWnrA=.50ea520e-aab8-4724-bfd7-aff76ca63432@github.com> Message-ID: On Mon, 25 Mar 2024 14:26:10 GMT, Kevin Rushforth wrote: >> This test has failed once and we are not seeing its failure after that instance in our test systems. >> >> This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. >> Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. >> >> We are making this test robust to make sure we don't see any of these single instance failures. >> Test is updated to: >> 1) To always show on top, so that we pick proper color. >> 2) Add additional sleep so that we give more time for test to be visible. >> 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. > > tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 87: > >> 85: testScene.setFill(Color.WHITE); >> 86: testStage.setScene(testScene); >> 87: testStage.setAlwaysOnTop(true); > > This is redundant. `getStage()` already sets `alwaysOnTop`. If the window currently isn't always on top then we have a bigger problem. I see that thanks, i didn't notice it. I will remove the change. I took https://github.com/openjdk/jfx/commit/56f2e17f#diff-43fd8d27727f352ddb3526031bd32e5d30aefa2bad722d1f3d21c4a0ca8a5a1f as an example and made this change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1538643028 From jdv at openjdk.org Tue Mar 26 06:24:27 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 26 Mar 2024 06:24:27 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently In-Reply-To: References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: On Mon, 25 Mar 2024 16:40:56 GMT, Andy Goryachev wrote: >> This test has failed once and we are not seeing its failure after that instance in our test systems. >> >> This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. >> Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. >> >> We are making this test robust to make sure we don't see any of these single instance failures. >> Test is updated to: >> 1) To always show on top, so that we pick proper color. >> 2) Add additional sleep so that we give more time for test to be visible. >> 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. > > tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 102: > >> 100: horizontalListView.setVisible(true); >> 101: }); >> 102: sleep(1000); > > we still have JDK-8176902 open, but perhaps here we could add a new method to VisualTestBase similar to waitNextFrame(), with an appropriate parameter? > > Something like > > protected void waitForIdle() { > frameWait(100); > } > > > instead of 1 second sleep() ? What do you think? I think waitForIdle() would not be a proper name for this use case. And we already have waitFirstFrame() which does frameWait(100). What i will do is, use waitFirstFrame() and add comment in test case that we are waiting after setVisible(true). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1538649261 From jdv at openjdk.org Tue Mar 26 06:30:49 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 26 Mar 2024 06:30:49 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently [v2] In-Reply-To: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: > This test has failed once and we are not seeing its failure after that instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Remove setAlwaysOnTop and update wait call ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1433/files - new: https://git.openjdk.org/jfx/pull/1433/files/2c9ed7d9..c4f3b9c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1433&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1433.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1433/head:pull/1433 PR: https://git.openjdk.org/jfx/pull/1433 From hmeda at openjdk.org Tue Mar 26 07:03:27 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 26 Mar 2024 07:03:27 GMT Subject: RFR: 8328749: Remove unused imports in javafx.web [v2] In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:11:52 GMT, Andy Goryachev wrote: >> Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports. >> >> >> -- >> >> This is a trivial change, 1 reviewer is probably enough. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > removed swing file modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/com/sun/webkit/dom/DOMWindowImpl.java line 37: > 35: import org.w3c.dom.views.AbstractView; > 36: import org.w3c.dom.views.DocumentView; > 37: import com.sun.webkit.Disposer; Minor: Generally, imports are added in alphabetic order. modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/com/sun/webkit/dom/NodeImpl.java line 38: > 36: import org.w3c.dom.events.EventListener; > 37: import org.w3c.dom.events.EventTarget; > 38: import com.sun.webkit.Disposer; Minor: Generally, imports are added in alphabetic order. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1421#discussion_r1538678437 PR Review Comment: https://git.openjdk.org/jfx/pull/1421#discussion_r1538678727 From hmeda at openjdk.org Tue Mar 26 07:24:24 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 26 Mar 2024 07:24:24 GMT Subject: RFR: 8328749: Remove unused imports in javafx.web [v2] In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:11:52 GMT, Andy Goryachev wrote: >> Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports. >> >> >> -- >> >> This is a trivial change, 1 reviewer is probably enough. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > removed swing file Verified Build and unit tests. No issue seen. Added few minor comments ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1421#pullrequestreview-1959499931 From kpk at openjdk.org Tue Mar 26 10:12:28 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 26 Mar 2024 10:12:28 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v7] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:36:48 GMT, Andy Goryachev wrote: >> Further changes to the MonkeyTester application: >> >> - remember split pane divider ? >> - use 'private' instead of 'protected' in many cases ? >> - added more scripts to the 'writing systems' text sample ? >> - added RTL window control menu ? >> - added embedded swing/fx in tools ? >> - added copy popup menu in clipboard viewer ? >> - added the custom css field to the css playground tool ? >> - added many new pages ? >> - split XYChartPage into separate pages ? >> - switched to use property sheets (some choices might be incomplete) ? >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md >> >> These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > spinner I have completed sanity testing all the pages. Added a comment inline. This change has added lot of options to the MT and it will be useful in testing the controls. Since you have already created a bug for next set of changes, I think this looks good for now. tests/manual/monkey/src/com/oracle/tools/fx/monkey/settings/FxSettingsSchema.java line 280: > 278: > 279: // FIX some kind of a bug, the dividers move slightly each time > 280: sp.setDividerPositions(divs); Since we are calling this outside FX thread it won't throw exception in any scenario right? I checked and couldn't find anything. Wanted to make sure. ------------- PR Review: https://git.openjdk.org/jfx/pull/1406#pullrequestreview-1959880649 PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1538919751 From duke at openjdk.org Tue Mar 26 10:20:27 2024 From: duke at openjdk.org (eduardsdv) Date: Tue, 26 Mar 2024 10:20:27 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511 > reverted accidental indentation chang Are there any open questions or objections? Can this pull request be merged? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2020037279 From jvos at openjdk.org Tue Mar 26 10:44:28 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 26 Mar 2024 10:44:28 GMT Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels [v2] In-Reply-To: References: Message-ID: <1aW7FgUwQSHSTtITY0XOXUg6BM56iWb9WcMjDJHbzNY=.0b5a0c4e-959b-429d-913e-5b6b58ebef18@github.com> On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier wrote: >> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. >> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. >> >> With this PR, always the default cell height is used, to determine how much is scrolled. >> This makes the behavior more consistent. >> >> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. >> >> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8323511 > reverted accidental indentation chang I plan to do an in-depth review later this week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2020088693 From mailtiltssalg at gmail.com Tue Mar 26 12:57:45 2024 From: mailtiltssalg at gmail.com (Mads) Date: Tue, 26 Mar 2024 13:57:45 +0100 Subject: JavaFX TableView text in the cells of the columns seems to jump Message-ID: Please see this Stack Overflow post where I have tried my best to document what is going on: https://stackoverflow.com/questions/77369768/javafx-tableview-text-in-the-cells-of-the-columns-seems-to-jump Seems to be an issue with CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS when drawing the table for the first time and when vertical scrollbar is added? Is this how it is intended to be? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Mar 26 13:17:26 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 26 Mar 2024 13:17:26 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. I agree, I've changed the title of the PR accordingly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2020402614 From kcr at openjdk.org Tue Mar 26 14:01:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 14:01:32 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: <4N5Mee42opXd-fpE3k0neZ-QU3tRo5kYUKVFrRdHXlk=.ae30ae72-0d39-4f28-8625-cf2d0960f8c9@github.com> On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. I changed the title of the JBS issue to match. I also filed [JDK-8329098](https://bugs.openjdk.org/browse/JDK-8329098) to track adding support for "@1x" named images as a fallback. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2020505620 From andy.goryachev at oracle.com Tue Mar 26 15:31:22 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 26 Mar 2024 15:31:22 +0000 Subject: JavaFX TableView text in the cells of the columns seems to jump In-Reply-To: References: Message-ID: Hi there. Thank you for bringing this up in the mailing list (we **do not** monitor stackoverflow). Do I understand it correctly from this stackoverflow posting that the problem is a momentary adjustment of the columns when the vertical scroll bar appears? And that it works correctly otherwise? If that's the case, yes - this is the expected behavior, at least given the current design of the TableView skin. If one adds a change listener to, let's say, the last column, one will see three updates: 1. in TableColumnHeader.doColumnAutoSize() as a response to setting the scene 2. TableColumnHeader.resizeColumnToFitContent(), called by TableViewSkinBase.updateContentWidth() as a response to Scene.doLayoutPass() 3. TableView.setContentWidth() as a response to VirtualFlow.computeBarVisibility() when it decides the vertical scroll bar needs to be shown. What I can't tell is whether steps 2 and 2 can be combined - in other words, whether it is possible to know that the vertical scroll bar needs to be shown before the layout pass is done. I am sure it can be in the case of the fixed row height, but if the row heights depend on the content width the things might get complicated. If it can, we can try to investigate, though it will be a low priority enhancement (the table does work correctly save for a momentary flicker). I am going to create a JBS ticket https://bugs.openjdk.org/browse/JDK-8329104 to investigate. Cheers, -andy From: openjfx-dev on behalf of Mads Date: Tuesday, March 26, 2024 at 05:58 To: openjfx-dev at openjdk.org Subject: JavaFX TableView text in the cells of the columns seems to jump Please see this Stack Overflow post where I have tried my best to document what is going on: https://stackoverflow.com/questions/77369768/javafx-tableview-text-in-the-cells-of-the-columns-seems-to-jump Seems to be an issue with CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS when drawing the table for the first time and when vertical scrollbar is added? Is this how it is intended to be? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Mar 26 15:34:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 15:34:27 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently [v2] In-Reply-To: References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: On Tue, 26 Mar 2024 06:30:49 GMT, Jayathirth D V wrote: >> This test has failed once and we are not seeing its failure after that instance in our test systems. >> >> This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. >> Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. >> >> We are making this test robust to make sure we don't see any of these single instance failures. >> Test is updated to: >> 1) To always show on top, so that we pick proper color. >> 2) Add additional sleep so that we give more time for test to be visible. >> 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Remove setAlwaysOnTop and update wait call Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1433#pullrequestreview-1960816132 From kcr at openjdk.org Tue Mar 26 16:15:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 16:15:31 GMT Subject: RFR: 8328749: Remove unused imports in javafx.web [v2] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 07:01:02 GMT, Hima Bindu Meda wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> removed swing file > > modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/com/sun/webkit/dom/NodeImpl.java line 38: > >> 36: import org.w3c.dom.events.EventListener; >> 37: import org.w3c.dom.events.EventTarget; >> 38: import com.sun.webkit.Disposer; > > Minor: Generally, imports are added in alphabetic order. I raised this question in PR #1420 as well, but didn't follow-up on it. We should make a deliberate decision on this rather than "whatever Andy's version of Eclipse happens to think is a good default". Let's resolve the discussion in _that_ PR and then apply it to all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1421#discussion_r1539576879 From kcr at openjdk.org Tue Mar 26 16:19:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 16:19:26 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 22:35:22 GMT, Andy Goryachev wrote: >> apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java line 55: >> >>> 53: import ensemble.SampleInfo; >>> 54: import ensemble.SampleInfo.URL; >>> 55: import ensemble.generated.Samples; >> >> I see that `ensemble.xxx` is moved after `javafx.xxx`; similarly, elsewhere I see `com.sun.xxx` imports moved after. What's the algorithm your IDE uses to sort imports? sort stuff that starts with "java" first and then everything else alphabetically? > > this is how the IDE formatter is currently configured - it should not matter, especially since it dos not use wildcards (except for static imports). While it doesn't matter from a correctness point of view, if we are going to make changes like this to several files across multiple PRs, I want to make a deliberate decision rather than "whatever the Eclipse IDE happens to be configured to do by default". That way whenever new files are created or existing files are modified, we can have consistency rather than "dueling import sorting". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1539591609 From kcr at openjdk.org Tue Mar 26 16:37:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 16:37:37 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change (though fairly large), 1 reviewer is probably enough. Here is my $0.02 on the sorting of imports. I haven't cared enough before now to raise the issue, but since we are now going to be setting a precedent with these PRs, I want to codify the style guidelines. We should update the CONTRIBUTING guidelines to reflect whatever we decide. The current guidelines say this: > Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. We should replace this with the recommended sort order. As for what that order should be, I have never much liked the idea of sorting or organizing imports into multiple groups with a set of rules that you have to remember / describe / teach your IDE about. The various IDEs or code-style guidelines with such conventions are often at odds with each other. Google used to have multiple groups (with rules about sorting the groups), but finally tired of this and changed to a simpler convention of having two groups: one for static imports (if any) and one for ordinary imports: static imports (sorted alphabetically) one blank line ordinary imports (sorted alphabetically) No wildcard imports (I favor an exception for static imports). I propose that we do the same, but if someone has strong opinions otherwise, we can discuss. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2020929321 From angorya at openjdk.org Tue Mar 26 16:37:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 16:37:38 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:16:37 GMT, Kevin Rushforth wrote: >> this is how the IDE formatter is currently configured - it should not matter, especially since it dos not use wildcards (except for static imports). > > While it doesn't matter from a correctness point of view, if we are going to make changes like this to several files across multiple PRs, I want to make a deliberate decision rather than "whatever the Eclipse IDE happens to be configured to do by default". That way whenever new files are created or existing files are modified, we can have consistency rather than "dueling import sorting". It looks like Eclipse uses the following order **by default**: [java,javax,org,com]. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1420#discussion_r1539698283 From kpk at openjdk.org Tue Mar 26 16:39:41 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 26 Mar 2024 16:39:41 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:10:22 GMT, drmarmac wrote: > This PR removes potentially incorrect usages of Stream.peek(). > The changed code should be covered by the tests that are already present. modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 176: > 174: .distinct() > 175: .filter(removeRowFilter) > 176: .forEach(row -> { In the java.util.stream package [docs](https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects) it is mentioned that `forEach()` method operates only via side-effects. So do you think we should avoid using `forEach()` here and iterate the generated list separately to clear selected index? modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 185: > 183: .mapToInt(TablePositionBase::getRow) > 184: .distinct() > 185: .forEach(row -> { Similar comment as above. Here if we do not use `forEach()` on streams, we can also avoid using array of size one for keeping count as well right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1539688222 PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1539689484 From angorya at openjdk.org Tue Mar 26 16:40:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 16:40:31 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:32:41 GMT, Kevin Rushforth wrote: > We should replace this with the recommended sort order. My 2 cents would be on the other side: I would strongly recommend **against** enforcing a specific order, especially since it causes no issues. We should avoid wildcards, yes (except for static imports), but the order - we should follow the current recommendation of ignoring the order. The main reason it is adding zero value and costs some time (just like whitespace warnings in jcheck). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2020943330 From kcr at openjdk.org Tue Mar 26 16:52:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 16:52:27 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:38:07 GMT, Andy Goryachev wrote: > > We should replace this with the recommended sort order. > > My 2 cents would be on the other side: I would strongly recommend **against** enforcing a specific order, especially since it causes no issues. We should avoid wildcards, yes (except for static imports), but the order - we should follow the current recommendation of ignoring the order. The main reason it is adding zero value and costs some time (just like whitespace warnings in jcheck). I agree that we shouldn't _enforce_ the order (and didn't mean to imply otherwise). I do see some value in having a "soft" recommendation, though, and encouraging IDE users to configure their IDEs with those recommendations. Otherwise, it can be a source of merge conflicts if one IDE sorts it one way, and another IDE sorts it a different way, and two different people are proposing changes to the same file. Maybe unlikely, but it has happened. So the questions are: 1. Should we have at least a soft recommendation or leave it unspecified? 2. If the answer to 1 is "yes", what should that recommendation be? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2020970308 From angorya at openjdk.org Tue Mar 26 17:24:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 17:24:25 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:49:58 GMT, Kevin Rushforth wrote: > 1. Should we have at least a soft recommendation or leave it unspecified? I would rather leave it unspecified. My concern is that different IDEs might have different sort orders by defaul (now or in the future) and then we have a perpetual problem. (Disclosure: I don't actually know the default order in IntelliJ/Netbeans/VS). The merge conflicts in the imports are easy to resolve and are possible even when the order is the same, so it should not be a deciding factor. What do other people think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2021042761 From angorya at openjdk.org Tue Mar 26 17:35:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 17:35:37 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement Message-ID: Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to - ListView - TreeView - TableView - TreeTableView to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. As far as I can tell, these key combinations do not interfere with editing. The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like public void horizontalUnitScroll(boolean right); Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior Note: Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8313138.horizontal - leaks - option command / alt ctrl - 8313138: TreeView/ListView Horizontal Scrollbar Keyboard enhancement Changes: https://git.openjdk.org/jfx/pull/1393/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313138 Stats: 223 lines in 9 files changed: 157 ins; 39 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1393.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1393/head:pull/1393 PR: https://git.openjdk.org/jfx/pull/1393 From kcr at openjdk.org Tue Mar 26 17:47:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 17:47:26 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change (though fairly large), 1 reviewer is probably enough. The other thing that a reordering of imports does is add noise to a review, so there is some advantage in having it be at least reasonably consistent. The current advice is already "try not to reorder imports", so as long as people follow that, it might be good enough. What I don't want to see is a lot of back and forth reordering, but maybe it won't be a problem (it typically hasn't been up to now). I don't have a strong opinion on this, other than the "no wildcard imports" rule, which is separate and already documented. I do like consistency, but as long there is some reasonable ordering, I can let it go if no one else feels the need for a gudeline. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2021091226 From kcr at openjdk.org Tue Mar 26 18:01:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 18:01:26 GMT Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement In-Reply-To: References: Message-ID: <3nlIcqV_yDNvctebTweR-frpaV9hVfqoPWrvizJ5eeI=.41779615-7770-499b-9f19-ff651fe5b204@github.com> On Wed, 6 Mar 2024 19:55:54 GMT, Andy Goryachev wrote: > Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal scrolling. The main reason for the change is to improve accessibility. > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > > > Q: Does this change require a CSR to explain the change in the controls' behavior? We don't yet have the key bindings documented in /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available. Since this is a noticeable (end-user-visible) behavioral change, I think a CSR would be in order (it need not be very detailed). We don't currently document keyboard shortcuts -- either for individual controls or for focus traversal -- although that would be a good doc enhancement (for a later time). Reviewers: @arapte @azuev-java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2021131371 From angorya at openjdk.org Tue Mar 26 18:13:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 18:13:28 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v7] In-Reply-To: References: Message-ID: <3gY-_56Ldvh08aRJKRDX9a1q2OhVGfnIOacgGhBgyd0=.8e23b144-9a41-478d-a36f-478e6dfe1701@github.com> On Tue, 26 Mar 2024 09:59:24 GMT, Karthik P K wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> spinner > > tests/manual/monkey/src/com/oracle/tools/fx/monkey/settings/FxSettingsSchema.java line 280: > >> 278: >> 279: // FIX some kind of a bug, the dividers move slightly each time >> 280: sp.setDividerPositions(divs); > > Since we are calling this outside FX thread it won't throw exception in any scenario right? I checked and couldn't find anything. Wanted to make sure. No, we are not calling this from outside the FX app thread. What happens here is that the resulting dividers are slightly off if we don't follow up with `Platform.runLater()`, and I am not sure why. I suspect this is a bug in SplitPane, but I can't easily come up with a SCCE. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1406#discussion_r1539855183 From angorya at openjdk.org Tue Mar 26 18:26:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 18:26:27 GMT Subject: RFR: 8306322: JDK8130122Test fails intermittently [v2] In-Reply-To: References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: On Tue, 26 Mar 2024 06:30:49 GMT, Jayathirth D V wrote: >> This test has failed once and we are not seeing its failure after that instance in our test systems. >> >> This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. >> Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. >> >> We are making this test robust to make sure we don't see any of these single instance failures. >> Test is updated to: >> 1) To always show on top, so that we pick proper color. >> 2) Add additional sleep so that we give more time for test to be visible. >> 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Remove setAlwaysOnTop and update wait call anyway, even if we decide to add another method that will be a separate PR. tests/system/src/test/java/test/robot/scenegraph/JDK8130122Test.java line 102: > 100: }); > 101: // Give more time after setVisible(true) is called for frame update > 102: waitFirstFrame(); this is fine, though I'd rather have a dedicated method - waitFirstFrame() implies that it should only be used to wait for the first frame, that it might have a different purpose and implementation. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1433#pullrequestreview-1961362059 PR Review Comment: https://git.openjdk.org/jfx/pull/1433#discussion_r1539870662 From kcr at openjdk.org Tue Mar 26 18:28:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 18:28:28 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 20:21:30 GMT, Andy Goryachev wrote: > ## ManualTestWindow > > This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons. > > A simple test would look like this: > > > public class SampleManualTest { > public static void main(String[] args) throws Exception { > ManualTestWindow.builder(). > title("Sample Manual Test"). > instructions( > """ > Provide > multi-line instructions here. > """ > ). > ui(() -> createTestUI()). > buildAndRun(); > } > > private static Node createTestUI() { > return new Label("Test UI"); > } > } > > > Resulting application window: > > ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7) > > Readme: > > https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md > > @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project and moved sources to src/, still using the default package). > > Q: Do we want to avoid using the default package? > > Q: What other features can be added to the test window? Not a review, but just a general comment or two. > EmojiTest has been converted to use the new test window as a demonstration That seems reasonable, but... > (also fixed the Eclipse project and moved sources to src/, still using the default package). I'm not sure how much value there is in moving the files under a "src" directory without also providing a build script (ant or gradle) to be able to build it. We don't currently have the manual tests wired up to the build, so there is no good way to depend on anything outside of the directory in question (at least not without using an IDE, which is a developer convenience, not a build system). That should probably be solved first. > Q: Do we want to avoid using the default package? For all manual tests? Probably not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2021181296 From angorya at openjdk.org Tue Mar 26 18:32:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 18:32:28 GMT Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for manual tests In-Reply-To: References: Message-ID: <1V2qszXSbNtLdry-RSxd7vgy7gIVq1Md_C-8P5wE2Qw=.d76eb778-b2e6-4baa-a28d-2de90b08c2f8@github.com> On Tue, 26 Mar 2024 18:26:00 GMT, Kevin Rushforth wrote: > I'm not sure how much value there is in moving the files under a "src" directory Thank you Kevin for the feedback! I had problems configuring the project with sources being in the root, but will take another look. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2021188076 From kcr at openjdk.org Tue Mar 26 18:32:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 18:32:26 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 21:58:37 GMT, Michael Strau? wrote: >> Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. >> >> The workaround is to set the system property "apple.awt.application.appearance=system". >> >> If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: >> >> >> WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem >> property apple.awt.application.appearance=system is set. This warning can be disabled by >> setting javafx.preferences.suppressAppleAwtWarning=true. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Break warning message into separate lines Pending a second reviewer. @beldenfox or @prsadhuk Would one of you be able to review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-2021187420 From kcr at openjdk.org Tue Mar 26 18:33:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 18:33:23 GMT Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when destination is external In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 22:35:49 GMT, Martin Fox wrote: > At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event. > > At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations. Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1371#issuecomment-2021188678 From kcr at openjdk.org Tue Mar 26 18:50:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 18:50:26 GMT Subject: RFR: 8307980: Rotate Transformation never invalidates inverseCache [v2] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 11:47:10 GMT, Lukasz Kostyra wrote: >> Fixed as described in the issue + added tests to check for this scenario with all Transform sub classes. Since the test scenario slightly exceeding the regular parametrized testing of `TransformOperationsTest` I decided to implement the tests in a separate class. >> >> I didn't manage to reproduce the issue with other Transform sub classes, so it seems to only affect `Rotate`. Also checked by looking at the code, only `Rotate` was affected by this bug. As such, without 08ba284 only `testTransformInverseCache_Rotate` fails, while others succeed. With the fix, all tests pass. >> >> Ran the whole test suite afterwards and didn't notice any changes to test results after introducing the fix. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary imports from test Looks good. I confirm that the new test fails without the fix and passes with the fix. modules/javafx.graphics/src/test/java/test/javafx/scene/transform/TransformValidCacheAfterInverseTest.java line 116: > 114: checkTransform(translate); > 115: } > 116: } Minor: add (single) missing newline at the end of this file. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1392#pullrequestreview-1961384005 PR Review Comment: https://git.openjdk.org/jfx/pull/1392#discussion_r1539889095 From mailtiltssalg at gmail.com Tue Mar 26 19:38:53 2024 From: mailtiltssalg at gmail.com (Mads) Date: Tue, 26 Mar 2024 20:38:53 +0100 Subject: JavaFX TableView text in the cells of the columns seems to jump In-Reply-To: References: Message-ID: Hi Andy Thank you for your respond and the explanation for the observed behavior. "Do I understand it correctly from this stackoverflow posting that the problem is a momentary adjustment of the columns when the vertical scroll bar appears? And that it works correctly otherwise? Yes, it works correctly otherwise. I would love if you can implement that the vertical scroll bar can to be shown before the layout pass is done. I think it would look a little bit more pro without the movements on first load. Kind Regards Mads Den tirs. 26. mar. 2024 kl. 16.31 skrev Andy Goryachev < andy.goryachev at oracle.com>: > Hi there. > > > > Thank you for bringing this up in the mailing list (we ***do not*** > monitor stackoverflow). > > > > Do I understand it correctly from this stackoverflow posting that the > problem is a momentary adjustment of the columns when the vertical scroll > bar appears? And that it works correctly otherwise? > > > > If that's the case, yes - this is the expected behavior, at least given > the current design of the TableView skin. If one adds a change listener > to, let's say, the last column, one will see three updates: > > > > 1. in TableColumnHeader.doColumnAutoSize() as a response to setting > the scene > 2. TableColumnHeader.resizeColumnToFitContent(), called by > TableViewSkinBase.updateContentWidth() as a response to Scene.doLayoutPass() > 3. TableView.setContentWidth() as a response to > VirtualFlow.computeBarVisibility() when it decides the vertical scroll bar > needs to be shown. > > > > What I can't tell is whether steps 2 and 2 can be combined - in other > words, whether it is possible to know that the vertical scroll bar needs to > be shown before the layout pass is done. I am sure it can be in the case > of the fixed row height, but if the row heights depend on the content width > the things might get complicated. > > > > If it can, we can try to investigate, though it will be a low priority > enhancement (the table does work correctly save for a momentary flicker). > I am going to create a JBS ticket > https://bugs.openjdk.org/browse/JDK-8329104 to investigate. > > > > Cheers, > > -andy > > > > > > > > > > > > > > *From: *openjfx-dev on behalf of Mads < > mailtiltssalg at gmail.com> > *Date: *Tuesday, March 26, 2024 at 05:58 > *To: *openjfx-dev at openjdk.org > *Subject: *JavaFX TableView text in the cells of the columns seems to jump > > Please see this Stack Overflow post where I have tried my best to document > what is going on: > > > https://stackoverflow.com/questions/77369768/javafx-tableview-text-in-the-cells-of-the-columns-seems-to-jump > > Seems to be an issue with CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS when > drawing the table for the first time and when vertical scrollbar is added? > > Is this how it is intended to be? > > Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Mar 26 19:49:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 19:49:24 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. The code changes and test changes look good to me. @drmarmac Please enable running GitHub Actions in your personal fork of the jfx repo, and trigger a test run so we can see the results (the bot will make them available in this PR once it runs to completion). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2021332454 From kcr at openjdk.org Tue Mar 26 19:52:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 19:52:26 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java line 78: > 76: }; > 77: for (String[] names : imageNames) { > 78: String name2x = ImageTools.getScaledImageName(names[0], scale); Minor: maybe rename this variable to `nameScaled` or similar (since it isn't always 2x any more)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1429#discussion_r1540003814 From angorya at openjdk.org Tue Mar 26 20:27:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:27:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. I am a bit uneasy with the proposed solution. Let me explain: The first thing that seems weird to me is the mere existence of increment(int)/decrement(int). Well, it is an existing API, and probably there are some use cases that I cannot immediately see. The real issue is when we have wrapAround enabled and either a large amountToStepBy or the argument for increase/decrease exceeding the (max - min) value. This simply makes no sense, and the modulo arithmetic produces, in my opinion, an unexpected user experience. What I mean is that some combinations of Spinner settings would result in apparently "random" jumps (from the user perspective). What I think should be done is - when this scenario is detected - the adjustment should default to maybe 1 (or (max - min)/10 in the case of the DoubleSpinnerValueFactory). The goal is to fall back gracefully to something a human can understand - and a modulo division is not one of those. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021398115 From mhanl at openjdk.org Tue Mar 26 20:27:27 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 26 Mar 2024 20:27:27 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> Message-ID: On Mon, 25 Mar 2024 23:11:12 GMT, Andy Goryachev wrote: >> AFAIK, we do not have other tests with that problem. >> I tried to keep the diff small, but nothing against writing a better method to compare the points here with a delta. > > I am not sure why this is needed here, so my concern stems from the fact that `ceil()` might introduce a large bias (0.000001 -> 1.0), and `rnd()` _seems_ to be a better choice. > > But then again, ceil() or rnd() might be a wrong thing to do if we are dealing with scaled coordinates and we don't expect the whole integers, but instead are dealing with small differences between expected and obtained values (in which case a better comparison is required). I can also use `round` here. Seems to be a bit safer, I agree. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1540048636 From angorya at openjdk.org Tue Mar 26 20:35:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:35:25 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. There is one more unexpected behavior - I am going to mention it here, but it might need to be extracted into its own ticket (if people agree it's a bug): Consider a Spinner with a ListSpinnerValueFactory, initialized with a list of values let's say [ "one", "two", "three", "four" ]. Let's start with "one" as a selected value, and press the Down Arrow button. Since it is based on a list, and majority of human writing systems start at the top and go down (unless we are in Australia), I would expect "two" to appear. But no, we see "four", wait, why? Yes, it might operate with an integer index and treat down arrow button as decrementing that index, but it is so wrong [citation needed]. I would expect that in a list spinner, clicking the down arrow button should navigate to the next item *in the list* ("as written") instead of going "up" the list. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021415528 From angorya at openjdk.org Tue Mar 26 20:38:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:38:26 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> Message-ID: On Tue, 26 Mar 2024 20:25:07 GMT, Marius Hanl wrote: >> I am not sure why this is needed here, so my concern stems from the fact that `ceil()` might introduce a large bias (0.000001 -> 1.0), and `rnd()` _seems_ to be a better choice. >> >> But then again, ceil() or rnd() might be a wrong thing to do if we are dealing with scaled coordinates and we don't expect the whole integers, but instead are dealing with small differences between expected and obtained values (in which case a better comparison is required). > > I can also use `round` here. Seems to be a bit safer, I agree. thank you. one more question - is it possible to set fractional scale with the StubToolkit, and how would that work in the StubFontLoader? Does it mean we'll be rounding the scaled values? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1540073971 From angorya at openjdk.org Tue Mar 26 20:42:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:42:26 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Thu, 21 Mar 2024 22:06:42 GMT, Marius Hanl wrote: > In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. > > The current implementation has the following shortcomings: > - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine > - Another consequence of this is, that the font size is always estimated with 0, as it is not detected > - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold > > Some tests were failing for the following reasons: > - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. > - `StackedBarChartTest.java` - since we now calculate correctly, the path changed > - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it > - The default System font is considered a `Regular` one (style) > > I wrote tests and documented the stub behaviour. > I did some minor changes here: > - System font is now detected, also in bold and italic > - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that > > Note: This only changes test setup, no 'production' code. One more question, for my education, since you are now the expert :-) I am trying to decide whether I should write a headful test for Labeled.truncated, or a headless one will suffice. If I write a test that uses the StubToolkit, one that requires some kind of font metrics - would that work? Will I get some kind of semi-valid values for preferred width of a text (Text, Labeled, etc.), or I cannot really rely on the correctness of the StubTextLayout? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1422#issuecomment-2021428506 From mhanl at openjdk.org Tue Mar 26 20:47:37 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 26 Mar 2024 20:47:37 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support [v2] In-Reply-To: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: > In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. > > The current implementation has the following shortcomings: > - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine > - Another consequence of this is, that the font size is always estimated with 0, as it is not detected > - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold > > Some tests were failing for the following reasons: > - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added ceiling to the data. > - `StackedBarChartTest.java` - since we now calculate correctly, the path changed > - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it > - The default System font is considered a `Regular` one (style) > > I wrote tests and documented the stub behaviour. > I did some minor changes here: > - System font is now detected, also in bold and italic > - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that > > Note: This only changes test setup, no 'production' code. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: improve (stub) font tests, fallback and documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1422/files - new: https://git.openjdk.org/jfx/pull/1422/files/ec1b2abe..f8909afc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1422&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1422&range=00-01 Stats: 98 lines in 4 files changed: 36 ins; 8 del; 54 mod Patch: https://git.openjdk.org/jfx/pull/1422.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1422/head:pull/1422 PR: https://git.openjdk.org/jfx/pull/1422 From mhanl at openjdk.org Tue Mar 26 20:52:25 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 26 Mar 2024 20:52:25 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Tue, 26 Mar 2024 20:40:11 GMT, Andy Goryachev wrote: > If I write a test that uses the StubToolkit, one that requires some kind of font metrics - would that work? Will I get some kind of semi-valid values for preferred width of a text (Text, Labeled, etc.), or I cannot really rely on the correctness of the StubTextLayout? Yes, it should! Especially with the hopefully more clear rules here. I added more javadoc in my last commit and used the System font as fallback since this is more aligned with what JavaFX is doing. Local tests seems fine, but we will see here. You could for example put a `Label` inside a container with the (max) width of 100px. With a normal font (size=12), 8 characters should be good (8x12=96), while 9 characters should make the `Label` truncated since we exceed the 100 pixels then. This is close to what JavaFX is doing, while you can still write a Headless tests about the basic rules of the truncated property. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1422#issuecomment-2021445366 From mhanl at openjdk.org Tue Mar 26 20:52:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 26 Mar 2024 20:52:26 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support [v2] In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Mon, 25 Mar 2024 23:00:25 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java line 76: >> >>> 74: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Regular"); >>> 75: case "amble light condensed italic" -> >>> 76: FontHelper.setNativeFont(font, nativeFont, font.getName(), "Amble LtCn", "Italic"); >> >> does it make sense to handle/log the default case, or this is indeed the desired code (i.e. a no-op)? > > Right now, if we try to load a font that is not known by the test setup, the font will not have a 'native font' since no branch will get executed. With that, the width calculation will return 0. > > Just checked the Prism font code, there the code will fallback to the system font if it can not load the specified font (family). > That would also be an idea here, not sure if it will have consequences on some tests. Also okay for me. What do you think? I gave the fallback font a shot, since this is closer to the `PrismFontLoader`, which is good when we try to be as close a possible in the tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1540093962 From angorya at openjdk.org Tue Mar 26 20:55:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:55:27 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support [v2] In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Tue, 26 Mar 2024 20:47:37 GMT, Marius Hanl wrote: >> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of the stub font implementation. As I don't want to clutter the PR with that, I decided to cherrypick the improvements I did to a new ticket and PR. >> >> The current implementation has the following shortcomings: >> - It does not reliable detect the System Font, as a consequence, tests in TableColumnHeaderTest.java are failing on my local machine >> - Another consequence of this is, that the font size is always estimated with 0, as it is not detected >> - One shortcoming currently is, that the stub font siie estimate is not considering bold fonts. That would improve writing tests for some scenarios, e.g. for TableColumnHeader, where we would expect that the size of the header is bigger since it is bold >> >> Some tests were failing for the following reasons: >> - `AreaChartTest.java` - `expected -30.0, was -30.00000000004` - I added rounding to the data. >> - `StackedBarChartTest.java` - since we now calculate correctly, the path changed >> - A test tried to load `Helvetica`, which is not supported in the stub font loader. I changed it >> - The default System font is considered a `Regular` one (style) - just like in JavaFX >> >> I wrote tests and documented the stub behaviour. >> I did some minor changes here: >> - System font is now detected, also in bold and italic >> - A bold font will be calculated with a little bit more width (1px). Checkout the test as well for that >> >> Note: This only changes test setup, no 'production' code. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > improve (stub) font tests, fallback and documentation modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java line 40: > 38: *
> 39: * Can calculate the bounds of text by simply using the size of the font. > 40: * If the text is bold, the font will be 1 pixel bigger. maybe change to "somewhat wider" instead, since the height is the same? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1540098655 From angorya at openjdk.org Tue Mar 26 20:58:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 20:58:30 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> Message-ID: On Tue, 26 Mar 2024 20:49:00 GMT, Marius Hanl wrote: > Yes, it should! Thank you so much for the code and explanations! I'll try to do a formal review tomorrow, using Labeled.truncated as a test bed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1422#issuecomment-2021457118 From kcr at openjdk.org Tue Mar 26 21:22:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 21:22:24 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 20:25:19 GMT, Andy Goryachev wrote: > The real issue is when we have wrapAround enabled and either a large amountToStepBy or the argument for increase/decrease exceeding the (max - min) value. This simply makes no sense, and the modulo arithmetic produces, in my opinion, an unexpected user experience. What I mean is that some combinations of Spinner settings would result in apparently "random" jumps (from the user perspective). Why? This is entirely under app control. Is it useful to pass an increment that will produce a step larger than the range? Maybe not, but restricting it doesn't see like the right solution, at least not without a good reason to do so. The "obvious" thing is to do modulo arithmetic, which is what this PR aims to do. By "obvious" thing to do, it is the mathematically correct thing to do. It makes a single step of 10 equivalent to 10 steps of 1 regardless of the min / max. > What I think should be done is - when this scenario is detected - the adjustment should default to maybe 1 (or (max - min)/10 in the case of the DoubleSpinnerValueFactory). The goal is to fall back gracefully to something a human can understand - and a modulo division is not one of those. And I would argue that either of those choices is more arbitrary and confusing than the proposed solution, and not appreciably better than what is done today. I see two sensible solutions: 1. Use modulo arithmetic to compute the value (what this PR proposed) 2. Don't process the increment at all (i.e., treat it as an out-of-range request and do nothing) Choice 1 seems best unless there is a down-side that I haven't considered. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021492726 From kcr at openjdk.org Tue Mar 26 21:27:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 21:27:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. > There is one more unexpected behavior - I am going to mention it here, but it might need to be extracted into its own ticket (if people agree it's a bug): > > Consider a Spinner with a ListSpinnerValueFactory, initialized with a list of values let's say [ "one", "two", "three", "four" ]. Let's start with "one" as a selected value, and press the Down Arrow button. Since it is based on a list, and majority of human writing systems start at the top and go down (unless we are in Australia), I would expect "two" to appear. But no, we see "four", wait, why? Yes, it might operate with an integer index and treat down arrow button as decrementing that index, but it is so wrong [citation needed]. I would expect that in a list spinner, clicking the down arrow button should navigate to the next item _in the list_ ("as written") instead of going "up" the list. This is definitely unrelated to this bug, so should be discussed separately. I can see your point, but this would be more than just a bug fix -- it would be a behavioral change that we would need to carefully consider. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021500457 From duke at openjdk.org Tue Mar 26 21:27:49 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 26 Mar 2024 21:27:49 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention [v2] In-Reply-To: References: Message-ID: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. drmarmac has updated the pull request incrementally with one additional commit since the last revision: Change name2x to nameScaled ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1429/files - new: https://git.openjdk.org/jfx/pull/1429/files/4c2b03e0..536143fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1429&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1429&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1429.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1429/head:pull/1429 PR: https://git.openjdk.org/jfx/pull/1429 From duke at openjdk.org Tue Mar 26 21:27:49 2024 From: duke at openjdk.org (drmarmac) Date: Tue, 26 Mar 2024 21:27:49 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: <5eek-LLmAT6F3cmueVzX1Uy3QPcENX8BKxKWBW6SGkw=.ad6e3357-c2f0-4ee0-8759-38feb400d6ea@github.com> On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. done, a GitHub Actions run seems to have started as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1429#issuecomment-2021499637 From angorya at openjdk.org Tue Mar 26 21:34:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 26 Mar 2024 21:34:24 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: <9fSkEU1XlCrF6-lTcvDhRnzBVtqQHylyuLB3eZJuPcQ=.51c1356a-940a-4a52-a26b-fa88f556c71c@github.com> On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. > * Use modulo arithmetic to compute the value (what this PR proposed) > * Don't process the increment at all (i.e., treat it as an out-of-range request and do nothing) 3. fall back to amountToStepBy=1 try this: integer spinner, min=0. max=100, step=137. initial value 50 there is the sequence when repeatedly pressing arrow down button: 14, 79, 43, 7, 72, 36, 0, ... makes no sense. falling back to step=1: 49, 48, 47, 46, ... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021511249 From kcr at openjdk.org Tue Mar 26 22:16:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 22:16:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: <9fSkEU1XlCrF6-lTcvDhRnzBVtqQHylyuLB3eZJuPcQ=.51c1356a-940a-4a52-a26b-fa88f556c71c@github.com> References: <9fSkEU1XlCrF6-lTcvDhRnzBVtqQHylyuLB3eZJuPcQ=.51c1356a-940a-4a52-a26b-fa88f556c71c@github.com> Message-ID: On Tue, 26 Mar 2024 21:32:16 GMT, Andy Goryachev wrote: > > * Use modulo arithmetic to compute the value (what this PR proposed) > > * Don't process the increment at all (i.e., treat it as an out-of-range request and do nothing) > > 3. fall back to amountToStepBy=1 > > try this: integer spinner, min=0. max=100, step=137. initial value 50 there is the sequence when repeatedly pressing arrow down button: 14, 79, 43, 7, 72, 36, 0, ... > > makes no sense. But if that's what the app says to do, and given that it's a well-defined operation (albeit not very useful in this example), there should be a good reason to ignore it. I'm not convinced that there is, but if there is, option 3 isn't it. > falling back to step=1: > > 49, 48, 47, 46, ... That's at least as arbitrary as clamping to the max value (the status quo). Clamping the result to the max says, in effect, "let's ignore the `wrap` flag" when we conclude that wrapping beyond a certain limit doesn't make sense. Setting the increment to 1 says, in effect, "let's ignore the `step` value" when we conclude that wrapping beyond a certain limit doesn't make sense. If we really are determined to not honor the step value / wrap flag when we conclude that wrapping beyond a certain limit doesn't make sense, then we should treat it as an app error and do nothing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2021560800 From kcr at openjdk.org Tue Mar 26 22:37:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 26 Mar 2024 22:37:26 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention [v2] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 21:27:49 GMT, drmarmac wrote: >> This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. >> Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. >> >> I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > Change name2x to nameScaled The fix looks good to me. I confirm that the updated test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1429#pullrequestreview-1961877522 From kpk at openjdk.org Wed Mar 27 05:04:27 2024 From: kpk at openjdk.org (Karthik P K) Date: Wed, 27 Mar 2024 05:04:27 GMT Subject: RFR: 8316372: Monkey Tester Application Part 3 [v7] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:36:48 GMT, Andy Goryachev wrote: >> Further changes to the MonkeyTester application: >> >> - remember split pane divider ? >> - use 'private' instead of 'protected' in many cases ? >> - added more scripts to the 'writing systems' text sample ? >> - added RTL window control menu ? >> - added embedded swing/fx in tools ? >> - added copy popup menu in clipboard viewer ? >> - added the custom css field to the css playground tool ? >> - added many new pages ? >> - split XYChartPage into separate pages ? >> - switched to use property sheets (some choices might be incomplete) ? >> >> https://github.com/andy-goryachev-oracle/jfx/blob/8316372.monkey/tests/manual/monkey/README.md >> >> These are all the changes I could make in this test sprint, other improvements will go to the follow-up ticket https://bugs.openjdk.org/browse/JDK-8328828 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > spinner Marked as reviewed by kpk (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1406#pullrequestreview-1962296060 From mhanl at openjdk.org Wed Mar 27 07:12:33 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 27 Mar 2024 07:12:33 GMT Subject: RFR: JDK-8328750: [TestBug] Improve Stub Font Support [v2] In-Reply-To: References: <13rBndR0C-KY4qUKFHsaMKz2Z8nElLqRLO_OJBhhbQU=.e0d94cd5-ced7-4ecb-b27e-6fa74a0adc3d@github.com> <8eVfZ2TCzGa39aZL6RSVX3tnFbCp24RgjotlOd5SFQU=.b693f167-5498-45a6-9637-1b2774558e4a@github.com> Message-ID: <53QFNpZ2vIWU3jTZuoONb7yalT-2qvJZ5fmaA36pOc4=.cf0293dd-0fc2-49b4-a25b-c67a4247c3cb@github.com> On Tue, 26 Mar 2024 20:36:02 GMT, Andy Goryachev wrote: >> I can also use `round` here. Seems to be a bit safer, I agree. > > thank you. > > one more question - is it possible to set fractional scale with the StubToolkit, and how would that work in the StubFontLoader? Does it mean we'll be rounding the scaled values? You mean for the font size? That will as far as I can see just work, although not 100% sure what the rendering, e.g. a Label will do with it ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1422#discussion_r1540576884 From mhanl at openjdk.org Wed Mar 27 07:23:24 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 27 Mar 2024 07:23:24 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:32:41 GMT, Kevin Rushforth wrote: > static imports (sorted alphabetically) > one blank line > ordinary imports (sorted alphabetically) > > No wildcard imports (I favor an exception for static imports). +1 for something like this. It is a simple rule and pretty sure that it works for all IDEs. Swing is also ordered alphabetically, but with groups usually. Otherwise it looks the order in Swing is the other way around: ordinary imports (sorted alphabetically) one blank line static imports (sorted alphabetically) For me, both are good and I understand and agree to have some king of guideline. That will make reviewing all the import PRs easier as well. Also +1 for no wildcard imports other than static imports. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2022108806 From duke at openjdk.org Wed Mar 27 09:11:56 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 09:11:56 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed [v2] In-Reply-To: References: Message-ID: > This PR removes potentially incorrect usages of Stream.peek(). > The changed code should be covered by the tests that are already present. drmarmac has updated the pull request incrementally with one additional commit since the last revision: Remove outdated comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1430/files - new: https://git.openjdk.org/jfx/pull/1430/files/676ec3cf..1b285b5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1430&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1430&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1430.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1430/head:pull/1430 PR: https://git.openjdk.org/jfx/pull/1430 From duke at openjdk.org Wed Mar 27 09:11:56 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 09:11:56 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:10:22 GMT, drmarmac wrote: > This PR removes potentially incorrect usages of Stream.peek(). > The changed code should be covered by the tests that are already present. I also removed a code comment that explained the usage of peek() here, which would be outdated now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1430#issuecomment-2022265808 From duke at openjdk.org Wed Mar 27 09:11:56 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 09:11:56 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed [v2] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 16:32:53 GMT, Karthik P K wrote: >> drmarmac has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove outdated comment > > modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 176: > >> 174: .distinct() >> 175: .filter(removeRowFilter) >> 176: .forEach(row -> { > > In the java.util.stream package [docs](https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects) it is mentioned that `forEach()` method operates only via side-effects. So do you think we should avoid using `forEach()` here and iterate the generated list separately to clear selected index? I'd say .forEach() is used correctly here, according to docs, it guarantees execution of the side-effects (add to removed list & clear index), just not in any particular order. This way we avoid multiple iteration. > modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 185: > >> 183: .mapToInt(TablePositionBase::getRow) >> 184: .distinct() >> 185: .forEach(row -> { > > Similar comment as above. Here if we do not use `forEach()` on streams, we can also avoid using array of size one for keeping count as well right? We'd need to iterate twice as well (select index & count), with forEach it's just once. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1540712652 PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1540712756 From duke at openjdk.org Wed Mar 27 09:29:25 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 09:29:25 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. I don't see that much value in any threshold like `step >= max-min`, no matter what the behavior beyond this threshold would be. It would be almost as weird already for less extreme cases: Take `min=0, max=100, step=99, initial=50`, leading to `50-49-48..`, which even appears to move backwards. Not sure if we can come up with any adjustments that cover all cases nicely - as an app developer I'd prefer either good logic that always works well, or simple logic that is easy to override (which it would be here). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2022298388 From mstrauss at openjdk.org Wed Mar 27 10:54:27 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 27 Mar 2024 10:54:27 GMT Subject: RFR: 8267565: Support "@3x" and greater high-density image naming convention [v2] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 21:27:49 GMT, drmarmac wrote: >> This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. >> Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. >> >> I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > Change name2x to nameScaled Looks good to me. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1429#pullrequestreview-1962957040 From fastegal at openjdk.org Wed Mar 27 11:12:28 2024 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 27 Mar 2024 11:12:28 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. afair, we already had extensive discussions in https://github.com/openjdk/jfx/pull/174 (and the related bug and the mailing list - too lazy to read up on all that) agreeing that modulo math (correctly done!) fits common client programmers' expectations most - doesn't matter the step size. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2022504622 From duke at openjdk.org Wed Mar 27 11:14:26 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 11:14:26 GMT Subject: Integrated: 8267565: Support "@3x" and greater high-density image naming convention In-Reply-To: References: Message-ID: On Fri, 22 Mar 2024 16:17:29 GMT, drmarmac wrote: > This PR extends the range of hi-res images that are loaded via naming convention, now including scale factors higher than `@2x`. > Supporting these is already being [recommended](https://developer.apple.com/design/human-interface-guidelines/images#Best-practices) for some platforms. > > I tested this manually on Windows with "300%" UI scale factor, and verified `@2x` still works on macOS. This pull request has now been integrated. Changeset: 5d886f82 Author: drmarmac <6900949+drmarmac at users.noreply.github.com> Committer: Michael Strau? URL: https://git.openjdk.org/jfx/commit/5d886f82260ee508c0da2dfee5d3ace1a199a675 Stats: 50 lines in 5 files changed: 19 ins; 0 del; 31 mod 8267565: Support "@3x" and greater high-density image naming convention Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1429 From mhanl at openjdk.org Wed Mar 27 12:26:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 27 Mar 2024 12:26:26 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed [v2] In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 09:07:15 GMT, drmarmac wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 176: >> >>> 174: .distinct() >>> 175: .filter(removeRowFilter) >>> 176: .forEach(row -> { >> >> In the java.util.stream package [docs](https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects) it is mentioned that `forEach()` method operates only via side-effects. So do you think we should avoid using `forEach()` here and iterate the generated list separately to clear selected index? > > I'd say .forEach() is used correctly here, according to docs, it guarantees execution of the side-effects (add to removed list & clear index), just not in any particular order. This way we avoid multiple iteration. Another idea is to use `toList()`, which is a very efficient operation and then iterate over it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1541003650 From jdv at openjdk.org Wed Mar 27 12:41:27 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 27 Mar 2024 12:41:27 GMT Subject: Integrated: 8306322: JDK8130122Test fails intermittently In-Reply-To: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> References: <-0IIv4zEdVEX0teHrzfj3e28wAB__lVX0HTaZxDOT1Q=.d6ba175e-62be-4819-b744-84b2303bcd2f@github.com> Message-ID: On Mon, 25 Mar 2024 12:25:33 GMT, Jayathirth D V wrote: > This test has failed once and we are not seeing its failure after that instance in our test systems. > > This test verifies whether bounds of GridPane gets updated properly on adding an invisible node. > Initial test has 8 nodes in GridPane and then we update it with another node with larger bounds without making it visible. After adding additional node we make the scenegraph visible and check for colors of the newly added node. > > We are making this test robust to make sure we don't see any of these single instance failures. > Test is updated to: > 1) To always show on top, so that we pick proper color. > 2) Add additional sleep so that we give more time for test to be visible. > 3) Pick color exactly at mid point in y axis, so that we pick the green color properly. This pull request has now been integrated. Changeset: 0541f371 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0541f37179ff4a672a40f3c4976e6019b8ecf7c2 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8306322: JDK8130122Test fails intermittently Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1433 From kcr at openjdk.org Wed Mar 27 12:57:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 27 Mar 2024 12:57:25 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. Let's proceed with the current plan of correctly-implemented modulo arithmetic. I can't think of a compelling reason to do otherwise. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2022700341 From nlisker at openjdk.org Wed Mar 27 13:44:27 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 13:44:27 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed [v2] In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 12:23:47 GMT, Marius Hanl wrote: >> I'd say .forEach() is used correctly here, according to docs, it guarantees execution of the side-effects (add to removed list & clear index), just not in any particular order. This way we avoid multiple iteration. > > Another idea is to use `toList()`, which is a very efficient operation and then iterate over it. > In the java.util.stream package [docs](https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects) it is mentioned that `forEach()` method operates only via side-effects. So do you think we should avoid using `forEach()` here and iterate the generated list separately to clear selected index? `forEach` is used correctly here. From the docs: > With the exception of terminal operations [forEach](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Stream.html#forEach(java.util.function.Consumer)) and [forEachOrdered](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Stream.html#forEachOrdered(java.util.function.Consumer)), side-effects of behavioral parameters may not always be executed when the stream implementation can optimize away the execution of behavioral parameters without affecting the result of the computation. > Another idea is to use `toList()`, which is a very efficient operation and then iterate over it. That's still 2 iterations. If the code is not performance-critical it doesn't matter. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1541140317 From nlisker at openjdk.org Wed Mar 27 13:54:26 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 13:54:26 GMT Subject: RFR: 8273349: Check uses of Stream::peek in controls and replace as needed [v2] In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 09:11:56 GMT, drmarmac wrote: >> This PR removes potentially incorrect usages of Stream.peek(). >> The changed code should be covered by the tests that are already present. > > drmarmac has updated the pull request incrementally with one additional commit since the last revision: > > Remove outdated comment modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 773: > 771: .collect(Collectors.toList()); > 772: > 773: sortedNewIndices.forEach(this::set); Why do the double-iteration pattern here and not do the `peek` operation in a `forEach` like in the other 2 places? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1430#discussion_r1541157874 From nlisker at openjdk.org Wed Mar 27 14:06:27 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 14:06:27 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: <2uk90mQRXoI5MLNtvdAnGZuKaWlQMmf0kteySL2mHvA=.b39f887b-9c71-47af-9452-739c5332c4d6@github.com> On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change (though fairly large), 1 reviewer is probably enough. I find it helpful to separate the imports by their high-level domain name, "java.", "javafx.", "com." etc. It makes it easier to see the "span" or requirements of the class. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2022856424 From angorya at openjdk.org Wed Mar 27 14:54:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 14:54:27 GMT Subject: RFR: 8328746: Remove unused imports in demo apps In-Reply-To: References: Message-ID: On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev wrote: > Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports. > > > -- > > This is a trivial change (though fairly large), 1 reviewer is probably enough. I would highly suggest to use the current guidelines in CONTRIBUTING.md * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so. as not doing so generates unnecessary (in my opinion) discussion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2022971911 From angorya at openjdk.org Wed Mar 27 15:20:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 15:20:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. If everyone is ok with modulo arithmetic. Please clarify the expected behavior in the case of an integer spinner with {min=0; max=100; amountToStepBy=101} and initial value of 0. What should the increment action result in? (0 + 101) % (100 - 0) + 0 = 1 the code in this PR produces no movement (0). Same for the decrement. Is this correct? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023034904 From fastegal at openjdk.org Wed Mar 27 16:33:28 2024 From: fastegal at openjdk.org (Jeanette Winzenburg) Date: Wed, 27 Mar 2024 16:33:28 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: <9amMEO7EzQn-K5hUUXmUDavNsSUPwnfujwXAJqCGKNQ=.9a62de61-ecf1-4a5d-bd83-760a95a72ccb@github.com> On Wed, 27 Mar 2024 15:17:29 GMT, Andy Goryachev wrote: > (0 + 101) % (100 - 0) + 0 = 1 > > the code in this PR produces no movement (0). Same for the decrement. > which means that the modulo arithmetic is not yet quite correct (_not_ that the modulo behavior as such is wrong ;) nice test case, btw ;) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023222179 From mfox at openjdk.org Wed Mar 27 16:42:29 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 27 Mar 2024 16:42:29 GMT Subject: RFR: 8325900: Emit a warning on macOS if AWT has set the NSAppearance [v4] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 21:58:37 GMT, Michael Strau? wrote: >> Platform preferences detection doesn't pick up effective macOS system preferences if AWT owns the NSApplication and has set its NSAppearance to a fixed value. >> >> The workaround is to set the system property "apple.awt.application.appearance=system". >> >> If this property is not set, the following warning will be emitted if a JavaFX application attempts to use the platform preferences API: >> >> >> WARNING: Reported preferences may not reflect the macOS system preferences unless the sytem >> property apple.awt.application.appearance=system is set. This warning can be disabled by >> setting javafx.preferences.suppressAppleAwtWarning=true. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Break warning message into separate lines I can review this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1367#issuecomment-2023250420 From angorya at openjdk.org Wed Mar 27 16:45:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 16:45:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. As a user, I would be very surprised with the behavior based on modulo arithmetic. But I do acknowledge the point made by Kevin - if this is what the application developers wanted, then it is their fault. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023260253 From duke at openjdk.org Wed Mar 27 18:22:25 2024 From: duke at openjdk.org (drmarmac) Date: Wed, 27 Mar 2024 18:22:25 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. The code, as currently suggested, effectively calculates `x(i+1) = (x(i) + amountToStepBy) MOD (max - min + 1)`. I'd say this is the modulo value we actually want, because x=min and x=max should both be included. Look at a simpler example, which would not work with a `MOD (max-min)` formula: min=0; max=2; amountToStepBy=1, initial=0 => 0, 1, 2, 0, 1, ... min=0; max=2; amountToStepBy=2, initial=0 => 0, 2, 0, 2, 0, ... min=0; max=2; amountToStepBy=3, initial=0 => 0, 0, 0, 0, 0, ... min=0; max=2; amountToStepBy=4, initial=0 => 0, 1, 2, 0, 1, ... So your example should result in `min=0; max=100; amountToStepBy=101, initial=0 => 0, 0, 0, 0...`, which it currently does. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023513947 From angorya at openjdk.org Wed Mar 27 18:33:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 18:33:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac wrote: > This PR should fix the issue and cover all relevant cases with new tests. > > Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner. the end result of stepping once by `amountToStepBy` must be equivalent of incrementing by one a total of `amountToStepBy` times, wouldn't you agree? so the formula for positive `amountToStepBy` values should look like `((val + amountToStepBy) % (max - min)) + min` or something along these lines. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023596265 From kcr at openjdk.org Wed Mar 27 19:08:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 27 Mar 2024 19:08:27 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 18:30:24 GMT, Andy Goryachev wrote: > the end result of stepping once by `amountToStepBy` must be equivalent of incrementing by one a total of `amountToStepBy` times, wouldn't you agree? Yes, this is the expectaion. > so the formula for positive `amountToStepBy` values should look like > > `((val + amountToStepBy) % (max - min)) + min` > > or something along these lines. Not quite. Because the range is inclusive on both ends, the number of discrete positions is `max - min + 1`. In your above example , where `min=0` and `max=100`, there are 101 discrete positions. A single step by 101 or 101 steps by 1 will both bring you back to the same position you started from. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023752621 From angorya at openjdk.org Wed Mar 27 19:22:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 19:22:26 GMT Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 19:05:40 GMT, Kevin Rushforth wrote: > the number of discrete positions is `max - min + 1` you are right! my earlier comment is invalid. please ignore. Now, when wrapping occurs, should max/min be considered as valid steps? Example, try both integer and double spinners with {min=0, max=10, step=7} starting with value=0. try incrementing. integer: 0, 7, 3, 10 double: 0, 7, 10, 0, 7, 10 And another question: should the new behavior (whatever everyone agrees to eventually) be documented? Where? This PR? JBS? Javadoc? A markdown file in doc-files/behavior/? Does it need a CSR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2023788836 From nlisker at openjdk.org Wed Mar 27 20:38:58 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 20:38:58 GMT Subject: RFR: 8327179: Update the 3D lighting application [v5] In-Reply-To: References: Message-ID: <8J6xB_aiNL7uR8r8xkp2bMLkbezHO8IBSWqD6CzEg4Y=.b10df39c-f807-4952-b59e-08c55ef88acb@github.com> > Update for the 3D lighting test tool as described in the JBS issue. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added gradle script ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1387/files - new: https://git.openjdk.org/jfx/pull/1387/files/9b3f0c5e..f063d088 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=03-04 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From nlisker at openjdk.org Wed Mar 27 20:44:35 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 20:44:35 GMT Subject: RFR: 8327179: Update the 3D lighting application [v5] In-Reply-To: <8J6xB_aiNL7uR8r8xkp2bMLkbezHO8IBSWqD6CzEg4Y=.b10df39c-f807-4952-b59e-08c55ef88acb@github.com> References: <8J6xB_aiNL7uR8r8xkp2bMLkbezHO8IBSWqD6CzEg4Y=.b10df39c-f807-4952-b59e-08c55ef88acb@github.com> Message-ID: <83EZjKvhSYP7MA5pxGNfZCe6CC5qYvWrfzM0TL9gaRI=.6944bc49-ee1d-4e7e-91ca-31fa0b947ec2@github.com> On Wed, 27 Mar 2024 20:38:58 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added gradle script I added the application to the gradle build file so it can be hooked up with its module dependencies. You can now produce a jar that bundles the resource with the classes. You still need to point to the modules at runtime. Let me know if this is a good enough solution. The way the project is configured in the main build file is not the best, but it will require large changes to do it better. Not sure what jcheck wants. It's complaining about empty spaces that have a `}` appear after them. This is the error: https://github.com/openjdk/jfx/pull/1387/files#annotation_19798318258. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2023946848 PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2023948839 From nlisker at openjdk.org Wed Mar 27 21:22:47 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 21:22:47 GMT Subject: RFR: 8327179: Update the 3D lighting application [v6] In-Reply-To: References: Message-ID: <71gJhxKjK17dZqoDndaxv2ljjXxKJnXLU0aTgKZVgEc=.58c3c8c0-89ce-41c6-8ddd-329f291e4939@github.com> > Update for the 3D lighting test tool as described in the JBS issue. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Whitespace? ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1387/files - new: https://git.openjdk.org/jfx/pull/1387/files/f063d088..ae471f2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1387&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1387.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/jfx/pull/1387 From nlisker at openjdk.org Wed Mar 27 21:22:48 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 27 Mar 2024 21:22:48 GMT Subject: RFR: 8327179: Update the 3D lighting application [v5] In-Reply-To: <8J6xB_aiNL7uR8r8xkp2bMLkbezHO8IBSWqD6CzEg4Y=.b10df39c-f807-4952-b59e-08c55ef88acb@github.com> References: <8J6xB_aiNL7uR8r8xkp2bMLkbezHO8IBSWqD6CzEg4Y=.b10df39c-f807-4952-b59e-08c55ef88acb@github.com> Message-ID: On Wed, 27 Mar 2024 20:38:58 GMT, Nir Lisker wrote: >> Update for the 3D lighting test tool as described in the JBS issue. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added gradle script Looks like the line specified by jcheck was off. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1387#issuecomment-2024008625 From angorya at openjdk.org Wed Mar 27 21:54:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 27 Mar 2024 21:54:37 GMT Subject: RFR: 8092102: Labeled: truncated property [v6] In-Reply-To: References: Message-ID: > Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width. > > The new property reacts to changes in the following properties: > - ellipsisString > - font > - height > - text > - width > - wrapText > > I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code. > > **Alternative** > > The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass. What is the benefit of adding this functionality to the core? > > UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126). The consequence of