From ethan.hall.1080 at gmail.com Thu Dec 1 01:51:48 2022 From: ethan.hall.1080 at gmail.com (Ethan Hall) Date: Wed, 30 Nov 2022 19:51:48 -0600 Subject: Project Proposal: Extending the PNG image loader to handle APNGs Message-ID: I am new here, but I have contributed to other open source projects before. I have signed the contributor agreement and read through the contributor info provided on the GitHub repository. The GitHub page says to discuss new features here, so here is my proposal. Summary ------- I would like to contribute code with the purpose of extending the PNG image loader to handle animated PNGs as specified by the APNG standard. The APNG specification can be found here: https://wiki.mozilla.org/APNG_Specification Goals ----- Enable JavaFX to be able to load APNGs as animated images. Motivation ---------- APNG is an extension of the PNG format that allows for animation. APNG images can be used as a higher quality alternative to GIF. The APNG standard is supported by all major modern internet browsers. JavaFX can already load animated GIFs, so additionally supporting animated PNGs makes sense. Description ----------- To support APNGs, the PNGImageLoader2 and PNGIDATChunkInputStream classes need to be modified so they can process the animation chunks acTL, fcTL, fdAT. Values from the acTL and fcTL chunks can simply be read like the image header chunk. The metadata for the frame can be updated based on these values. The fdAT chunks store data in exactly the same way as the IDAT chunks and can be handled by the PNGIDATChunkInputStream class with little modification. Once a new frame of image data has been decompressed, it will need to be composited with the frame buffer based on the blend OP code. Then, the frame buffer needs to be updated based on the disposal OP code. The composting process can be handled in a similar way to how JavaFX handles GIFs. After compositing, the ImageFrame can be returned. Testing ----------- Other than unit tests, I am not sure. I would like some advice on what to include for testing. Dependencies ------------ This change should not require any additional dependencies. Thanks, -Ethan Hall -------------- next part -------------- An HTML attachment was scrubbed... URL: From swpalmer at gmail.com Thu Dec 1 01:54:59 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 30 Nov 2022 20:54:59 -0500 Subject: Dialog Resizing Message-ID: <80B733A0-57EC-4EDF-80D6-A9A9008DE964@gmail.com> I just noticed that Dialogs set to be resizable don?t have any constraints on min/max size. So no min/max size properties on Dialog, nor does it limit resizing to within the constraints of the DialogPane. Am I missing something, or shall I file an enhancement request? Scott From swpalmer at gmail.com Thu Dec 1 01:54:59 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 30 Nov 2022 20:54:59 -0500 Subject: Dialog Resizing Message-ID: <80B733A0-57EC-4EDF-80D6-A9A9008DE964@gmail.com> I just noticed that Dialogs set to be resizable don?t have any constraints on min/max size. So no min/max size properties on Dialog, nor does it limit resizing to within the constraints of the DialogPane. Am I missing something, or shall I file an enhancement request? Scott From armin.schrenk at skymatic.de Thu Dec 1 09:32:07 2022 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Thu, 1 Dec 2022 10:32:07 +0100 Subject: Signing shared libraries and questions about loading In-Reply-To: <5A0D768E-22A1-400C-8B46-E07016702A70@gmail.com> References: <3b058835-9cb8-7972-6d55-b798c7432fb3@skymatic.de> <5A0D768E-22A1-400C-8B46-E07016702A70@gmail.com> Message-ID: <9a6c677b-1211-456e-7ff4-79df6b094ec9@skymatic.de> A solution via dependency management would be great, indeed. But since the problem at hand needs to be fixed, for now we are rolling with the "duck tape" build. I have follow-up question on that: We want to add a guard to our CI, checking that the JavaFX version in the POM and the JavaFx version in the jmods are always the same. Extracting the javafx version from the pom is easy, but for the jmods there is no apparent way. After looking into the JMODS, i found the file javafx.base.jmod/lib/javafx.properties which contains the JFX version. Also looking at the JDK bug tracker, this file is mentioned in several tickets. Can I rely on this file or is it "for internal use" only and can change anytime? Best wishes, Armin Am 21/11/2022 um 22:59 schrieb Scott Palmer: > This is why I suggested long ago that there should be .jmod zips in Maven central or similar. We need a dependency management system that works with JMODs for exactly this reason. Zips in the current public repos would work. > > Scott > >> On Nov 21, 2022, at 11:08 AM, Armin Schrenk wrote: >> >> Oh, thanks, didn't knew that. I tried the JMOD files provided by Gloun company with a local build. Works! >> >> But how can this be integrated into an automatic/CI build? Using a more or less arbitrary url pointing to a third-party website downloading a zip file of unknown structure would result in a "ducktape build" and is not very resilient against any changes. Furthermore, some build systems (i.e., ubuntu-ppa) do not allow external downloads. >> >> Does automatic build examples exist which are jlinking JFX to a custom JRE? >> >> Best wishes, >> >> Armin >> >> Am 16/11/2022 um 15:39 schrieb Kevin Rushforth: >>> Leaving aside the question of signed libraries, if you are using jpackage / jlink to create a custom Java runtime with the JavaFX modules, then you should use the JMODs bundles and not the artifacts from Maven central. The maven modules are a handy convenience for developers, but not recommend for creating packaged applications. >>> >>> -- Kevin >>> >>> >>> >>> >>> On 11/16/2022 6:29 AM, Armin Schrenk wrote: >>>> Hello, >>>> >>>> for our application, a customer reported that the shared libraries (in this case DLLs) used by JFX are unsigned and thus were blocked from loading, which blocks the app from starting. The culprit for blocking is a new security feature for Windows 11, Smart App Control (https://support.microsoft.com/en-gb/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003). Since this feature seems to be a future part of Windows, i suggest to sign the shared libs before the maven release. In our case, the archive javafx-graphics-*-win.jar contains the DLLs. >>>> >>>> Apart from this feature request, we want to fix the issue on our side. To do that, I investigated into the sharedLib loading of JFX. >>>> >>>> SharedLib Loading is in JFX is done with the NativeLibLoader (https://github.com/openjdk/jfx/blob/19+11/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java). It does the following to load the native lib: >>>> >>>> 1. Load the DLLs from a certain path (see below) >>>> 2. On Failure, load the DLLs from a resource (aka the jar) by extracting them to a cache directory and load them from there >>>> 3. On Failure, do other stuff not of interest >>>> >>>> Our app is modular (or as much as possible), thus, the DLLs were always loaded from the resource. But this extract-and-cache approach is unsatisfying from our point of view. The app uses a custom JRE via jlink and is packaged with jpackage, and we would like to place the sharedLibs at build time somewhere in the app directory. >>>> >>>> So I had to figure out the where to place the DLLs, or more specifically, what path is checked in Step 1 of shared libLoading. Reading the inline comment starting at line 117, it should be the same dir as the jar is placed. Unfortunately, this is not the case and i had to dig more through the code to find out. >>>> >>>> Our app has the following structure: >>>> |- JarsAndMods >>>> | - Mods >>>> | - modul1.jar >>>> | - modul2.jar >>>> | - ... >>>> | - javafx-graphics-XXX-win.jar >>>> | - ... >>>> | - nonModular1.jar >>>> | - nonModular2.jar >>>> | - ... >>>> |- executable >>>> >>>> According to the comment, the path to place all DLLs should be /JarsAndMods/Mods. >>>> But verbose logging showed and later proofed by the code, it has to be /JarsAndMods/bin. >>>> >>>> My questions are: >>>> >>>> Why does JFX require only for Windows the `../bin` directory? >>>> >>>> Additionally, this inline comment has a FIXME that Step 1 of SharedLibLoading should be removed in the future. Is there already an ETA? >>>> >>>> And lastly, I would love to see some Documentation for this. I can write it and create the PR, but where should it be placed? >>>> >>>> >>>> Best wishes, >>>> >>>> Armin >>>> From duke at openjdk.org Thu Dec 1 10:12:26 2022 From: duke at openjdk.org (eduardsdv) Date: Thu, 1 Dec 2022 10:12:26 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v4] In-Reply-To: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: > This fixes a race condition between application and 'Print Job Thread' threads when printing. > > The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, > and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. > The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. > > In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. > It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. eduardsdv has updated the pull request incrementally with three additional commits since the last revision: - Revert "8295324: Apply patch with junit from the issue" This reverts commit c76b8207242a7af82f5515e49760158fa40da2a9. - Revert "8295324: Fix race condition in junit test" This reverts commit fdec73d8f4ff21908bf99d191b76ffeed42bfb36. - Revert "8295324: Adjust the J2DPrinterJobTest" This reverts commit 0723d2ebcd2c41d40005dbb1652c4ec96cfe4f8c. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/916/files - new: https://git.openjdk.org/jfx/pull/916/files/acd4825b..127cb03b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=916&range=02-03 Stats: 488 lines in 6 files changed: 6 ins; 471 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/916.diff Fetch: git fetch https://git.openjdk.org/jfx pull/916/head:pull/916 PR: https://git.openjdk.org/jfx/pull/916 From nlisker at gmail.com Thu Dec 1 10:23:43 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 12:23:43 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly Message-ID: Hi, Given the following code var cb1 = new Label("1"); var cb2 = new Label ("2"); var b1 = new Button("A"); cb1.setGraphic(b1); b1.setOnAction(e -> { if (b1.getParent() == cb1) { // cb1.setGraphic(null); cb2.setGraphic(b1); } else { // cb2.setGraphic(null); cb1.setGraphic(b1); } }); Pressing the first button will move it (the graphic) to the second label, however, pressing it again will not move it back to the first label. It's required to set the graphics to null prior to moving them as in the commented lines. This looks like a bug to me. I would think that when a graphic is moved, it will appear in its new label immediately, like moving a child. Apparently a single node can be the graphics for multiple Labeled nodes, but it will appear only in 1. Is this intentional? - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Thu Dec 1 10:38:09 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 1 Dec 2022 10:38:09 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: On Wed, 26 Oct 2022 06:52:17 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1426: >> >>> 1424: if (s == null) return false; >>> 1425: Window w = s.getWindow(); >>> 1426: return w != null && w.isShowing(); >> >> Are you avoiding calling `get` on the property to avoid its initialization? > > Yeah, I actually copied this pattern from an older method that has since been removed (`isWindowShowing`) in an effort to avoid initializing the property if all you're doing is calling its getter. I personally don't mind either way, but as it seems `Node` goes through every effort to delay initialization, I followed that pattern. It does duplicate the logic of the property which uses `flatMap`s to achieve the same. I would suggest adding a comment saying that this is done to avoid initialization. I'm not sure that it's that critical for performance, to be honest. ------------- PR: https://git.openjdk.org/jfx/pull/830 From duke at openjdk.org Thu Dec 1 10:39:01 2022 From: duke at openjdk.org (eduardsdv) Date: Thu, 1 Dec 2022 10:39:01 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. It seems that no one needs it, so I am closing this PR. ------------- PR: https://git.openjdk.org/jfx/pull/657 From duke at openjdk.org Thu Dec 1 10:39:02 2022 From: duke at openjdk.org (eduardsdv) Date: Thu, 1 Dec 2022 10:39:02 GMT Subject: Withdrawn: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/657 From arapte at openjdk.org Thu Dec 1 10:39:49 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Dec 2022 10:39:49 GMT Subject: RFR: 8297554: Remove Scene.KeyHandler In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:49:02 GMT, Michael Strau? wrote: > The `Scene.KeyHandler` class doesn't seem to have a clear purpose, mixing focus handling with event propagation. Since #852, `KeyHandler.setFocusVisible` is also called from mouse and touch event handlers, which makes the purpose of the class even less pronounced. > > Moving the focus-related functionality next to the other focus functions in the `Scene` class makes it easier to work with the code in the future. > > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, this code can be rolled into `Scene.processKeyEvent` and the now-empty `KeyHandler` class can be removed. It looks in a quick look, shall review in detail in couple days. ------------- PR: https://git.openjdk.org/jfx/pull/962 From duke at openjdk.org Thu Dec 1 10:40:10 2022 From: duke at openjdk.org (eduardsdv) Date: Thu, 1 Dec 2022 10:40:10 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v4] In-Reply-To: References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Thu, 1 Dec 2022 10:12:26 GMT, eduardsdv wrote: >> This fixes a race condition between application and 'Print Job Thread' threads when printing. >> >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. >> >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. > > eduardsdv has updated the pull request incrementally with three additional commits since the last revision: > > - Revert "8295324: Apply patch with junit from the issue" > > This reverts commit c76b8207242a7af82f5515e49760158fa40da2a9. > - Revert "8295324: Fix race condition in junit test" > > This reverts commit fdec73d8f4ff21908bf99d191b76ffeed42bfb36. > - Revert "8295324: Adjust the J2DPrinterJobTest" > > This reverts commit 0723d2ebcd2c41d40005dbb1652c4ec96cfe4f8c. Ok. I have reverted all changes regarding refactoring and testing. ------------- PR: https://git.openjdk.org/jfx/pull/916 From mpaus at openjdk.org Thu Dec 1 10:48:49 2022 From: mpaus at openjdk.org (Michael Paus) Date: Thu, 1 Dec 2022 10:48:49 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. It's a pitty that this review was never completed. Very demotivating. ------------- PR: https://git.openjdk.org/jfx/pull/657 From nlisker at openjdk.org Thu Dec 1 10:48:49 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 1 Dec 2022 10:48:49 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v8] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Wed, 26 Oct 2022 07:56:52 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix javadoc error Looks good. Left a couple of minor comments. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1410: > 1408: /** > 1409: * Indicates whether or not this {@code Node} is shown. A node is considered shown if it's > 1410: * part of a {@code Scene} which is part of a {@code Window} whose which -> that modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420: > 1418: * when it is no longer shown. > 1419: * > 1420: * @see ObservableValue#when(ObservableValue) You don't need the `@see` since you linked it in the docs. ------------- PR: https://git.openjdk.org/jfx/pull/830 From arapte at openjdk.org Thu Dec 1 10:59:08 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Dec 2022 10:59:08 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. Sanity testing looks good. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/953 From arapte at openjdk.org Thu Dec 1 11:00:37 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 1 Dec 2022 11:00:37 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test Sanity testing looks good, on Mac and Windows. No Robot test failed. Shall try some combinations and update. ------------- PR: https://git.openjdk.org/jfx/pull/940 From aghaisas at openjdk.org Thu Dec 1 11:13:53 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 1 Dec 2022 11:13:53 GMT Subject: RFR: 8295506: ButtonBarSkin: memory leak when changing skin [v2] In-Reply-To: References: Message-ID: <9ry-i9gCQ7iw-LsfSgCDUKxBQkZR3CAGObZT8YfwMJQ=.799b3033-201d-4f09-8f7a-00aef77712a6@github.com> On Wed, 30 Nov 2022 17:10:50 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 165) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.BUTTON_BAR; >> >> >> caused by: >> - adding and not removing listeners >> - adding and not removing children Nodes > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295506.button.bar.skin > - Merge remote-tracking branch 'origin/master' into > 8295506.button.bar.skin > - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin > - 8294809: is alive > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8295506: button bar skin > - 8294809: removed weak listeners support > - 8294809: use weak reference correctly this time > - ... and 13 more: https://git.openjdk.org/jfx/compare/0a785ae0...759ecaf4 modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonBarSkin.java line 139: > 137: } > 138: > 139: updateButtonListeners(getSkinnable().getButtons(), false); Can we use `ListenerHelper` in `updateButtonListeners` method? We may need to use `ListernerHelper` of `ButtonSkin`. ------------- PR: https://git.openjdk.org/jfx/pull/921 From aghaisas at openjdk.org Thu Dec 1 11:25:22 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 1 Dec 2022 11:25:22 GMT Subject: RFR: 8295426: MenuButtonSkin: memory leak when changing skin [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 17:00:55 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 170) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Also applies to SplitMenuButton, since they share the same base class MenuButtonSkinBase. >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.MENU_BUTTON; // or SPLIT_MENU_BUTTON >> >> In addition, there seems to be another failure scenario when simply replacing the skin - no menu is shown upon a click. To reproduce, launch LeakTest and click once on the [Replace Skin] button. Second click restores the function. >> >> caused by: >> - adding and not removing EventHandlers >> - setting and not clearing onAction handlers >> - incorrect logic in setting mousePressed/mouse/Released handlers > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295426.menu.button.skin > - Merge remote-tracking branch 'origin/master' into > 8295426.menu.button.skin > - 8295426: listener helper update > - Merge remote-tracking branch 'origin/8294809.listener.helper' into 8295426.menu.button.skin > - 8294809: review comments > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - 8294809: whitespace > - 8294809: no public api > - 8294809: map change listener > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - ... and 27 more: https://git.openjdk.org/jfx/compare/0a785ae0...800d3f1e Fix looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/919 From john.hendrikx at gmail.com Thu Dec 1 12:20:36 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 13:20:36 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: Message-ID: Internally the graphics is just a child node, and nodes can't be part of the scene graph twice (this is done in LabeledSkinBase). It showing up only once is probably because it is getting removed from the other labels. I think things are probably getting out of sync, where the graphics property may think it still has a certain node as its graphics, but it is no longer a child of the label. --John On 01/12/2022 11:23, Nir Lisker wrote: > Hi, > > Given the following code > > ? ? ? ? var cb1 = new Label("1"); > ? ? ? ? var cb2 = new Label? ("2"); > ? ? ? ? var b1 = new Button("A"); > ? ? ? ? cb1.setGraphic(b1); > ? ? ? ? b1.setOnAction(e -> { > ? ? ? ? ? ? if (b1.getParent() == cb1) { > ? ? ? ? ? ? ? ? // cb1.setGraphic(null); > ? ? ? ? ? ? ? ? cb2.setGraphic(b1); > ? ? ? ? ? ? } else { > ? ? ? ? ? ? ? ? // cb2.setGraphic(null); > ? ? ? ? ? ? ? ? cb1.setGraphic(b1); > ? ? ? ? ? ? } > ? ? ? ? }); > > Pressing the first button will move it (the graphic) to the second > label, however, pressing it again will not move it back to the first > label. It's required to set the graphics to null prior to moving them > as in the commented lines. This looks like a bug to?me. I would think > that when a graphic is moved, it will appear in its new label > immediately, like moving a child. Apparently a single node can be the > graphics for multiple Labeled nodes, but it will appear only in 1. Is > this intentional? > > - Nir From nlisker at gmail.com Thu Dec 1 12:38:52 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 14:38:52 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: Message-ID: That's my point. Currently, a node can serve as the graphics property for multiple Labels, but will appear only in 1 because it can only have a single parent in the scenegraph. While this is technically fine, it causes issues like the one I showed above. I'm not sure if a node is supposed to be able to serve as multiple graphics (and displayed only in the last Label it was set to?), or removed from other Labels' graphic properties just like is done for children in the scenegraph. Personally, I find it confusing that label.getGraphics() will return a node that isn't shown in that label. On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx wrote: > Internally the graphics is just a child node, and nodes can't be part of > the scene graph twice (this is done in LabeledSkinBase). > > It showing up only once is probably because it is getting removed from > the other labels. > > I think things are probably getting out of sync, where the graphics > property may think it still has a certain node as its graphics, but it > is no longer a child of the label. > > --John > > On 01/12/2022 11:23, Nir Lisker wrote: > > Hi, > > > > Given the following code > > > > var cb1 = new Label("1"); > > var cb2 = new Label ("2"); > > var b1 = new Button("A"); > > cb1.setGraphic(b1); > > b1.setOnAction(e -> { > > if (b1.getParent() == cb1) { > > // cb1.setGraphic(null); > > cb2.setGraphic(b1); > > } else { > > // cb2.setGraphic(null); > > cb1.setGraphic(b1); > > } > > }); > > > > Pressing the first button will move it (the graphic) to the second > > label, however, pressing it again will not move it back to the first > > label. It's required to set the graphics to null prior to moving them > > as in the commented lines. This looks like a bug to me. I would think > > that when a graphic is moved, it will appear in its new label > > immediately, like moving a child. Apparently a single node can be the > > graphics for multiple Labeled nodes, but it will appear only in 1. Is > > this intentional? > > > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Thu Dec 1 13:46:44 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 14:46:44 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: Message-ID: Setting the same Node for multiple graphics is not allowed.? Your program should IMHO throw "IllegalArgumentException" on the 2nd click. ???? * An optional icon for the Labeled. This can be positioned relative to the ???? * text by using {@link #setContentDisplay}.? The node specified for this ???? * variable cannot appear elsewhere in the scene graph, otherwise ???? * the {@code IllegalArgumentException} is thrown.? See the class ???? * description of {@link Node} for more detail. --John On 01/12/2022 13:38, Nir Lisker wrote: > That's my point. Currently, a node can serve as the graphics property > for multiple Labels, but will appear only in 1 because it can only > have a single parent in the scenegraph. While this is technically > fine, it causes issues like the one I showed above. I'm not sure if a > node is supposed to be able to serve as multiple graphics (and > displayed?only in the last Label it was set to?), or removed from > other Labels' graphic properties just like is done for children in the > scenegraph. Personally, I find it confusing that label.getGraphics() > will return a node that isn't shown in that label. > > On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx > wrote: > > Internally the graphics is just a child node, and nodes can't be > part of > the scene graph twice (this is done in LabeledSkinBase). > > It showing up only once is probably because it is getting removed > from > the other labels. > > I think things are probably getting out of sync, where the graphics > property may think it still has a certain node as its graphics, > but it > is no longer a child of the label. > > --John > > On 01/12/2022 11:23, Nir Lisker wrote: > > Hi, > > > > Given the following code > > > > ? ? ? ? var cb1 = new Label("1"); > > ? ? ? ? var cb2 = new Label? ("2"); > > ? ? ? ? var b1 = new Button("A"); > > ? ? ? ? cb1.setGraphic(b1); > > ? ? ? ? b1.setOnAction(e -> { > > ? ? ? ? ? ? if (b1.getParent() == cb1) { > > ? ? ? ? ? ? ? ? // cb1.setGraphic(null); > > ? ? ? ? ? ? ? ? cb2.setGraphic(b1); > > ? ? ? ? ? ? } else { > > ? ? ? ? ? ? ? ? // cb2.setGraphic(null); > > ? ? ? ? ? ? ? ? cb1.setGraphic(b1); > > ? ? ? ? ? ? } > > ? ? ? ? }); > > > > Pressing the first button will move it (the graphic) to the second > > label, however, pressing it again will not move it back to the > first > > label. It's required to set the graphics to null prior to moving > them > > as in the commented lines. This looks like a bug to?me. I would > think > > that when a graphic is moved, it will appear in its new label > > immediately, like moving a child. Apparently a single node can > be the > > graphics for multiple Labeled nodes, but it will appear only in > 1. Is > > this intentional? > > > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Thu Dec 1 13:49:19 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 14:49:19 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: Message-ID: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> Sorry, I meant on the first click already. --John On 01/12/2022 14:46, John Hendrikx wrote: > > Setting the same Node for multiple graphics is not allowed. Your > program should IMHO throw "IllegalArgumentException" on the 2nd click. > > ???? * An optional icon for the Labeled. This can be positioned > relative to the > ???? * text by using {@link #setContentDisplay}.? The node specified > for this > ???? * variable cannot appear elsewhere in the scene graph, otherwise > ???? * the {@code IllegalArgumentException} is thrown.? See the class > ???? * description of {@link Node} for more detail. > > --John > > On 01/12/2022 13:38, Nir Lisker wrote: >> That's my point. Currently, a node can serve as the graphics property >> for multiple Labels, but will appear only in 1 because it can only >> have a single parent in the scenegraph. While this is technically >> fine, it causes issues like the one I showed above. I'm not sure if a >> node is supposed to be able to serve as multiple graphics (and >> displayed?only in the last Label it was set to?), or removed from >> other Labels' graphic properties just like is done for children in >> the scenegraph. Personally, I find it confusing that >> label.getGraphics() will return a node that isn't shown in that label. >> >> On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx >> wrote: >> >> Internally the graphics is just a child node, and nodes can't be >> part of >> the scene graph twice (this is done in LabeledSkinBase). >> >> It showing up only once is probably because it is getting removed >> from >> the other labels. >> >> I think things are probably getting out of sync, where the graphics >> property may think it still has a certain node as its graphics, >> but it >> is no longer a child of the label. >> >> --John >> >> On 01/12/2022 11:23, Nir Lisker wrote: >> > Hi, >> > >> > Given the following code >> > >> > ? ? ? ? var cb1 = new Label("1"); >> > ? ? ? ? var cb2 = new Label? ("2"); >> > ? ? ? ? var b1 = new Button("A"); >> > ? ? ? ? cb1.setGraphic(b1); >> > ? ? ? ? b1.setOnAction(e -> { >> > ? ? ? ? ? ? if (b1.getParent() == cb1) { >> > ? ? ? ? ? ? ? ? // cb1.setGraphic(null); >> > ? ? ? ? ? ? ? ? cb2.setGraphic(b1); >> > ? ? ? ? ? ? } else { >> > ? ? ? ? ? ? ? ? // cb2.setGraphic(null); >> > ? ? ? ? ? ? ? ? cb1.setGraphic(b1); >> > ? ? ? ? ? ? } >> > ? ? ? ? }); >> > >> > Pressing the first button will move it (the graphic) to the second >> > label, however, pressing it again will not move it back to the >> first >> > label. It's required to set the graphics to null prior to >> moving them >> > as in the commented lines. This looks like a bug to?me. I would >> think >> > that when a graphic is moved, it will appear in its new label >> > immediately, like moving a child. Apparently a single node can >> be the >> > graphics for multiple Labeled nodes, but it will appear only in >> 1. Is >> > this intentional? >> > >> > - Nir >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Dec 1 14:21:34 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 16:21:34 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> Message-ID: Technically it doesn't appear elsewhere in the scenegraph, it is the child of only one label. It's set as the graphics property of 2 labels though. The mismatch is that being set as a graphics property isn't a 1-to-1 relationship with being a child of the label. Something has to be fixed along this chain of inconsistency, I just wasn't sure where. It seems like the IAE that you mentioned should be thrown, but isn't. I can write a PR for that. One thing I'm not sure about is: in a situation where the graphic belongs to a label that is detached from a scene, and that graphic is set to a label that *is* part of a scene, should an IAE be thrown as well. By the way, changing to throwing an IAE is going to cause some new exceptions. There is a possibility that some VirtualFlow things will break because that mechanism recycles nodes and re-attaches their properties. Then again, it might just mean that it was done wrong. On Thu, Dec 1, 2022 at 3:49 PM John Hendrikx wrote: > Sorry, I meant on the first click already. > > --John > On 01/12/2022 14:46, John Hendrikx wrote: > > Setting the same Node for multiple graphics is not allowed. Your program > should IMHO throw "IllegalArgumentException" on the 2nd click. > > * An optional icon for the Labeled. This can be positioned relative > to the > * text by using {@link #setContentDisplay}. The node specified for > this > * variable cannot appear elsewhere in the scene graph, otherwise > * the {@code IllegalArgumentException} is thrown. See the class > * description of {@link Node} for more detail. > > --John > On 01/12/2022 13:38, Nir Lisker wrote: > > That's my point. Currently, a node can serve as the graphics property for > multiple Labels, but will appear only in 1 because it can only have a > single parent in the scenegraph. While this is technically fine, it causes > issues like the one I showed above. I'm not sure if a node is supposed to > be able to serve as multiple graphics (and displayed only in the last Label > it was set to?), or removed from other Labels' graphic properties just like > is done for children in the scenegraph. Personally, I find it confusing > that label.getGraphics() will return a node that isn't shown in that label. > > On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx > wrote: > >> Internally the graphics is just a child node, and nodes can't be part of >> the scene graph twice (this is done in LabeledSkinBase). >> >> It showing up only once is probably because it is getting removed from >> the other labels. >> >> I think things are probably getting out of sync, where the graphics >> property may think it still has a certain node as its graphics, but it >> is no longer a child of the label. >> >> --John >> >> On 01/12/2022 11:23, Nir Lisker wrote: >> > Hi, >> > >> > Given the following code >> > >> > var cb1 = new Label("1"); >> > var cb2 = new Label ("2"); >> > var b1 = new Button("A"); >> > cb1.setGraphic(b1); >> > b1.setOnAction(e -> { >> > if (b1.getParent() == cb1) { >> > // cb1.setGraphic(null); >> > cb2.setGraphic(b1); >> > } else { >> > // cb2.setGraphic(null); >> > cb1.setGraphic(b1); >> > } >> > }); >> > >> > Pressing the first button will move it (the graphic) to the second >> > label, however, pressing it again will not move it back to the first >> > label. It's required to set the graphics to null prior to moving them >> > as in the commented lines. This looks like a bug to me. I would think >> > that when a graphic is moved, it will appear in its new label >> > immediately, like moving a child. Apparently a single node can be the >> > graphics for multiple Labeled nodes, but it will appear only in 1. Is >> > this intentional? >> > >> > - Nir >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fkirmaier at openjdk.org Thu Dec 1 15:27:48 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 1 Dec 2022 15:27:48 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. I'm actually using it for my builds ... But sadly I'm not a reviewer. ------------- PR: https://git.openjdk.org/jfx/pull/657 From nlisker at openjdk.org Thu Dec 1 15:57:15 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 1 Dec 2022 15:57:15 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. It requires only 1 reviewer with the tole of Reviewer. One of you can be the second reviewer. ------------- PR: https://git.openjdk.org/jfx/pull/657 From kcr at openjdk.org Thu Dec 1 16:14:44 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 1 Dec 2022 16:14:44 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. In this case, there was no agreement that we should add this capability. As @johanvos said in [this comment](https://bugs.openjdk.org/browse/JDK-8276170?focusedCommentId=14455624&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14455624) in the JBS bug report, it might have been better for the maven publishing task to not be in the build at all. ------------- PR: https://git.openjdk.org/jfx/pull/657 From angorya at openjdk.org Thu Dec 1 16:25:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 16:25:39 GMT Subject: Integrated: 8295426: MenuButtonSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 22:42:42 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 170) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Also applies to SplitMenuButton, since they share the same base class MenuButtonSkinBase. > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.MENU_BUTTON; // or SPLIT_MENU_BUTTON > > In addition, there seems to be another failure scenario when simply replacing the skin - no menu is shown upon a click. To reproduce, launch LeakTest and click once on the [Replace Skin] button. Second click restores the function. > > caused by: > - adding and not removing EventHandlers > - setting and not clearing onAction handlers > - incorrect logic in setting mousePressed/mouse/Released handlers This pull request has now been integrated. Changeset: 4a19fe71 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/4a19fe71f9151460dca97d4ca9962fd630404ee8 Stats: 175 lines in 4 files changed: 109 ins; 32 del; 34 mod 8295426: MenuButtonSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/919 From angorya at openjdk.org Thu Dec 1 16:43:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 16:43:10 GMT Subject: RFR: 8295506: ButtonBarSkin: memory leak when changing skin [v2] In-Reply-To: <9ry-i9gCQ7iw-LsfSgCDUKxBQkZR3CAGObZT8YfwMJQ=.799b3033-201d-4f09-8f7a-00aef77712a6@github.com> References: <9ry-i9gCQ7iw-LsfSgCDUKxBQkZR3CAGObZT8YfwMJQ=.799b3033-201d-4f09-8f7a-00aef77712a6@github.com> Message-ID: On Thu, 1 Dec 2022 11:11:31 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Merge remote-tracking branch 'origin/master' into >> 8295506.button.bar.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295506.button.bar.skin >> - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin >> - 8294809: generics >> - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin >> - 8294809: is alive >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - 8295506: button bar skin >> - 8294809: removed weak listeners support >> - 8294809: use weak reference correctly this time >> - ... and 13 more: https://git.openjdk.org/jfx/compare/0a785ae0...759ecaf4 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ButtonBarSkin.java line 139: > >> 137: } >> 138: >> 139: updateButtonListeners(getSkinnable().getButtons(), false); > > Can we use `ListenerHelper` in `updateButtonListeners` method? > We may need to use `ListernerHelper` of `ButtonSkin`. good question. I did not want to make drastic structural changes for risk of introducing regression. Right now, this skin uses the same pattern when dealing with multiple child items - it adds/removes listeners in the constructor, in the dispose() method, and upon any changes to the observable list. Perhaps not the most optimal solution, but it works and causes no trouble. I'd rather keep it as is. ------------- PR: https://git.openjdk.org/jfx/pull/921 From angorya at openjdk.org Thu Dec 1 17:04:15 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 17:04:15 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v17] In-Reply-To: References: Message-ID: <-2bx32_5TvmEqs-dxEWOB5RmwW_R8JJU7ZrX5OyDveg=.8b130a09-d3b8-4c40-b450-1946e024fb3d@github.com> > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits: - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: review comments - 8294589: cleanup - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: testing github merge-conflict label behavior - 8294589: cleanup - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - Merge branch '8294809.listener.helper' into 8294589.menubarskin.leak - 8294809: generics - 8294589: owner - ... and 39 more: https://git.openjdk.org/jfx/compare/4a19fe71...b51db815 ------------- Changes: https://git.openjdk.org/jfx/pull/906/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=16 Stats: 470 lines in 2 files changed: 234 ins; 205 del; 31 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 17:04:18 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 17:04:18 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: <6BKmT4dfxws4iW0Y--KyFJQXvtgLq2qzIgYJBILfBoE=.0b969175-9adb-44b7-bc1e-03d5ddec6c5e@github.com> On Wed, 30 Nov 2022 23:13:42 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 227: >> >>> 225: ComboBox.class, >>> 226: DatePicker.class, >>> 227: //MenuBar.class, >> >> minor: commented out code > > intentionally, to avoid merge conflicts. edit: unfortunately, this trick did help - getting merge conflicts. will be removing the entries. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 17:09:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 17:09:50 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 164) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.ACCORDION; > > > caused by: > - adding and not removing listeners Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - 8295500: cleanup - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - 8295500: cleanup - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - Merge branch '8294809.listener.helper' into 8295500.accordion.skin - 8294809: generics - Merge branch '8294809.listener.helper' into 8295500.accordion.skin - 8294809: is alive - Merge branch '8294809.listener.helper' into 8295500.accordion.skin - ... and 19 more: https://git.openjdk.org/jfx/compare/4a19fe71...8da3b64f ------------- Changes: https://git.openjdk.org/jfx/pull/920/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=920&range=02 Stats: 37 lines in 2 files changed: 16 ins; 13 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/920.diff Fetch: git fetch https://git.openjdk.org/jfx pull/920/head:pull/920 PR: https://git.openjdk.org/jfx/pull/920 From angorya at openjdk.org Thu Dec 1 17:09:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 17:09:53 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 16:29:58 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 164) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.ACCORDION; >> >> >> caused by: >> - adding and not removing listeners > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin > - 8295500: cleanup > - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - 8294809: is alive > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8295500: cleanup > - ... and 17 more: https://git.openjdk.org/jfx/compare/0a785ae0...218c6ea9 @aghaisas : would you please review this? ------------- PR: https://git.openjdk.org/jfx/pull/920 From john.hendrikx at gmail.com Thu Dec 1 17:14:04 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 18:14:04 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> Message-ID: <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> The mechanism does seem like it is a bit poorly designed, as it is easy to create inconsistencies. Luckily it seems that you can't remove a graphic yourself from a Control (getChildren is protected). I don't think there is an easy solution though... I think that once you set a graphic on a Labeled, you need to somehow mark it as "in use".? Normally you could just check parent != null for this, but it is trickier than that.? The Skin ultimately determines if it adds the graphic as child, which may be delayed or may even be disabled (content display property is set to showing TEXT only). Perhaps Skins should always add the graphic and just hide it (visible false, managed false), but that's going to be hard to enforce. Marking the graphic as "in use" could be done with: - a property in `getProperties` - a new "owner" or "ownedBy" property - allowing "parent" to be set without adding it to children (probably going to mess up stuff) --John On 01/12/2022 15:21, Nir Lisker wrote: > Technically it doesn't appear elsewhere in the scenegraph, it is the > child of only one label. It's set as the graphics property of 2 labels > though. The mismatch is that being set as a graphics property isn't a > 1-to-1 relationship with being a child of the label. > > Something has to be fixed along this chain of inconsistency, I just > wasn't sure where. It seems like the IAE that you mentioned should be > thrown, but isn't. I can write a PR for that. One thing I'm not sure > about is: in a situation where the graphic belongs to a label that is > detached from a scene, and that graphic is set to a label that *is* > part of a scene, should an IAE be thrown as well. Even if the Labeled is part of the Scene, the graphic may not be (depending on Skin used and on Content Display property for the default skin). > > By the way, changing to throwing an IAE is going to cause some new > exceptions. There is a possibility?that some VirtualFlow things will > break because that mechanism recycles nodes and re-attaches their > properties. Then again, it might just mean that it was done wrong. > > On Thu, Dec 1, 2022 at 3:49 PM John Hendrikx > wrote: > > Sorry, I meant on the first click already. > > --John > > On 01/12/2022 14:46, John Hendrikx wrote: >> >> Setting the same Node for multiple graphics is not allowed.? Your >> program should IMHO throw "IllegalArgumentException" on the 2nd >> click. >> >> ???? * An optional icon for the Labeled. This can be positioned >> relative to the >> ???? * text by using {@link #setContentDisplay}.? The node >> specified for this >> ???? * variable cannot appear elsewhere in the scene graph, otherwise >> ???? * the {@code IllegalArgumentException} is thrown. See the class >> ???? * description of {@link Node} for more detail. >> >> --John >> >> On 01/12/2022 13:38, Nir Lisker wrote: >>> That's my point. Currently, a node can serve as the graphics >>> property for multiple Labels, but will appear only in 1 because >>> it can only have a single parent in the scenegraph. While this >>> is technically fine, it causes issues like the one I showed >>> above. I'm not sure if a node is supposed to be able to serve as >>> multiple graphics (and displayed?only in the last Label it was >>> set to?), or removed from other Labels' graphic properties just >>> like is done for children in the scenegraph. Personally, I find >>> it confusing that label.getGraphics() will return a node that >>> isn't shown in that label. >>> >>> On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx >>> wrote: >>> >>> Internally the graphics is just a child node, and nodes >>> can't be part of >>> the scene graph twice (this is done in LabeledSkinBase). >>> >>> It showing up only once is probably because it is getting >>> removed from >>> the other labels. >>> >>> I think things are probably getting out of sync, where the >>> graphics >>> property may think it still has a certain node as its >>> graphics, but it >>> is no longer a child of the label. >>> >>> --John >>> >>> On 01/12/2022 11:23, Nir Lisker wrote: >>> > Hi, >>> > >>> > Given the following code >>> > >>> > ? ? ? ? var cb1 = new Label("1"); >>> > ? ? ? ? var cb2 = new Label? ("2"); >>> > ? ? ? ? var b1 = new Button("A"); >>> > ? ? ? ? cb1.setGraphic(b1); >>> > ? ? ? ? b1.setOnAction(e -> { >>> > ? ? ? ? ? ? if (b1.getParent() == cb1) { >>> > ? ? ? ? ? ? ? ? // cb1.setGraphic(null); >>> > ? ? ? ? ? ? ? ? cb2.setGraphic(b1); >>> > ? ? ? ? ? ? } else { >>> > ? ? ? ? ? ? ? ? // cb2.setGraphic(null); >>> > ? ? ? ? ? ? ? ? cb1.setGraphic(b1); >>> > ? ? ? ? ? ? } >>> > ? ? ? ? }); >>> > >>> > Pressing the first button will move it (the graphic) to >>> the second >>> > label, however, pressing it again will not move it back to >>> the first >>> > label. It's required to set the graphics to null prior to >>> moving them >>> > as in the commented lines. This looks like a bug to?me. I >>> would think >>> > that when a graphic is moved, it will appear in its new label >>> > immediately, like moving a child. Apparently a single node >>> can be the >>> > graphics for multiple Labeled nodes, but it will appear >>> only in 1. Is >>> > this intentional? >>> > >>> > - Nir >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Dec 1 17:16:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 17:16:36 GMT Subject: RFR: 8295506: ButtonBarSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: <_pIyjdN5WyUZ2sNjaGwF_2KwHsENVVXRneU0A7-BF24=.97344ea6-7c01-444a-97fe-ed7b36fe690a@github.com> > as determined by SkinMemoryLeakTest (remove line 165) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.BUTTON_BAR; > > > caused by: > - adding and not removing listeners > - adding and not removing children Nodes Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - 8295506: cleanup - Merge remote-tracking branch 'origin/master' into 8295506.button.bar.skin - Merge remote-tracking branch 'origin/master' into 8295506.button.bar.skin - Merge remote-tracking branch 'origin/master' into 8295506.button.bar.skin - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin - 8294809: generics - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin - 8294809: is alive - Revert "8294809: removed weak listeners support" This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. - 8295506: button bar skin - ... and 15 more: https://git.openjdk.org/jfx/compare/4a19fe71...efc60c0c ------------- Changes: https://git.openjdk.org/jfx/pull/921/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=921&range=02 Stats: 30 lines in 2 files changed: 17 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/921.diff Fetch: git fetch https://git.openjdk.org/jfx pull/921/head:pull/921 PR: https://git.openjdk.org/jfx/pull/921 From andy.goryachev at oracle.com Thu Dec 1 17:20:47 2022 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 1 Dec 2022 17:20:47 +0000 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> Message-ID: Does wrapping the action code in runLater() help? b1.setOnAction((ev) -> { Platform.runLater(() -> { if (b1.getParent() == cb1) { ... -andy From: openjfx-dev on behalf of John Hendrikx Date: Thursday, 2022/12/01 at 09:14 To: Nir Lisker Cc: openjfx-dev at openjdk.org Subject: Re: Setting graphics of a Labeled does not show the Label correctly The mechanism does seem like it is a bit poorly designed, as it is easy to create inconsistencies. Luckily it seems that you can't remove a graphic yourself from a Control (getChildren is protected). I don't think there is an easy solution though... I think that once you set a graphic on a Labeled, you need to somehow mark it as "in use". Normally you could just check parent != null for this, but it is trickier than that. The Skin ultimately determines if it adds the graphic as child, which may be delayed or may even be disabled (content display property is set to showing TEXT only). Perhaps Skins should always add the graphic and just hide it (visible false, managed false), but that's going to be hard to enforce. Marking the graphic as "in use" could be done with: - a property in `getProperties` - a new "owner" or "ownedBy" property - allowing "parent" to be set without adding it to children (probably going to mess up stuff) --John On 01/12/2022 15:21, Nir Lisker wrote: Technically it doesn't appear elsewhere in the scenegraph, it is the child of only one label. It's set as the graphics property of 2 labels though. The mismatch is that being set as a graphics property isn't a 1-to-1 relationship with being a child of the label. Something has to be fixed along this chain of inconsistency, I just wasn't sure where. It seems like the IAE that you mentioned should be thrown, but isn't. I can write a PR for that. One thing I'm not sure about is: in a situation where the graphic belongs to a label that is detached from a scene, and that graphic is set to a label that *is* part of a scene, should an IAE be thrown as well. Even if the Labeled is part of the Scene, the graphic may not be (depending on Skin used and on Content Display property for the default skin). By the way, changing to throwing an IAE is going to cause some new exceptions. There is a possibility that some VirtualFlow things will break because that mechanism recycles nodes and re-attaches their properties. Then again, it might just mean that it was done wrong. On Thu, Dec 1, 2022 at 3:49 PM John Hendrikx > wrote: Sorry, I meant on the first click already. --John On 01/12/2022 14:46, John Hendrikx wrote: Setting the same Node for multiple graphics is not allowed. Your program should IMHO throw "IllegalArgumentException" on the 2nd click. * An optional icon for the Labeled. This can be positioned relative to the * text by using {@link #setContentDisplay}. The node specified for this * variable cannot appear elsewhere in the scene graph, otherwise * the {@code IllegalArgumentException} is thrown. See the class * description of {@link Node} for more detail. --John On 01/12/2022 13:38, Nir Lisker wrote: That's my point. Currently, a node can serve as the graphics property for multiple Labels, but will appear only in 1 because it can only have a single parent in the scenegraph. While this is technically fine, it causes issues like the one I showed above. I'm not sure if a node is supposed to be able to serve as multiple graphics (and displayed only in the last Label it was set to?), or removed from other Labels' graphic properties just like is done for children in the scenegraph. Personally, I find it confusing that label.getGraphics() will return a node that isn't shown in that label. On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx > wrote: Internally the graphics is just a child node, and nodes can't be part of the scene graph twice (this is done in LabeledSkinBase). It showing up only once is probably because it is getting removed from the other labels. I think things are probably getting out of sync, where the graphics property may think it still has a certain node as its graphics, but it is no longer a child of the label. --John On 01/12/2022 11:23, Nir Lisker wrote: > Hi, > > Given the following code > > var cb1 = new Label("1"); > var cb2 = new Label ("2"); > var b1 = new Button("A"); > cb1.setGraphic(b1); > b1.setOnAction(e -> { > if (b1.getParent() == cb1) { > // cb1.setGraphic(null); > cb2.setGraphic(b1); > } else { > // cb2.setGraphic(null); > cb1.setGraphic(b1); > } > }); > > Pressing the first button will move it (the graphic) to the second > label, however, pressing it again will not move it back to the first > label. It's required to set the graphics to null prior to moving them > as in the commented lines. This looks like a bug to me. I would think > that when a graphic is moved, it will appear in its new label > immediately, like moving a child. Apparently a single node can be the > graphics for multiple Labeled nodes, but it will appear only in 1. Is > this intentional? > > - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Dec 1 17:30:23 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Dec 2022 09:30:23 -0800 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> Message-ID: I'm not sure wrapping it in a runLater would make much difference, and if it does, it would be fragile. I think that the best approach might be to disallow using the same Node as the "graphic" of two controls, in the same way that we disallow setting a Node as a clip of two different nodes. This would involve a CSR, since it's both a spec and a behavior change. The implementation would need to check whether the Node is in use, and if so, throw an exception (after first unbinding if bound). -- Kevin On 12/1/2022 9:20 AM, Andy Goryachev wrote: > > Does wrapping the action code in runLater() help? > > b1.setOnAction((ev) -> { > > Platform.runLater(() -> { > ? if (b1.getParent() == cb1) { > > ... > > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Thursday, 2022/12/01 at 09:14 > *To: *Nir Lisker > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: Setting graphics of a Labeled does not show the Label > correctly > > The mechanism does seem like it is a bit poorly designed, as it is > easy to create inconsistencies. > > Luckily it seems that you can't remove a graphic yourself from a > Control (getChildren is protected). > > I don't think there is an easy solution though... > > I think that once you set a graphic on a Labeled, you need to somehow > mark it as "in use".? Normally you could just check parent != null for > this, but it is trickier than that.? The Skin ultimately determines if > it adds the graphic as child, which may be delayed or may even be > disabled (content display property is set to showing TEXT only). > > Perhaps Skins should always add the graphic and just hide it (visible > false, managed false), but that's going to be hard to enforce. > > Marking the graphic as "in use" could be done with: > > - a property in `getProperties` > - a new "owner" or "ownedBy" property > - allowing "parent" to be set without adding it to children (probably > going to mess up stuff) > > --John > > On 01/12/2022 15:21, Nir Lisker wrote: > > Technically it doesn't appear elsewhere in the scenegraph, it is > the child of only one label. It's set as the graphics property of > 2 labels though. The mismatch is that being set as a graphics > property isn't a 1-to-1 relationship with being a child of the label. > > Something has to be fixed along this chain of inconsistency, I > just wasn't sure where. It seems like the IAE that you mentioned > should be thrown, but isn't. I can write a PR for that. One thing > I'm not sure about is: in a situation where the graphic belongs to > a label that is detached from a scene, and that graphic is set to > a label that *is* part of a scene, should an IAE be thrown as well. > > Even if the Labeled is part of the Scene, the graphic may not be > (depending on Skin used and on Content Display property for the > default skin). > > By the way, changing to throwing an IAE is going to cause some new > exceptions. There is a possibility?that some VirtualFlow things > will break because that mechanism recycles nodes and re-attaches > their properties. Then again, it might just mean that it was done > wrong. > > On Thu, Dec 1, 2022 at 3:49 PM John Hendrikx > wrote: > > Sorry, I meant on the first click already. > > --John > > On 01/12/2022 14:46, John Hendrikx wrote: > > Setting the same Node for multiple graphics is not > allowed.? Your program should IMHO throw > "IllegalArgumentException" on the 2nd click. > > ???? * An optional icon for the Labeled. This can be > positioned relative to the > ???? * text by using {@link #setContentDisplay}. The node > specified for this > ???? * variable cannot appear elsewhere in the scene > graph, otherwise > ???? * the {@code IllegalArgumentException} is thrown.? > See the class > ???? * description of {@link Node} for more detail. > > --John > > On 01/12/2022 13:38, Nir Lisker wrote: > > That's my point. Currently, a node can serve as the > graphics property for multiple Labels, but will appear > only in 1 because it can only have a single parent in > the scenegraph. While this is technically fine, it > causes issues like the one I showed above. I'm not > sure if a node is supposed to be able to serve as > multiple graphics (and displayed?only in the last > Label it was set to?), or removed from other Labels' > graphic properties just like is done for children in > the scenegraph. Personally, I find it confusing that > label.getGraphics() will return a node that isn't > shown in that label. > > On Thu, Dec 1, 2022 at 2:21 PM John Hendrikx > wrote: > > Internally the graphics is just a child node, and > nodes can't be part of > the scene graph twice (this is done in > LabeledSkinBase). > > It showing up only once is probably because it is > getting removed from > the other labels. > > I think things are probably getting out of sync, > where the graphics > property may think it still has a certain node as > its graphics, but it > is no longer a child of the label. > > --John > > On 01/12/2022 11:23, Nir Lisker wrote: > > Hi, > > > > Given the following code > > > > ? ? ? ? var cb1 = new Label("1"); > > ? ? ? ? var cb2 = new Label? ("2"); > > ? ? ? ? var b1 = new Button("A"); > > ? ? ? ? cb1.setGraphic(b1); > > ? ? ? ? b1.setOnAction(e -> { > > ? ? ? ? ? ? if (b1.getParent() == cb1) { > > ? ? ? ? ? ? ? ? // cb1.setGraphic(null); > > ? ? ? ? ? ? ? ? cb2.setGraphic(b1); > > ? ? ? ? ? ? } else { > > ? ? ? ? ? ? ? ? // cb2.setGraphic(null); > > ? ? ? ? ? ? ? ? cb1.setGraphic(b1); > > ? ? ? ? ? ? } > > ? ? ? ? }); > > > > Pressing the first button will move it (the > graphic) to the second > > label, however, pressing it again will not move > it back to the first > > label. It's required to set the graphics to null > prior to moving them > > as in the commented lines. This looks like a bug > to?me. I would think > > that when a graphic is moved, it will appear in > its new label > > immediately, like moving a child. Apparently a > single node can be the > > graphics for multiple Labeled nodes, but it will > appear only in 1. Is > > this intentional? > > > > - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Thu Dec 1 17:38:01 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 17:38:01 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Adjust Node - Fixed javadoc - Added comment for code that avoid eager instantiation - Changed `isShown` to use property if it is available ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/46f206aa..5c22fdd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=07-08 Stats: 12 lines in 1 file changed: 6 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Thu Dec 1 17:38:03 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 17:38:03 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v6] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com> Message-ID: <8LizsX7622GIMZ7lzqVZjcQAA0aFjIm6mjnUFS79yKo=.afd9c07c-58d5-4ff4-b092-fc8d15779433@github.com> On Thu, 1 Dec 2022 10:35:58 GMT, Nir Lisker wrote: >> Yeah, I actually copied this pattern from an older method that has since been removed (`isWindowShowing`) in an effort to avoid initializing the property if all you're doing is calling its getter. I personally don't mind either way, but as it seems `Node` goes through every effort to delay initialization, I followed that pattern. It does duplicate the logic of the property which uses `flatMap`s to achieve the same. > > I would suggest adding a comment saying that this is done to avoid initialization. > > I'm not sure that it's that critical for performance, to be honest. I think the pattern is good to do, the `shownProperty` will only be used for a small number of nodes, and not initializing it when not needed is a common pattern in `Node` itself already. Here for example for `opacity`: private DoubleProperty opacity; public final void setOpacity(double value) { opacityProperty().set(value); } public final double getOpacity() { return opacity == null ? 1 : opacity.get(); } But it is far from the only one. `disabled` does it, `pickOnBounds`, `blendMode`, etc. None of these contain a comment as to why, but I'll add one for `shown`. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Thu Dec 1 17:39:57 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 17:39:57 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v8] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <0ykpuQIF2iH_y9FtHp0UhfdKW0yzj_fSHvlH_2aNfSg=.da6e280b-3ab6-4a9b-a25d-7fdef505c9dc@github.com> On Mon, 7 Nov 2022 20:29:16 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix javadoc error > > I am not a native speaker, but to me `whenever` sounds event better than `conditionOn`. I might be wrong, but it does suggest that the binding becomes active *again* when the condition turns `true`. @andy-goryachev-oracle @mstr2 would one of you be willing to review this one as well? It should be close to its final state now. ------------- PR: https://git.openjdk.org/jfx/pull/830 From michaelstrau2 at gmail.com Thu Dec 1 17:42:16 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 1 Dec 2022 18:42:16 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> Message-ID: There's a larger picture here: from a user perspective, there's a difference between the scene graph and the "document graph". The document graph is what users actually work with, for example by setting the `Labeled.graphic` property. In some cases, document nodes don't correspond to scene nodes at all (`MenuItem` or `Tab` come to mind). The document graph is later inflated into a scene graph of unknown structure (because skins are mostly black boxes with regards to their internal structure). I've proposed an enhancement that would make the document graph a first-class citizen: https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html With this in place, we could simply disallow the same node appearing multiple times in the document graph, which would not only solve the problem for `Labeled`, but for all controls with a similar problem. On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx wrote: > > The mechanism does seem like it is a bit poorly designed, as it is easy to create inconsistencies. > > Luckily it seems that you can't remove a graphic yourself from a Control (getChildren is protected). > > I don't think there is an easy solution though... > > I think that once you set a graphic on a Labeled, you need to somehow mark it as "in use". Normally you could just check parent != null for this, but it is trickier than that. The Skin ultimately determines if it adds the graphic as child, which may be delayed or may even be disabled (content display property is set to showing TEXT only). > > Perhaps Skins should always add the graphic and just hide it (visible false, managed false), but that's going to be hard to enforce. > > Marking the graphic as "in use" could be done with: > > - a property in `getProperties` > - a new "owner" or "ownedBy" property > - allowing "parent" to be set without adding it to children (probably going to mess up stuff) > > --John From jhendrikx at openjdk.org Thu Dec 1 17:52:38 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 17:52:38 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 23:25:16 GMT, Andy Goryachev wrote: > but instead the whole component or Pane might be removed from the scene and discarded. If that happens, weak reference won't make a difference there either. Removing an entire branch from the Scene and not referring to it anymore will do correct clean-up even without a call to dispose and without the use of weak references. The only use case I see is that we still don't trust the Skin lifecycle to be adhered to and "just in case" are using weak references in case somehow dispose is not called. I would much prefer to see an actual reason to use it, and then adding a comment as to why this weak reference is needed so that in 6 months time we're not scratching our heads as to why a weak reference is needed here. ------------- PR: https://git.openjdk.org/jfx/pull/906 From kevin.rushforth at oracle.com Thu Dec 1 17:55:06 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Dec 2022 09:55:06 -0800 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> Message-ID: <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> This seems related, but somewhat tangential. A Control's "graphic" isn't a child node, just like a Shape's "clip" isn't a child node. Creating a separate "document graph" (or "logical graph") sounds like an interesting idea, but it would bring its own set of challenges. And it wouldn't directly solve this case anyway. -- Kevin On 12/1/2022 9:42 AM, Michael Strau? wrote: > There's a larger picture here: from a user perspective, there's a > difference between the scene graph and the "document graph". > The document graph is what users actually work with, for example by > setting the `Labeled.graphic` property. In some cases, document nodes > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to > mind). > The document graph is later inflated into a scene graph of unknown > structure (because skins are mostly black boxes with regards to their > internal structure). > > I've proposed an enhancement that would make the document graph a > first-class citizen: > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html > > With this in place, we could simply disallow the same node appearing > multiple times in the document graph, which would not only solve the > problem for `Labeled`, but for all controls with a similar problem. > > > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx wrote: >> The mechanism does seem like it is a bit poorly designed, as it is easy to create inconsistencies. >> >> Luckily it seems that you can't remove a graphic yourself from a Control (getChildren is protected). >> >> I don't think there is an easy solution though... >> >> I think that once you set a graphic on a Labeled, you need to somehow mark it as "in use". Normally you could just check parent != null for this, but it is trickier than that. The Skin ultimately determines if it adds the graphic as child, which may be delayed or may even be disabled (content display property is set to showing TEXT only). >> >> Perhaps Skins should always add the graphic and just hide it (visible false, managed false), but that's going to be hard to enforce. >> >> Marking the graphic as "in use" could be done with: >> >> - a property in `getProperties` >> - a new "owner" or "ownedBy" property >> - allowing "parent" to be set without adding it to children (probably going to mess up stuff) >> >> --John From jhendrikx at openjdk.org Thu Dec 1 17:55:34 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 17:55:34 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 23:28:02 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 374: >> >>> 372: >>> 373: // When the parent window looses focus - menu selection should be cleared >>> 374: sceneListenerHelper.addChangeListener(scene.windowProperty(), true, (sr, oldw, w) -> { >> >> Suggestion: >> >> sceneListenerHelper.addChangeListener(scene.windowProperty(), true, w -> { > > my version does not create extra object(s). Hm, I thought that the number of objects created is the same, either a `ChangeListener` is created and then wrapped in `ChLi` or a `Consumer` is created and wrapped in `ChLi`. ------------- PR: https://git.openjdk.org/jfx/pull/906 From john.hendrikx at gmail.com Thu Dec 1 18:14:05 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 19:14:05 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> Message-ID: Yes, I always felt something was off about how graphics and clips worked and that in some cases these are actually inaccessible children (you can still look them up) -- it feels like they should allow sharing (clips especially) but things then break. On 01/12/2022 18:42, Michael Strau? wrote: > There's a larger picture here: from a user perspective, there's a > difference between the scene graph and the "document graph". > The document graph is what users actually work with, for example by > setting the `Labeled.graphic` property. In some cases, document nodes > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to > mind). > The document graph is later inflated into a scene graph of unknown > structure (because skins are mostly black boxes with regards to their > internal structure). > > I've proposed an enhancement that would make the document graph a > first-class citizen: > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html > > With this in place, we could simply disallow the same node appearing > multiple times in the document graph, which would not only solve the > problem for `Labeled`, but for all controls with a similar problem. And also when Nodes are shared between different types of properties: ???? Label label; ???? Button button; ???? label.setGraphic(button); ???? label.setClip(button); Even with the logic in `setClip` (using `clipParent`) this will still go undetected. --John > > > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx wrote: >> The mechanism does seem like it is a bit poorly designed, as it is easy to create inconsistencies. >> >> Luckily it seems that you can't remove a graphic yourself from a Control (getChildren is protected). >> >> I don't think there is an easy solution though... >> >> I think that once you set a graphic on a Labeled, you need to somehow mark it as "in use". Normally you could just check parent != null for this, but it is trickier than that. The Skin ultimately determines if it adds the graphic as child, which may be delayed or may even be disabled (content display property is set to showing TEXT only). >> >> Perhaps Skins should always add the graphic and just hide it (visible false, managed false), but that's going to be hard to enforce. >> >> Marking the graphic as "in use" could be done with: >> >> - a property in `getProperties` >> - a new "owner" or "ownedBy" property >> - allowing "parent" to be set without adding it to children (probably going to mess up stuff) >> >> --John From angorya at openjdk.org Thu Dec 1 18:31:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 18:31:26 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v16] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits: - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: step1 - 8293119: more integers - 8293119: more integers - 8293119: use integers for rounded values - 8293119: tester - 8293119: descriptions - 8293119: all columns - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: cleanup - ... and 57 more: https://git.openjdk.org/jfx/compare/4a19fe71...b6e2ae59 ------------- Changes: https://git.openjdk.org/jfx/pull/897/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=15 Stats: 2260 lines in 14 files changed: 1999 ins; 250 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From nlisker at openjdk.org Thu Dec 1 18:32:10 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 1 Dec 2022 18:32:10 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <-sCOZCnq031-bdIsKu-GWoXEr7sxSlcJCM11Btc41no=.4c6cfbd2-68f4-4d50-917b-405fcecc6b03@github.com> On Thu, 1 Dec 2022 17:38:01 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Node > > - Fixed javadoc > - Added comment for code that avoid eager instantiation > - Changed `isShown` to use property if it is available Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/830 From nlisker at gmail.com Thu Dec 1 18:47:38 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 20:47:38 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: By the way, these issues are caused by this inconsistent behavior (they are probably duplicates): https://bugs.openjdk.org/browse/JDK-8209017 https://bugs.openjdk.org/browse/JDK-8190331 The graphic of the checkbox of a CheckBoxTreeItem is not set correctly on the new CheckBox that is provided with the cell when virtual flow switches it. It might happen with other controls that use virtual flow. On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth wrote: > This seems related, but somewhat tangential. A Control's "graphic" isn't > a child node, just like a Shape's "clip" isn't a child node. > > Creating a separate "document graph" (or "logical graph") sounds like an > interesting idea, but it would bring its own set of challenges. And it > wouldn't directly solve this case anyway. > > -- Kevin > > > On 12/1/2022 9:42 AM, Michael Strau? wrote: > > There's a larger picture here: from a user perspective, there's a > > difference between the scene graph and the "document graph". > > The document graph is what users actually work with, for example by > > setting the `Labeled.graphic` property. In some cases, document nodes > > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to > > mind). > > The document graph is later inflated into a scene graph of unknown > > structure (because skins are mostly black boxes with regards to their > > internal structure). > > > > I've proposed an enhancement that would make the document graph a > > first-class citizen: > > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html > > > > With this in place, we could simply disallow the same node appearing > > multiple times in the document graph, which would not only solve the > > problem for `Labeled`, but for all controls with a similar problem. > > > > > > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx > wrote: > >> The mechanism does seem like it is a bit poorly designed, as it is easy > to create inconsistencies. > >> > >> Luckily it seems that you can't remove a graphic yourself from a > Control (getChildren is protected). > >> > >> I don't think there is an easy solution though... > >> > >> I think that once you set a graphic on a Labeled, you need to somehow > mark it as "in use". Normally you could just check parent != null for > this, but it is trickier than that. The Skin ultimately determines if it > adds the graphic as child, which may be delayed or may even be disabled > (content display property is set to showing TEXT only). > >> > >> Perhaps Skins should always add the graphic and just hide it (visible > false, managed false), but that's going to be hard to enforce. > >> > >> Marking the graphic as "in use" could be done with: > >> > >> - a property in `getProperties` > >> - a new "owner" or "ownedBy" property > >> - allowing "parent" to be set without adding it to children (probably > going to mess up stuff) > >> > >> --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Dec 1 19:03:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 19:03:10 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Thu, 1 Dec 2022 17:38:01 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Node > > - Fixed javadoc > - Added comment for code that avoid eager instantiation > - Changed `isShown` to use property if it is available looking good! ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/830 From nlisker at gmail.com Thu Dec 1 19:26:18 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 21:26:18 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: Michael's idea could solve the problem if it's about more than just traversing, it needs to set rules for allowing a node to serve only 1 logical role (or 1 role type, like clip and graphic?) at the same time. In any case, these rules need to be decided upon before starting to work on anything. I can do a quick fix for now that can be reverted later if needed. From what I gather, I will need to add a graphicsParent field like clipParent does. On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote: > By the way, these issues are caused by this inconsistent behavior (they > are probably duplicates): > > https://bugs.openjdk.org/browse/JDK-8209017 > https://bugs.openjdk.org/browse/JDK-8190331 > > The graphic of the checkbox of a CheckBoxTreeItem is not set correctly on > the new CheckBox that is provided with the cell when virtual flow switches > it. It might happen with other controls that use virtual flow. > > On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth > wrote: > >> This seems related, but somewhat tangential. A Control's "graphic" isn't >> a child node, just like a Shape's "clip" isn't a child node. >> >> Creating a separate "document graph" (or "logical graph") sounds like an >> interesting idea, but it would bring its own set of challenges. And it >> wouldn't directly solve this case anyway. >> >> -- Kevin >> >> >> On 12/1/2022 9:42 AM, Michael Strau? wrote: >> > There's a larger picture here: from a user perspective, there's a >> > difference between the scene graph and the "document graph". >> > The document graph is what users actually work with, for example by >> > setting the `Labeled.graphic` property. In some cases, document nodes >> > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to >> > mind). >> > The document graph is later inflated into a scene graph of unknown >> > structure (because skins are mostly black boxes with regards to their >> > internal structure). >> > >> > I've proposed an enhancement that would make the document graph a >> > first-class citizen: >> > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html >> > >> > With this in place, we could simply disallow the same node appearing >> > multiple times in the document graph, which would not only solve the >> > problem for `Labeled`, but for all controls with a similar problem. >> > >> > >> > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx >> wrote: >> >> The mechanism does seem like it is a bit poorly designed, as it is >> easy to create inconsistencies. >> >> >> >> Luckily it seems that you can't remove a graphic yourself from a >> Control (getChildren is protected). >> >> >> >> I don't think there is an easy solution though... >> >> >> >> I think that once you set a graphic on a Labeled, you need to somehow >> mark it as "in use". Normally you could just check parent != null for >> this, but it is trickier than that. The Skin ultimately determines if it >> adds the graphic as child, which may be delayed or may even be disabled >> (content display property is set to showing TEXT only). >> >> >> >> Perhaps Skins should always add the graphic and just hide it (visible >> false, managed false), but that's going to be hard to enforce. >> >> >> >> Marking the graphic as "in use" could be done with: >> >> >> >> - a property in `getProperties` >> >> - a new "owner" or "ownedBy" property >> >> - allowing "parent" to be set without adding it to children (probably >> going to mess up stuff) >> >> >> >> --John >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Dec 1 19:43:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 19:43:47 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 17:53:32 GMT, John Hendrikx wrote: >> my version does not create extra object(s). > > Hm, I thought that the number of objects created is the same, either a `ChangeListener` is created and then wrapped in `ChLi` or a `Consumer` is created and wrapped in `ChLi`. yes, you are right (I was thinking of some earlier version of LH). thanks! ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 19:51:44 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 19:51:44 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 17:48:59 GMT, John Hendrikx wrote: >> You are right: some weak listeners remain, I did not want to re-write the whole thing for a fear of introducing regression and to keep the changes to a minimum. >> >> The second `ListenerHelper` (line 293) gets disconnected in dispose(), or when the skin is collected (since the skin may not be explicitly uninstalled, but instead the whole component or `Pane` might be removed from the scene and discarded. > >> but instead the whole component or Pane might be removed from the scene and discarded. > > If that happens, weak reference won't make a difference there either. Removing an entire branch from the Scene and not referring to it anymore will do correct clean-up even without a call to dispose and without the use of weak references. > > The only use case I see is that we still don't trust the Skin lifecycle to be adhered to and "just in case" are using weak references in case somehow dispose is not called. I would much prefer to see an actual reason to use it, and then adding a comment as to why this weak reference is needed so that in 6 months time we're not scratching our heads as to why a weak reference is needed here. just to be sure, which weak listener are you referring to? ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 19:55:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 19:55:33 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v18] In-Reply-To: References: Message-ID: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294589: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/906/files - new: https://git.openjdk.org/jfx/pull/906/files/b51db815..cbcc17e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From john.hendrikx at gmail.com Thu Dec 1 21:41:00 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 1 Dec 2022 22:41:00 +0100 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: Adding another field doesn't seem ideal, would it be possible to generalize the clipParent field to function for both (the ownedBy or owner field that I suggested earlier)? --John On 01/12/2022 20:26, Nir Lisker wrote: > Michael's idea could solve?the problem if it's about more than just > traversing, it needs to set rules for allowing a node to serve only 1 > logical role (or 1 role type, like clip and graphic?) at the > same?time. In any case, these rules need to be decided upon before > starting to work on anything. I can do a quick fix for now that can be > reverted later if?needed. From what I gather, I will need to add a > graphicsParent field like clipParent does. > > On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote: > > By the way, these issues are caused by this inconsistent behavior > (they are probably duplicates): > > https://bugs.openjdk.org/browse/JDK-8209017 > https://bugs.openjdk.org/browse/JDK-8190331 > > The graphic of the checkbox of a CheckBoxTreeItem is not set > correctly on the new CheckBox that is provided with the cell when > virtual flow switches it. It might happen with other controls that > use virtual flow. > > On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth > wrote: > > This seems related, but somewhat tangential. A Control's > "graphic" isn't > a child node, just like a Shape's "clip" isn't a child node. > > Creating a separate "document graph" (or "logical graph") > sounds like an > interesting idea, but it would bring its own set of > challenges. And it > wouldn't directly solve this case anyway. > > -- Kevin > > > On 12/1/2022 9:42 AM, Michael Strau? wrote: > > There's a larger picture here: from a user perspective, > there's a > > difference between the scene graph and the "document graph". > > The document graph is what users actually work with, for > example by > > setting the `Labeled.graphic` property. In some cases, > document nodes > > don't correspond to scene nodes at all (`MenuItem` or `Tab` > come to > > mind). > > The document graph is later inflated into a scene graph of > unknown > > structure (because skins are mostly black boxes with regards > to their > > internal structure). > > > > I've proposed an enhancement that would make the document > graph a > > first-class citizen: > > > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html > > > > With this in place, we could simply disallow the same node > appearing > > multiple times in the document graph, which would not only > solve the > > problem for `Labeled`, but for all controls with a similar > problem. > > > > > > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx > wrote: > >> The mechanism does seem like it is a bit poorly designed, > as it is easy to create inconsistencies. > >> > >> Luckily it seems that you can't remove a graphic yourself > from a Control (getChildren is protected). > >> > >> I don't think there is an easy solution though... > >> > >> I think that once you set a graphic on a Labeled, you need > to somehow mark it as "in use".? Normally you could just check > parent != null for this, but it is trickier than that.? The > Skin ultimately determines if it adds the graphic as child, > which may be delayed or may even be disabled (content display > property is set to showing TEXT only). > >> > >> Perhaps Skins should always add the graphic and just hide > it (visible false, managed false), but that's going to be hard > to enforce. > >> > >> Marking the graphic as "in use" could be done with: > >> > >> - a property in `getProperties` > >> - a new "owner" or "ownedBy" property > >> - allowing "parent" to be set without adding it to children > (probably going to mess up stuff) > >> > >> --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Dec 1 21:53:58 2022 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 1 Dec 2022 23:53:58 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: Are we convinced that a node can't be both a graphic and a clip, or something else? The docs for clip specify that the node is not a child in the scenegraph. On Thu, Dec 1, 2022 at 11:41 PM John Hendrikx wrote: > Adding another field doesn't seem ideal, would it be possible to > generalize the clipParent field to function for both (the ownedBy or owner > field that I suggested earlier)? > > --John > On 01/12/2022 20:26, Nir Lisker wrote: > > Michael's idea could solve the problem if it's about more than just > traversing, it needs to set rules for allowing a node to serve only 1 > logical role (or 1 role type, like clip and graphic?) at the same time. In > any case, these rules need to be decided upon before starting to work on > anything. I can do a quick fix for now that can be reverted later > if needed. From what I gather, I will need to add a graphicsParent field > like clipParent does. > > On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote: > >> By the way, these issues are caused by this inconsistent behavior (they >> are probably duplicates): >> >> https://bugs.openjdk.org/browse/JDK-8209017 >> https://bugs.openjdk.org/browse/JDK-8190331 >> >> The graphic of the checkbox of a CheckBoxTreeItem is not set correctly on >> the new CheckBox that is provided with the cell when virtual flow switches >> it. It might happen with other controls that use virtual flow. >> >> On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> This seems related, but somewhat tangential. A Control's "graphic" isn't >>> a child node, just like a Shape's "clip" isn't a child node. >>> >>> Creating a separate "document graph" (or "logical graph") sounds like an >>> interesting idea, but it would bring its own set of challenges. And it >>> wouldn't directly solve this case anyway. >>> >>> -- Kevin >>> >>> >>> On 12/1/2022 9:42 AM, Michael Strau? wrote: >>> > There's a larger picture here: from a user perspective, there's a >>> > difference between the scene graph and the "document graph". >>> > The document graph is what users actually work with, for example by >>> > setting the `Labeled.graphic` property. In some cases, document nodes >>> > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to >>> > mind). >>> > The document graph is later inflated into a scene graph of unknown >>> > structure (because skins are mostly black boxes with regards to their >>> > internal structure). >>> > >>> > I've proposed an enhancement that would make the document graph a >>> > first-class citizen: >>> > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html >>> > >>> > With this in place, we could simply disallow the same node appearing >>> > multiple times in the document graph, which would not only solve the >>> > problem for `Labeled`, but for all controls with a similar problem. >>> > >>> > >>> > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx >>> wrote: >>> >> The mechanism does seem like it is a bit poorly designed, as it is >>> easy to create inconsistencies. >>> >> >>> >> Luckily it seems that you can't remove a graphic yourself from a >>> Control (getChildren is protected). >>> >> >>> >> I don't think there is an easy solution though... >>> >> >>> >> I think that once you set a graphic on a Labeled, you need to somehow >>> mark it as "in use". Normally you could just check parent != null for >>> this, but it is trickier than that. The Skin ultimately determines if it >>> adds the graphic as child, which may be delayed or may even be disabled >>> (content display property is set to showing TEXT only). >>> >> >>> >> Perhaps Skins should always add the graphic and just hide it (visible >>> false, managed false), but that's going to be hard to enforce. >>> >> >>> >> Marking the graphic as "in use" could be done with: >>> >> >>> >> - a property in `getProperties` >>> >> - a new "owner" or "ownedBy" property >>> >> - allowing "parent" to be set without adding it to children (probably >>> going to mess up stuff) >>> >> >>> >> --John >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Thu Dec 1 23:03:19 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 1 Dec 2022 23:03:19 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: References: Message-ID: <7ia-LxabbcCms3yg2ZbHijvpKN--zMwCBND0EiEnjjk=.6c33c67a-3a2a-40b2-ac1a-38461f9a5e65@github.com> On Thu, 1 Dec 2022 19:47:52 GMT, Andy Goryachev wrote: >>> but instead the whole component or Pane might be removed from the scene and discarded. >> >> If that happens, weak reference won't make a difference there either. Removing an entire branch from the Scene and not referring to it anymore will do correct clean-up even without a call to dispose and without the use of weak references. >> >> The only use case I see is that we still don't trust the Skin lifecycle to be adhered to and "just in case" are using weak references in case somehow dispose is not called. I would much prefer to see an actual reason to use it, and then adding a comment as to why this weak reference is needed so that in 6 months time we're not scratching our heads as to why a weak reference is needed here. > > just to be sure, which weak listener are you referring to? I didn't mean a weak listener, but a weak reference. This line creates one: sceneListenerHelper = new ListenerHelper(MenuBarSkin.this); I think a plain `new ListenerHelper()` would work correct here. If you don't think so, I think it may be good to add a comment why the weak reference is needed to make the clean up work correctly. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 23:33:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 23:33:47 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v15] In-Reply-To: <7ia-LxabbcCms3yg2ZbHijvpKN--zMwCBND0EiEnjjk=.6c33c67a-3a2a-40b2-ac1a-38461f9a5e65@github.com> References: <7ia-LxabbcCms3yg2ZbHijvpKN--zMwCBND0EiEnjjk=.6c33c67a-3a2a-40b2-ac1a-38461f9a5e65@github.com> Message-ID: On Thu, 1 Dec 2022 22:45:20 GMT, John Hendrikx wrote: >> just to be sure, which weak listener are you referring to? > > I didn't mean a weak listener, but a weak reference. This line creates one: > > sceneListenerHelper = new ListenerHelper(MenuBarSkin.this); > > I think a plain `new ListenerHelper()` would work correct here. If you don't think so, I think it may be good to add a comment why the weak reference is needed to make the clean up work correctly. I have to agree with you - it is not needed in this case. The reason I put it there was "what if Stage.hide() gets called and the whole thing disappears, perhaps we want to make sure that all listeners that were registered via `sceneListenerHelper` get disconnected. The thing is, all these listeners are registered against the scene belonging to that stage, so we are ok. ------------- PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 23:39:08 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 23:39:08 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v19] In-Reply-To: References: Message-ID: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294589: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/906/files - new: https://git.openjdk.org/jfx/pull/906/files/cbcc17e7..693667a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Thu Dec 1 23:39:10 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 1 Dec 2022 23:39:10 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v18] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 19:55:33 GMT, Andy Goryachev wrote: >> Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). >> >> This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. >> See https://github.com/openjdk/jfx/pull/908 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8294589: review comments @aghaisas : would you please take a look? ------------- PR: https://git.openjdk.org/jfx/pull/906 From jhendrikx at openjdk.org Fri Dec 2 00:35:36 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 00:35:36 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v19] In-Reply-To: References: <-fRb-TJPTUO5ij6EL-UStAi2L_LTU8CYm8SlyygSJT4=.e89a3a0c-fe65-4190-bcee-92e02a632050@github.com> Message-ID: <_5PplfwBw8_E9gZiYYTVjxkU3iworCSC2c-sYFvG8Qw=.b8920d5f-4825-4acb-9ab8-35c07aeb2f17@github.com> On Tue, 11 Oct 2022 18:50:54 GMT, Andy Goryachev wrote: >>> You are right, @kleopatra - this executeOnceWhenPropertyIsNonNull() is installing a listener. perhaps we should add a similar functionality to LambdaMultiplePropertyChangeListenerHandler and actually install a WeakListener instead. >> >> - yes, we need weakListeners (to wait for a not-null value to add the event handler) _and_ remove both the weakListener and the event handlers in dispose >> - adding functionality to the LambdaHandler sounds like a good idea, but needs some thinking and should be done in a separate issue which also adds delegate methods to expose the new functionality in SkinBase for use in sub classes >> >> For this issue, you might simply inline the utility method and register the listeners using skinbase api (didn't try, it's your issue :), see TableRowSkin for a similar pattern >> >> This conditional adding of handlers/listeners is needed if we have to support path properties (also f.i. when listening to selectedXX in any of the skins with selectionModels as properties). Which basically should be supported by base - but probably without any chance to ever get them ;) > > ListenerHelper - replacement for LambdaMultiplePropertyChangeListenerHandler . > Please take a look at https://github.com/openjdk/jfx/pull/908 > Sure, but I think this should be done with a clear vision of where we're going, and not just as a collection of ad-hoc helper methods. There are even more problems that a new API should at least consider: Some skins change their behavior depending on the configuration of their associated control at the time when the skin is installed. For example, `MenuButtonSkinBase` adds a `MOUSE_PRESSED` handler only if the control didn't specify one for its onMousePressed property: > > ``` > if (control.getOnMousePressed() == null) { > control.addEventHandler(MouseEvent.MOUSE_PRESSED, ... > ``` > > But what happens if the `onMousePressed` property is set after the skin is installed? Rather than a one-time check, cases like these should probably be a dynamic expression: > > ``` > when control.onMousePressedProperty().isNotNull() and skin.isInstalled() > control.addEventHandler > otherwise > control.removeEventHandler > ``` I think you meant `isNull()` instead of `isNotNull()`: when control.onMousePressedProperty().isNull() and skin.isInstalled() control.addEventHandler otherwise control.removeEventHandler So... I was curious, and was checking to see if this can be done with fluent bindings these days, and I can get quite close. First assume we have a convenient property in all skins (or everything that is `SkinBase`) that reflects whether or not the skin is currently installed or active: BooleanProperty installed = new SimpleBooleanProperty(); You can then create a condition: ObservableValue noMouseAndInstalled = installed .flatMap(b -> b ? control.onMousePressedProperty() : installed) .map(x -> false) // ---+ use case for isNotEmpty .orElse(true); // --/ Or (if `isNotEmpty` already exists): ObservableValue noMouseAndInstalled = installed .flatMap(b -> b ? control.onMousePressedProperty() : installed) .isNotEmpty(); It's then a simple matter of adding a listener to this result to either add or remove the event handler: installed .flatMap(b -> b ? control.onMousePressedProperty() : installed) .isNotEmpty(); .addListener((obs, old, active) -> { if(active) control.addEventHandler(...); else control.removeEventHandler(...); }); One of the nice things here is that when `installed` is `false`, the listener on `control.onMousePressedProperty()` is automatically removed. This is because the `flatMap` will switch to listening to `installed`. This should mean that it will automatically be eligible for GC when `installed` becomes `false`. The second nice thing is that you can do this in the constructor already, no need to do this in the `install` callback. If you do it in the callback, then make sure to do it before `installed` is set to `true` as otherwise the change listener won't fire for the first change (another reason to have value listeners...) If this becomes a common idiom, we could introduce a short circuiting `and` construct so the `flatMap` can be expressed easier (the short circuiting part will ensure the onMousePressedProperty won't be observed if installed is `false`): installed .and(control.onMousePressedProperty().isNotEmpty()) .addListener( ... ); ------------- PR: https://git.openjdk.org/jfx/pull/906 From kcr at openjdk.org Fri Dec 2 00:37:59 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 2 Dec 2022 00:37:59 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Thu, 1 Dec 2022 17:38:01 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Node > > - Fixed javadoc > - Added comment for code that avoid eager instantiation > - Changed `isShown` to use property if it is available The API and docs for `ObservableValue::when` look like they are in good shape, so I'll review them next week. My only overall comment is that this PR should be limited to the new API, implementation, and tests in `javafx.base`. Although it's helpful to review them together, the changes to `Node` to add a new `shown` property is an interesting use case that should stand on its own merits and should be done as a follow-on Enhancement in a separate PR. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 00:44:10 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 00:44:10 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 2 Dec 2022 00:34:35 GMT, Kevin Rushforth wrote: > The API and docs for `ObservableValue::when` look like they are in good shape, so I'll review them next week. > > My only overall comment is that this PR should be limited to the new API, implementation, and tests in `javafx.base`. Although it's helpful to review them together, the changes to `Node` to add a new `shown` property is an interesting use case that should stand on its own merits and should be done as a follow-on Enhancement in a separate PR. Okay, that would mean removing the examples from `when` that use the `shownProperty`, and I suppose adding them back in later. The ticket was specifically worded to make it easier to deterministically manage listeners, which at least for UI controls, the `shown` property is an important part of. If you think its realistic, I can file a new ticket, split it off so hopefully both can be part of the same release? ------------- PR: https://git.openjdk.org/jfx/pull/830 From tsayao at openjdk.org Fri Dec 2 00:44:59 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 2 Dec 2022 00:44:59 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Tue, 22 Nov 2022 01:40:02 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix View position Those iconify tests always fails for me, but it works testing manually. About the focus, `gtk_window_present` might have changed between releases, I will investigate. ------------- PR: https://git.openjdk.org/jfx/pull/915 From mstrauss at openjdk.org Fri Dec 2 01:24:37 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Dec 2022 01:24:37 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Thu, 1 Dec 2022 17:38:01 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Node > > - Fixed javadoc > - Added comment for code that avoid eager instantiation > - Changed `isShown` to use property if it is available modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1413: > 1411: * Indicates whether or not this {@code Node} is shown. A node is considered shown if it's > 1412: * part of a {@code Scene} that is part of a {@code Window} whose > 1413: * {@link Window#showingProperty showing property} is {@code true}. The {@link Node#visibleProperty visibility} I think you should choose one of the following: `...whose {@link Window#showingProperty} is...` `...whose {@link Window#showingProperty showing} property is...` modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420: > 1418: *

> 1419: * This property can also be used to start animations when the node is shown, and to stop them > 1420: * when it is no longer shown. This sentence sounds like `shownProperty()` is quite deeply connected to animations, which it isn't. Maybe you can clarify with "For example, ..."? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1437: > 1435: } > 1436: > 1437: public final ReadOnlyBooleanProperty shownProperty() { This property probably should have been named `showing` to align it with `Window.showing`, but the "good name" is already taken by `ComboBox` and other controls. Just out of interest, have you considered alternatives to `shown`? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1443: > 1441: .flatMap(Window::showingProperty); // note: the null case is handled by the delegate with an orElse(false) > 1442: > 1443: shown = new ReadOnlyBooleanDelegate(Node.this, "shown", ov); `shownProperty()` might be used quite a lot, have you considered using a specialized implementation that doesn't need several intermediate observable values? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1453: > 1451: private final ObservableValue delegate; > 1452: private final Object bean; > 1453: private final String name; You could omit the `bean` and `name` fields by making this a non-static inner class and returning `Node.this` and `"shown"` directly from `getBean()` and `getName()` respectively. In that case, you could also make this class an anonymous implementation of `ReadOnlyBooleanProperty`. This pattern is used quite extensively in JavaFX, since it can potentially save a few bytes of memory. ------------- PR: https://git.openjdk.org/jfx/pull/830 From duke at openjdk.org Fri Dec 2 05:29:55 2022 From: duke at openjdk.org (Karthik P K) Date: Fri, 2 Dec 2022 05:29:55 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true Message-ID: Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). Fix: Initialized dragStart in initialize method. Test: Added system test to validate the fix. Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. ------------- Commit messages: - Correct file permissions - Correct line endings - Merge branch 'master' into slider_npe_fix - SliderSkin NPE fix Changes: https://git.openjdk.org/jfx/pull/965/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8190411 Stats: 152 lines in 2 files changed: 152 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From arapte at openjdk.org Fri Dec 2 06:50:40 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 2 Dec 2022 06:50:40 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 17:03:03 GMT, Karthik P K wrote: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Providing few quick comments about the test. tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 78: > 76: } > 77: } > 78: `main()` method is not required, can be removed. tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 84: > 82: } > 83: > 84: private void dragSliderAfterTooltipDisplayed(int dragDistance, boolean xIncr) throws Throwable { `boolean xIncr` is not required for the test. It can be removed along with it's use on line 101. tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 89: > 87: Util.runAndWait(() -> { > 88: robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + SCENE_WIDTH/2), > 89: (int)(scene.getWindow().getY() + scene.getY() + SCENE_HEIGHT/2)); The x and y position calculation should consider the sliders layout as well. I think it should be as: robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + slider.getLayoutX() + slider.getLayoutBounds().getWidth()/2), (int)(scene.getWindow().getY() + scene.getY() + slider.getLayoutY() + slider.getLayoutBounds().getHeight()/2)); and similar change on line 102. Line 105 would get removed when removing `xIncr` tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 92: > 90: }); > 91: > 92: Thread.sleep(3000); // Wait for tooltip to be displayed This `sleep` can be removed, The sleep of 1000 ms on line 85 should be sufficient. I ran by removing this sleep on Mac, Test ran well. Please check on other platforms. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/965 From jhendrikx at openjdk.org Fri Dec 2 08:56:38 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 08:56:38 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 2 Dec 2022 01:06:16 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1443: > >> 1441: .flatMap(Window::showingProperty); // note: the null case is handled by the delegate with an orElse(false) >> 1442: >> 1443: shown = new ReadOnlyBooleanDelegate(Node.this, "shown", ov); > > `shownProperty()` might be used quite a lot, have you considered using a specialized implementation that doesn't need several intermediate observable values? I think that this is already optimized enough by being lazily instantiated (ie. it won't be created if never used). As a second layer, these are fluent bindings which only register listeners when observed. Creating a specialized implementation should IMHO replicate the lazy behavior (to avoid too many listeners on window/scene when the property isn't actually observed) which is non-trivial and would require an extensive test. This risks creating bugs now (or later) of which there have been quite a few with similar custom properties -- it's easy to accidentally cache an "old" value or forgetting to clear a cached "current" value when invalidated. In short, I think optimized custom implementations have been and still are a source of bugs, with no evidence that these optimizations are worth while.. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 09:14:26 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:14:26 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <32YM9KHyKM__0IR_RPK0fLTcV5yhv-ltnTJ8Iuw_EA8=.ce22a6b8-34bf-415f-9c22-bf2b0a8859e4@github.com> On Fri, 2 Dec 2022 01:22:01 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1437: > >> 1435: } >> 1436: >> 1437: public final ReadOnlyBooleanProperty shownProperty() { > > This property probably should have been named `showing` to align it with `Window.showing`, but the "good name" is already taken by `ComboBox` and other controls. Just out of interest, have you considered alternatives to `shown`? I didn't look too far for alternative names after I discovered `showing` would not be possible. The name comes from `isTreeShowing` which is used for a similar purpose (inside `Node`) and from `conditionOnShowing` in ReactFX. The name needs to imply that visibility has no effect on it (ie, `setVisible(false)` won't toggle it). Neither does it check if the node isn't covered or off screen. In theory you could use a more general name (like `active` as in "part of an active currently showing scene graph"). `isActive` seems to even be available... A name like "used" or "inUse" may also work (as in "indicates the node is currently used as part of a currently showing scene graph". ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 09:14:27 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:14:27 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: <32YM9KHyKM__0IR_RPK0fLTcV5yhv-ltnTJ8Iuw_EA8=.ce22a6b8-34bf-415f-9c22-bf2b0a8859e4@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <32YM9KHyKM__0IR_RPK0fLTcV5yhv-ltnTJ8Iuw_EA8=.ce22a6b8-34bf-415f-9c22-bf2b0a8859e4@github.com> Message-ID: On Fri, 2 Dec 2022 09:08:36 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1437: >> >>> 1435: } >>> 1436: >>> 1437: public final ReadOnlyBooleanProperty shownProperty() { >> >> This property probably should have been named `showing` to align it with `Window.showing`, but the "good name" is already taken by `ComboBox` and other controls. Just out of interest, have you considered alternatives to `shown`? > > I didn't look too far for alternative names after I discovered `showing` would not be possible. The name comes from `isTreeShowing` which is used for a similar purpose (inside `Node`) and from `conditionOnShowing` in ReactFX. > > The name needs to imply that visibility has no effect on it (ie, `setVisible(false)` won't toggle it). Neither does it check if the node isn't covered or off screen. > > In theory you could use a more general name (like `active` as in "part of an active currently showing scene graph"). `isActive` seems to even be available... > > A name like "used" or "inUse" may also work (as in "indicates the node is currently used as part of a currently showing scene graph". That reminds me... `parent` is described as: > The parent of this {@code Node}. If this {@code Node} has not been added to a scene graph, then parent will be null. Which I think is incorrect; parent can easily be non-null while not being part of a scene graph. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 09:19:57 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:19:57 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 2 Dec 2022 01:13:13 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1420: > >> 1418: *

>> 1419: * This property can also be used to start animations when the node is shown, and to stop them >> 1420: * when it is no longer shown. > > This sentence sounds like `shownProperty()` is quite deeply connected to animations, which it isn't. Maybe you can clarify with "For example, ..."? I find it reads really weird when I just make it an example (without putting a code example below it); I only added these to indicate possible use cases. Perhaps if I rephrase it to "This property can also be useful to perform actions when the node is shown or no longer shown, like starting and stopping animations". ------------- PR: https://git.openjdk.org/jfx/pull/830 From aghaisas at openjdk.org Fri Dec 2 09:46:20 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 2 Dec 2022 09:46:20 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 17:09:50 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 164) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.ACCORDION; >> >> >> caused by: >> - adding and not removing listeners > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - 8295500: cleanup > - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin > - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin > - 8295500: cleanup > - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - 8294809: is alive > - Merge branch '8294809.listener.helper' into 8295500.accordion.skin > - ... and 19 more: https://git.openjdk.org/jfx/compare/4a19fe71...8da3b64f Looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/920 From jhendrikx at openjdk.org Fri Dec 2 09:52:38 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:52:38 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <4PDNQsoVM9Qvl_FuWwPj4Aa--A6fKu0YGc2ZtK7Ccwc=.7c7f3d3f-90bd-4679-bf8e-6e2bfe6d06c1@github.com> On Thu, 1 Dec 2022 22:23:20 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1453: > >> 1451: private final ObservableValue delegate; >> 1452: private final Object bean; >> 1453: private final String name; > > You could omit the `bean` and `name` fields by making this a non-static inner class and returning `Node.this` and `"shown"` directly from `getBean()` and `getName()` respectively. In that case, you could also make this class an anonymous implementation of `ReadOnlyBooleanProperty`. This pattern is used quite extensively in JavaFX, since it can potentially save a few bytes of memory. I don't mind changing it, but I should point out, it is already lazily created. Once it does get created, you would save 8 bytes in the best case (assuming alignment is 8 bytes). ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 09:56:42 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:56:42 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Improve wording in javadoc and comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/5c22fdd0..67c277cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=08-09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Fri Dec 2 09:56:44 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 2 Dec 2022 09:56:44 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 2 Dec 2022 01:10:13 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1413: > >> 1411: * Indicates whether or not this {@code Node} is shown. A node is considered shown if it's >> 1412: * part of a {@code Scene} that is part of a {@code Window} whose >> 1413: * {@link Window#showingProperty showing property} is {@code true}. The {@link Node#visibleProperty visibility} > > I think you should choose one of the following: > `...whose {@link Window#showingProperty} is...` > `...whose {@link Window#showingProperty showing} property is...` Updated to second variant ------------- PR: https://git.openjdk.org/jfx/pull/830 From aghaisas at openjdk.org Fri Dec 2 10:02:23 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 2 Dec 2022 10:02:23 GMT Subject: RFR: 8295506: ButtonBarSkin: memory leak when changing skin [v3] In-Reply-To: <_pIyjdN5WyUZ2sNjaGwF_2KwHsENVVXRneU0A7-BF24=.97344ea6-7c01-444a-97fe-ed7b36fe690a@github.com> References: <_pIyjdN5WyUZ2sNjaGwF_2KwHsENVVXRneU0A7-BF24=.97344ea6-7c01-444a-97fe-ed7b36fe690a@github.com> Message-ID: On Thu, 1 Dec 2022 17:16:36 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 165) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.BUTTON_BAR; >> >> >> caused by: >> - adding and not removing listeners >> - adding and not removing children Nodes > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - 8295506: cleanup > - Merge remote-tracking branch 'origin/master' into 8295506.button.bar.skin > - Merge remote-tracking branch 'origin/master' into > 8295506.button.bar.skin > - Merge remote-tracking branch 'origin/master' into > 8295506.button.bar.skin > - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295506.button.bar.skin > - 8294809: is alive > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - 8295506: button bar skin > - ... and 15 more: https://git.openjdk.org/jfx/compare/4a19fe71...efc60c0c Looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/921 From duke at openjdk.org Fri Dec 2 11:11:58 2022 From: duke at openjdk.org (Karthik P K) Date: Fri, 2 Dec 2022 11:11:58 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v2] In-Reply-To: References: Message-ID: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/965/files - new: https://git.openjdk.org/jfx/pull/965/files/289fda52..86e7823c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=00-01 Stats: 62 lines in 1 file changed: 23 ins; 25 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From duke at openjdk.org Fri Dec 2 11:13:36 2022 From: duke at openjdk.org (Karthik P K) Date: Fri, 2 Dec 2022 11:13:36 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v2] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 06:47:41 GMT, Ambarish Rapte wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Providing few quick comments about the test. @arapte , Addressed review comments and added CountDownLatch for tooltip display as discussed. ------------- PR: https://git.openjdk.org/jfx/pull/965 From fkirmaier at openjdk.org Fri Dec 2 11:47:35 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 2 Dec 2022 11:47:35 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. Honestly, the idea of removing the Maven build horrifies me. This would basically force me (and probably many others) to maintain a forked build script. As long as people are willing to maintain the Gradle+MavenBuild it would be a shame if they wouldn't get the opportunity to do so. I'm still wondering what is even the alternative, to the MavenBuild. Create manually pom files by hand? Only using JDK. with bundled JFX? (Which oracle kind of killed in the past) So please give the other users to maintain this. ------------- PR: https://git.openjdk.org/jfx/pull/657 From arapte at openjdk.org Fri Dec 2 13:14:33 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 2 Dec 2022 13:14:33 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v2] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 11:11:58 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 346: > 344: thumb.getStyleClass().setAll("thumb"); > 345: thumb.setAccessibleRole(AccessibleRole.THUMB); > 346: dragStart = new Point2D(thumb.getLayoutX(), thumb.getLayoutY()); `dragStart` should be the exact mouse position where mouse pressed has occurred. With this change mouse gets moved to the layout X, Y position of thumb, even though the mouse press occurred at any other location inside the thumb. ------------- PR: https://git.openjdk.org/jfx/pull/965 From duke at openjdk.org Fri Dec 2 13:44:25 2022 From: duke at openjdk.org (Karthik P K) Date: Fri, 2 Dec 2022 13:44:25 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v2] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 13:10:37 GMT, Ambarish Rapte wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 346: > >> 344: thumb.getStyleClass().setAll("thumb"); >> 345: thumb.setAccessibleRole(AccessibleRole.THUMB); >> 346: dragStart = new Point2D(thumb.getLayoutX(), thumb.getLayoutY()); > > `dragStart` should be the exact mouse position where mouse pressed has occurred. > With this change mouse gets moved to the layout X, Y position of thumb, even though the mouse press occurred at any other location inside the thumb. This change makes sure that `dragStart` is not null when `setOnMouseDragged `event handler is called. As suggested in the issue, I tried to initialize `dragStart` in `layoutChildren` method but it was causing side effects. I checked for other event handlers such as `onDragDetected` and `onMouseDragEntered`, but none of these event handlers were invoked. Looks like these events are also consumed by tooltip similar to how it consumes `setOnMousePressed`. I haven't seen above mentioned side effect while checking the fix. I will check again. ------------- PR: https://git.openjdk.org/jfx/pull/965 From nlisker at openjdk.org Fri Dec 2 13:45:26 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 2 Dec 2022 13:45:26 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v9] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <32YM9KHyKM__0IR_RPK0fLTcV5yhv-ltnTJ8Iuw_EA8=.ce22a6b8-34bf-415f-9c22-bf2b0a8859e4@github.com> Message-ID: <4AixR7IC3qAd511ro6CYHLN0bGU9Q4Rmr-Fo9x5vdLQ=.edf425c4-8a0c-4d25-91a5-1c7a413969a8@github.com> On Fri, 2 Dec 2022 09:10:34 GMT, John Hendrikx wrote: >> I didn't look too far for alternative names after I discovered `showing` would not be possible. The name comes from `isTreeShowing` which is used for a similar purpose (inside `Node`) and from `conditionOnShowing` in ReactFX. >> >> The name needs to imply that visibility has no effect on it (ie, `setVisible(false)` won't toggle it). Neither does it check if the node isn't covered or off screen. >> >> In theory you could use a more general name (like `active` as in "part of an active currently showing scene graph"). `isActive` seems to even be available... >> >> A name like "used" or "inUse" may also work (as in "indicates the node is currently used as part of a currently showing scene graph". > > That reminds me... `parent` is described as: > >> The parent of this {@code Node}. If this {@code Node} has not been added to a scene graph, then parent will be null. > > Which I think is incorrect; parent can easily be non-null while not being part of a scene graph. `displayed`/`displaying`? ------------- PR: https://git.openjdk.org/jfx/pull/830 From jvos at openjdk.org Fri Dec 2 15:55:28 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 2 Dec 2022 15:55:28 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. I think there is some confusion, so let me clarify. My intention was never to remove or stop building the maven artifacts. Those are extremely important and heavily used, and we will keep them, and keep uploading new artifacts (including ea versions) to maven central.?There are also no plans to stop the javafx maven and gradle plugins, so we continue maintaining those. However, I think having the maven build logic (for building OpenJFX artifacts, not for building JavaFX apps with OpenJFX artifacts) inside the same file (build.gradle) as all the build logic for OpenJFX makes things overcomplicated. The build.gradle file in the OpenJFX repository is imho too complex and does too many things. Every line that is added inside this file makes the maintenance of OpenJFX harder.I? personally would like to have an approach similar to OpenJDK, which is more Makefile based and deals with module/platform/architecture specific things in a cleaner?way. However, it would be a huge effort to move from the monolith build.gradle that we currently have towards a system like OpenJDK -- especially since we need to get all testing and all cornercases?100% correct -- so it's not on my personal short-term roadmap. So what I regret is that I wanted to have the artifact build logic inside the monolithic build.gradle file. I believe that was a mistake that we have to fix, and in doing so we can improve the process (e.g. by adding the source builds).?I should have commented on the PR, and I want to apologize (especially to @eduardsdv ) because I failed to do so.? ------------- PR: https://git.openjdk.org/jfx/pull/657 From angorya at openjdk.org Fri Dec 2 16:16:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:16:32 GMT Subject: Integrated: 8295506: ButtonBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: <4mZcJ1yPvYyMOBZMjjiTJ-hrSS9oeQvpgfV-b7B4XZE=.3ec30c85-71ce-4971-8de8-80cbab63b42d@github.com> On Tue, 18 Oct 2022 19:49:45 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 165) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.BUTTON_BAR; > > > caused by: > - adding and not removing listeners > - adding and not removing children Nodes This pull request has now been integrated. Changeset: 6ab65a96 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/6ab65a9625871cc75953575372ac1b672198b2e9 Stats: 30 lines in 2 files changed: 17 ins; 9 del; 4 mod 8295506: ButtonBarSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/921 From angorya at openjdk.org Fri Dec 2 16:34:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:34:59 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v4] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 164) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.ACCORDION; > > > caused by: > - adding and not removing listeners Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - 8295500: cleanup - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - 8295500: cleanup - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin - Merge branch '8294809.listener.helper' into 8295500.accordion.skin - 8294809: generics - Merge branch '8294809.listener.helper' into 8295500.accordion.skin - 8294809: is alive - ... and 20 more: https://git.openjdk.org/jfx/compare/6ab65a96...d930b08f ------------- Changes: https://git.openjdk.org/jfx/pull/920/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=920&range=03 Stats: 31 lines in 2 files changed: 16 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/920.diff Fetch: git fetch https://git.openjdk.org/jfx pull/920/head:pull/920 PR: https://git.openjdk.org/jfx/pull/920 From angorya at openjdk.org Fri Dec 2 16:39:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:39:06 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v20] In-Reply-To: References: Message-ID: <0knah1G8g2iPUbD0BtHa9igNeKNyincWtOMHX4HkOaM=.0afb801b-a50e-4455-9393-008f1649d26d@github.com> > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: review comments - 8294589: review comments - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: review comments - 8294589: cleanup - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: testing github merge-conflict label behavior - 8294589: cleanup - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - ... and 42 more: https://git.openjdk.org/jfx/compare/6ab65a96...4434e5f7 ------------- Changes: https://git.openjdk.org/jfx/pull/906/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=19 Stats: 464 lines in 2 files changed: 234 ins; 199 del; 31 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Fri Dec 2 16:45:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:45:16 GMT Subject: RFR: 8295531: ComboBoxBaseSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 166) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Affected skins: > - ColorPicker > - DatePicker > - ComboBox > > caused by: > - out-of-order modification of the control property (skin.install) > - adding skin nodes and not removing them in dispose() > - adding listeners and not removing them in dispose() > > NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - 8295531: whitespace - 8295531: selection model leak - Merge branch '8294809.listener.helper' into 8295531.color.picker.skin - 8294809: generics - Merge branch '8294809.listener.helper' into 8295531.color.picker.skin - 8294809: is alive - ... and 44 more: https://git.openjdk.org/jfx/compare/6ab65a96...735b2d53 ------------- Changes: https://git.openjdk.org/jfx/pull/922/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=922&range=02 Stats: 185 lines in 6 files changed: 82 ins; 44 del; 59 mod Patch: https://git.openjdk.org/jfx/pull/922.diff Fetch: git fetch https://git.openjdk.org/jfx pull/922/head:pull/922 PR: https://git.openjdk.org/jfx/pull/922 From angorya at openjdk.org Fri Dec 2 16:48:04 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:48:04 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v5] In-Reply-To: References: Message-ID: <1PE9xgDDDe4KaccFmbzMvc0Ia5prDarlLEYDtd3Lyso=.0b5ddde5-e932-4a31-a387-1dc236d681d1@github.com> > as determined by SkinMemoryLeakTest (remove line 164) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.ACCORDION; > > > caused by: > - adding and not removing listeners Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8295500: trying to avoid merge conflicts in the future ------------- Changes: - all: https://git.openjdk.org/jfx/pull/920/files - new: https://git.openjdk.org/jfx/pull/920/files/d930b08f..005ada7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=920&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=920&range=03-04 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/920.diff Fetch: git fetch https://git.openjdk.org/jfx pull/920/head:pull/920 PR: https://git.openjdk.org/jfx/pull/920 From angorya at openjdk.org Fri Dec 2 16:49:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:49:41 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 09:42:33 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: >> >> - 8295500: cleanup >> - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin >> - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin >> - 8295500: cleanup >> - Merge remote-tracking branch 'origin/master' into 8295500.accordion.skin >> - Merge branch '8294809.listener.helper' into 8295500.accordion.skin >> - 8294809: generics >> - Merge branch '8294809.listener.helper' into 8295500.accordion.skin >> - 8294809: is alive >> - Merge branch '8294809.listener.helper' into 8295500.accordion.skin >> - ... and 19 more: https://git.openjdk.org/jfx/compare/4a19fe71...8da3b64f > > Looks good to me! @aghaisas could you please re-review this PR? I've added some extra comments and whitespace hoping that will avoid further merge conflicts. ------------- PR: https://git.openjdk.org/jfx/pull/920 From angorya at openjdk.org Fri Dec 2 16:55:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:55:43 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v21] In-Reply-To: References: Message-ID: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8294589: trying to avoid merge conflicts in the future ------------- Changes: - all: https://git.openjdk.org/jfx/pull/906/files - new: https://git.openjdk.org/jfx/pull/906/files/4434e5f7..b546a15b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=19-20 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Fri Dec 2 16:56:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 16:56:59 GMT Subject: RFR: 8295531: ComboBoxBaseSkin: memory leak when changing skin [v4] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 166) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Affected skins: > - ColorPicker > - DatePicker > - ComboBox > > caused by: > - out-of-order modification of the control property (skin.install) > - adding skin nodes and not removing them in dispose() > - adding listeners and not removing them in dispose() > > NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8295531: trying to avoid merge conflicts in the future ------------- Changes: - all: https://git.openjdk.org/jfx/pull/922/files - new: https://git.openjdk.org/jfx/pull/922/files/735b2d53..968b08cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=922&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=922&range=02-03 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/922.diff Fetch: git fetch https://git.openjdk.org/jfx pull/922/head:pull/922 PR: https://git.openjdk.org/jfx/pull/922 From angorya at openjdk.org Fri Dec 2 17:07:17 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:07:17 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: <8o_XlHkfME3zFnEjmpGAo_cFOBUJzpR2bd4Uz534jKQ=.88b29dbf-c55c-4d56-b842-56cf4c9ba63f@github.com> > Fixed memory leak by removing all the listeners in dispose(); > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: generics - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: is alive - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - Revert "8294809: removed weak listeners support" This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - ... and 18 more: https://git.openjdk.org/jfx/compare/6ab65a96...ffe938ce ------------- Changes: https://git.openjdk.org/jfx/pull/911/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=911&range=02 Stats: 89 lines in 2 files changed: 50 ins; 18 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/911.diff Fetch: git fetch https://git.openjdk.org/jfx pull/911/head:pull/911 PR: https://git.openjdk.org/jfx/pull/911 From aghaisas at openjdk.org Fri Dec 2 17:14:24 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 2 Dec 2022 17:14:24 GMT Subject: RFR: 8295500: AccordionSkin: memory leak when changing skin [v5] In-Reply-To: <1PE9xgDDDe4KaccFmbzMvc0Ia5prDarlLEYDtd3Lyso=.0b5ddde5-e932-4a31-a387-1dc236d681d1@github.com> References: <1PE9xgDDDe4KaccFmbzMvc0Ia5prDarlLEYDtd3Lyso=.0b5ddde5-e932-4a31-a387-1dc236d681d1@github.com> Message-ID: On Fri, 2 Dec 2022 16:48:04 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 164) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Make sure to configure the current test in LeakTest: >> protected final Type WE_ARE_TESTING = Type.ACCORDION; >> >> >> caused by: >> - adding and not removing listeners > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8295500: trying to avoid merge conflicts in the future Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/920 From angorya at openjdk.org Fri Dec 2 17:19:21 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:19:21 GMT Subject: Integrated: 8295500: AccordionSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 18:51:33 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 164) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Make sure to configure the current test in LeakTest: > protected final Type WE_ARE_TESTING = Type.ACCORDION; > > > caused by: > - adding and not removing listeners This pull request has now been integrated. Changeset: e64e1292 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/e64e1292e674cb0f8c525ddde66ee5c4de86cf8d Stats: 47 lines in 2 files changed: 32 ins; 6 del; 9 mod 8295500: AccordionSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/920 From duke at openjdk.org Fri Dec 2 17:22:32 2022 From: duke at openjdk.org (eduardsdv) Date: Fri, 2 Dec 2022 17:22:32 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. Thanks for the clarification and I totally comprehend your point of view. The build file is really big. It was not easy to find the change set to build the sources, in a regular maven build it would be very easy. But I would also like to see a solution for building the sources. How can they be created? How are they created for each release? ------------- PR: https://git.openjdk.org/jfx/pull/657 From angorya at openjdk.org Fri Dec 2 17:25:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:25:16 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v22] In-Reply-To: References: Message-ID: <50AaE6NfJf0snAqEWhst9w1iAszF6OiC3yUFLa8b5fg=.b7f23474-3150-4082-9258-c2304a6259a4@github.com> > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: trying to avoid merge conflicts in the future - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: review comments - 8294589: review comments - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: review comments - 8294589: cleanup - Merge remote-tracking branch 'origin/master' into 8294589.menubarskin.leak - 8294589: testing github merge-conflict label behavior - ... and 44 more: https://git.openjdk.org/jfx/compare/e64e1292...d4e6141f ------------- Changes: https://git.openjdk.org/jfx/pull/906/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=906&range=21 Stats: 464 lines in 2 files changed: 234 ins; 198 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/906.diff Fetch: git fetch https://git.openjdk.org/jfx pull/906/head:pull/906 PR: https://git.openjdk.org/jfx/pull/906 From angorya at openjdk.org Fri Dec 2 17:28:13 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:28:13 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v4] In-Reply-To: References: Message-ID: > Fixed memory leak by removing all the listeners in dispose(); > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: generics - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: is alive - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - Revert "8294809: removed weak listeners support" This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. - ... and 19 more: https://git.openjdk.org/jfx/compare/e64e1292...fb7d9ea6 ------------- Changes: https://git.openjdk.org/jfx/pull/911/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=911&range=03 Stats: 70 lines in 2 files changed: 31 ins; 18 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/911.diff Fetch: git fetch https://git.openjdk.org/jfx pull/911/head:pull/911 PR: https://git.openjdk.org/jfx/pull/911 From angorya at openjdk.org Fri Dec 2 17:35:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:35:05 GMT Subject: RFR: 8295531: ComboBoxBaseSkin: memory leak when changing skin [v5] In-Reply-To: References: Message-ID: <8kMTyv8VfNQHAMuz_orxe_MRJHgumBka67F22JotxF4=.462c0147-4065-4719-82ab-a825d933ff95@github.com> > as determined by SkinMemoryLeakTest (remove line 166) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Affected skins: > - ColorPicker > - DatePicker > - ComboBox > > caused by: > - out-of-order modification of the control property (skin.install) > - adding skin nodes and not removing them in dispose() > - adding listeners and not removing them in dispose() > > NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - 8295531: trying to avoid merge conflicts in the future - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin - 8295531: whitespace - 8295531: selection model leak - Merge branch '8294809.listener.helper' into 8295531.color.picker.skin - 8294809: generics - ... and 46 more: https://git.openjdk.org/jfx/compare/e64e1292...06cf1dfc ------------- Changes: https://git.openjdk.org/jfx/pull/922/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=922&range=04 Stats: 185 lines in 6 files changed: 82 ins; 41 del; 62 mod Patch: https://git.openjdk.org/jfx/pull/922.diff Fetch: git fetch https://git.openjdk.org/jfx pull/922/head:pull/922 PR: https://git.openjdk.org/jfx/pull/922 From angorya at openjdk.org Fri Dec 2 17:42:00 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:42:00 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v3] In-Reply-To: References: Message-ID: > Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. > > NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits: - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - 8245145: cleanup - 8245145: cleanup - 8245145: cleanup - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - 8245145: listener helper - Merge branch '8294809.listener.helper' into 8245145.spinner.skin - 8294809: whitespace - 8294809: no public api - ... and 41 more: https://git.openjdk.org/jfx/compare/e64e1292...c933b7b5 ------------- Changes: https://git.openjdk.org/jfx/pull/904/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=904&range=02 Stats: 58 lines in 3 files changed: 33 ins; 12 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/904.diff Fetch: git fetch https://git.openjdk.org/jfx pull/904/head:pull/904 PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Fri Dec 2 17:45:23 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:45:23 GMT Subject: RFR: 8295806: TableViewSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 179) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > > NOTE: > this fix requires [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) ListenerHelper Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - 8295806: placeholder - 8295806: plugged the leak - Merge remote-tracking branch 'origin/8294809.listener.helper' into 8295806.table.view.skin - 8294809: map change listener - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - 8294809: generics - ... and 17 more: https://git.openjdk.org/jfx/compare/e64e1292...ba84ea24 ------------- Changes: https://git.openjdk.org/jfx/pull/929/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=929&range=02 Stats: 200 lines in 7 files changed: 95 ins; 57 del; 48 mod Patch: https://git.openjdk.org/jfx/pull/929.diff Fetch: git fetch https://git.openjdk.org/jfx pull/929/head:pull/929 PR: https://git.openjdk.org/jfx/pull/929 From prr at openjdk.org Fri Dec 2 19:39:20 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 2 Dec 2022 19:39:20 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v4] In-Reply-To: References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Thu, 1 Dec 2022 10:12:26 GMT, eduardsdv wrote: >> This fixes a race condition between application and 'Print Job Thread' threads when printing. >> >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. >> >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. > > eduardsdv has updated the pull request incrementally with three additional commits since the last revision: > > - Revert "8295324: Apply patch with junit from the issue" > > This reverts commit c76b8207242a7af82f5515e49760158fa40da2a9. > - Revert "8295324: Fix race condition in junit test" > > This reverts commit fdec73d8f4ff21908bf99d191b76ffeed42bfb36. > - Revert "8295324: Adjust the J2DPrinterJobTest" > > This reverts commit 0723d2ebcd2c41d40005dbb1652c4ec96cfe4f8c. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/916 From kizune at openjdk.org Fri Dec 2 21:11:37 2022 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 2 Dec 2022 21:11:37 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Tue, 22 Nov 2022 01:40:02 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix View position Tested on Ubuntu 20.04.5 and Ubuntu 22.04.1 with both automated testing suite and manually with different applications, found no visible or functional regressions. ------------- PR: https://git.openjdk.org/jfx/pull/915 From almatvee at openjdk.org Sat Dec 3 00:17:04 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 3 Dec 2022 00:17:04 GMT Subject: Integrated: 8297362: EOS might not be delivered by progressbuffer in some cases In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 00:57:11 GMT, Alexander Matveev wrote: > This is regression from [JDK-8043352](https://bugs.openjdk.org/browse/JDK-8043352). [JDK-8043352](https://bugs.openjdk.org/browse/JDK-8043352) moved clearing pending events in progress buffer when upstream sends EOS. We need to do this for any other events except EOS. If we clear pending EOS, then it will not be delivered and we will hang due to downstream waiting for data or EOS. We still need to clear any other events such as new segment and not deliver it once we receive EOS. > > Added "plugins" folder to macOS project. For some reason it was missing and debugging plugins with xcode was not possible. > > Tested on all platforms with all formats over FILE and HTTP protocol. EOS was delivered correctly in all cases. This pull request has now been integrated. Changeset: 9416874f Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/9416874f632d8d036a324e195fae58e6a831bfc5 Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod 8297362: EOS might not be delivered by progressbuffer in some cases Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/961 From almatvee at openjdk.org Sat Dec 3 00:20:12 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 3 Dec 2022 00:20:12 GMT Subject: Integrated: 8287822: [macos] Remove support of duplicated formats from macOS In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 00:01:18 GMT, Alexander Matveev wrote: > - Added support for JAR and JRT protocol to AVFoundation platform. > - Removed H.264/MP3 and AAC support from GStreamer platform, which was primary used to playback these formats for JAR and JRT protocols. > - Added ability to FXMediaPlayer sample to generate playlist for JAR and JRT protocols for testing. See FXMedia.java for how to use it. > - H.265/HEVC via JAR/JRT protocols should work on macOS after this change. Before it did not work because GStreamer platform did not support H.265/HEVC and AVFoundation did not support JAR/JRT protocols. > - Minor code clean up. > > After this changes: > GSTPlatform: AIFF and WAV for all protocols. > AVFoundation: MP3, AAC, HLS, H.264 and H.265 for all protocols. > > This change is transparent for end user and does not affect list of supported formats by JavaFX Media. This pull request has now been integrated. Changeset: fe81a27f Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/fe81a27f0dc9e90a51d42e525b074be32ec5c82b Stats: 3283 lines in 26 files changed: 455 ins; 2784 del; 44 mod 8287822: [macos] Remove support of duplicated formats from macOS Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/909 From angorya at openjdk.org Sat Dec 3 00:24:46 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sat, 3 Dec 2022 00:24:46 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v17] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits: - 8293119: small delta - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: pref - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: step1 - 8293119: more integers - 8293119: more integers - 8293119: use integers for rounded values - 8293119: tester - 8293119: descriptions - ... and 60 more: https://git.openjdk.org/jfx/compare/e64e1292...fb40d98a ------------- Changes: https://git.openjdk.org/jfx/pull/897/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=16 Stats: 2340 lines in 14 files changed: 2079 ins; 250 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From mstrauss at openjdk.org Sat Dec 3 16:20:09 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Dec 2022 16:20:09 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> Message-ID: On Fri, 2 Dec 2022 09:56:42 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Improve wording in javadoc and comments I think that `ObservableValue.when` is good to go, but the case for `Node.shown` seems less clear. Applications might want to bind the active scope of an `ObservableValue` to any number of conditions, for example: * whether a node is connected to a `Scene` * ... that is connected to a window * ... that is currently showing * whether a node is currently `visible` * ... and it is also not hidden by other controls or outside the viewport * all of the above combined The proposed `shown` property picks one of these semantics and promotes it to a first-class API on `Node`. But it doesn't add any functionality that can't be provided by libraries or applications, since it's essentially just a convenience method for sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) The bar for adding convenience methods to `Node` should be high, and I'm not sure that `shown` clears the bar. My main objection would be that it's quite easy to add this (and other useful convenience methods) in a way that's not clearly worse, for example using a collection of static methods: public static class NodeUtil { public static ObservableValue shown(Node node) { ObservableValue shown = (ObservableValue)node.getProperties().get("shown"); if (shown == null) { shown = node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty); node.getProperties().put("shown", shown); } return shown; } public static ObservableValue visiblyShown(Node node) { ... } public static ObservableValue visiblyShownOnScreen(Node node) { ... } } When put into use, it's doesn't look terrible compared to a `Node.shown` property: label.textProperty().bind(longLivedProperty.when(label::shownProperty)); label.textProperty().bind(longLivedProperty.when(NodeUtil.shown(label)); This suggests to me that we should discuss the `Node` additions separately from `ObservableValue.when`. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jgneff at openjdk.org Sat Dec 3 18:41:55 2022 From: jgneff at openjdk.org (John Neffenger) Date: Sat, 3 Dec 2022 18:41:55 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 15:52:59 GMT, Johan Vos wrote: > I personally would like to have an approach similar to OpenJDK, which is more Makefile based and deals with module/platform/architecture specific things in a cleaner?way. Me too! I thought I was alone in wanting to move to Makefiles. The OpenJDK build is by far one of the easiest open-source build systems I've encountered. OpenJFX is by far one of the most difficult. Most of that difficulty is due to essential complexity: it just does so much on so many operating systems and hardware platforms. But there is a lot of accidental complexity in our current build system that could be removed, too. > However, it would be a huge effort to move from the monolith build.gradle that we currently have towards a system like OpenJDK -- especially since we need to get all testing and all cornercases?100% correct -- so it's not on my personal short-term roadmap. We don't need to get any testing or corner cases correct at all. We just need reproducible builds. Once we have reproducible builds, we can be bold and reckless in our changes to the build system. If the artifacts produced by the old build and the new build are bit-for-bit identical, we're done. Zero testing required. ------------- PR: https://git.openjdk.org/jfx/pull/657 From jhendrikx at openjdk.org Sat Dec 3 20:27:32 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:27:32 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v3] In-Reply-To: References: Message-ID: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Revert changes to gesture recognizers to be addressed in follow up bug - Fix incorrect cast removals ------------- Changes: - all: https://git.openjdk.org/jfx/pull/960/files - new: https://git.openjdk.org/jfx/pull/960/files/b033ed1c..4cc73ecf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=960&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=960&range=01-02 Stats: 21 lines in 10 files changed: 8 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/960.diff Fetch: git fetch https://git.openjdk.org/jfx pull/960/head:pull/960 PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sat Dec 3 20:50:44 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:50:44 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v3] In-Reply-To: References: Message-ID: <97bVdjM7niAbldUv3vvk0D4iRjMkmjoRVF2Eh713B9Q=.5db27ce2-4471-467e-80e2-0959b21751c9@github.com> On Sat, 26 Nov 2022 18:19:00 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert changes to gesture recognizers to be addressed in follow up bug >> - Fix incorrect cast removals > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java line 42: > >> 40: >> 41: private final Map slotToIDMap = >> 42: new HashMap<>(); > > Same line. There are more places where this formatting can be fixed, but it's up to you. I'll only fix the lines that were touched, as there are many many places that could be written more succinct. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinHTMLCodec.java line 157: > >> 155: htmlPrefix = ""; >> 156: htmlSuffix = ""; >> 157: if( -1 == stUpContext.indexOf(" > Might as well fix the spacing for `if`. I've left this as is (even though I agree this is ugly), as I didn't touch that line. Fixing these issues is a slippery slope :) ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sat Dec 3 20:50:45 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:50:45 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v3] In-Reply-To: References: Message-ID: <6E6QVUC72_7UxFmsLbXJj24ZJ31N4QKej7tEhi9Y-lA=.9bbbf742-9383-436e-8c89-74529e178367@github.com> On Tue, 29 Nov 2022 16:49:30 GMT, Kevin Rushforth wrote: >> +1 for reverting the changes and disabling the warning > >> Specifically about this code, `rotationStartTime` probably should not have been a `double` depending on what is stored in it (checking: its source is `System.nanoTime()`) as the conversion from `long` to `double` will lose precision in the area where it really counts as it wants to see the difference of the current and last value, so in this case the warning may have exposed a (precision) bug. > > You may be right. In this case, I would recommend either reverting this change, or else adding a `.0` to the divisor along with the removal of the explicit cast. Either way, we should consider a follow-up bug to address the question of possible loss of precision (in the existing code, which is unchanged by the refactoring). I've reverted the changes to the gesture recognizers and filed https://bugs.openjdk.org/browse/JDK-8298060 ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sat Dec 3 20:50:48 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:50:48 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 16:50:00 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/RotateGestureRecognizer.java line 306: > >> 304: sendRotateEvent(false); >> 305: angleReference = newAngle; >> 306: double timePassed = (time - rotationStartTime) / 1000000000; > > Ditto here and in the other gesture recognizers. I've reverted these and filed the follow up bug https://bugs.openjdk.org/browse/JDK-8298060 ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sat Dec 3 20:50:49 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:50:49 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v3] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 16:01:58 GMT, Kevin Rushforth wrote: >> `4L * physicalWidth * physicalHeight;` does not require an explicit cast, so I think it's the clearest. > > That variant is fine with me. Updated with this variant. ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sat Dec 3 20:54:04 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 3 Dec 2022 20:54:04 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix indentations and merge short lines ------------- Changes: - all: https://git.openjdk.org/jfx/pull/960/files - new: https://git.openjdk.org/jfx/pull/960/files/4cc73ecf..a81b9640 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=960&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=960&range=02-03 Stats: 9 lines in 4 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/960.diff Fetch: git fetch https://git.openjdk.org/jfx pull/960/head:pull/960 PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Sun Dec 4 15:08:02 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 4 Dec 2022 15:08:02 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> Message-ID: On Fri, 2 Dec 2022 09:56:42 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Improve wording in javadoc and comments > I think that `ObservableValue.when` is good to go, but the case for `Node.shown` seems less clear. > > Applications might want to bind the active scope of an `ObservableValue` to any number of conditions, for example: > > * whether a node is connected to a `Scene` > * ... that is connected to a window > * ... that is currently showing > * whether a node is currently `visible` > * ... and it is also not hidden by other controls or outside the viewport > * all of the above combined > > The proposed `shown` property picks one of these semantics and promotes it to a first-class API on `Node`. But it doesn't add any functionality that can't be provided by libraries or applications, since it's essentially just a convenience method for > > ```java > sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > ``` In the past, a form of this property already existed as part of `Node` in the `NodeHelper` class, which was almost always created. It was not public API and had the name `treeShowing`. I removed this as part of https://github.com/openjdk/jfx/pull/185 because it caused big performance issues because it was not a lazy property. I then implemented the required functionality directly in `PopupWindow` and `ProgressIndicatorSkin`. The performance problems were not related to the existence of the extra property, but because it was eagerly registering listeners on a many-to-one dependency (all nodes would register on scene and window, causing huge listener lists on the latter two). As I think the property is still useful (internally as well as publicly) putting it back in a form that won't cause performance issues seemed reasonable. However, good arguments can be made to leave it out. Currently there are three concepts within Node (all private): - `windowShowing` - true when the Node is part of a Scene that is part of a showing Window - `treeVisible` - true when the Node is visible and all its parents are visible - `treeShowing` (removed) - the combination of `windowShowing` and `treeVisible` `windowShowing` is not a real property currently, the `shown` property is basically making it available to all. `treeVisible` is a real property, but it's private API part of the `NodeHelper` instance that is part of `Node` -- it does not suffer the performance problems that `treeShowing` had because it only registers on its parent, spreading the load of the listeners it needs (they don't all end up on Scene or Window) -- it may still be worth it to optimize this one though by switching to lazy listeners. `treeShowing` as said was the combination of the previous two. My idea here was to make `windowShowing` public (as `shown`), and perhaps later `treeVisible`. The most interesting options will then no longer be only available for internal use, but for everyone. The combination of the two need not be a separate property. This can be handled with a double `when` or some kind of `and` construct: property.when(label::shownProperty).when(label::treeVisibleProperty) > The bar for adding convenience methods to `Node` should be high, and I'm not sure that `shown` clears the bar. My main objection would be that it's quite easy to add this (and other useful convenience methods) in a way that's not clearly worse, for example using a collection of static methods: > > ```java > public static class NodeUtil { > public static ObservableValue shown(Node node) { > ObservableValue shown = (ObservableValue)node.getProperties().get("shown"); > if (shown == null) { > shown = node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty); > node.getProperties().put("shown", shown); > } > return shown; > } > > public static ObservableValue visiblyShown(Node node) { > ... > } > > public static ObservableValue visiblyShownOnScreen(Node node) { > ... > } > } > ``` > > When put into use, it's doesn't look terrible compared to a `Node.shown` property: > > ``` > label.textProperty().bind(longLivedProperty.when(label::shownProperty)); > label.textProperty().bind(longLivedProperty.when(NodeUtil.shown(label)); > ``` > > This suggests to me that we should discuss the `Node` additions separately from `ObservableValue.when`. I suppose so; my main reason for making it a lot more visible is because of how important I think it is for deterministic listener management in UI's. The reasoning here is that if it is very visible it is discovered more easily, and it can be made good use of in examples to help people do the right thing -- combined with the fact that there apparently is some internal need for such properties as well. Then again, I agree that a helper class is not a too big of a compromise (I'd go for `Nodes` in the spirit of `Bindings` because I dislike classes with generic terms like `Util` or `Helper`). It's primary use case is to remove the need for weak listeners; it's not common that people remove listeners when things become invisible or are covered by something else -- when a control is invisible, it's main cost (rendering) is already gone, any updates that would affect its appearance will be deferred anyway until it becomes visible, so removing the listeners in those cases is not that urgent. So I think listeners are usually only removed when a piece of UI is going to be disposed permanently (this is also how weak listeners work, as they can't work in any other way). The closest I've managed to get to "is going to be disposed" is to use `scene.window.isShowing`, but even in those cases listeners may be removed too early (although not a problem as they'll be re-added if somehow that piece of UI didn't get GC'd and is shown again later). As the primary use case is to remove the reliance on weak listeners I think the `shown` property (in whatever form) is what we all need, and cases involving actual visibility are far less important. ------------- PR: https://git.openjdk.org/jfx/pull/830 From john.hendrikx at gmail.com Sun Dec 4 16:22:19 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 4 Dec 2022 17:22:19 +0100 Subject: Warnings Message-ID: We've done a few fixes in JavaFX trying to reduce the amount of warnings, and there was some discussion as to the value of fixing certain warnings. Some of these are purely aesthetic (like using the diamond operator) but others can hide current or future programming problems. I thought I'd post why I think fixing certain warnings is important for the continued health of a large code base. - Unnecessary casts (on Objects) Every cast in a code base is a potential place where a ClassCastException may lurk.? When a cast is unnecessary, it may seem harmless to leave it in.? However, as a code base grows or is refactored, a harmless cast hides a potential compilation problem which can become a runtime ClassCastException.? Java developers rely a lot on the compiler helping them when they do small refactorings to point out places where a type no longer matches after a change. Take the code below: ??? private Number n; ??? private Float f = (Float) n;? // warning unnecessary cast Changing `n` to a more specific type (let's say `Double`) will not generate an error for `f`.? The only thing that happens is that the cast is no longer deemed unnecessary and will do an actual cast (resulting in CCE at runtime) -- as there is no error reported, the developer may easily miss this. - Unnecessary casts (on primitives) A cast on a primitive that is not currently required can become a place where precision is lost without warning when a refactoring occurs. ??? private int x; ??? private int y = (int) x;? // warning unnecessary cast A refactoring that changes `x` to a type like `long` would go unnoticed by the compiler.? The version without the unnecessary cast would emit an error. - Unnecessary declared checked exceptions When a checked exception is declared that is never thrown from the underlying code, it is good to remove these to prevent them from propagating up the call chain.? Sometimes code bases have a checked exception in some deeply nested function that is not actually thrown, leading to perhaps top level public API to declare this exception. When the problem is discovered, the exception could be removed from dozens of places and could even affect public API (which now throws an exception that it can't actually throw but can't be removed as it is was already made public). - Missing @Override annotations Adding these everywhere makes extending super types and refactoring safer.? A sub type may declare a method that currently does not override any of its super types. If a super type is changed and a method is added that has a signature that is compatible with one that is already present in a sub type, the compiler will emit a warning that it is missing the override annotation alerting you of a potential problem (assuming the code base is relatively warning free, or it may get lost in the noise).? Conversely, removing or changing a currently overriden method would result in errors if sub types declared their overriden methods with the override annotation, alerting you that this functionality was perhaps more broadly used than anticipated.? Without the annotation, the method in the sub type would simply change to a non-overriden version without any further warning. - Avoiding indirect access to static methods and fields Code that accesses static members via `this` or indirectly via a sub type that didn't declare it, runs the risk of that access being diverted to a new member if one is introduced with the same name without a compiler error: ?????? class A { static final int ONE = 1; } ?????? class B { } ?? ??? class C extends B { ??????????? int one = ONE;? // unqualified access to A.ONE ???? ? } A "harmless" constant is introduced in B: ?????? class B { static final int ONE = 0x10000;? }? // 1 in 16-bit fixed point No error occurs, and class C is broken. A further reason to not allow indirect accesses to static members is that it may hide problems where an instance wasn't needed at all (if using `this.ONE` for example). - Using raw types With the introduction of generic types in Java 1.5, use of raw types should be considered something to be always avoided.? Using raw types will require casts in places that the compiler could have inferred or checked for you if you had used a generic type. Not using a generic type is basically risking a ClassCastException in those places (it was one of the most common exceptions in the pre-1.5 days).? Further more, the compiler can't help you during refactorings.? If a generic declared List is changed to contain a different type, there will be compiler errors in all the places you interact with the List.? Not so for a raw List; failing to fix all the casts will pay a runtime price. - Unused fields / variables / parameters All of these may point to a potential problem. It could be that the author mistyped something and meant to use one of the unused values; it could be that a parameter is genuinely unused and should be removed (triggering a potential cascade in callers that may be doing unnecessary actions to "provide" this unneeded information); it could be that a field is accessed by reflection (in which case that would have meritted a BIG warning comment and `SuppressWarnings`); whatever the case, it is confusing to future maintainers, may involve unnecessary memory use or unnecessary calculations (setting but never reading a value could involve a big calculation that may be completely unnecessary). --John From john at status6.com Sun Dec 4 19:53:26 2022 From: john at status6.com (John Neffenger) Date: Sun, 4 Dec 2022 11:53:26 -0800 Subject: Warnings In-Reply-To: References: Message-ID: On 12/4/22 8:22 AM, John Hendrikx wrote: > - Avoiding indirect access to static methods and fields > > ?????? class A { static final int ONE = 1; } > ?????? class B { } > ?? ??? class C extends B { > ??????????? int one = ONE;? // unqualified access to A.ONE > ???? ? } Did you mean the following? class B extends A { } There's a related trap in this category: inaccessible members can be unintentionally made public by an intermediate subclass. For example: package pkg1; interface A { static final int ONE = 1; } // ONE has package access package pkg1; public class B implements A { } // ONE is now public in B package pkg2; import pkg1.B; class C extends B { int one = ONE; // ONE is accessible in pkg2.C } Through this chain, members with package access (not just constants) can inadvertently end up in a public API. There are 423 occurrences of this in the Java API. There's a fix in JDK 20 that should let us find them in the JavaFX API, too. I don't think there's much we can do about it except be aware of them. I was really surprised by this, but see the classes in the 'pkg1' and 'pkg2' directories below for an example that you can compile and run: https://github.com/openjdk/jdk/tree/master/test/langtools/jdk/javadoc/doclet/testIndexInherited John From jvos at openjdk.org Sun Dec 4 20:14:07 2022 From: jvos at openjdk.org (Johan Vos) Date: Sun, 4 Dec 2022 20:14:07 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. We're now using the github issue tracker to discuss reproducible builds, which is probably not the primary reason Github issues were created, so I think it's better to start this discussion on a mail thread :) After reading it twice, I agree with your analysis (no need to test corner cases *IF* we have reproducible builds) I think there is some overlap in the two goals. We'll need to test for bit-for-bit identical artifacts for all the cornercases. By cornercases, I mean for example JavaFX 64 bit on Pi 4 with Ubuntu. You can't build that with the same compiler/libc/gtk-libs/... as Raspberry Pi OS for the same Pi 4. The majority of potential issues I see are on niche platforms with niche usecases. Creating reproducible builds for all these platforms sounds extremely difficult to me, but I'd like to be proven wrong. Especially the dependency on system libs and the low-level graphical drivers are non-trivial. We already had issues in differences for Linux 64 bit desktop when compiling using Ubuntu 18 versus Ubuntu 20 libs, and Linux/Ubuntu is about the simplest case I can think of. The myriad of embedded platforms make it harder. But we should probably continue the discussion on a mailthread :) ------------- PR: https://git.openjdk.org/jfx/pull/657 From mpaus at openjdk.org Sun Dec 4 20:25:08 2022 From: mpaus at openjdk.org (Michael Paus) Date: Sun, 4 Dec 2022 20:25:08 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Sun, 4 Dec 2022 20:10:29 GMT, Johan Vos wrote: > We're now using the github issue tracker to discuss reproducible builds, which is probably not the primary reason Github issues were created, so I think it's better to start this discussion on a mail thread :) Or maybe use https://docs.github.com/en/discussions here. ------------- PR: https://git.openjdk.org/jfx/pull/657 From nlisker at openjdk.org Mon Dec 5 02:07:03 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 5 Dec 2022 02:07:03 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations and merge short lines Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/960 From john.hendrikx at gmail.com Mon Dec 5 03:50:25 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 5 Dec 2022 04:50:25 +0100 Subject: Warnings In-Reply-To: References: Message-ID: On 04/12/2022 20:53, John Neffenger wrote: > On 12/4/22 8:22 AM, John Hendrikx wrote: >> - Avoiding indirect access to static methods and fields >> >> ??????? class A { static final int ONE = 1; } >> ??????? class B { } >> ??? ??? class C extends B { >> ???????????? int one = ONE;? // unqualified access to A.ONE >> ????? ? } > > Did you mean the following? > > ??? class B extends A { } Yes, my mistake. > > There's a related trap in this category: inaccessible members can be > unintentionally made public by an intermediate subclass. For example: > > ??? package pkg1; > ??? interface A { static final int ONE = 1; } // ONE has package access > > ??? package pkg1; > ??? public class B implements A { } // ONE is now public in B > > ??? package pkg2; > ??? import pkg1.B; > ??? class C extends B { > ??????? int one = ONE; // ONE is accessible in pkg2.C > ??? } > > Through this chain, members with package access (not just constants) > can inadvertently end up in a public API. There are 423 occurrences of > this in the Java API. There's a fix in JDK 20 that should let us find > them in the JavaFX API, too. I don't think there's much we can do > about it except be aware of them. > > I was really surprised by this, but see the classes in the 'pkg1' and > 'pkg2' directories below for an example that you can compile and run: > > https://github.com/openjdk/jdk/tree/master/test/langtools/jdk/javadoc/doclet/testIndexInherited > It is a bit unexpected indeed, I hadn't really thought about it that much. For methods it makes sense enough, as everything in an interface is always public and they are inherited and implemented in the implementation as public members. Those methods can be accessed simply because they're public, it doesn't matter that they came from an interface.? The static field however is not inherited or implemented in the sub type; perhaps it was not such a good idea to allow indirect access to static members in the first place. Hopefully IDE's will get a warning for this soon as well. --John From arapte at openjdk.org Mon Dec 5 08:22:10 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 5 Dec 2022 08:22:10 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test The current behavior is different on all three platforms: Behavior when running the test program attached to JBS. 1. Windows - Without fix: The Stage does NOT steal focus when scene changes and is NOT brought to foreground. but, the stage icon in task bar flashes with Orange color. - With this fix: The Stage does NOT steal the focus and is NOT be brought to foreground. but the icon flashing does not occur. It looks like a behavior change. 2. Mac - Without fix: The Stage does NOT steal the focus but is brought to foreground. - With this fix: The Stage does NOT steal the focus and is NOT be brought to foreground. 3. Ubuntu - Without fix: The Stage steals the focus and is brought to foreground. - With this fix: The Stage does NOT steal the focus and is NOT be brought to foreground. After the fix, the behavior looks similar on all platform, but this way the user does not get any notification of the Scene change in Application's content. i.e. the behavior change on Windows(icon not flashing) and Mac(not bringing Stage to foreground) seem little undesirable change to me. Should we consider to atleast bring the Stage to foreground without stealing focus ? or any alternatives ? ------------- PR: https://git.openjdk.org/jfx/pull/940 From kpk at openjdk.org Mon Dec 5 09:01:24 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 5 Dec 2022 09:01:24 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v3] In-Reply-To: References: Message-ID: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix for behavioural side effect ------------- Changes: - all: https://git.openjdk.org/jfx/pull/965/files - new: https://git.openjdk.org/jfx/pull/965/files/86e7823c..104ddb7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=01-02 Stats: 13 lines in 1 file changed: 12 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From lkostyra at openjdk.org Mon Dec 5 10:57:12 2022 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Dec 2022 10:57:12 GMT Subject: RFR: 8238968: Inconsisent formatting of Rectangle2D toString method Message-ID: The string was fixed to match other parameters' formatting. There was a PR submitted for this change a long time ago, but there were some issue with its previous author. Today I found the issue being assigned to me, so I figured I might as well submit a patch for it as it was a quick & easy fix. ------------- Commit messages: - 8238968: Inconsisent formatting of Rectangle2D toString method Changes: https://git.openjdk.org/jfx/pull/967/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8238968 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/967.diff Fetch: git fetch https://git.openjdk.org/jfx pull/967/head:pull/967 PR: https://git.openjdk.org/jfx/pull/967 From aghaisas at openjdk.org Mon Dec 5 11:05:07 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 5 Dec 2022 11:05:07 GMT Subject: RFR: 8295806: TableViewSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:45:23 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 179) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> caused by: >> - adding and not removing listeners >> - adding and not removing event handlers/filters >> >> NOTE: >> this fix requires [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) ListenerHelper > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - 8295806: placeholder > - 8295806: plugged the leak > - Merge remote-tracking branch 'origin/8294809.listener.helper' into 8295806.table.view.skin > - 8294809: map change listener > - Merge remote-tracking branch 'origin/master' into 8294809.listener.helper > - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin > - 8294809: generics > - ... and 17 more: https://git.openjdk.org/jfx/compare/e64e1292...ba84ea24 Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/929 From nlisker at openjdk.org Mon Dec 5 12:09:41 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 5 Dec 2022 12:09:41 GMT Subject: RFR: 8238968: Inconsisent formatting of Rectangle2D toString method In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 10:50:56 GMT, Lukasz Kostyra wrote: > The string was fixed to match other parameters' formatting. > > There was a PR submitted for this change a long time ago, but there were some issue with its previous author. Today I found the issue being assigned to me, so I figured I might as well submit a patch for it as it was a quick & easy fix. A trivial fix that was proposed in #88. One reviewer is enough. This is a case where a `record` would have been best. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/967 From aghaisas at openjdk.org Mon Dec 5 12:09:43 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 5 Dec 2022 12:09:43 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v4] In-Reply-To: References: Message-ID: <8RapBA2cGjKe7zdQCTX18c8F66zUNQskvegFboOr5EY=.751437ae-792c-4dcc-a163-c1e8ff97efbf@github.com> On Fri, 2 Dec 2022 17:28:13 GMT, Andy Goryachev wrote: >> Fixed memory leak by removing all the listeners in dispose(); >> >> This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. >> See https://github.com/openjdk/jfx/pull/908 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper > - 8294809: is alive > - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper > - Revert "8294809: removed weak listeners support" > > This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. > - ... and 19 more: https://git.openjdk.org/jfx/compare/e64e1292...fb7d9ea6 modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 627: > 625: } > 626: > 627: private void rebuildDividers(boolean removeAllDividers) { Looks like this is unnecessary refactoring. Having a method to add dividers will be clearer than a method that tries to do 2 things based on input parameter. We already have `removeAllDividers()` method. Similarly if this method can be restricted to `addAllDividers()` (or simply `addDividers()`) the callers can make calls to 2 methods whenever required. modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 660: > 658: lastDividerUpdate = 0; > 659: > 660: if(contentDividerListenerHelper != null) { Minor : space after `if` ------------- PR: https://git.openjdk.org/jfx/pull/911 From nlisker at gmail.com Mon Dec 5 12:11:26 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 5 Dec 2022 14:11:26 +0200 Subject: Warnings In-Reply-To: References: Message-ID: I have been working with John on the effort to remove warnings, so obviously I agree with these. I'd like to add a few points: * There is flexibility in how to tell the comp[iler to mark these possible problems. Some warnings can be turned into errors for stricter standards, and I think that this should be considered in parallel to the cleanup effort. Personally, I treat "missing override annotations" as errors since the damage potential when ignoring them is high and there's never a reason not to treat them. Raw types is another I would consider upgrading since for its damage potential, and the proper use cases of raw types are extremely few (I couldn't find a single one in my codebase O(100) classes). They are very common in JavaFX, unfortunately, but we will work on minimizing them, which should be simple for the most part (change List to List<>). * There are more warnings that can be fixed, but we are doing an iterative approach by fixing groups of warnings. With every iteration, the next step can be seen more clearly through the dense warnings forest. * Many warnings point at a deeper issue in the code. The simple fix is to address the warning directly, but inspecting the reason sometimes reveals badly written code. When I reviewed these PRs, there were several places where I asked myself "why was it written this way to begin with?". For example, looking at some "raw types" warnings that actually require the use of raw types will show that the approach taken there was flawed to begin with. While non-trivial refactoring should not be introduced in these PRs, and there is little gain in changing some small piece of code if it works, it's worth noting for the future. * Aside from fixing potential bugs, the result is often a more readable code since some fixes also remove clutter. On Mon, Dec 5, 2022 at 5:50 AM John Hendrikx wrote: > > On 04/12/2022 20:53, John Neffenger wrote: > > On 12/4/22 8:22 AM, John Hendrikx wrote: > >> - Avoiding indirect access to static methods and fields > >> > >> class A { static final int ONE = 1; } > >> class B { } > >> class C extends B { > >> int one = ONE; // unqualified access to A.ONE > >> } > > > > Did you mean the following? > > > > class B extends A { } > > Yes, my mistake. > > > > > There's a related trap in this category: inaccessible members can be > > unintentionally made public by an intermediate subclass. For example: > > > > package pkg1; > > interface A { static final int ONE = 1; } // ONE has package access > > > > package pkg1; > > public class B implements A { } // ONE is now public in B > > > > package pkg2; > > import pkg1.B; > > class C extends B { > > int one = ONE; // ONE is accessible in pkg2.C > > } > > > > Through this chain, members with package access (not just constants) > > can inadvertently end up in a public API. There are 423 occurrences of > > this in the Java API. There's a fix in JDK 20 that should let us find > > them in the JavaFX API, too. I don't think there's much we can do > > about it except be aware of them. > > > > I was really surprised by this, but see the classes in the 'pkg1' and > > 'pkg2' directories below for an example that you can compile and run: > > > > > https://github.com/openjdk/jdk/tree/master/test/langtools/jdk/javadoc/doclet/testIndexInherited > > > > It is a bit unexpected indeed, I hadn't really thought about it that > much. For methods it makes sense enough, as everything in an interface > is always public and they are inherited and implemented in the > implementation as public members. Those methods can be accessed simply > because they're public, it doesn't matter that they came from an > interface. The static field however is not inherited or implemented in > the sub type; perhaps it was not such a good idea to allow indirect > access to static members in the first place. > > Hopefully IDE's will get a warning for this soon as well. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Mon Dec 5 12:17:09 2022 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Dec 2022 12:17:09 GMT Subject: Integrated: 8238968: Inconsisent formatting of Rectangle2D toString method In-Reply-To: References: Message-ID: <0cg-8PkBBue-Khmxo7ekGilklFVX9T2D8KNhhjPHWh8=.f207ef76-bbd4-44e7-80bd-f0e6778c0f7f@github.com> On Mon, 5 Dec 2022 10:50:56 GMT, Lukasz Kostyra wrote: > The string was fixed to match other parameters' formatting. > > There was a PR submitted for this change a long time ago, but there were some issue with its previous author. Today I found the issue being assigned to me, so I figured I might as well submit a patch for it as it was a quick & easy fix. This pull request has now been integrated. Changeset: c2af0c31 Author: Lukasz Kostyra Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/c2af0c31b70df238769bd0eb1b7fd04eb7241446 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8238968: Inconsisent formatting of Rectangle2D toString method Reviewed-by: nlisker ------------- PR: https://git.openjdk.org/jfx/pull/967 From tsayao at openjdk.org Mon Dec 5 12:19:08 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Dec 2022 12:19:08 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test I still think that calling it when setting the scene is not the right place to demand attention or change the window stacking order. It would be possible to implement the taskbar attention on Linux, this functionality exists. ------------- PR: https://git.openjdk.org/jfx/pull/940 From aghaisas at openjdk.org Mon Dec 5 12:24:58 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 5 Dec 2022 12:24:58 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v22] In-Reply-To: <50AaE6NfJf0snAqEWhst9w1iAszF6OiC3yUFLa8b5fg=.b7f23474-3150-4082-9258-c2304a6259a4@github.com> References: <50AaE6NfJf0snAqEWhst9w1iAszF6OiC3yUFLa8b5fg=.b7f23474-3150-4082-9258-c2304a6259a4@github.com> Message-ID: On Fri, 2 Dec 2022 17:25:16 GMT, Andy Goryachev wrote: >> Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). >> >> This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. >> See https://github.com/openjdk/jfx/pull/908 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: > > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: trying to avoid merge conflicts in the future > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: review comments > - 8294589: review comments > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: review comments > - 8294589: cleanup > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: testing github merge-conflict label behavior > - ... and 44 more: https://git.openjdk.org/jfx/compare/e64e1292...d4e6141f Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/906 From jhendrikx at openjdk.org Mon Dec 5 12:32:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 12:32:24 GMT Subject: RFR: 8294589: MenuBarSkin: memory leak when changing skin [v22] In-Reply-To: <50AaE6NfJf0snAqEWhst9w1iAszF6OiC3yUFLa8b5fg=.b7f23474-3150-4082-9258-c2304a6259a4@github.com> References: <50AaE6NfJf0snAqEWhst9w1iAszF6OiC3yUFLa8b5fg=.b7f23474-3150-4082-9258-c2304a6259a4@github.com> Message-ID: On Fri, 2 Dec 2022 17:25:16 GMT, Andy Goryachev wrote: >> Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). >> >> This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. >> See https://github.com/openjdk/jfx/pull/908 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: > > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: trying to avoid merge conflicts in the future > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: review comments > - 8294589: review comments > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: review comments > - 8294589: cleanup > - Merge remote-tracking branch 'origin/master' into > 8294589.menubarskin.leak > - 8294589: testing github merge-conflict label behavior > - ... and 44 more: https://git.openjdk.org/jfx/compare/e64e1292...d4e6141f Marked as reviewed by jhendrikx (Author). ------------- PR: https://git.openjdk.org/jfx/pull/906 From jhendrikx at openjdk.org Mon Dec 5 12:47:38 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 12:47:38 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes Message-ID: This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. ------------- Commit messages: - General clean ups - Fix precision problems in gesture recognizers Changes: https://git.openjdk.org/jfx/pull/966/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=966&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298060 Stats: 206 lines in 4 files changed: 35 ins; 47 del; 124 mod Patch: https://git.openjdk.org/jfx/pull/966.diff Fetch: git fetch https://git.openjdk.org/jfx pull/966/head:pull/966 PR: https://git.openjdk.org/jfx/pull/966 From kpk at openjdk.org Mon Dec 5 12:48:14 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 5 Dec 2022 12:48:14 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Update in mouse enter and exit events. Update in unit test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/965/files - new: https://git.openjdk.org/jfx/pull/965/files/104ddb7b..26150c06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=02-03 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From tsayao at openjdk.org Mon Dec 5 13:53:45 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Dec 2022 13:53:45 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test Taskbar attention is something we could implement and let the user decide when to call it. ------------- PR: https://git.openjdk.org/jfx/pull/940 From mstrauss at openjdk.org Mon Dec 5 16:07:22 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 5 Dec 2022 16:07:22 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 41: > 39: import org.junit.Assert; > 40: import org.junit.BeforeClass; > 41: import org.junit.Test; Since this is a new test class, you should probably use the JUnit5 API. ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Mon Dec 5 16:19:57 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:19:57 GMT Subject: Integrated: 8294589: MenuBarSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 23:00:17 GMT, Andy Goryachev wrote: > Fixed memory leak by using weak listeners and making sure to undo everything that has been done to MenuBar/Skin in dispose(). > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 This pull request has now been integrated. Changeset: 2c18c181 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/2c18c1816f81daf49d022de590f406a7dfc67e8e Stats: 464 lines in 2 files changed: 234 ins; 198 del; 32 mod 8294589: MenuBarSkin: memory leak when changing skin Reviewed-by: aghaisas, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/906 From mstrauss at openjdk.org Mon Dec 5 16:21:07 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 5 Dec 2022 16:21:07 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: <3NG7imnlZVz9Afvjl97t6ZbnLgsDI1UI4THkKBzouQc=.42bf42fc-7825-4d66-9cb9-cb95ec785112@github.com> On Mon, 5 Dec 2022 08:19:59 GMT, Ambarish Rapte wrote: > After the fix, the behavior looks similar on all platform, but this way the user does not get any notification of the Scene change in Application's content. i.e. the behavior change on Windows(icon not flashing) and Mac(not bringing Stage to foreground) seem little undesirable change to me. > > Should we consider to atleast bring the Stage to foreground without stealing focus ? or any alternatives ? A `Scene` is an implementation detail of a JavaFX application, and not something that users of an application will find meaningful. Since we don't attempt to change the window stacking order when the scene graph is changed, we also shouldn't attempt to do so when a `Scene` is changed. In any case, Windows doesn't allow applications to force a window to the foreground, so that wouldn't work anyway. If a non-foreground process tries to set the foreground window, the call to `SetForegroundWindow` will fail, and the taskbar icon will flash instead. ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Mon Dec 5 16:28:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:28:47 GMT Subject: Integrated: 8295806: TableViewSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 23:21:52 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 179) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > > NOTE: > this fix requires [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) ListenerHelper This pull request has now been integrated. Changeset: bb98d886 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/bb98d886b01d5d1c6117303f40d43eab9f7ac504 Stats: 200 lines in 7 files changed: 95 ins; 57 del; 48 mod 8295806: TableViewSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/929 From angorya at openjdk.org Mon Dec 5 16:49:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:49:43 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v5] In-Reply-To: References: Message-ID: > Fixed memory leak by removing all the listeners in dispose(); > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - 8295175: review comments - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: generics - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper - 8294809: is alive - ... and 21 more: https://git.openjdk.org/jfx/compare/bb98d886...3b30ba7a ------------- Changes: https://git.openjdk.org/jfx/pull/911/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=911&range=04 Stats: 64 lines in 2 files changed: 26 ins; 17 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/911.diff Fetch: git fetch https://git.openjdk.org/jfx pull/911/head:pull/911 PR: https://git.openjdk.org/jfx/pull/911 From angorya at openjdk.org Mon Dec 5 16:49:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:49:45 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v4] In-Reply-To: <8RapBA2cGjKe7zdQCTX18c8F66zUNQskvegFboOr5EY=.751437ae-792c-4dcc-a163-c1e8ff97efbf@github.com> References: <8RapBA2cGjKe7zdQCTX18c8F66zUNQskvegFboOr5EY=.751437ae-792c-4dcc-a163-c1e8ff97efbf@github.com> Message-ID: On Mon, 5 Dec 2022 12:05:16 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: >> >> - Merge remote-tracking branch 'origin/master' into >> 8295175.splitpaneskin.with.helper >> - Merge remote-tracking branch 'origin/master' into >> 8295175.splitpaneskin.with.helper >> - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper >> - Merge remote-tracking branch 'origin/master' into >> 8295175.splitpaneskin.with.helper >> - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper >> - 8294809: generics >> - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper >> - 8294809: is alive >> - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper >> - Revert "8294809: removed weak listeners support" >> >> This reverts commit 2df4a85db638d76cacaf6c54ba669cdb3dd91a18. >> - ... and 19 more: https://git.openjdk.org/jfx/compare/e64e1292...fb7d9ea6 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SplitPaneSkin.java line 627: > >> 625: } >> 626: >> 627: private void rebuildDividers(boolean removeAllDividers) { > > Looks like this is unnecessary refactoring. > Having a method to add dividers will be clearer than a method that tries to do 2 things based on input parameter. > We already have `removeAllDividers()` method. Similarly if this method can be restricted to `addAllDividers()` (or simply `addDividers()`) the callers can make calls to 2 methods whenever required. good point. thanks! ------------- PR: https://git.openjdk.org/jfx/pull/911 From angorya at openjdk.org Mon Dec 5 16:53:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:53:19 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v3] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:42:00 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits: > > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: cleanup > - 8245145: cleanup > - 8245145: cleanup > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: listener helper > - Merge branch '8294809.listener.helper' into 8245145.spinner.skin > - 8294809: whitespace > - 8294809: no public api > - ... and 41 more: https://git.openjdk.org/jfx/compare/e64e1292...c933b7b5 @aghaisas @hjohn : could you please review? ------------- PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Mon Dec 5 16:54:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 16:54:34 GMT Subject: RFR: 8295531: ComboBoxBaseSkin: memory leak when changing skin [v5] In-Reply-To: <8kMTyv8VfNQHAMuz_orxe_MRJHgumBka67F22JotxF4=.462c0147-4065-4719-82ab-a825d933ff95@github.com> References: <8kMTyv8VfNQHAMuz_orxe_MRJHgumBka67F22JotxF4=.462c0147-4065-4719-82ab-a825d933ff95@github.com> Message-ID: On Fri, 2 Dec 2022 17:35:05 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 166) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Affected skins: >> - ColorPicker >> - DatePicker >> - ComboBox >> >> caused by: >> - out-of-order modification of the control property (skin.install) >> - adding skin nodes and not removing them in dispose() >> - adding listeners and not removing them in dispose() >> >> NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - 8295531: trying to avoid merge conflicts in the future > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin > - 8295531: whitespace > - 8295531: selection model leak > - Merge branch '8294809.listener.helper' into 8295531.color.picker.skin > - 8294809: generics > - ... and 46 more: https://git.openjdk.org/jfx/compare/e64e1292...06cf1dfc @aghaisas @hjohn @karthikpandelu could you please review? ------------- PR: https://git.openjdk.org/jfx/pull/922 From kcr at openjdk.org Mon Dec 5 16:57:15 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Dec 2022 16:57:15 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: <3FVGr2tam67qZO-EFXzqsEL4w8hut3WTiXHWOJYX2K8=.aade0798-7d7b-461b-9d05-3bb31ae4dfd3@github.com> On Sun, 13 Nov 2022 01:02:36 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test I'll finish my testing soon. As long as the behavior for the initial display of the Stage is the same on all platforms before/after this fix, I think it is fine. In particular, the "after" behavior for switching Scenes that Ambarish documented above is what I would expect after this bug fix is integrated. > A `Scene` is an implementation detail of a JavaFX application, and not something that users of an application will find meaningful. Since we don't attempt to change the window stacking order when the scene graph is changed, we also shouldn't attempt to do so when a `Scene` is changed. Exactly what I was going to say. ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Mon Dec 5 17:18:00 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:18:00 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin Message-ID: as determined by SkinMemoryLeakTest (remove line 180) and a leak tester https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java caused by: - adding and not removing listeners - adding and not removing event handlers/filters - adding and not removing cell factory - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only NOTES: 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into - 8295809: cleanup - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into - 8295809: temporarily disabled some tests - 8295809: plugged the leak - ... and 24 more: https://git.openjdk.org/jfx/compare/bb98d886...e6e96d62 Changes: https://git.openjdk.org/jfx/pull/931/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295809 Stats: 197 lines in 4 files changed: 93 ins; 77 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/931.diff Fetch: git fetch https://git.openjdk.org/jfx pull/931/head:pull/931 PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Mon Dec 5 17:18:01 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:18:01 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:06:26 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. must be reviewed after https://github.com/openjdk/jfx/pull/929 ------------- PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Mon Dec 5 17:21:45 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:21:45 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 12:48:14 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Update in mouse enter and exit events. Update in unit test Changes requested by angorya (Committer). modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 395: > 393: > 394: thumb.setOnMouseEntered(me -> { > 395: if (getSkinnable().getTooltip() != null && getSkinnable().getTooltip().isAutoHide()) { If I may suggest an edit in these two event handlers - create a local variable: Tooltip t = getSkinnable().getTooltip(); if (t != null && t.isAutoHide()) { tooltipConsumeAutoHidingEvents = t.getConsumeAutoHidingEvents(); t.setConsumeAutoHidingEvents(false); } tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 85: > 83: > 84: private void dragSliderAfterTooltipDisplayed(int dragDistance) throws Exception { > 85: Thread.sleep(1000); // Wait for slider to layout is there an equivalent of waitForIdle()? could we replace the sleep() with waiting for some event/property instead? ------------- PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Mon Dec 5 17:21:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:21:49 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 16:57:05 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Update in mouse enter and exit events. Update in unit test > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 395: > >> 393: >> 394: thumb.setOnMouseEntered(me -> { >> 395: if (getSkinnable().getTooltip() != null && getSkinnable().getTooltip().isAutoHide()) { > > If I may suggest an edit in these two event handlers - create a local variable: > > > Tooltip t = getSkinnable().getTooltip(); > if (t != null && t.isAutoHide()) { > tooltipConsumeAutoHidingEvents = t.getConsumeAutoHidingEvents(); > t.setConsumeAutoHidingEvents(false); > } Also, since the reason for this change is not immediately obvious, I'd add a comment explaining why (perhaps above tooltipConsumeAutoHidingEvents declaration, line 64?) ------------- PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Mon Dec 5 17:25:15 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:25:15 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 12:48:14 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Update in mouse enter and exit events. Update in unit test @aghaisas @karthikpandelu : could you guys check if this change fixes [JDK-8293916](https://bugs.openjdk.org/browse/JDK-8293916) ? I don't have a touchscreen machine here, and these two bugs seem related. ------------- PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Mon Dec 5 17:32:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 17:32:59 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v13] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: cleanup - 8187145: also tree table view - 8187145: whitespace - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: review comments - 8187145: github - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - ... and 10 more: https://git.openjdk.org/jfx/compare/bb98d886...2e19c490 ------------- Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=12 Stats: 471 lines in 15 files changed: 378 ins; 12 del; 81 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From tsayao at openjdk.org Mon Dec 5 20:59:30 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Dec 2022 20:59:30 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v3] In-Reply-To: References: Message-ID: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Use JUnit 5 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/113e472a..f3c7097b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=01-02 Stats: 13 lines in 1 file changed: 2 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Mon Dec 5 20:59:32 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Dec 2022 20:59:32 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v2] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 16:03:25 GMT, Michael Strau? wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test > > tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 41: > >> 39: import org.junit.Assert; >> 40: import org.junit.BeforeClass; >> 41: import org.junit.Test; > > Since this is a new test class, you should probably use the JUnit5 API. Done ------------- PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Mon Dec 5 21:03:09 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 5 Dec 2022 21:03:09 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: References: Message-ID: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add new line ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/f3c7097b..39d74209 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Mon Dec 5 21:16:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Dec 2022 21:16:49 GMT Subject: RFR: 8295324: JavaFX: Blank pages when printing [v4] In-Reply-To: References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Thu, 1 Dec 2022 10:12:26 GMT, eduardsdv wrote: >> This fixes a race condition between application and 'Print Job Thread' threads when printing. >> >> The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, >> and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. >> The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. >> >> In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. >> It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. > > eduardsdv has updated the pull request incrementally with three additional commits since the last revision: > > - Revert "8295324: Apply patch with junit from the issue" > > This reverts commit c76b8207242a7af82f5515e49760158fa40da2a9. > - Revert "8295324: Fix race condition in junit test" > > This reverts commit fdec73d8f4ff21908bf99d191b76ffeed42bfb36. > - Revert "8295324: Adjust the J2DPrinterJobTest" > > This reverts commit 0723d2ebcd2c41d40005dbb1652c4ec96cfe4f8c. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/916 From angorya at openjdk.org Mon Dec 5 21:20:48 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 21:20:48 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations and merge short lines 1 revert and a follow-up bug is requested. This is one giant pull request, somewhat difficult on the reviewers, especially since we have to go through it several times. It would be *much* easier for the reviewers to deal with one fix per PR, especially in the cases where more than 30 files are going to be touched. For example, changes involving diamond operator and missing @overrides could have been made into two separate PRs, making it a breeze to review and integrate, while also cutting down on the number of files which contained non-trivial changes. What do you think? modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 601: > 599: } > 600: args.add("--" + k + "=" + (v != null ? v : "")); > 601: idx++; I suspect there might be a deviation from original intent that had happened earlier. The original idea seems to be of capturing IOException and sending some diagnostic output to stderr, then continuing. I am guessing here, but perhaps at some point in the past `Base64.getDecoder().decode()` replaced whatever was there before - and instead of throwing `IOException` it now throws `IllegalArgumentException` if things cannot be parsed. So the try-catch block should remain, catching an `IllegalArgumentException` instead. Perhaps we ought to revert these changes and file a follow-up bug? What do you think? modules/javafx.graphics/src/main/java/com/sun/javafx/css/PseudoClassState.java line 172: > 170: > 171: static final List pseudoClasses = > 172: new ArrayList<>(); minor: if you make further changes, these two can be on one line. modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java line 586: > 584: ascent = -(float)hhea.getShort(4); > 585: descent = -(float)hhea.getShort(6); > 586: linegap = hhea.getShort(8); interesting: why not on the previous 2 lines? isn't `-(float)shortValue == (float)(-shortValue)` ? modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DContext.java line 514: > 512: case D3DERR_DEVICEREMOVED: > 513: return "D3DERR_DEVICEREMOVED"; > 514: case D3D_OK: this change is probably correct, but one can think of a theoretical possibility of collision, i.e. `hResult = ((1L << 32) + D3DERR_DEVICENOTRESET)` will hit `D3DERR_DEVICENOTRESET` case instead of the default one. but again, hResult is long perhaps because it's originally unsigned32 or something like that. modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 2579: > 2577: term = nextLayer(lastTerm); > 2578: } > 2579: return new ParsedValueImpl<>(layers, CornerRadiiConverter.getInstance()); My eclipse has a problem with this class (might be an Eclipse bug). It does compile, but any time I modify the class it generates a bunch of errors. The only code that does not produce the errors is returning a raw value. ------------- Changes requested by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/960 From angorya at openjdk.org Mon Dec 5 21:20:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Dec 2022 21:20:49 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 22:34:42 GMT, Andy Goryachev wrote: >> I don't see it as a useful warning. The code isn't necessarily better without, and can be less clear. I think this might argue for asking Eclipse users to disable this warning in the IDE. > > I do agree with @kevinrushforth here. > > It might be borderline useful to enable the warning once just to see if there are any bugs or perhaps to clean up the most obvious cases, but it probably makes little sense to enable the said warning for large and long lived code bases like this one. just to clarify: 1. I am ok with this code change, the typecast is unnecessary 2. I agree with Kevin that this particular warning (unnecessary cast) is of little value, especially in the large and long lived code bases. ------------- PR: https://git.openjdk.org/jfx/pull/960 From prr at openjdk.org Mon Dec 5 21:27:12 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 5 Dec 2022 21:27:12 GMT Subject: RFR: 8296854: NULL check of CTFontCopyAvailableTables return value is required Message-ID: Guard against de-referencing null, although it is currently theoretical as far as I can see (more info in the bug eval) ------------- Commit messages: - 8296854 Changes: https://git.openjdk.org/jfx/pull/968/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=968&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296854 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/968.diff Fetch: git fetch https://git.openjdk.org/jfx pull/968/head:pull/968 PR: https://git.openjdk.org/jfx/pull/968 From jhendrikx at openjdk.org Mon Dec 5 21:43:05 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 21:43:05 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 20:11:53 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentations and merge short lines > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java line 586: > >> 584: ascent = -(float)hhea.getShort(4); >> 585: descent = -(float)hhea.getShort(6); >> 586: linegap = hhea.getShort(8); > > interesting: why not on the previous 2 lines? isn't > > `-(float)shortValue == (float)(-shortValue)` ? Almost, but not quite. If the `short` is -32768 than negating it would still be -32768. If you write it the other way around though, it might get promoted to `int` first anyway, and the point is moot, I would have to test to make sure. ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Mon Dec 5 21:49:00 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 21:49:00 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 20:37:09 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentations and merge short lines > > modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DContext.java line 514: > >> 512: case D3DERR_DEVICEREMOVED: >> 513: return "D3DERR_DEVICEREMOVED"; >> 514: case D3D_OK: > > this change is probably correct, but one can think of a theoretical possibility of collision, i.e. > > `hResult = ((1L << 32) + D3DERR_DEVICENOTRESET)` will hit `D3DERR_DEVICENOTRESET` case instead of the default one. > > but again, hResult is long perhaps because it's originally unsigned32 or something like that. The code will not do anything different than it did already. It casts `hResult` to `int` in the switch, if that's not intended, then that's a bug. > modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 2579: > >> 2577: term = nextLayer(lastTerm); >> 2578: } >> 2579: return new ParsedValueImpl<>(layers, CornerRadiiConverter.getInstance()); > > My eclipse has a problem with this class (might be an Eclipse bug). It does compile, but any time I modify the class it generates a bunch of errors. The only code that does not produce the errors is returning a raw value. You mentioned this one before. It's a bug in Eclipse. ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Mon Dec 5 21:51:01 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 5 Dec 2022 21:51:01 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: <-QcVwOTG2gsBauUkCOEf4SxTg9e7tpcv3lRAzY-BIqI=.80140dec-08ad-4d32-940f-f8bf622c9476@github.com> On Mon, 5 Dec 2022 21:46:12 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 2579: >> >>> 2577: term = nextLayer(lastTerm); >>> 2578: } >>> 2579: return new ParsedValueImpl<>(layers, CornerRadiiConverter.getInstance()); >> >> My eclipse has a problem with this class (might be an Eclipse bug). It does compile, but any time I modify the class it generates a bunch of errors. The only code that does not produce the errors is returning a raw value. > > You mentioned this one before. It's a bug in Eclipse. It's a bug in Eclipse. ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Mon Dec 5 21:57:27 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 5 Dec 2022 21:57:27 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 21:40:40 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java line 586: >> >>> 584: ascent = -(float)hhea.getShort(4); >>> 585: descent = -(float)hhea.getShort(6); >>> 586: linegap = hhea.getShort(8); >> >> interesting: why not on the previous 2 lines? isn't >> >> `-(float)shortValue == (float)(-shortValue)` ? > > Almost, but not quite. If the `short` is -32768 than negating it would still be -32768. > > If you write it the other way around though, it might get promoted to `int` first anyway, and the point is moot, I would have to test to make sure. As John explained, the minus sign makes the difference. A `short` has the range of -32,768 to 32,767. If `getShort` returns -32,768, then -(-32,768) is not in the range (32,768 is non-representable). Therefore, you first need to widen it to a type that does include 32,768, and only then negate. ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Mon Dec 5 22:03:27 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 22:03:27 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: <02NLjmPVopQzOCmC4wMjwcS8boneHmhlMq_5WSsaHZg=.18d5f4bb-9df9-4f3f-9c2e-cb781e65766d@github.com> On Mon, 5 Dec 2022 19:59:45 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentations and merge short lines > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 601: > >> 599: } >> 600: args.add("--" + k + "=" + (v != null ? v : "")); >> 601: idx++; > > I suspect there might be a deviation from original intent that had happened earlier. The original idea seems to be of capturing IOException and sending some diagnostic output to stderr, then continuing. I am guessing here, but perhaps at some point in the past `Base64.getDecoder().decode()` replaced whatever was there before - and instead of throwing `IOException` it now throws `IllegalArgumentException` if things cannot be parsed. > > So the try-catch block should remain, catching an `IllegalArgumentException` instead. > > Perhaps we ought to revert these changes and file a follow-up bug? > > What do you think? The code was already broken (since 2014 apparently when the new Base64 decoder was used). Had the author turned on these handy warnings, they would have noticed that something was amiss. Now they unwittingly changed the behavior. Personally, I think the current code is an improvement. The catch block was already unreachable since 2014, and the `IllegalArgumentException` has been bubbling up and terminating the program since then (it's called from `launchApplication`). Whether a follow-up bug is needed depends on whether we want to restore the original behavior: log an exception, ignore parsing the rest of the parameters and continue without them... I think we shouldn't. ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Mon Dec 5 22:03:28 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 5 Dec 2022 22:03:28 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 20:17:04 GMT, Andy Goryachev wrote: >> I do agree with @kevinrushforth here. >> >> It might be borderline useful to enable the warning once just to see if there are any bugs or perhaps to clean up the most obvious cases, but it probably makes little sense to enable the said warning for large and long lived code bases like this one. > > just to clarify: > 1. I am ok with this code change, the typecast is unnecessary > 2. I agree with Kevin that this particular warning (unnecessary cast) is of little value, especially in the large and long lived code bases. I wrote what I think in [this comment](https://github.com/openjdk/jfx/pull/960#issuecomment-1325782856). Even if in this specific case the cast should not be changed, the warning is very useful to have since it encapsulates non-numeric types as well. ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Mon Dec 5 22:23:05 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 5 Dec 2022 22:23:05 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations and merge short lines > This is one giant pull request, somewhat difficult on the reviewers, especially since we have to go through it several times. > > It would be _much_ easier for the reviewers to deal with one fix per PR, especially in the cases where more than 30 files are going to be touched. > > For example, changes involving diamond operator and missing @OVERRIDES could have been made into two separate PRs, making it a breeze to review and integrate, while also cutting down on the number of files which contained non-trivial changes. > > What do you think? Agreed, they'll be smaller and more focused in the future. ------------- PR: https://git.openjdk.org/jfx/pull/960 From angorya at openjdk.org Tue Dec 6 03:07:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 03:07:16 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations and merge short lines explanations accepted. ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/960 From angorya at openjdk.org Tue Dec 6 03:07:18 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 03:07:18 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: <02NLjmPVopQzOCmC4wMjwcS8boneHmhlMq_5WSsaHZg=.18d5f4bb-9df9-4f3f-9c2e-cb781e65766d@github.com> References: <02NLjmPVopQzOCmC4wMjwcS8boneHmhlMq_5WSsaHZg=.18d5f4bb-9df9-4f3f-9c2e-cb781e65766d@github.com> Message-ID: On Mon, 5 Dec 2022 22:00:01 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 601: >> >>> 599: } >>> 600: args.add("--" + k + "=" + (v != null ? v : "")); >>> 601: idx++; >> >> I suspect there might be a deviation from original intent that had happened earlier. The original idea seems to be of capturing IOException and sending some diagnostic output to stderr, then continuing. I am guessing here, but perhaps at some point in the past `Base64.getDecoder().decode()` replaced whatever was there before - and instead of throwing `IOException` it now throws `IllegalArgumentException` if things cannot be parsed. >> >> So the try-catch block should remain, catching an `IllegalArgumentException` instead. >> >> Perhaps we ought to revert these changes and file a follow-up bug? >> >> What do you think? > > The code was already broken (since 2014 apparently when the new Base64 decoder was used). Had the author turned on these handy warnings, they would have noticed that something was amiss. Now they unwittingly changed the behavior. > > Personally, I think the current code is an improvement. The catch block was already unreachable since 2014, and the `IllegalArgumentException` has been bubbling up and terminating the program since then (it's called from `launchApplication`). > > Whether a follow-up bug is needed depends on whether we want to restore the original behavior: log an exception, ignore parsing the rest of the parameters and continue without them... I think we shouldn't. I agree with you - we shouldn't. ------------- PR: https://git.openjdk.org/jfx/pull/960 From arapte at openjdk.org Tue Dec 6 05:41:55 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Dec 2022 05:41:55 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 21:03:09 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add new line Suggesting minor changes in the test. tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 61: > 59: public static void initFX() throws Exception { > 60: new Thread(() -> Application.launch(TestApp.class, (String[]) null)).start(); > 61: waitForLatch(startupLatch, 10, "FX runtime failed to start."); With the changes made in #950, we have a new pattern for launch and exit. These two lines would be now: `Util.launch(startupLatch, TestApp.class);` and similarly exit method would be : `Util.shutdown(stage);` and `waitForLatch` method can be removed. tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 80: > 78: tl.setCycleCount(Animation.INDEFINITE); > 79: tl.getKeyFrames().addAll(new KeyFrame(Duration.millis(0), e -> stage.setScene(scene1)), > 80: new KeyFrame(Duration.millis(200), e -> stage.setScene(scene2))); With `Duration.millis(0)`, JavaFX gets no time to switch to `scene2`. We should allow some time for `stage.setScene(scene2)` to be processed. We can observe the behavior by commenting two lines 55 and 88, and adding a delay `Util.sleep(10000)` in `exit()` method : The `scene2` will never be seen on Window. I would recommend to change `Duration.millis(0)` to `Duration.millis(100)` OR any other duration with sufficient gap between the two Frames. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/940 From arapte at openjdk.org Tue Dec 6 06:09:13 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Dec 2022 06:09:13 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: <6dV9ptwywhRDQlKxzUCOio1f7Rjol-Fijrv3dn4orws=.ddb48457-0bff-4a68-940b-b79b7c209405@github.com> On Mon, 7 Nov 2022 12:03:38 GMT, Dean Wookey wrote: >> When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. >> >> MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. >> >> When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. >> >> This pull request just removes the redundant code in the MenuButtonSkinBase. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added changing scene tests for accelerator change listeners Now that #919 is integrated, the conflict needs to be resolved. ------------- PR: https://git.openjdk.org/jfx/pull/937 From nlisker at openjdk.org Tue Dec 6 06:39:15 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 6 Dec 2022 06:39:15 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 22:20:59 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentations and merge short lines > >> This is one giant pull request, somewhat difficult on the reviewers, especially since we have to go through it several times. >> >> It would be _much_ easier for the reviewers to deal with one fix per PR, especially in the cases where more than 30 files are going to be touched. >> >> For example, changes involving diamond operator and missing @OVERRIDES could have been made into two separate PRs, making it a breeze to review and integrate, while also cutting down on the number of files which contained non-trivial changes. >> >> What do you think? > > Agreed, they'll be smaller and more focused in the future. @hjohn Kevin has outstanding requests. Even though you can technically integrate, you should resolve these with him. ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Tue Dec 6 06:39:15 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 6 Dec 2022 06:39:15 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: <02NLjmPVopQzOCmC4wMjwcS8boneHmhlMq_5WSsaHZg=.18d5f4bb-9df9-4f3f-9c2e-cb781e65766d@github.com> Message-ID: On Tue, 6 Dec 2022 03:03:13 GMT, Andy Goryachev wrote: >> The code was already broken (since 2014 apparently when the new Base64 decoder was used). Had the author turned on these handy warnings, they would have noticed that something was amiss. Now they unwittingly changed the behavior. >> >> Personally, I think the current code is an improvement. The catch block was already unreachable since 2014, and the `IllegalArgumentException` has been bubbling up and terminating the program since then (it's called from `launchApplication`). >> >> Whether a follow-up bug is needed depends on whether we want to restore the original behavior: log an exception, ignore parsing the rest of the parameters and continue without them... I think we shouldn't. > > I agree with you - we shouldn't. This is an example of what I was talking about in [this comment](https://github.com/openjdk/jfx/pull/958#pullrequestreview-1198517697). ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Tue Dec 6 06:44:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 6 Dec 2022 06:44:24 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: <_DQQ4lSPil829-6Ko9n3j_CfUc_fKiG4i0cV7Yc-8A0=.0540cee2-d105-4c92-8ca0-84a266bab23a@github.com> On Wed, 30 Nov 2022 12:55:08 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java line 41: >> >>> 39: * The PresentingPainter is used when we are rendering to the main screen. >>> 40: */ >>> 41: final class UploadingPainter extends ViewPainter { >> >> I'm not sure I see the value in making this change. > > Since this is an internal class (not public API), I won't object to this change. I do think it's a rather pointless change, but I'll leave it up to you. Personally, I find that re-declaring type hierarchy is clutter. I can see why sometimes you might want to emphasize a functionality of a class that already exists, but the IDE makes it rather easy, I find. ------------- PR: https://git.openjdk.org/jfx/pull/960 From nlisker at openjdk.org Tue Dec 6 06:44:26 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 6 Dec 2022 06:44:26 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 12:48:10 GMT, Kevin Rushforth wrote: >> If the casts in the numerator actually matter, then the cast in the denominator can be removed. The latter are the ones that Eclipse flags for me as unnecessary. > > I still think that any change here would be a very low value change. If done incorrectly, as it was in the initial attempt, it can introduce bugs. Even if done correctly, I see no point in it. I don't really mind either way. Eclipse's refactoring are safe, so I don't see any risk in doing what it says (removing the denominator casts). For me, the less casts the more clear what the calculation is doing. Like I said before, it's probably a personal thing. ------------- PR: https://git.openjdk.org/jfx/pull/960 From arapte at openjdk.org Tue Dec 6 08:17:17 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Dec 2022 08:17:17 GMT Subject: RFR: 8297554: Remove Scene.KeyHandler In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 06:49:02 GMT, Michael Strau? wrote: > The `Scene.KeyHandler` class doesn't seem to have a clear purpose, mixing focus handling with event propagation. Since #852, `KeyHandler.setFocusVisible` is also called from mouse and touch event handlers, which makes the purpose of the class even less pronounced. > > Moving the focus-related functionality next to the other focus functions in the `Scene` class makes it easier to work with the code in the future. > > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, this code can be rolled into `Scene.processKeyEvent` and the now-empty `KeyHandler` class can be removed. The changes look equivalent to the code before. Suggesting minor changes. Shall do some sanity testing with focus and update. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2091: > 2089: **************************************************************************/ > 2090: > 2091: private void windowForSceneChanged(Window oldWindow, Window window) { Minor: rename the second parameter `window` to `newWindow`. As the method source is shown modified in the patch it seems Okay to make this change. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 2208: > 2206: > 2207: private class FocusOwnerProperty extends ReadOnlyObjectWrapper { > 2208: Node oldValue; The variable name `oldFocusOwner` seems more readable and using the same name as before will reduce the diff. Could you please change the name to `oldFocusOwner` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/962 From jhendrikx at openjdk.org Tue Dec 6 08:58:05 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 08:58:05 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 22:30:16 GMT, Kevin Rushforth wrote: >> I agree. The problem is that we will not be able to enable the warning in IDE, or it has to be @suppressed. >> >> So the choice is either fix the code and enable warning, or keep the code as is and disable the warning. > > I don't see it as a useful warning. The code isn't necessarily better without, and can be less clear. I think this might argue for asking Eclipse users to disable this warning in the IDE. @kevinrushforth Is this okay as it is? Even though the benefit of removing the cast here is minimal, removing it still seems better as it won't need to be suppressed later if we decide to enforce the rules as part of the build. In this specific case, there was no obvious way to "break" the code (by losing precision) by changing something unrelated (like changing `ptSize` to `double` or `long`). ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Tue Dec 6 09:04:41 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 09:04:41 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 22:20:59 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentations and merge short lines > >> This is one giant pull request, somewhat difficult on the reviewers, especially since we have to go through it several times. >> >> It would be _much_ easier for the reviewers to deal with one fix per PR, especially in the cases where more than 30 files are going to be touched. >> >> For example, changes involving diamond operator and missing @OVERRIDES could have been made into two separate PRs, making it a breeze to review and integrate, while also cutting down on the number of files which contained non-trivial changes. >> >> What do you think? > > Agreed, they'll be smaller and more focused in the future. > @hjohn Kevin has outstanding requests. Even though you can technically integrate, you should resolve these with him. Yes, I will wait until @kevinrushforth had time to take another look. ------------- PR: https://git.openjdk.org/jfx/pull/960 From jhendrikx at openjdk.org Tue Dec 6 09:04:43 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 09:04:43 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 12:48:10 GMT, Kevin Rushforth wrote: >> If the casts in the numerator actually matter, then the cast in the denominator can be removed. The latter are the ones that Eclipse flags for me as unnecessary. > > I still think that any change here would be a very low value change. If done incorrectly, as it was in the initial attempt, it can introduce bugs. Even if done correctly, I see no point in it. @kevinrushforth This has been mostly reverted, and is a lesson for me to not do more than what the warning suggests without checking very carefully. It just looked like a bunch of unnecessary casts, but it is has one edge case with negation overflow of a signed integer that I missed (whether it can happen in practice I did not analyze further). ------------- PR: https://git.openjdk.org/jfx/pull/960 From tsayao at openjdk.org Tue Dec 6 11:03:15 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 11:03:15 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 05:35:07 GMT, Ambarish Rapte wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add new line > > tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 80: > >> 78: tl.setCycleCount(Animation.INDEFINITE); >> 79: tl.getKeyFrames().addAll(new KeyFrame(Duration.millis(0), e -> stage.setScene(scene1)), >> 80: new KeyFrame(Duration.millis(200), e -> stage.setScene(scene2))); > > With `Duration.millis(0)`, JavaFX gets no time to switch to `scene2`. We should allow some time for `stage.setScene(scene2)` to be processed. > We can observe the behavior by commenting two lines 55 and 88, and adding a delay `Util.sleep(10000)` in `exit()` method : The `scene2` will never be seen on Window. > I would recommend to change `Duration.millis(0)` to `Duration.millis(100)` OR any other duration with sufficient gap between the two Frames. I don't mind changing it, but I think those durations are relative, so `Duration.millis(0)` means "don't wait". I'm not sure I follow the recommendation. ------------- PR: https://git.openjdk.org/jfx/pull/940 From aghaisas at openjdk.org Tue Dec 6 11:11:23 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Dec 2022 11:11:23 GMT Subject: RFR: 8295175: SplitPaneSkin: memory leak when changing skin [v5] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 16:49:43 GMT, Andy Goryachev wrote: >> Fixed memory leak by removing all the listeners in dispose(); >> >> This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. >> See https://github.com/openjdk/jfx/pull/908 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - 8295175: review comments > - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into 8295175.splitpaneskin.with.helper > - Merge remote-tracking branch 'origin/master' into > 8295175.splitpaneskin.with.helper > - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper > - 8294809: generics > - Merge branch '8294809.listener.helper' into 8295175.splitpaneskin.with.helper > - 8294809: is alive > - ... and 21 more: https://git.openjdk.org/jfx/compare/bb98d886...3b30ba7a Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/911 From aghaisas at openjdk.org Tue Dec 6 11:25:51 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Dec 2022 11:25:51 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v3] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:42:00 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits: > > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: cleanup > - 8245145: cleanup > - 8245145: cleanup > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: listener helper > - Merge branch '8294809.listener.helper' into 8245145.spinner.skin > - 8294809: whitespace > - 8294809: no public api > - ... and 41 more: https://git.openjdk.org/jfx/compare/e64e1292...c933b7b5 modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 267: > 265: @Override > 266: public void install() { > 267: getChildren().add(textField); `dispose()` method removes 3 children, whereas `install()` method adds only 1 child. Is this intentional? ------------- PR: https://git.openjdk.org/jfx/pull/904 From kpk at openjdk.org Tue Dec 6 11:25:44 2022 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Dec 2022 11:25:44 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: Message-ID: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Address review comment. Add comments for changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/965/files - new: https://git.openjdk.org/jfx/pull/965/files/26150c06..3e4de9c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=03-04 Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Tue Dec 6 11:25:49 2022 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Dec 2022 11:25:49 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 17:16:01 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 395: >> >>> 393: >>> 394: thumb.setOnMouseEntered(me -> { >>> 395: if (getSkinnable().getTooltip() != null && getSkinnable().getTooltip().isAutoHide()) { >> >> If I may suggest an edit in these two event handlers - create a local variable: >> >> >> Tooltip t = getSkinnable().getTooltip(); >> if (t != null && t.isAutoHide()) { >> tooltipConsumeAutoHidingEvents = t.getConsumeAutoHidingEvents(); >> t.setConsumeAutoHidingEvents(false); >> } > > Also, since the reason for this change is not immediately obvious, I'd add a comment explaining why (perhaps above tooltipConsumeAutoHidingEvents declaration, line 64?) Added above suggested edit and added comments ------------- PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Tue Dec 6 11:25:46 2022 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Dec 2022 11:25:46 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 12:48:14 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Update in mouse enter and exit events. Update in unit test I do not have a touchscreen machine as well. @aghaisas please check if bug given above is fixed. ------------- PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Tue Dec 6 11:25:52 2022 From: kpk at openjdk.org (Karthik P K) Date: Tue, 6 Dec 2022 11:25:52 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 17:18:12 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Update in mouse enter and exit events. Update in unit test > > tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java line 85: > >> 83: >> 84: private void dragSliderAfterTooltipDisplayed(int dragDistance) throws Exception { >> 85: Thread.sleep(1000); // Wait for slider to layout > > is there an equivalent of waitForIdle()? > > could we replace the sleep() with waiting for some event/property instead? Here I followed the same pattern used in other system tests such as TabPaneDragPolicyTest and ColorPickerTest. visibleProperty is present for slider but no function is available to handle the event when this peoperty changes. Please let me know if you have any suggestions. ------------- PR: https://git.openjdk.org/jfx/pull/965 From tsayao at openjdk.org Tue Dec 6 11:35:35 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 11:35:35 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v5] In-Reply-To: References: Message-ID: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request 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 29 additional commits since the last revision: - Use utility class. - Merge branch 'master' into 8296621_focus_stealing - Merge branch 'openjdk:master' into master - Add new line - Use JUnit 5 - Add test - 8296621 - Stage steals focus on scene change - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 19 more: https://git.openjdk.org/jfx/compare/7ef6332d...8ce83fde ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/39d74209..8ce83fde Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=03-04 Stats: 15933 lines in 1104 files changed: 6152 ins; 5286 del; 4495 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Tue Dec 6 11:35:39 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 11:35:39 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 05:09:40 GMT, Ambarish Rapte wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add new line > > tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 61: > >> 59: public static void initFX() throws Exception { >> 60: new Thread(() -> Application.launch(TestApp.class, (String[]) null)).start(); >> 61: waitForLatch(startupLatch, 10, "FX runtime failed to start."); > > With the changes made in #950, we have a new pattern for launch and exit. > These two lines would be now: `Util.launch(startupLatch, TestApp.class);` > and similarly exit method would be : `Util.shutdown(stage);` > and `waitForLatch` method can be removed. Done. ------------- PR: https://git.openjdk.org/jfx/pull/940 From aghaisas at openjdk.org Tue Dec 6 11:54:17 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Dec 2022 11:54:17 GMT Subject: RFR: 8295531: ComboBoxBaseSkin: memory leak when changing skin [v5] In-Reply-To: <8kMTyv8VfNQHAMuz_orxe_MRJHgumBka67F22JotxF4=.462c0147-4065-4719-82ab-a825d933ff95@github.com> References: <8kMTyv8VfNQHAMuz_orxe_MRJHgumBka67F22JotxF4=.462c0147-4065-4719-82ab-a825d933ff95@github.com> Message-ID: On Fri, 2 Dec 2022 17:35:05 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 166) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> Affected skins: >> - ColorPicker >> - DatePicker >> - ComboBox >> >> caused by: >> - out-of-order modification of the control property (skin.install) >> - adding skin nodes and not removing them in dispose() >> - adding listeners and not removing them in dispose() >> >> NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: > > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - 8295531: trying to avoid merge conflicts in the future > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into > 8295531.color.picker.skin > - Merge remote-tracking branch 'origin/master' into 8295531.color.picker.skin > - 8295531: whitespace > - 8295531: selection model leak > - Merge branch '8294809.listener.helper' into 8295531.color.picker.skin > - 8294809: generics > - ... and 46 more: https://git.openjdk.org/jfx/compare/e64e1292...06cf1dfc Fix Looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/922 From tsayao at openjdk.org Tue Dec 6 12:09:29 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 12:09:29 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Tue, 22 Nov 2022 01:40:02 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix View position I did some testing with Ubuntu 16.04 and it does have a bug on window staying behind. I think it's Unity specific, will fix it. Also, for some reason the window manager name is reporting as Compiz, and I did check for Unity. ------------- PR: https://git.openjdk.org/jfx/pull/915 From aghaisas at openjdk.org Tue Dec 6 12:31:08 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Dec 2022 12:31:08 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v4] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 11:21:08 GMT, Karthik P K wrote: > @aghaisas please check if bug given above is fixed. I tested the program provided in [JDK-8190411](https://bugs.openjdk.org/browse/JDK-8190411) with touch based Windows system. The proposed fix fixes the issue. For [JDK-8293916](https://bugs.openjdk.org/browse/JDK-8293916) 1. The bug does not have a reproducible test program. 2. It is reported that the bug does not occur on Windows system - and - I have a touch based Windows system. 3. It is reported that the bug is observed without ToolTip. This indicates that there exists another path to the reported NPE. My take is on this is - we need to close [JDK-8293916](https://bugs.openjdk.org/browse/JDK-8293916) as "incomplete" till a reproducible sample is provided. ------------- PR: https://git.openjdk.org/jfx/pull/965 From kcr at openjdk.org Tue Dec 6 12:39:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 12:39:19 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote: >> - Remove unsupported/unnecessary SuppressWarning annotations >> - Remove reduntant type specifications (use diamond operator) >> - Remove unused or duplicate imports >> - Remove unnecessary casts (type is already correct type or can be autoboxed) >> - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) >> - Remove redundant super interfaces (interface that is already inherited) >> - Remove unused type parameters >> - Remove declared checked exceptions that are never thrown >> - Add missing `@Override` annotations > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentations and merge short lines Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/960 From kcr at openjdk.org Tue Dec 6 12:39:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 12:39:19 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: <97bVdjM7niAbldUv3vvk0D4iRjMkmjoRVF2Eh713B9Q=.5db27ce2-4471-467e-80e2-0959b21751c9@github.com> References: <97bVdjM7niAbldUv3vvk0D4iRjMkmjoRVF2Eh713B9Q=.5db27ce2-4471-467e-80e2-0959b21751c9@github.com> Message-ID: <860We52-IoMrgWSnYuqIxtmTczgIa7GdsxKaxWI2P1I=.60804ba2-c0a3-4b6e-a629-b181edaee977@github.com> On Sat, 3 Dec 2022 20:46:22 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/LinuxStatefulMultiTouchProcessor.java line 42: >> >>> 40: >>> 41: private final Map slotToIDMap = >>> 42: new HashMap<>(); >> >> Same line. There are more places where this formatting can be fixed, but it's up to you. > > I'll only fix the lines that were touched, as there are many many places that could be written more succinct. Yes, tempting as it is to reformat an entire file, it's best to limit reformatting changes to the places you are otherwise modifying. ------------- PR: https://git.openjdk.org/jfx/pull/960 From kcr at openjdk.org Tue Dec 6 12:39:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 12:39:19 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: <02NLjmPVopQzOCmC4wMjwcS8boneHmhlMq_5WSsaHZg=.18d5f4bb-9df9-4f3f-9c2e-cb781e65766d@github.com> Message-ID: On Tue, 6 Dec 2022 06:33:20 GMT, Nir Lisker wrote: >> I agree with you - we shouldn't. > > This is an example of what I was talking about in [this comment](https://github.com/openjdk/jfx/pull/958#pullrequestreview-1198517697). I agree that no follow-on bug is needed. ------------- PR: https://git.openjdk.org/jfx/pull/960 From kcr at openjdk.org Tue Dec 6 12:46:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 12:46:22 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: <_DQQ4lSPil829-6Ko9n3j_CfUc_fKiG4i0cV7Yc-8A0=.0540cee2-d105-4c92-8ca0-84a266bab23a@github.com> References: <_DQQ4lSPil829-6Ko9n3j_CfUc_fKiG4i0cV7Yc-8A0=.0540cee2-d105-4c92-8ca0-84a266bab23a@github.com> Message-ID: On Tue, 6 Dec 2022 06:39:32 GMT, Nir Lisker wrote: >> Since this is an internal class (not public API), I won't object to this change. I do think it's a rather pointless change, but I'll leave it up to you. > > Personally, I find that re-declaring type hierarchy is clutter. I can see why sometimes you might want to emphasize a functionality of a class that already exists, but the IDE makes it rather easy, I find. In this particular case, it doesn't matter (especially since it's not public API), so I'm OK with the change. Where I _do_ think being more explicit is useful, is when a subclass `S` of a base class `B` wants to indicate that it has the property of being an instance of an interface `I` independent of whether or not its superclass `B` happens to implement `I`. ------------- PR: https://git.openjdk.org/jfx/pull/960 From kcr at openjdk.org Tue Dec 6 12:50:28 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 12:50:28 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 08:54:26 GMT, John Hendrikx wrote: >> I don't see it as a useful warning. The code isn't necessarily better without, and can be less clear. I think this might argue for asking Eclipse users to disable this warning in the IDE. > > @kevinrushforth Is this okay as it is? Even though the benefit of removing the cast here is minimal, removing it still seems better as it won't need to be suppressed later if we decide to enforce the rules as part of the build. In this specific case, there was no obvious way to "break" the code (by losing precision) by changing something unrelated (like changing `ptSize` to `double` or `long`). Yes, this is OK. ------------- PR: https://git.openjdk.org/jfx/pull/960 From duke at openjdk.org Tue Dec 6 12:52:04 2022 From: duke at openjdk.org (eduardsdv) Date: Tue, 6 Dec 2022 12:52:04 GMT Subject: Integrated: 8295324: JavaFX: Blank pages when printing In-Reply-To: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> References: <9oYbikhutI3xDjgm4ND3hQrgl_ZlahIzaS0xpT02TOk=.217afb96-c22a-4413-8db2-c9c1f9773f46@github.com> Message-ID: On Fri, 14 Oct 2022 15:45:10 GMT, eduardsdv wrote: > This fixes a race condition between application and 'Print Job Thread' threads when printing. > > The race condition occurs when application thread calls `endJob()`, which in effect sets the `jobDone` flag to true, > and when the 'Print Job Thread' thread was in the `synchronized` block in `waitForNextPage()` at that time. > The 'Print Job Thread' thread checks `jobDone` flag after exiting the `synchronized` block and, if it is true, skips the last page. > > In this fix, not only the `jobDone` is checked, but also that there is no other page to be printed. > It was also needed to introduce a new flag 'jobCanceled', to skip the page if the printing was canceled by 'cancelJob()'. This pull request has now been integrated. Changeset: 7b3c88b5 Author: Eduard Sedov Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/7b3c88b5aeb802c756056bc3bf9a167dc359f1ab Stats: 20 lines in 1 file changed: 8 ins; 0 del; 12 mod 8295324: JavaFX: Blank pages when printing Reviewed-by: prr, kcr ------------- PR: https://git.openjdk.org/jfx/pull/916 From jhendrikx at openjdk.org Tue Dec 6 14:28:12 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 14:28:12 GMT Subject: Integrated: JDK-8297413: Remove easy warnings in javafx.graphics In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 18:39:43 GMT, John Hendrikx wrote: > - Remove unsupported/unnecessary SuppressWarning annotations > - Remove reduntant type specifications (use diamond operator) > - Remove unused or duplicate imports > - Remove unnecessary casts (type is already correct type or can be autoboxed) > - Remove unnecessary semi-colons (at end of class definitions, or just repeated ones) > - Remove redundant super interfaces (interface that is already inherited) > - Remove unused type parameters > - Remove declared checked exceptions that are never thrown > - Add missing `@Override` annotations This pull request has now been integrated. Changeset: f333662a Author: John Hendrikx Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/f333662abe61a19a4d8a7b10ee4c409a22f2d63e Stats: 3226 lines in 619 files changed: 1262 ins; 461 del; 1503 mod 8297413: Remove easy warnings in javafx.graphics Reviewed-by: kcr, nlisker, angorya ------------- PR: https://git.openjdk.org/jfx/pull/960 From kcr at openjdk.org Tue Dec 6 14:30:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 14:30:29 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v5] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 11:35:35 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request 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 29 additional commits since the last revision: > > - Use utility class. > - Merge branch 'master' into 8296621_focus_stealing > - Merge branch 'openjdk:master' into master > - Add new line > - Use JUnit 5 > - Add test > - 8296621 - Stage steals focus on scene change > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 19 more: https://git.openjdk.org/jfx/compare/43f465a7...8ce83fde I still need to do a little more testing, but so far, the fix looks good to me. As for the test, I left an inline comment answering your question. More importantly, though, the test doesn't catch the bug. It passes both with and without your fix on all three platforms. ------------- PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Tue Dec 6 14:30:32 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 14:30:32 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: References: Message-ID: <49txN9f-ZEHyyCDIK8oDjRQSppGiXitrPCrlOaaj9XE=.a89669fd-b762-421d-b8ee-9eb2f3fed50a@github.com> On Tue, 6 Dec 2022 11:01:08 GMT, Thiago Milczarek Sayao wrote: >> tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 80: >> >>> 78: tl.setCycleCount(Animation.INDEFINITE); >>> 79: tl.getKeyFrames().addAll(new KeyFrame(Duration.millis(0), e -> stage.setScene(scene1)), >>> 80: new KeyFrame(Duration.millis(200), e -> stage.setScene(scene2))); >> >> With `Duration.millis(0)`, JavaFX gets no time to switch to `scene2`. We should allow some time for `stage.setScene(scene2)` to be processed. >> We can observe the behavior by commenting two lines 55 and 88, and adding a delay `Util.sleep(10000)` in `exit()` method : The `scene2` will never be seen on Window. >> I would recommend to change `Duration.millis(0)` to `Duration.millis(100)` OR any other duration with sufficient gap between the two Frames. > > I don't mind changing it, but I think those durations are relative, so `Duration.millis(0)` means "don't wait". I'm not sure I follow the recommendation. To expand on what Ambarish said, if you have a repeating timeline, any action that is done as part of a `KeyFrame` at time 0 will be executed immediately (with no delay) after an action that is done as part of the `KeyFrame` at time `last`. So in the current test (which mimics the manual test program submitted with the bug), what you have is: set scene 1 wait 200 msec set scene 2 set scene 1 // immediately after the previous wait 200 msec ... To do what you want, you might add a third "no-op" `KeyFrame` at time 400 (you could also change the time values for the two existing `KeyFrame`s to 200 and 400, respectively, but then no scene would be set for the first 200 msec of the test when the timeline first plays). ------------- PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Tue Dec 6 14:40:18 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 14:40:18 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v5] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 11:35:35 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request 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 29 additional commits since the last revision: > > - Use utility class. > - Merge branch 'master' into 8296621_focus_stealing > - Merge branch 'openjdk:master' into master > - Add new line > - Use JUnit 5 > - Add test > - 8296621 - Stage steals focus on scene change > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 19 more: https://git.openjdk.org/jfx/compare/3f2d3ce1...8ce83fde One other thing to note about the test, and also about the test case from the bug report on which it was based: The fact that the test sets the scene in rapid succession to two different values (at time = N, and immediately thereafter at time = 0) has uncovered a bug in JavaFX. I see an intermittent NPE in `Window::adjustSize` with a scene that is transiently null. I'll submit a new bug with a modified version of the test program attached to this bug. ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Tue Dec 6 16:24:27 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:24:27 GMT Subject: RFR: JDK-8297413: Remove easy warnings in javafx.graphics [v4] In-Reply-To: References: Message-ID: <9HYPWSv7HCUy853-TihINrJheFbwcL7UlmPzjcnOnA4=.69790f7b-fb35-4e0a-aa4d-247c7f71556a@github.com> On Tue, 6 Dec 2022 09:00:02 GMT, John Hendrikx wrote: >>> This is one giant pull request, somewhat difficult on the reviewers, especially since we have to go through it several times. >>> >>> It would be _much_ easier for the reviewers to deal with one fix per PR, especially in the cases where more than 30 files are going to be touched. >>> >>> For example, changes involving diamond operator and missing @OVERRIDES could have been made into two separate PRs, making it a breeze to review and integrate, while also cutting down on the number of files which contained non-trivial changes. >>> >>> What do you think? >> >> Agreed, they'll be smaller and more focused in the future. > >> @hjohn Kevin has outstanding requests. Even though you can technically integrate, you should resolve these with him. > > Yes, I will wait until @kevinrushforth had time to take another look. good job @hjohn ! ------------- PR: https://git.openjdk.org/jfx/pull/960 From angorya at openjdk.org Tue Dec 6 16:30:17 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:30:17 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 11:25:44 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment. Add comments for changes > Pre-submit test status Skipped ? Testing is not configured Please enable github actions, so the unit tests can be run automatically. ------------- PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Tue Dec 6 16:30:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:30:19 GMT Subject: Integrated: 8295531: ComboBoxBaseSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Tue, 18 Oct 2022 23:41:05 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 166) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > Affected skins: > - ColorPicker > - DatePicker > - ComboBox > > caused by: > - out-of-order modification of the control property (skin.install) > - adding skin nodes and not removing them in dispose() > - adding listeners and not removing them in dispose() > > NOTE: the fix will require not only ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) but also Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. This pull request has now been integrated. Changeset: bb139208 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/bb139208222d7c045be0a3c6f07ef15edcb1625b Stats: 185 lines in 6 files changed: 82 ins; 41 del; 62 mod 8295531: ComboBoxBaseSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/922 From mstrauss at openjdk.org Tue Dec 6 16:33:58 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Dec 2022 16:33:58 GMT Subject: RFR: 8297554: Remove Scene.KeyHandler [v2] In-Reply-To: References: Message-ID: > The `Scene.KeyHandler` class doesn't seem to have a clear purpose, mixing focus handling with event propagation. Since #852, `KeyHandler.setFocusVisible` is also called from mouse and touch event handlers, which makes the purpose of the class even less pronounced. > > Moving the focus-related functionality next to the other focus functions in the `Scene` class makes it easier to work with the code in the future. > > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, this code can be rolled into `Scene.processKeyEvent` and the now-empty `KeyHandler` class can be removed. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/962/files - new: https://git.openjdk.org/jfx/pull/962/files/14c66129..cb576505 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=962&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=962&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/962.diff Fetch: git fetch https://git.openjdk.org/jfx pull/962/head:pull/962 PR: https://git.openjdk.org/jfx/pull/962 From angorya at openjdk.org Tue Dec 6 16:38:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:38:31 GMT Subject: Integrated: 8295175: SplitPaneSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 22:44:10 GMT, Andy Goryachev wrote: > Fixed memory leak by removing all the listeners in dispose(); > > This PR depends on a new internal class ListenerHelper, a replacement for LambdaMultiplePropertyChangeListenerHandler. > See https://github.com/openjdk/jfx/pull/908 This pull request has now been integrated. Changeset: 6f36e704 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/6f36e7043299bfb9edf8befbca1e45a938077e4b Stats: 64 lines in 2 files changed: 26 ins; 17 del; 21 mod 8295175: SplitPaneSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/911 From angorya at openjdk.org Tue Dec 6 16:41:05 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:41:05 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v18] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: small delta - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: pref - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: step1 - 8293119: more integers - 8293119: more integers - 8293119: use integers for rounded values - 8293119: tester - ... and 61 more: https://git.openjdk.org/jfx/compare/6f36e704...0122d5fc ------------- Changes: https://git.openjdk.org/jfx/pull/897/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=17 Stats: 2340 lines in 14 files changed: 2079 ins; 250 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From mstrauss at openjdk.org Tue Dec 6 16:46:19 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Dec 2022 16:46:19 GMT Subject: RFR: 8297554: Remove Scene.KeyHandler [v3] In-Reply-To: References: Message-ID: > The `Scene.KeyHandler` class doesn't seem to have a clear purpose, mixing focus handling with event propagation. Since #852, `KeyHandler.setFocusVisible` is also called from mouse and touch event handlers, which makes the purpose of the class even less pronounced. > > Moving the focus-related functionality next to the other focus functions in the `Scene` class makes it easier to work with the code in the future. > > With the focus-related functions gone, `KeyHandler` only contains a single, small method that is called from `Scene.processKeyEvent`. For simplicity, this code can be rolled into `Scene.processKeyEvent` and the now-empty `KeyHandler` class can be removed. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into fixes/keyhandler-refactor - review changes - Removed KeyHandler ------------- Changes: https://git.openjdk.org/jfx/pull/962/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=962&range=02 Stats: 190 lines in 1 file changed: 84 ins; 89 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/962.diff Fetch: git fetch https://git.openjdk.org/jfx pull/962/head:pull/962 PR: https://git.openjdk.org/jfx/pull/962 From angorya at openjdk.org Tue Dec 6 16:52:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 16:52:42 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v18] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 16:41:05 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: > > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: small delta > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: pref > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: step1 > - 8293119: more integers > - 8293119: more integers > - 8293119: use integers for rounded values > - 8293119: tester > - ... and 61 more: https://git.openjdk.org/jfx/compare/6f36e704...0122d5fc Added a different algorithm for distributing small changes, which produces a better result that does not suffer from a few columns getting wider at the expense of others. ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Tue Dec 6 17:18:50 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 17:18:50 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v4] In-Reply-To: References: Message-ID: > Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. > > NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: - 8245145: clarification - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - 8245145: cleanup - 8245145: cleanup - 8245145: cleanup - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin - 8245145: listener helper - Merge branch '8294809.listener.helper' into 8245145.spinner.skin - ... and 43 more: https://git.openjdk.org/jfx/compare/6f36e704...f83fc9d6 ------------- Changes: https://git.openjdk.org/jfx/pull/904/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=904&range=03 Stats: 60 lines in 3 files changed: 35 ins; 12 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/904.diff Fetch: git fetch https://git.openjdk.org/jfx pull/904/head:pull/904 PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Tue Dec 6 17:18:53 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 17:18:53 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v3] In-Reply-To: References: Message-ID: <2Y5Jn_fCl9mvmEGhdlkEQ3DrJrAC9WBxIWoWS-ABJgg=.6676fbd0-8f66-4781-a619-5b8df9c63815@github.com> On Tue, 6 Dec 2022 11:20:51 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin >> - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin >> - 8245145: cleanup >> - 8245145: cleanup >> - 8245145: cleanup >> - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin >> - 8245145: listener helper >> - Merge branch '8294809.listener.helper' into 8245145.spinner.skin >> - 8294809: whitespace >> - 8294809: no public api >> - ... and 41 more: https://git.openjdk.org/jfx/compare/e64e1292...c933b7b5 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 267: > >> 265: @Override >> 266: public void install() { >> 267: getChildren().add(textField); > > `dispose()` method removes 3 children, whereas `install()` method adds only 1 child. Is this intentional? good question! yes, it is intentional - the textField, unlike the buttons, comes from the control, so when we change skins the old skin removes it in its dispose(), followed by the new skin adding it back in install(), as it cannot do that in the constructor. added a comment in the code to clarify ------------- PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Tue Dec 6 17:29:40 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 17:29:40 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v2] In-Reply-To: References: Message-ID: <8ggig7mq2APXOcxgZR5tyCdvy5huiuj9OfUczgXkXAY=.22fd273c-7eb8-4a5b-a086-7e6df0e2d3dd@github.com> > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - 8295809: cleanup - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - 8295809: cleanup - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - ... and 26 more: https://git.openjdk.org/jfx/compare/6f36e704...cfa05b79 ------------- Changes: https://git.openjdk.org/jfx/pull/931/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=931&range=01 Stats: 198 lines in 4 files changed: 93 ins; 77 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/931.diff Fetch: git fetch https://git.openjdk.org/jfx pull/931/head:pull/931 PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Tue Dec 6 17:29:41 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 17:29:41 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:06:26 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. @aghaisas could you please take a look at this PR? ------------- PR: https://git.openjdk.org/jfx/pull/931 From john at status6.com Tue Dec 6 17:37:27 2022 From: john at status6.com (John Neffenger) Date: Tue, 6 Dec 2022 09:37:27 -0800 Subject: Discussion: Reproducible builds Message-ID: <23c741b1-34b9-6a32-b84a-2ce7aaac6211@status6.com> This message continues the conversation I started with Johan in a random GitHub issue. :-) I'm posting it to the mailing list so that anyone can join the discussion with other questions or comments. > We're now using the github issue tracker to discuss reproducible builds, which is probably not the primary reason Github issues were created, so I think it's better to start this discussion on a mail thread :) Agreed, and thanks for the suggestion. In general, I find it difficult to stay silent when I witness situations like the following: - Thomas Reinhardt having to do "a little digging" to determine which JAR files are platform independent, when reproducible builds makes that self-evident because they're identical no matter which platform built them. - Reviewers having to figure out which refactoring might cause a change in the compiled output, when reproducible builds lets them make that distinction immediately. - Developers having to be timid and unsure about changes to our build system, when reproducible builds allows them be fearless and certain, even with radical changes. At a minimum, a reproducible build is a tool that makes some formerly difficult tasks easy. At best, a reproducible build is a superpower that reveals old bugs otherwise impossible to find.[1] Somewhere in the middle, it gives us our best chance to detect the supply-chain attacks that threaten a world increasingly dependent on software. > The majority of potential issues I see are on niche platforms with niche usecases. Creating reproducible builds for all these platforms sounds extremely difficult to me, but I'd like to be proven wrong. That would be difficult, but that's not what we're doing. The goal is not to make, for example, builds by Oracle and Gluon identical, nor builds on Ubuntu 18.04, Ubuntu 20.04, and Raspberry Pi OS identical. The goal is to allow each published build to be separately reproducible using the same dependencies as the original build. So those niche-platform corner cases are just additional builds, each one reproducible in its own unique environment. The goal of my pull request is even more modest: to allow any individual or organization, and especially the Linux distributions, to create reproducible builds of JavaFX. There's no plan to require reproducible builds -- just to permit them. Oracle, though, has already made the switch for the JDK. Builds of OpenJDK 20 and later will always create reproducible builds. In making the change, Magnus Ihse Bursie wrote, "If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one."[2] On that point, I couldn't agree more. John [1] https://github.com/openjdk/jdk/pull/10070#issuecomment-1230888930 [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997 From tsayao at openjdk.org Tue Dec 6 17:38:45 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 17:38:45 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v6] In-Reply-To: References: Message-ID: <9zioGQhbkSeGIs5l36FHbPOCKCAoenLqnTNM3b_aQXA=.3e13dfc5-40fe-45ba-a68e-46d30bb94fdb@github.com> > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix timeline ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/8ce83fde..bf0177b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Tue Dec 6 17:41:56 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 17:41:56 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v5] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 14:27:55 GMT, Kevin Rushforth wrote: > I still need to do a little more testing, but so far, the fix looks good to me. > > As for the test, I left an inline comment answering your question. More importantly, though, the test doesn't catch the bug. It passes both with and without your fix on all three platforms. That's odd, It does consistently fail/works for me when I add/remove `requestFocus()`. ------------- PR: https://git.openjdk.org/jfx/pull/940 From tsayao at openjdk.org Tue Dec 6 17:41:56 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 6 Dec 2022 17:41:56 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v4] In-Reply-To: <49txN9f-ZEHyyCDIK8oDjRQSppGiXitrPCrlOaaj9XE=.a89669fd-b762-421d-b8ee-9eb2f3fed50a@github.com> References: <49txN9f-ZEHyyCDIK8oDjRQSppGiXitrPCrlOaaj9XE=.a89669fd-b762-421d-b8ee-9eb2f3fed50a@github.com> Message-ID: On Tue, 6 Dec 2022 13:09:25 GMT, Kevin Rushforth wrote: >> I don't mind changing it, but I think those durations are relative, so `Duration.millis(0)` means "don't wait". I'm not sure I follow the recommendation. > > To expand on what Ambarish said, if you have a repeating timeline, any action that is done as part of a `KeyFrame` at time 0 will be executed immediately (with no delay) after an action that is done as part of the `KeyFrame` at time `last`. So in the current test (which mimics the manual test program submitted with the bug), what you have is: > > > set scene 1 > wait 200 msec > set scene 2 > set scene 1 // immediately after the previous > wait 200 msec > ... > > > To do what you want, you might add a third "no-op" `KeyFrame` at time 400 (you could also change the time values for the two existing `KeyFrame`s to 200 and 400, respectively, but then no scene would be set for the first 200 msec of the test when the timeline first plays). I've changed it as requested, but I must confess I didn't get the point. But don't waste time to explain, somewhere in the future it will become clear. ------------- PR: https://git.openjdk.org/jfx/pull/940 From jgneff at openjdk.org Tue Dec 6 17:55:17 2022 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 6 Dec 2022 17:55:17 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ?? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error Closing this pull request as we discussed in the previous comments. ------------- PR: https://git.openjdk.org/jfx/pull/488 From jgneff at openjdk.org Tue Dec 6 17:55:17 2022 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 6 Dec 2022 17:55:17 GMT Subject: Withdrawn: 8266396: Save VSCMD_DEBUG output in Windows build In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote: > The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. > > This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. > > This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. > > ### Before > > For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: > > > $ gradle sdk > Dependency verification is an incubating feature. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 4s > > > *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ?? > > ### After > > With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: > > > $ gradle sdk > Dependency verification is an incubating feature. > >> Configure project : > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > > ? > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 3s > > > *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/488 From jgneff at openjdk.org Tue Dec 6 18:04:39 2022 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 6 Dec 2022 18:04:39 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: <51ZmalS2DF_u82oZz9Q9TWiUYBpKqCjgZ3y-ZTRuwrs=.d5d15bb9-0b0b-46d8-b196-6af94e66bc72@github.com> On Sat, 7 May 2022 04:17:13 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 4 more: https://git.openjdk.org/jfx/compare/d69a498c...3fd4449b **Status update:** I'm waiting for the JavaFX build to switch to JDK 19. When that happens, I can add the one-line change that makes all JMOD archives reproducible. When I post the new test results, that would be a great time for a final review. Let's save the build path issue and any lingering problems with the WebKit shared library for follow-up bug reports and pull requests. I can start work on those as soon as this pull request is integrated. ------------- PR: https://git.openjdk.org/jfx/pull/446 From aghaisas at openjdk.org Tue Dec 6 18:04:33 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 6 Dec 2022 18:04:33 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v4] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 17:18:50 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: > > - 8245145: clarification > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: cleanup > - 8245145: cleanup > - 8245145: cleanup > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: listener helper > - Merge branch '8294809.listener.helper' into 8245145.spinner.skin > - ... and 43 more: https://git.openjdk.org/jfx/compare/6f36e704...f83fc9d6 Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Tue Dec 6 18:13:36 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 18:13:36 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v4] In-Reply-To: References: Message-ID: <0lawvPDcqd3rKNdH_noNxB6tc4s7sBkdXunuj5zfQRU=.5260974a-4b5a-423b-8d72-90d9339a8155@github.com> On Tue, 6 Dec 2022 17:18:50 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: > > - 8245145: clarification > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: cleanup > - 8245145: cleanup > - 8245145: cleanup > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: listener helper > - Merge branch '8294809.listener.helper' into 8245145.spinner.skin > - ... and 43 more: https://git.openjdk.org/jfx/compare/6f36e704...f83fc9d6 @nlisker or @kevinrushforth could you take a look please? ------------- PR: https://git.openjdk.org/jfx/pull/904 From jvos at openjdk.org Tue Dec 6 18:34:25 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 6 Dec 2022 18:34:25 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 04:17:13 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 4 more: https://git.openjdk.org/jfx/compare/d69a498c...3fd4449b The switch to JDK 19 requires an update of gradle first. Speaking of which, that is my main worry about this PR: we are increasing our dependency on Gradle by adding logic inside the build.gradle file. IMHO, the size of the build.gradle is related to the difficulty of building OpenJFX. I have no magic solution though for doing this completely outside the current build system. It might be something for another issue and PR to remove the maven artifact building from build.gradle and do it in another way. ------------- PR: https://git.openjdk.org/jfx/pull/446 From mhanl at openjdk.org Tue Dec 6 18:40:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Dec 2022 18:40:53 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Can anyone else check this out soon? :) ------------- PR: https://git.openjdk.org/jfx/pull/805 From kcr at openjdk.org Tue Dec 6 18:43:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 18:43:26 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:38:17 GMT, Marius Hanl wrote: > Can anyone else check this out soon? :) Sorry about the delay. I do want to see this go in soon, so yes, I can take a look. Perhaps @andy-goryachev-oracle can too? ------------- PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Tue Dec 6 19:01:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 19:01:25 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: <9WNzTZCCOFbTkMtXOD_nWJ55J-Xr8GH-8VmEPVv1O6M=.ac2de1cf-c35f-408f-b653-767d805c4804@github.com> On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing we also have https://github.com/openjdk/jfx/pull/938 ------------- PR: https://git.openjdk.org/jfx/pull/805 From jhendrikx at openjdk.org Tue Dec 6 19:37:18 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 19:37:18 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* Message-ID: - Added generics (to package private or internal classes only) - Minor clean-ups of code I touched (naming) - Fixed incorrect use of generics - Fixed raw type warnings Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. ------------- Commit messages: - Generics clean up javafx.beans.property.* and com.sun.javafx.property.* Changes: https://git.openjdk.org/jfx/pull/969/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298200 Stats: 139 lines in 38 files changed: 9 ins; 0 del; 130 mod Patch: https://git.openjdk.org/jfx/pull/969.diff Fetch: git fetch https://git.openjdk.org/jfx pull/969/head:pull/969 PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Tue Dec 6 19:37:18 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Dec 2022 19:37:18 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:12:39 GMT, John Hendrikx wrote: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. @nlisker early ping ------------- PR: https://git.openjdk.org/jfx/pull/969 From jgneff at openjdk.org Tue Dec 6 20:12:17 2022 From: jgneff at openjdk.org (John Neffenger) Date: Tue, 6 Dec 2022 20:12:17 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:32:19 GMT, Johan Vos wrote: > Speaking of which, that is my main worry about this PR: we are increasing our dependency on Gradle by adding logic inside the build.gradle file. You mean the 17-line `setFileTimestamps` method? I see that as the main issue, as all the other changes are trivial or just clean-up tasks: removing incorrect uses of tabs in Makefiles and finally fixing old `FIXME` notes, for example. The `setFileTimestamps` method actually removes a dependency on Gradle by setting the timestamps in a way that's consistent with the JDK itself, Apache Maven, and even Apache Ant. I was reluctant to add it, but it's the best solution I found to Kevin's review asking me **not** to use the hard-coded timestamps implemented by Gradle. As I implied in my message to the mailing list, this is the pull request that frees us from Gradle. ------------- PR: https://git.openjdk.org/jfx/pull/446 From angorya at openjdk.org Tue Dec 6 21:07:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 21:07:34 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Minor suggestion: to make it easier to review, please sync up with the master branch if the PR is out for a prolonged period. LGTM ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/805 From kcr at openjdk.org Tue Dec 6 23:02:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:02:19 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v6] In-Reply-To: References: Message-ID: <_3aLgtI-sObmMOvvz9RuQ-C-o1IbV5GXzLBFLIdoTjk=.2c4992fd-f5e1-4570-9abb-80ade2bea14e@github.com> On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Given how far behind your branch is from master, I agree with Andy that it would be helpful to merge the latest master so that we could see a GHA run and ensure no strange interactions. I'll approve it as is, though, since I did do a quick local test (on Windows only), and I always do such tests on a branch where I merge in the latest master. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/805 From kcr at openjdk.org Tue Dec 6 23:09:23 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:09:23 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 04:17:13 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 4 more: https://git.openjdk.org/jfx/compare/d69a498c...3fd4449b I like the direction of this PR, and am not overly concerned about the additional build logic. Btw, there are a pair of issues filed to update gradle to 7.6 and update the boot JDK to 19. > As I implied in my message to the mailing list, this is the pull request that frees us from Gradle. That sounds nice in theory, but in practice, it won't really do that. This is still something I'd like to see for JavaFX 20. ------------- PR: https://git.openjdk.org/jfx/pull/446 From kcr at openjdk.org Tue Dec 6 23:27:29 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:27:29 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: Message-ID: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> On Tue, 6 Dec 2022 11:25:44 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment. Add comments for changes Other than my general concern about not setting the value of a property that is under app control, this looks like it will work, unless the app binds to the property. See my comment inline. modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 404: > 402: // This is done to receive mouse pressed event on thumb and > 403: // inturn to detect start of drag. > 404: t.setConsumeAutoHidingEvents(false); In general, I'm not in favor of setting the value of a public property (for a few reasons). Have you considered alternative approaches? One thing to note is that this will be ineffective if the app binds to the `consumeAutoHidingEvents` property (unlikely as that might be). ------------- PR: https://git.openjdk.org/jfx/pull/965 From kcr at openjdk.org Tue Dec 6 23:32:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:32:19 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v6] In-Reply-To: <9zioGQhbkSeGIs5l36FHbPOCKCAoenLqnTNM3b_aQXA=.3e13dfc5-40fe-45ba-a68e-46d30bb94fdb@github.com> References: <9zioGQhbkSeGIs5l36FHbPOCKCAoenLqnTNM3b_aQXA=.3e13dfc5-40fe-45ba-a68e-46d30bb94fdb@github.com> Message-ID: On Tue, 6 Dec 2022 17:38:45 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix timeline It might be timing problem. I ran it a couple more times without the fix and it failed once (so it failed 2 out of 3 times). I'll test it again now that you've updated the test. ------------- PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Tue Dec 6 23:33:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:33:14 GMT Subject: RFR: 8296854: NULL check of CTFontCopyAvailableTables return value is required In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 21:18:38 GMT, Phil Race wrote: > Guard against de-referencing null, although it is currently theoretical as far as I can see (more info in the bug eval) Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/968 From kcr at openjdk.org Tue Dec 6 23:38:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:38:24 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v4] In-Reply-To: References: Message-ID: <9Ou7CpU11xepV2ncKTI7IWj9LxGTLYE2JzJPV4UGQcM=.a33efb0b-14b4-4179-b821-ad73e96c2eb1@github.com> On Tue, 6 Dec 2022 17:18:50 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: > > - 8245145: clarification > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: cleanup > - 8245145: cleanup > - 8245145: cleanup > - Merge remote-tracking branch 'origin/master' into 8245145.spinner.skin > - 8245145: listener helper > - Merge branch '8294809.listener.helper' into 8245145.spinner.skin > - ... and 43 more: https://git.openjdk.org/jfx/compare/6f36e704...f83fc9d6 Looks good with one minor formatting issue. modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 275: > 273: @Override > 274: public void dispose() { > 275: if(getSkinnable() == null) { Minor: add a space after the `if`. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Tue Dec 6 23:46:47 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Dec 2022 23:46:47 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v5] In-Reply-To: References: Message-ID: <1-nKONWYjQ_wQuEUNsSwf_E9Ggh1T4l9bu7y7GmjIL8=.b9258049-1600-476f-a446-a2a8b95d8280@github.com> > Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. > > NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8245145: space ------------- Changes: - all: https://git.openjdk.org/jfx/pull/904/files - new: https://git.openjdk.org/jfx/pull/904/files/f83fc9d6..5c4880af Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=904&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=904&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/904.diff Fetch: git fetch https://git.openjdk.org/jfx pull/904/head:pull/904 PR: https://git.openjdk.org/jfx/pull/904 From kcr at openjdk.org Tue Dec 6 23:46:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Dec 2022 23:46:48 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v5] In-Reply-To: <1-nKONWYjQ_wQuEUNsSwf_E9Ggh1T4l9bu7y7GmjIL8=.b9258049-1600-476f-a446-a2a8b95d8280@github.com> References: <1-nKONWYjQ_wQuEUNsSwf_E9Ggh1T4l9bu7y7GmjIL8=.b9258049-1600-476f-a446-a2a8b95d8280@github.com> Message-ID: <9FhU1u1d9g5mWc9UddrfU6Jbn4mytqG8_52xO1OKUs4=.97888538-bc9e-47f7-9c44-42ed734137a3@github.com> On Tue, 6 Dec 2022 23:39:51 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8245145: space Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/904 From prr at openjdk.org Wed Dec 7 00:19:17 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 7 Dec 2022 00:19:17 GMT Subject: Integrated: 8296854: NULL check of CTFontCopyAvailableTables return value is required In-Reply-To: References: Message-ID: On Mon, 5 Dec 2022 21:18:38 GMT, Phil Race wrote: > Guard against de-referencing null, although it is currently theoretical as far as I can see (more info in the bug eval) This pull request has now been integrated. Changeset: f96b3504 Author: Phil Race URL: https://git.openjdk.org/jfx/commit/f96b3504d364ce3baa42e46f5d7238b344791e08 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod 8296854: NULL check of CTFontCopyAvailableTables return value is required Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/968 From aghaisas at openjdk.org Wed Dec 7 02:23:16 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 7 Dec 2022 02:23:16 GMT Subject: RFR: 8245145: Spinner: throws IllegalArgumentException when replacing skin [v5] In-Reply-To: <1-nKONWYjQ_wQuEUNsSwf_E9Ggh1T4l9bu7y7GmjIL8=.b9258049-1600-476f-a446-a2a8b95d8280@github.com> References: <1-nKONWYjQ_wQuEUNsSwf_E9Ggh1T4l9bu7y7GmjIL8=.b9258049-1600-476f-a446-a2a8b95d8280@github.com> Message-ID: On Tue, 6 Dec 2022 23:46:47 GMT, Andy Goryachev wrote: >> Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. >> >> NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8245145: space Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/904 From kpk at openjdk.org Wed Dec 7 05:48:29 2022 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Dec 2022 05:48:29 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> References: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> Message-ID: <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> On Tue, 6 Dec 2022 23:21:55 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment. Add comments for changes > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 404: > >> 402: // This is done to receive mouse pressed event on thumb and >> 403: // inturn to detect start of drag. >> 404: t.setConsumeAutoHidingEvents(false); > > In general, I'm not in favor of setting the value of a public property (for a few reasons). Have you considered alternative approaches? One thing to note is that this will be ineffective if the app binds to the `consumeAutoHidingEvents` property (unlikely as that might be). I considered following 2 approaches. 1. Initializing `dragStart` in `layoutChildren` method as suggested in the bug. With this approach I was not able to get the exact mouse click position on the thumb. Thumb was lagging behind the cursor while dragging and thumb was also flickering when initialized with (`layoutX`, `layoutY`) values. 2. Initializing `dragStart` in `initialize` method. In this case also I was not able to get the mouse click position on the thumb. Tried initializing thumb with `layoutX` and `layoutY` values, this causes side effect of cursor moving to the (`layoutX`, `layoutY`) on dragging the thumb. Because of these side effects, considered above approach. Please let me know if you have any suggestions. ------------- PR: https://git.openjdk.org/jfx/pull/965 From aghaisas at openjdk.org Wed Dec 7 10:30:12 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 7 Dec 2022 10:30:12 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v2] In-Reply-To: <8ggig7mq2APXOcxgZR5tyCdvy5huiuj9OfUczgXkXAY=.22fd273c-7eb8-4a5b-a086-7e6df0e2d3dd@github.com> References: <8ggig7mq2APXOcxgZR5tyCdvy5huiuj9OfUczgXkXAY=.22fd273c-7eb8-4a5b-a086-7e6df0e2d3dd@github.com> Message-ID: On Tue, 6 Dec 2022 17:29:40 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 180) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> caused by: >> - adding and not removing listeners >> - adding and not removing event handlers/filters >> - adding and not removing cell factory >> - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only >> >> NOTES: >> 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. >> 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: > > - 8295809: cleanup > - Merge remote-tracking branch 'origin/master' into > 8295809.tree.table.view.skin > - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin > - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - 8295809: cleanup > - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin > - Merge remote-tracking branch 'origin/master' into > 8295806.table.view.skin > - ... and 26 more: https://git.openjdk.org/jfx/compare/6f36e704...cfa05b79 Marked as reviewed by aghaisas (Reviewer). I have identified the minor changes required. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 277: > 275: } > 276: > 277: @Ignore("JDK-8295809") // TODO probably need to verify the result of listener action, We need to file a follow-on bug to modify or cleanup these ignored tests in future. Use the bug ID of the newly filed bug with `@Ignore` tag for these two tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 235: > 233: > 234: // > 235: //PasswordField.class, This seems an unrelated change. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 238: > 236: > 237: // > 238: Spinner.class This seems an unrelated change. ------------- PR: https://git.openjdk.org/jfx/pull/931Changes requested by aghaisas (Reviewer). From kcr at openjdk.org Wed Dec 7 13:11:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 13:11:11 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v6] In-Reply-To: <9zioGQhbkSeGIs5l36FHbPOCKCAoenLqnTNM3b_aQXA=.3e13dfc5-40fe-45ba-a68e-46d30bb94fdb@github.com> References: <9zioGQhbkSeGIs5l36FHbPOCKCAoenLqnTNM3b_aQXA=.3e13dfc5-40fe-45ba-a68e-46d30bb94fdb@github.com> Message-ID: On Tue, 6 Dec 2022 17:38:45 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix timeline Yes, it is a timing problem, most likely related to the performance of my Ubuntu 20.04 VM. I left comments inline with two suggested changes (I think only the first is necessary, but setting iconify before the stage is shown may make the test more robust). With those changes, it fails reliably without your fix and passes reliably with your fix. tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 54: > 52: @Test > 53: void windowShouldRemainIconified() { > 54: Util.sleep(1000); I recommend changing this to 2000. tests/system/src/test/java/test/robot/javafx/scene/SceneChangeShouldNotFocusStageTest.java line 86: > 84: > 85: stage.show(); > 86: stage.setIconified(true); I recommend swapping these two statements. ------------- PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Wed Dec 7 13:32:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 13:32:13 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* In-Reply-To: References: Message-ID: <0G78v4e1WF7C9GM3ueLSBOsCvs39IDhvwPUeKaqwYyg=.a28e8540-75f3-4d48-ba7d-4feaf40f1354@github.com> On Tue, 6 Dec 2022 18:12:39 GMT, John Hendrikx wrote: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. Overall this looks good to me. > Minor clean-ups of code I touched (naming) This seems unnecessary, so I left an inline comment. > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see JavaBeanObjectPropertyBuilder. The javadoc would have the method signatures change ( would be appended to the affected methods). For now I've added a TODO there. Will you file a new bug for this? It will need a CSR, but seems a reasonble thing to do. modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/Disposer.java line 47: > 45: public class Disposer implements Runnable { > 46: private static final ReferenceQueue QUEUE = new ReferenceQueue<>(); > 47: private static final Map, Runnable> RECORDS = new ConcurrentHashMap<>(); I don't really care for the suggestion that most IDEs seem to offer of naming `static final` objects (as opposed to primitive types) using all caps. This should be left up to the developer, and in this case I think the existing names are fine and don't need to be changed. I note that this code was borrowed from Java2D where a similar fix was done to add the generics, but the names were left unchanged. ------------- PR: https://git.openjdk.org/jfx/pull/969 From tsayao at openjdk.org Wed Dec 7 13:41:37 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 7 Dec 2022 13:41:37 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v7] In-Reply-To: References: Message-ID: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Review recommendations ------------- Changes: - all: https://git.openjdk.org/jfx/pull/940/files - new: https://git.openjdk.org/jfx/pull/940/files/bf0177b9..35f657a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=940&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/940.diff Fetch: git fetch https://git.openjdk.org/jfx pull/940/head:pull/940 PR: https://git.openjdk.org/jfx/pull/940 From kcr at openjdk.org Wed Dec 7 13:55:17 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 13:55:17 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v7] In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 13:41:37 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review recommendations Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/940 From mstrauss at openjdk.org Wed Dec 7 14:10:15 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Dec 2022 14:10:15 GMT Subject: RFR: 8296621: Stage steals focus on scene change [v7] In-Reply-To: References: Message-ID: <7csKhTyemh-pDmIAyISmNYFbOSNvM-v7SQS3-7T_h7M=.322ea84d-b87d-4ff1-8b07-adf3355d7450@github.com> On Wed, 7 Dec 2022 13:41:37 GMT, Thiago Milczarek Sayao wrote: >> Simple fix to not requestFocus() on scene change. >> >> The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review recommendations Marked as reviewed by mstrauss (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/940 From nlisker at openjdk.org Wed Dec 7 15:10:28 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 7 Dec 2022 15:10:28 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* In-Reply-To: <0G78v4e1WF7C9GM3ueLSBOsCvs39IDhvwPUeKaqwYyg=.a28e8540-75f3-4d48-ba7d-4feaf40f1354@github.com> References: <0G78v4e1WF7C9GM3ueLSBOsCvs39IDhvwPUeKaqwYyg=.a28e8540-75f3-4d48-ba7d-4feaf40f1354@github.com> Message-ID: On Wed, 7 Dec 2022 13:25:47 GMT, Kevin Rushforth wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/Disposer.java line 47: > >> 45: public class Disposer implements Runnable { >> 46: private static final ReferenceQueue QUEUE = new ReferenceQueue<>(); >> 47: private static final Map, Runnable> RECORDS = new ConcurrentHashMap<>(); > > I don't really care for the suggestion that most IDEs seem to offer of naming `static final` objects (as opposed to primitive types) using all caps. This should be left up to the developer, and in this case I think the existing names are fine and don't need to be changed. I note that this code was borrowed from Java2D where a similar fix was done to add the generics, but the names were left unchanged. I only use all-uppercase if the collection itself is immutable. Here, the collections/wrapper are mutable, so I wouldn't change the names either. A matter of style. ------------- PR: https://git.openjdk.org/jfx/pull/969 From tsayao at openjdk.org Wed Dec 7 15:23:54 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 7 Dec 2022 15:23:54 GMT Subject: Integrated: 8296621: Stage steals focus on scene change In-Reply-To: References: Message-ID: <7GwFiBf8JOsR35z_bC3v3dA2Ov7i5PGQ6cGoTXZ_7gs=.36684aae-16ab-4503-a8d5-8285ab587635@github.com> On Wed, 9 Nov 2022 00:53:19 GMT, Thiago Milczarek Sayao wrote: > Simple fix to not requestFocus() on scene change. > > The attached bug sample shows that the TextField focused on the scene remains focused when the scene comes back. This pull request has now been integrated. Changeset: 5b0d3b55 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/5b0d3b554aa73d1e92a5f449a3f44808ab3b5f35 Stats: 94 lines in 2 files changed: 93 ins; 1 del; 0 mod 8296621: Stage steals focus on scene change Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/940 From angorya at openjdk.org Wed Dec 7 16:13:07 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 16:13:07 GMT Subject: Integrated: 8245145: Spinner: throws IllegalArgumentException when replacing skin In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:08:19 GMT, Andy Goryachev wrote: > Fixed SpinnerSkin initialization using new Skin.install(). Also in this PR - fixing memory leaks in SpinnerSkin by properly removing all listeners and event filters added in the constructor, as well as any child Nodes. > > NOTE: the fix requires both ListenerHelper [JDK-8294809](https://bugs.openjdk.org/browse/JDK-8294809) and Skin.install() [JDK-8290844](https://bugs.openjdk.org/browse/JDK-8290844) changes. This pull request has now been integrated. Changeset: 07e693b5 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/07e693b52f54dd92ee055de7c51f173902dda583 Stats: 60 lines in 3 files changed: 35 ins; 12 del; 13 mod 8245145: Spinner: throws IllegalArgumentException when replacing skin Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.org/jfx/pull/904 From angorya at openjdk.org Wed Dec 7 16:33:28 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 16:33:28 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v3] In-Reply-To: References: Message-ID: > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - 8295809: cleanup - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - Merge remote-tracking branch 'origin/master' into 8295806.table.view.skin - 8295809: cleanup - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin - ... and 27 more: https://git.openjdk.org/jfx/compare/07e693b5...4f40923a ------------- Changes: https://git.openjdk.org/jfx/pull/931/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=931&range=02 Stats: 197 lines in 4 files changed: 93 ins; 77 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/931.diff Fetch: git fetch https://git.openjdk.org/jfx pull/931/head:pull/931 PR: https://git.openjdk.org/jfx/pull/931 From kcr at openjdk.org Wed Dec 7 17:17:41 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 17:17:41 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> References: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> Message-ID: On Wed, 7 Dec 2022 05:46:23 GMT, Karthik P K wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 404: >> >>> 402: // This is done to receive mouse pressed event on thumb and >>> 403: // inturn to detect start of drag. >>> 404: t.setConsumeAutoHidingEvents(false); >> >> In general, I'm not in favor of setting the value of a public property (for a few reasons). Have you considered alternative approaches? One thing to note is that this will be ineffective if the app binds to the `consumeAutoHidingEvents` property (unlikely as that might be). > > I considered following 2 approaches. > > 1. Initializing `dragStart` in `layoutChildren` method as suggested in the bug. With this approach I was not able to get the exact mouse click position on the thumb. Thumb was lagging behind the cursor while dragging and thumb was also flickering when initialized with (`layoutX`, `layoutY`) values. > 2. Initializing `dragStart` in `initialize` method. In this case also I was not able to get the mouse click position on the thumb. Tried initializing thumb with `layoutX` and `layoutY` values, this causes side effect of cursor moving to the (`layoutX`, `layoutY`) on dragging the thumb. > Because of these side effects, considered above approach. > Please let me know if you have any suggestions. Thanks for the explanation. I don't have a better suggestion than what you propose, so let's proceed. It might be good to check whether the property is bound and skip setting it in the unlikely event that it is (save/restore the binding might be tricky and not something I can recall ever doing). ------------- PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Wed Dec 7 17:24:26 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 17:24:26 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> Message-ID: On Wed, 7 Dec 2022 17:15:03 GMT, Kevin Rushforth wrote: >> I considered following 2 approaches. >> >> 1. Initializing `dragStart` in `layoutChildren` method as suggested in the bug. With this approach I was not able to get the exact mouse click position on the thumb. Thumb was lagging behind the cursor while dragging and thumb was also flickering when initialized with (`layoutX`, `layoutY`) values. >> 2. Initializing `dragStart` in `initialize` method. In this case also I was not able to get the mouse click position on the thumb. Tried initializing thumb with `layoutX` and `layoutY` values, this causes side effect of cursor moving to the (`layoutX`, `layoutY`) on dragging the thumb. >> Because of these side effects, considered above approach. >> Please let me know if you have any suggestions. > > Thanks for the explanation. I don't have a better suggestion than what you propose, so let's proceed. It might be good to check whether the property is bound and skip setting it in the unlikely event that it is (save/restore the binding might be tricky and not something I can recall ever doing). Perhaps we can introduce another property - either public or internal to suppress consumption of auto-hiding events? The other aspect of this problem, as we discussed earlier, is that, in my opinion, the tooltips should really be transparent to mouse clicks. We do have this problem in Swing - if the tool tip overlaps a button , the user needs two clicks - first dismisses the tooltip and the other depresses the button. That will be a behavioral change. What do you think? ------------- PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Wed Dec 7 17:53:00 2022 From: kpk at openjdk.org (Karthik P K) Date: Wed, 7 Dec 2022 17:53:00 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes Message-ID: Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. Test: Added system test to validate the fix. ------------- Commit messages: - Correct line endings and file permission - Add system test to verify datePicker issue fix - Merge branch 'master' into datePicker_issue_fix - Fix for DatePicker wrong value update Changes: https://git.openjdk.org/jfx/pull/963/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295339 Stats: 184 lines in 2 files changed: 184 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/963.diff Fetch: git fetch https://git.openjdk.org/jfx pull/963/head:pull/963 PR: https://git.openjdk.org/jfx/pull/963 From angorya at openjdk.org Wed Dec 7 17:54:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 17:54:55 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v4] In-Reply-To: References: Message-ID: <_lwUO-A92a5qTjwSIsE_eRExz6K3thfLhMziPBUxEvs=.45fe3691-5e2e-40a8-a926-59206126adc5@github.com> > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8295809: updated tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/931/files - new: https://git.openjdk.org/jfx/pull/931/files/4f40923a..2a153d9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=931&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=931&range=02-03 Stats: 77 lines in 2 files changed: 16 ins; 55 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/931.diff Fetch: git fetch https://git.openjdk.org/jfx pull/931/head:pull/931 PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Wed Dec 7 17:54:59 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 17:54:59 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v2] In-Reply-To: References: <8ggig7mq2APXOcxgZR5tyCdvy5huiuj9OfUczgXkXAY=.22fd273c-7eb8-4a5b-a086-7e6df0e2d3dd@github.com> Message-ID: On Wed, 7 Dec 2022 10:16:36 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: >> >> - 8295809: cleanup >> - Merge remote-tracking branch 'origin/master' into >> 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - 8295809: cleanup >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - ... and 26 more: https://git.openjdk.org/jfx/compare/6f36e704...cfa05b79 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 235: > >> 233: >> 234: // >> 235: //PasswordField.class, > > This seems an unrelated change. since this is the last PR in the series of skin memory leak fixes, the code block will be removed. ------------- PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Wed Dec 7 17:56:56 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 17:56:56 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v2] In-Reply-To: References: <8ggig7mq2APXOcxgZR5tyCdvy5huiuj9OfUczgXkXAY=.22fd273c-7eb8-4a5b-a086-7e6df0e2d3dd@github.com> Message-ID: On Wed, 7 Dec 2022 10:25:50 GMT, Ajit Ghaisas wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: >> >> - 8295809: cleanup >> - Merge remote-tracking branch 'origin/master' into >> 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into 8295809.tree.table.view.skin >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - 8295809: cleanup >> - Merge branch '8295806.table.view.skin' into 8295809.tree.table.view.skin >> - Merge remote-tracking branch 'origin/master' into >> 8295806.table.view.skin >> - ... and 26 more: https://git.openjdk.org/jfx/compare/6f36e704...cfa05b79 > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 277: > >> 275: } >> 276: >> 277: @Ignore("JDK-8295809") // TODO probably need to verify the result of listener action, > > We need to file a follow-on bug to modify or cleanup these ignored tests in future. > Use the bug ID of the newly filed bug with `@Ignore` tag for these two tests. thank you for noticing! the tests are changed to validate functionality rather than implementation detail, i.e. that the tree table row skin tracks the virtual flow width with or without skin replacement. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinMemoryLeakTest.java line 238: > >> 236: >> 237: // >> 238: Spinner.class > > This seems an unrelated change. cleaned up. ------------- PR: https://git.openjdk.org/jfx/pull/931 From kcr at openjdk.org Wed Dec 7 20:18:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 20:18:48 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens Message-ID: On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. ------------- Commit messages: - 8251862: Wrong position of Popup windows at the intersection of 2 screens Changes: https://git.openjdk.org/jfx/pull/971/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=971&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8251862 Stats: 153 lines in 3 files changed: 150 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/971.diff Fetch: git fetch https://git.openjdk.org/jfx pull/971/head:pull/971 PR: https://git.openjdk.org/jfx/pull/971 From jgneff at openjdk.org Wed Dec 7 22:01:27 2022 From: jgneff at openjdk.org (John Neffenger) Date: Wed, 7 Dec 2022 22:01:27 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:32:19 GMT, Johan Vos wrote: > I have no magic solution though for doing this completely outside the current build system. @johanvos There is one magic solution for post-processing files outside of the build: the `strip-nondeterminism` program I mentioned at the top of this pull request. It won't fix nested archives, such as JAR files inside ZIP files, but it can fix those files individually (and JMOD archives, too). ------------- PR: https://git.openjdk.org/jfx/pull/446 From angorya at openjdk.org Wed Dec 7 22:02:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Dec 2022 22:02:32 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 20:12:56 GMT, Kevin Rushforth wrote: > On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. > > The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. > > The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. Tried PopupControlTest with two monitors on Mac; the secondary non-retina monitor is above the primary (retina). Most of the window is on top (secondary). Curiously, the window is shown on both monitors which seems to be a new functionality on Mac (mine is Monterey 12.5.1) - previously it would always show a clipped window on one monitor. Invoking the content menu popup by right-clicking on the last visible text line on the top monitor, actually expecting the popup to be visible on the top monitor. It does, however, appear on the primary screen, sharp, while the underlying portion of the application is rendered a bit fuzzy, see the screenshot. Questions: - isn't the popup expected to be shown on top where the right click happened? - should the bottom portion of the application be rendered using retina quality? - Screen Shot 2022-12-07 at 13 52 33 ------------- PR: https://git.openjdk.org/jfx/pull/971 From kcr at openjdk.org Wed Dec 7 23:17:32 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Dec 2022 23:17:32 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 20:12:56 GMT, Kevin Rushforth wrote: > On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. > > The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. > > The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. This particular bug and PR is Windows-specific, although it would be helpful to know what happens on Mac. I tried macOS 12.5.1 and macOS 12.6.1, and by default, windows only show on one screen or the other, so it doesn't look like a new setting. I checked to see whether there is an option to enable windows to span two displays, and there is (uncheck "Displays have separate spaces" in the "Mission Control" panel), but we don't have any special code on macOS to handle this. Anything we do for Mac would be a separate issue. ------------- PR: https://git.openjdk.org/jfx/pull/971 From kcr at openjdk.org Thu Dec 8 00:20:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 00:20:26 GMT Subject: RFR: 8251862: Wrong position of Popup windows at the intersection of 2 screens In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 20:12:56 GMT, Kevin Rushforth wrote: > On Windows platforms with more than one screen, a PopupWindow created for a Stage that straddles two windows will be drawn with an incorrect position and screen scale if the majority of the Stage is on one screen, and the popup is positioned on the other screen. In this case, the Stage is drawn using the screen scale of the screen that most of the window is on, while the popup is drawn using the scale of the screen that it is (typically entirely) on. > > The most common way this can happen is when you have two screens of a different scale with the secondary screen on the left or above the primary screen. If you position the Stage such that most of it is still on the primary screen (thus the Stage is drawn using the scale of the primary screen), with a menu, a control with a context menu, or a control with a Tooltip now on the secondary screen, the popup window for the menu or Tooltip will be drawn using the screen scale of the secondary window and thus won't be positioned or sized correctly relative to the menu bar, or control in the main window. > > The fix implemented by this PR is to always use the screen of the owner window, including the screen scales, when rendering a popup window. This matches the behavior of native Windows apps, such as Notepad. As a note for reviewers: While testing this I found a few cases where it clamps the position of a popup drawn on the second monitor near the edges to something closer to the middle of the screen. This might be a separate issue (my guess is that it probably is), but be on the look out for anything odd in your testing. ------------- PR: https://git.openjdk.org/jfx/pull/971 From kcr at openjdk.org Thu Dec 8 03:12:11 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 03:12:11 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> Message-ID: On Wed, 7 Dec 2022 17:21:48 GMT, Andy Goryachev wrote: >> Thanks for the explanation. I don't have a better suggestion than what you propose, so let's proceed. It might be good to check whether the property is bound and skip setting it in the unlikely event that it is (save/restore the binding might be tricky and not something I can recall ever doing). > > Perhaps we can introduce another property - either public or internal to suppress consumption of auto-hiding events? > > The other aspect of this problem, as we discussed earlier, is that, in my opinion, the tooltips should really be transparent to mouse clicks. We do have this problem in Swing - if the tool tip overlaps a button , the user needs two clicks - first dismisses the tooltip and the other depresses the button. That will be a behavioral change. > > What do you think? Whatever we decide for this particular bug fix, I agree that we should reexamine whether tooltips should be transparent to mouse clicks by default. As for this bug fix, I wouldn't want to introduce a new public property, so that leaves either the currently proposed solution of saving / restoring the existing public property, or adding an internal property. If this new internal property could be somehow limited to Tooltip, that might be OK; otherwise it could be pretty intrusive. ------------- PR: https://git.openjdk.org/jfx/pull/965 From mhanl at openjdk.org Thu Dec 8 09:45:52 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 09:45:52 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v7] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Added other ticket as reference in javadoc - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin  Conflicts:  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java - Enable tests again - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing ------------- Changes: https://git.openjdk.org/jfx/pull/805/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=06 Stats: 109 lines in 8 files changed: 98 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From mhanl at openjdk.org Thu Dec 8 10:12:36 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 10:12:36 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:45:52 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Just merged in the latest master to be safe. :) ------------- PR: https://git.openjdk.org/jfx/pull/805 From kpk at openjdk.org Thu Dec 8 10:34:34 2022 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Dec 2022 10:34:34 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Add check whether consumeAutoHidingEventsProperty is bound ------------- Changes: - all: https://git.openjdk.org/jfx/pull/965/files - new: https://git.openjdk.org/jfx/pull/965/files/3e4de9c2..883fcf55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=965&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/965.diff Fetch: git fetch https://git.openjdk.org/jfx pull/965/head:pull/965 PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Thu Dec 8 10:40:15 2022 From: kpk at openjdk.org (Karthik P K) Date: Thu, 8 Dec 2022 10:40:15 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v5] In-Reply-To: References: <85_M3yJr38BsEezjmK6im1Qd8vUWOJlF04aD6n8VVpk=.981f74cc-09a7-4987-8e19-6cf03e35fe53@github.com> <6fk7eOQkSks49tHiD8XBXpsVkNTyXJXpNMIXmZPYtGY=.6230595e-8d14-4557-abd0-3cb144bb83b4@github.com> Message-ID: <3UFWHr6TDQhERDVgCOAqrTO0Y68U0DcdjNmujUNBw_E=.4280be88-c5ce-44df-b9a1-884350bdf47b@github.com> On Thu, 8 Dec 2022 03:10:06 GMT, Kevin Rushforth wrote: >> Perhaps we can introduce another property - either public or internal to suppress consumption of auto-hiding events? >> >> The other aspect of this problem, as we discussed earlier, is that, in my opinion, the tooltips should really be transparent to mouse clicks. We do have this problem in Swing - if the tool tip overlaps a button , the user needs two clicks - first dismisses the tooltip and the other depresses the button. That will be a behavioral change. >> >> What do you think? > > Whatever we decide for this particular bug fix, I agree that we should reexamine whether tooltips should be transparent to mouse clicks by default. > > As for this bug fix, I wouldn't want to introduce a new public property, so that leaves either the currently proposed solution of saving / restoring the existing public property, or adding an internal property. If this new internal property could be somehow limited to Tooltip, that might be OK; otherwise it could be pretty intrusive. Updated code to check whether `consumeAutoHidingEventsProperty` is bound and skip the property value change in mouse entered and exited event handlers. Since we need to recheck the behavior of tooltip, I would like to keep the above proposed solution for the time being. ------------- PR: https://git.openjdk.org/jfx/pull/965 From tsayao at openjdk.org Thu Dec 8 11:41:15 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 8 Dec 2022 11:41:15 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Tue, 22 Nov 2022 01:40:02 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix View position About Ubuntu 16.04 I've done some research and it's a compiz bug (window showing behind). There are some "work-arounds" on glass-gtk code for Unity/Compiz (which are "ugly"). Since those are old and not maintained anymore and Ubuntu 16.04 reached [end-of-life ](https://ubuntu.com/about/release-cycle) (it's on extended support), my proposal is to remove those work-arounds. Thoughts? ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Thu Dec 8 13:14:37 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 13:14:37 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:45:52 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/805 From kcr at openjdk.org Thu Dec 8 13:31:15 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 13:31:15 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. @jaybhaskar Please review @johanvos @tiainen Do you want to do a test build? ------------- PR: https://git.openjdk.org/jfx/pull/953 From jhendrikx at openjdk.org Thu Dec 8 14:21:45 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 8 Dec 2022 14:21:45 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Revert renames in Disposer ------------- Changes: - all: https://git.openjdk.org/jfx/pull/969/files - new: https://git.openjdk.org/jfx/pull/969/files/fd77fea2..69d15ee1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/969.diff Fetch: git fetch https://git.openjdk.org/jfx pull/969/head:pull/969 PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Thu Dec 8 14:21:47 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 8 Dec 2022 14:21:47 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: <0G78v4e1WF7C9GM3ueLSBOsCvs39IDhvwPUeKaqwYyg=.a28e8540-75f3-4d48-ba7d-4feaf40f1354@github.com> Message-ID: <9C3xd-vBFfkgF-vSnKX_wNidYbNm-0W9B43KpN7MU6A=.dae3c414-30dd-49ed-a032-6449b09367de@github.com> On Wed, 7 Dec 2022 15:08:00 GMT, Nir Lisker wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/Disposer.java line 47: >> >>> 45: public class Disposer implements Runnable { >>> 46: private static final ReferenceQueue QUEUE = new ReferenceQueue<>(); >>> 47: private static final Map, Runnable> RECORDS = new ConcurrentHashMap<>(); >> >> I don't really care for the suggestion that most IDEs seem to offer of naming `static final` objects (as opposed to primitive types) using all caps. This should be left up to the developer, and in this case I think the existing names are fine and don't need to be changed. I note that this code was borrowed from Java2D where a similar fix was done to add the generics, but the names were left unchanged. > > I only use all-uppercase if the collection itself is immutable. Here, the collections/wrapper are mutable, so I wouldn't change the names either. A matter of style. I reverted these changes. ------------- PR: https://git.openjdk.org/jfx/pull/969 From jvos at openjdk.org Thu Dec 8 14:24:33 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 8 Dec 2022 14:24:33 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Tue, 22 Nov 2022 01:40:02 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix View position > About Ubuntu 16.04 > re old and not maintained anymore and Ubuntu 16.04 reached [end-of-life ](https://ubuntu.com/about/release-cycle) (it's on > > extended support), my proposal is to remove those work-arounds. If it is only on Ubuntu 16.04, I am ok with not doing an ugly work-around. There is no crash or similar critical issue, and if we get this PR in the next OpenJFX release, it will be 7 years after 16.04. However, from the remark from @kevinrushforth I understand that it occurs on other distributions as well? Or did I misunderstand it? ------------- PR: https://git.openjdk.org/jfx/pull/915 From jhendrikx at openjdk.org Thu Dec 8 14:37:16 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 8 Dec 2022 14:37:16 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 14:21:45 GMT, John Hendrikx wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Revert renames in Disposer > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see JavaBeanObjectPropertyBuilder. The javadoc would have the method signatures change ( would be appended to the affected methods). For now I've added a TODO there. > > Will you file a new bug for this? It will need a CSR, but seems a reasonble thing to do. @kevinrushforth I've filed https://bugs.openjdk.org/browse/JDK-8298392 ------------- PR: https://git.openjdk.org/jfx/pull/969 From aghaisas at openjdk.org Thu Dec 8 14:54:03 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 8 Dec 2022 14:54:03 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 09:45:52 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/805 From aghaisas at openjdk.org Thu Dec 8 14:58:29 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 8 Dec 2022 14:58:29 GMT Subject: RFR: 8295809: TreeTableViewSkin: memory leak when changing skin [v4] In-Reply-To: <_lwUO-A92a5qTjwSIsE_eRExz6K3thfLhMziPBUxEvs=.45fe3691-5e2e-40a8-a926-59206126adc5@github.com> References: <_lwUO-A92a5qTjwSIsE_eRExz6K3thfLhMziPBUxEvs=.45fe3691-5e2e-40a8-a926-59206126adc5@github.com> Message-ID: On Wed, 7 Dec 2022 17:54:55 GMT, Andy Goryachev wrote: >> as determined by SkinMemoryLeakTest (remove line 180) and a leak tester >> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java >> >> caused by: >> - adding and not removing listeners >> - adding and not removing event handlers/filters >> - adding and not removing cell factory >> - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only >> >> NOTES: >> 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. >> 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8295809: updated tests Thanks for fixing the tests. Fix looks good now. This will have some conflict with https://github.com/openjdk/jfx/pull/805 fix though. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Thu Dec 8 16:08:17 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 16:08:17 GMT Subject: Integrated: 8295809: TreeTableViewSkin: memory leak when changing skin In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:06:26 GMT, Andy Goryachev wrote: > as determined by SkinMemoryLeakTest (remove line 180) and a leak tester > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/apps/LeakTest.java > > caused by: > - adding and not removing listeners > - adding and not removing event handlers/filters > - adding and not removing cell factory > - holding unnecessary instance in TreeTableViewSkin.treeTableViewSkin // test-only > > NOTES: > 1. this fix requires JDK-8294809 ListenerHelper and JDK-8295806 TableViewSkin. > 2. there were more memory leaks in this skin than detected by SkinMemoryLeakTest, probably because of cell factory (?). A manual test using LeakTest shows that there are no memory leaks after a) replacing skin, b) moving the components to a new window, and c) removing all the components from the window. This pull request has now been integrated. Changeset: 6abbe080 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/6abbe0803456ad648117b8e72deeeeced7cb5231 Stats: 262 lines in 4 files changed: 104 ins; 127 del; 31 mod 8295809: TreeTableViewSkin: memory leak when changing skin Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/931 From angorya at openjdk.org Thu Dec 8 16:15:49 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 16:15:49 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v7] In-Reply-To: References: Message-ID: <9PXjmkXpWqpHsgxC_kRWhP6rUpzlbeeoMc5GF6nmcQs=.05cb1ad7-eab3-41a2-9265-32069855ec15@github.com> On Thu, 8 Dec 2022 09:45:52 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing the changes look good, please resolve the conflict - my https://github.com/openjdk/jfx/pull/931 got integrated first, sorry. ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Thu Dec 8 16:16:58 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 16:16:58 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v14] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: cleanup - 8187145: also tree table view - 8187145: whitespace - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8187145: review comments - 8187145: github - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - ... and 11 more: https://git.openjdk.org/jfx/compare/6abbe080...5093f056 ------------- Changes: https://git.openjdk.org/jfx/pull/876/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=13 Stats: 469 lines in 15 files changed: 378 ins; 12 del; 79 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From mhanl at openjdk.org Thu Dec 8 17:50:15 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 17:50:15 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v8] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin  Conflicts:  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Added other ticket as reference in javadoc - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin  Conflicts:  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java - Enable tests again - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener - ... and 1 more: https://git.openjdk.org/jfx/compare/6abbe080...54f24a7f ------------- Changes: https://git.openjdk.org/jfx/pull/805/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=07 Stats: 109 lines in 8 files changed: 96 ins; 5 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From kcr at openjdk.org Thu Dec 8 18:01:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 18:01:33 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v8] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 17:50:15 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - ... and 1 more: https://git.openjdk.org/jfx/compare/6abbe080...54f24a7f Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Thu Dec 8 18:06:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 18:06:42 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v8] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 17:50:15 GMT, Marius Hanl wrote: >> Initialize the `(Tree)TableView` when creating the measure row. >> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). >> >> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. >> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 >> >> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Added other ticket as reference in javadoc > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > >  Conflicts: >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java >  modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java > - Enable tests again > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin > - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing > - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup > - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener > - ... and 1 more: https://git.openjdk.org/jfx/compare/6abbe080...54f24a7f lgtm ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/805 From angorya at openjdk.org Thu Dec 8 18:06:43 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 18:06:43 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 12:42:15 GMT, Karthik P K wrote: > Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. > > Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. > > Test: Added system test to validate the fix. Marked as reviewed by angorya (Committer). tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 61: > 59: * 4. Verify that selected date is updated in the date picker. > 60: */ > 61: minor: unnecessary newline. otherwise, very solid code. thank you Karthik! ------------- PR: https://git.openjdk.org/jfx/pull/963 From angorya at openjdk.org Thu Dec 8 18:15:58 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Dec 2022 18:15:58 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v14] In-Reply-To: References: Message-ID: <3yQnwfMPH-XP34EyZ38bi1aiT4c5Wx3RSrPs84DaYDg=.6fb216b7-6b72-4bd6-96b1-eba4ca526e74@github.com> On Thu, 8 Dec 2022 16:16:58 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: cleanup > - 8187145: also tree table view > - 8187145: whitespace > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: review comments > - 8187145: github > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - ... and 11 more: https://git.openjdk.org/jfx/compare/6abbe080...5093f056 @Maran23 would you review this please? ------------- PR: https://git.openjdk.org/jfx/pull/876 From jvos at openjdk.org Thu Dec 8 18:21:43 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 8 Dec 2022 18:21:43 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. Doing a test build + sanity tests ------------- PR: https://git.openjdk.org/jfx/pull/953 From mhanl at openjdk.org Thu Dec 8 18:29:48 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 18:29:48 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: > The problem here is, that the `AnchorPane` does not use its snapped insets. > Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. > > Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. > Line 2995 in `modena.css`: > > .titled-pane > .content > AnchorPane { > -fx-padding: 0.8em; > } > > which translates to 9.6px. > > EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - 8295078: Snap anchors as well - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry  Conflicts:  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java - 8295078: Replace JUnit4 with Junit5 imports - 8295078: Adjusted Copyright year - 8295078: TextField blurry when inside an TitledPane -> AnchorPane ------------- Changes: https://git.openjdk.org/jfx/pull/910/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=910&range=03 Stats: 184 lines in 3 files changed: 153 ins; 6 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/910.diff Fetch: git fetch https://git.openjdk.org/jfx pull/910/head:pull/910 PR: https://git.openjdk.org/jfx/pull/910 From kcr at openjdk.org Thu Dec 8 18:53:48 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 18:53:48 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v30] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Thu, 8 Dec 2022 14:20:22 GMT, Johan Vos wrote: > If it is only on Ubuntu 16.04, I am ok with not doing an ugly work-around. There is no crash or similar critical issue, and if we get this PR in the next OpenJFX release, it will be 7 years after 16.04. I agree. > However, from the remark from @kevinrushforth I understand that it occurs on other distributions as well? Or did I misunderstand it? Our results on the two other distros we tried -- Ubuntu 20.04 and Ubuntu 22.04 -- show no regressions. The iconify tests fail intermittently on most distros, and fail pretty consistently on 22.04, with or without this fix. I discovered a compiz setting that will workaround this problem (setting Focus Prevention Level to OFF in compiz config settings tool). Manual testing looks good, and I am rerunning the automated tests. Even if it doesn't fix everything, this workaround allows JavaFX to remain usable on 16.04. And even if it didn't, I don't think that would be a reason to block this fix. I am testing one other old distro -- Oracle Linux 7.7 -- I'll post results when done. ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Thu Dec 8 19:00:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Dec 2022 19:00:12 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 12:42:15 GMT, Karthik P K wrote: > Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. > > Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. > > Test: Added system test to validate the fix. Looks fine. I did a quick test on Windows and it fails without the fix and passes with the fix. I left a couple comments inline. The main question is whether we might need a small delay after the mouse click before checking the value. tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 25: > 23: * questions. > 24: */ > 25: package test.robot.javafx.scene; Minor: as long as you are removing the blank like Andy pointed out, you can add a missing blank line here. :) tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 121: > 119: datePicker.getLayoutY() + datePicker.getHeight() * Y_FACTOR); > 120: > 121: Assert.assertFalse(LocalDate.now().isEqual(datePicker.getValue())); Do you need a small sleep here? It works for me without it on Windows, but I haven't tried it on my slow Ubuntu 20.04 VM. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/963 From mhanl at openjdk.org Thu Dec 8 19:10:47 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 19:10:47 GMT Subject: RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:29:48 GMT, Marius Hanl wrote: >> The problem here is, that the `AnchorPane` does not use its snapped insets. >> Therefore, the fix is to replace all `getInsets().getXXX` calls with their corresponding `snappedXXXInset()` methods. >> >> Note: The reason the `AnchorPane` inside a `TitledPane` is blurry in the first place is because a `TitledPane` applies padding to its content. >> Line 2995 in `modena.css`: >> >> .titled-pane > .content > AnchorPane { >> -fx-padding: 0.8em; >> } >> >> which translates to 9.6px. >> >> EDIT: This is btw a good example of the JUnit 5 feature `@ParameterizedTest` with `@ValueSource` > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - 8295078: Snap anchors as well > - Merge branch 'master' of https://github.com/openjdk/jfx into 8295078-textfield-blurry > >  Conflicts: >  modules/javafx.graphics/src/test/java/test/javafx/scene/layout/AnchorPaneTest.java > - 8295078: Replace JUnit4 with Junit5 imports > - 8295078: Adjusted Copyright year > - 8295078: TextField blurry when inside an TitledPane -> AnchorPane I thought about this one more time. Example: - render scale of 1.25 (125%). - `Control` with a width of 200px - `left inset` = 10, `right inset` = 15 - `left anchor` = 10, `right anchor` = 15 Now the UI would look like this currently: [`Left inset` = 10.4][`Left anchor` = 10.4][`Control` = 148.8][`Right anchor` = 15.2][`Right inset` = 15.2] Control width is calculated like this: 200 - 10.4 - 15.2 - 10.4 - 15.2 = 148.8 If we would not snap intermediate values, the left side (inset + anchor) would be 20 instead of 20.8. The right side would still be 30.4. Thinking about this again, isn't the current behaviour what we would expect from the layout with a scale of 1.25? Snapping 'intermediate' values seems logical to me (current vehaviour), but maybe I'm missing something. But we should avoid snapping things more than one time. ------------- PR: https://git.openjdk.org/jfx/pull/910 From mhanl at openjdk.org Thu Dec 8 19:15:15 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 19:15:15 GMT Subject: Integrated: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 17:06:39 GMT, Marius Hanl wrote: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events. This pull request has now been integrated. Changeset: c900a00c Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/c900a00c7527f290e8047792fef4b45002930892 Stats: 109 lines in 8 files changed: 96 ins; 5 del; 8 mod 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize 8292009: Wrong text artifacts in table header Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/805 From tsayao at openjdk.org Thu Dec 8 19:20:30 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 8 Dec 2022 19:20:30 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v31] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Unity uses Compiz ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/06bb05e2..e87b75fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=30 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=29-30 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From mhanl at openjdk.org Thu Dec 8 19:25:15 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 8 Dec 2022 19:25:15 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 12:42:15 GMT, Karthik P K wrote: > Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. > > Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. > > Test: Added system test to validate the fix. modules/javafx.controls/src/main/java/javafx/scene/control/skin/DatePickerSkin.java line 145: > 143: show(); > 144: } else { > 145: updateDisplayNode(); Can the call to `updateDisplayNode();` be removed in line 128 then? Just asking, since `updateDisplayNode();` is now called two times. But it looks like this is also still needed.. ------------- PR: https://git.openjdk.org/jfx/pull/963 From jvos at openjdk.org Thu Dec 8 20:53:16 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 8 Dec 2022 20:53:16 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. Marked as reviewed by jvos (Reviewer). Looks good on darwin-x86_64, linux and windows. Didn't test darwin-aarch64. ------------- PR: https://git.openjdk.org/jfx/pull/953 From jbhaskar at openjdk.org Fri Dec 9 03:22:08 2022 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 9 Dec 2022 03:22:08 GMT Subject: RFR: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. + looks ok to me ------------- Marked as reviewed by jbhaskar (Author). PR: https://git.openjdk.org/jfx/pull/953 From kpk at openjdk.org Fri Dec 9 06:53:46 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 06:53:46 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: > Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. > > Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. > > Test: Added system test to validate the fix. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/963/files - new: https://git.openjdk.org/jfx/pull/963/files/7b9448f8..7f7eb42b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=963&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=963&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/963.diff Fetch: git fetch https://git.openjdk.org/jfx pull/963/head:pull/963 PR: https://git.openjdk.org/jfx/pull/963 From kpk at openjdk.org Fri Dec 9 06:53:48 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 06:53:48 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:21:14 GMT, Marius Hanl wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/DatePickerSkin.java line 145: > >> 143: show(); >> 144: } else { >> 145: updateDisplayNode(); > > Can the call to `updateDisplayNode();` be removed in line 128 then? > Just asking, since `updateDisplayNode();` is now called two times. But it looks like this is also still needed.. I believe `updateDisplayNode()` in line 128 is required as it is the event handler on `valueProperty`. ------------- PR: https://git.openjdk.org/jfx/pull/963 From kpk at openjdk.org Fri Dec 9 06:53:52 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 06:53:52 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:53:48 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 25: > >> 23: * questions. >> 24: */ >> 25: package test.robot.javafx.scene; > > Minor: as long as you are removing the blank like Andy pointed out, you can add a missing blank line here. :) Added new line > tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 121: > >> 119: datePicker.getLayoutY() + datePicker.getHeight() * Y_FACTOR); >> 120: >> 121: Assert.assertFalse(LocalDate.now().isEqual(datePicker.getValue())); > > Do you need a small sleep here? It works for me without it on Windows, but I haven't tried it on my slow Ubuntu 20.04 VM. Even I checked on Windows machine itself which is quite good in configuration. Added small delay of 400ms similar to the delay present where we wait for date picker popup. ------------- PR: https://git.openjdk.org/jfx/pull/963 From kpk at openjdk.org Fri Dec 9 06:53:53 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 06:53:53 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:04:24 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > tests/system/src/test/java/test/robot/javafx/scene/DatePickerUpdateOnAlertCloseTest.java line 61: > >> 59: * 4. Verify that selected date is updated in the date picker. >> 60: */ >> 61: > > minor: unnecessary newline. > > otherwise, very solid code. thank you Karthik! Removed new line. Thanks Andy. ------------- PR: https://git.openjdk.org/jfx/pull/963 From mhanl at openjdk.org Fri Dec 9 08:48:19 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 9 Dec 2022 08:48:19 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 06:49:55 GMT, Karthik P K wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/DatePickerSkin.java line 145: >> >>> 143: show(); >>> 144: } else { >>> 145: updateDisplayNode(); >> >> Can the call to `updateDisplayNode();` be removed in line 128 then? >> Just asking, since `updateDisplayNode();` is now called two times. But it looks like this is also still needed.. > > I believe `updateDisplayNode()` in line 128 is required as it is the event handler on `valueProperty`. I think so too. ------------- PR: https://git.openjdk.org/jfx/pull/963 From kpk at openjdk.org Fri Dec 9 09:38:05 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 09:38:05 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 10:34:34 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add check whether consumeAutoHidingEventsProperty is bound Hi All, All the changes mentioned in the review are now addressed. Please review. ------------- PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Fri Dec 9 09:51:09 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 9 Dec 2022 09:51:09 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 06:53:46 GMT, Karthik P K wrote: >> Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. >> >> Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. >> >> Test: Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Hi All, Looks like the PR went back to RFR when changes are updated. Please review the same. ------------- PR: https://git.openjdk.org/jfx/pull/963 From hmeda at openjdk.org Fri Dec 9 13:02:39 2022 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 9 Dec 2022 13:02:39 GMT Subject: Integrated: JDK-8295755 : Update SQLite to 3.39.4 In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:16:34 GMT, Hima Bindu Meda wrote: > Updated sqlite to v3.39.4 > Verified build on windows, linux and mac. > Sanity testing looks fine. This pull request has now been integrated. Changeset: 9f6ec88b Author: Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/9f6ec88b222461da9486911ecefb68a936e5fc77 Stats: 11694 lines in 4 files changed: 5822 ins; 1215 del; 4657 mod 8295755: Update SQLite to 3.39.4 Reviewed-by: arapte, jvos, jbhaskar ------------- PR: https://git.openjdk.org/jfx/pull/953 From kcr at openjdk.org Fri Dec 9 14:18:10 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 14:18:10 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 06:53:46 GMT, Karthik P K wrote: >> Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. >> >> Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. >> >> Test: Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/963 From angorya at openjdk.org Fri Dec 9 16:09:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 16:09:06 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 06:53:46 GMT, Karthik P K wrote: >> Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. >> >> Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. >> >> Test: Added system test to validate the fix. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments lgtm ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/963 From angorya at openjdk.org Fri Dec 9 16:34:25 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 16:34:25 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 10:34:34 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add check whether consumeAutoHidingEventsProperty is bound lgtm modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 410: > 408: thumb.setOnMouseExited(me -> { > 409: Tooltip t = getSkinnable().getTooltip(); > 410: if (t != null && t.isAutoHide() && !t.consumeAutoHidingEventsProperty().isBound()) { I still think a second property or a boolean might be better. What if the app code binds autoHidingEventsProperty after onMouseEntered? I know this is highly unlikely, but there is a potential. At the same time, I think we should proceed with this fix as it addresses a problem which occurs always. ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/965 From kcr at openjdk.org Fri Dec 9 17:36:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 17:36:24 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v31] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Thu, 8 Dec 2022 19:20:30 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unity uses Compiz I don't see any new problems on Oracle Linux 7.7. Two additional observations: 1. While doing some additional testing, I did discover a regression introduced by this patch (unrelated to your most recent commit). A stage that set to iconified before it is shown, is not iconified with your patch. This behavior happens on all distros I've tested it on. It turns out that we don't have a test that checked this case -- or rather we didn't until `SceneChangeShouldNotFocusStageTest` was added by PR #940 as part of the fix for JDK-8296621. That test now fails consistently with this patch. A simple "HelloWorld" program with `stage.setIconified(true);` called before showing the stage reproduces this bug. This needs to be fixed before this PR can be integrated.

2. I figured out why `IconifiedTest` is so fragile on Linux. It looks like there is an intermittent (or, on some distros, not-so-intermittent) bug when showing two stages that are both always-on-top. The expectation is that if there is more than one Stage that is always-on-top, they will be stacked in the order they were created. It seems like this isn't always the case. The IconifyTest program creates a "bottom" and a "top" stages with both set to always-on-top. If I modify IconifyTest to call `getStage(false)` for the bottom stage, meaning it won't be always-on-top, the test passes for me consistently on Ubuntu 20.04. This is unrelated to your patch, but fixing the test will make it easier to verify that there is no regression introduced by your patch. Follow-on issues: * related to point 1 above, I think we need new test cases to check showing stages that are initially {iconified,maximized,fullscreen}, so I'll file a follow-on test bug. * related to point 2 above, I'll file a pair of additional follow-on bugs: a test bug to fix `IconifyTest` to make it more robust, and a product bug to track the problem of stacking order for multiple always-on-top windows. ------------- PR: https://git.openjdk.org/jfx/pull/915 From nlisker at openjdk.org Fri Dec 9 18:10:10 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 9 Dec 2022 18:10:10 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 14:21:45 GMT, John Hendrikx wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Revert renames in Disposer I see that you moved the generic type declarations from the inner classes to the outer ones. I wasn't getting any raw type warnings on these. What requires these? modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java line 177: > 175: if (bean.equals(propertyChangeEvent.getSource()) && name.equals(propertyChangeEvent.getPropertyName())) { > 176: final ReadOnlyJavaBeanProperty property = checkRef(); > 177: if ((property instanceof Property) && (((Property)property).isBound()) && !updating) { This line can be if ((property instanceof Property prop) && prop.isBound() && !updating) { with perhaps better naming. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java line 119: > 117: > 118: @SuppressWarnings("unchecked") > 119: final List list = (List)obj; // safe cast as elements are only referenced I'm not sure why it's safe to cast to a `List`. You're getting a `List`, but it could be a list of something else. In the `Map` and `Set` variants there is a try-catch for casting exceptions. ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Fri Dec 9 18:38:50 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Dec 2022 18:38:50 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 17:47:33 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert renames in Disposer > > modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java line 119: > >> 117: >> 118: @SuppressWarnings("unchecked") >> 119: final List list = (List)obj; // safe cast as elements are only referenced > > I'm not sure why it's safe to cast to a `List`. You're getting a `List`, but it could be a list of something else. In the `Map` and `Set` variants there is a try-catch for casting exceptions. It's safe as you're never actually using the type `E`, but I suppose the 2nd list can also be `List` as only `equals` is called on it. The 2nd `ListIterator` would then also be `ListIterator`. Casting to a specific generic type (like `List`) never verifies if all the elements are of that type, you're just telling the compiler that they are. Only when you do something like: E e = list.get(0); ... you may get a CCE here (but the compiler allowed it because you casted it to `List` earlier). That's why I say it is safe because the follow up code does not do any such action (it in fact does `Object o2 = e2.next()` -- it would be bad if it was `E o2 = e2.next`). Looking at it again, I think making the 2nd `List` a `List` is better, as we don't know yet at that stage that they all are of type `E` (even though it doesn't matter for the code following it). ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Fri Dec 9 18:38:52 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Dec 2022 18:38:52 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 18:35:28 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java line 119: >> >>> 117: >>> 118: @SuppressWarnings("unchecked") >>> 119: final List list = (List)obj; // safe cast as elements are only referenced >> >> I'm not sure why it's safe to cast to a `List`. You're getting a `List`, but it could be a list of something else. In the `Map` and `Set` variants there is a try-catch for casting exceptions. > > It's safe as you're never actually using the type `E`, but I suppose the 2nd list can also be `List` as only `equals` is called on it. The 2nd `ListIterator` would then also be `ListIterator`. > > Casting to a specific generic type (like `List`) never verifies if all the elements are of that type, you're just telling the compiler that they are. > > Only when you do something like: > > E e = list.get(0); > > ... you may get a CCE here (but the compiler allowed it because you casted it to `List` earlier). That's why I say it is safe because the follow up code does not do any such action (it in fact does `Object o2 = e2.next()` -- it would be bad if it was `E o2 = e2.next`). > > Looking at it again, I think making the 2nd `List` a `List` is better, as we don't know yet at that stage that they all are of type `E` (even though it doesn't matter for the code following it). It also removes the need for the `SuppressWarnings` here. ------------- PR: https://git.openjdk.org/jfx/pull/969 From nlisker at openjdk.org Fri Dec 9 18:46:14 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 9 Dec 2022 18:46:14 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 18:35:57 GMT, John Hendrikx wrote: >> It's safe as you're never actually using the type `E`, but I suppose the 2nd list can also be `List` as only `equals` is called on it. The 2nd `ListIterator` would then also be `ListIterator`. >> >> Casting to a specific generic type (like `List`) never verifies if all the elements are of that type, you're just telling the compiler that they are. >> >> Only when you do something like: >> >> E e = list.get(0); >> >> ... you may get a CCE here (but the compiler allowed it because you casted it to `List` earlier). That's why I say it is safe because the follow up code does not do any such action (it in fact does `Object o2 = e2.next()` -- it would be bad if it was `E o2 = e2.next`). >> >> Looking at it again, I think making the 2nd `List` a `List` is better, as we don't know yet at that stage that they all are of type `E` (even though it doesn't matter for the code following it). > > It also removes the need for the `SuppressWarnings` here. I suggest the following method: @Override public boolean equals(Object obj) { if (this == obj) { return true; } if (!(obj instanceof List list)) { return false; } if (size() != list.size()) { return false; } ListIterator e1 = listIterator(); ListIterator e2 = list.listIterator(); while (e1.hasNext() && e2.hasNext()) { if (!Objects.equals(e1.next(), e2.next())) { return false; } } return true; } Technically, there's no need to check `hasNext` on both since they have the same length, but it doesn't matter. I also don't like the names `e1` and `e2` for list iterators :) ------------- PR: https://git.openjdk.org/jfx/pull/969 From kcr at openjdk.org Fri Dec 9 19:25:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 19:25:55 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v31] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Thu, 8 Dec 2022 19:20:30 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unity uses Compiz I filed the following three follow-up bugs: https://bugs.openjdk.org/browse/JDK-8298496 https://bugs.openjdk.org/browse/JDK-8298499 https://bugs.openjdk.org/browse/JDK-8298500 I think the first of these (fixing `IconifyTest` to be more robust) is important in validating this PR. ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Fri Dec 9 19:43:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 19:43:55 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v18] In-Reply-To: References: Message-ID: <8nEDnLp3z1Xi6UBTcSEaOr1QjeszLZ0kve6o9-TaOds=.952b2698-04c7-46a0-b323-1222fd956979@github.com> On Tue, 6 Dec 2022 16:41:05 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: > > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: small delta > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: pref > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: step1 > - 8293119: more integers > - 8293119: more integers > - 8293119: use integers for rounded values > - 8293119: tester > - ... and 61 more: https://git.openjdk.org/jfx/compare/6f36e704...0122d5fc I left a few minor doc comments. The docs otherwise looks good to me. modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 64: > 62: public double getContentWidth() { > 63: // not available in the base class > 64: throw new UnsupportedOperationException("method not available in the base class"); Since the default implementation of this method throws `UnsupportedOperationException`, I recommend documenting that subclasses must override this method. modules/javafx.controls/src/main/java/javafx/scene/control/ResizeFeaturesBase.java line 76: > 74: public Control getTableControl() { > 75: // not available in the base class > 76: throw new UnsupportedOperationException("method not available in the base class"); Ditto. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 400: > 398: /** > 399: * A policy that tries to adjust other columns in order to fit the table width. > 400: *

For all of the constrained policies, I would say `A resize policy that adjusts...`. I think the word "resize" is important in the first sentence, and I don't think you need to say "tries", since it will adjust it, subject to the minimum size of the columns being adjusted (and the details of what happens when it hits the limit are explained later). Also, I don't think the `

` is really needed after the first sentence. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 401: > 399: * A policy that tries to adjust other columns in order to fit the table width. > 400: *

> 401: * During UI adjustment, proportionately resizes all columns. You might want to add `to preserve the total width` here since you say it for some of the other policies. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 413: > 411: > 412: /** > 413: * A policy that tries to adjust last column in order to fit the table width. That should be "_the_ last column" modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 415: > 413: * A policy that tries to adjust last column in order to fit the table width. > 414: *

> 415: * During UI adjustment, resizes the last column only. You might want to add `to preserve the total width` here since you say it for some of the other policies. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 427: > 425: > 426: /** > 427: * A policy adjusts the next column in the opposite way in order to fit the table width. I would remove "in the opposite way" here, since it is equally true of most of the other policies, and is covered later. When looking at just the summary list of the first sentences for each policy I think it reads better without it. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 429: > 427: * A policy adjusts the next column in the opposite way in order to fit the table width. > 428: *

> 429: * During UI adjustment, resizes the next column the opposite way. Here, it seems OK to say "the opposite way", since it adds more information. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 443: > 441: * A policy that tries to adjust subsequent columns in order to fit the table width. > 442: *

> 443: * During UI adjustment, resizes subsequent columns to preserve the total width. Maybe say `proportionately resizes...` to match the language in `CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS`? ------------- PR: https://git.openjdk.org/jfx/pull/897 From jhendrikx at openjdk.org Fri Dec 9 20:05:53 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Dec 2022 20:05:53 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 18:06:21 GMT, Nir Lisker wrote: > I see that you moved the generic type declarations from the inner classes to the outer ones. I wasn't getting any raw type warnings on these. What requires these? I checked, it's not strictly required. I tried to make all of these classes more generic, but ran into problems and reverted some of it. The change to move the type parameter was apparently not strictly needed. It makes sense though, the descriptors are factories for non-static listeners. When the factory carries the type information then everything that is produced is of the correct type. The factory can make its `getType` method return `Class` there as well then. The change makes it possible to write `DescriptorCleanerListener` with a type parameter as well, so that you can enforce that its descriptor and listener parameter are for the same type, instead of: DescriptorListenerCleaner(ReadOnlyPropertyDescriptor pd, ReadOnlyPropertyDescriptor.ReadOnlyListener l); You get a tighter constructor: DescriptorListenerCleaner(ReadOnlyPropertyDescriptor pd, ReadOnlyPropertyDescriptor.ReadOnlyListener l); I think its still an improvement, but not strictly raw type fixing after I reverted my other changes. ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Fri Dec 9 20:13:52 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 9 Dec 2022 20:13:52 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> On Fri, 9 Dec 2022 18:40:09 GMT, Nir Lisker wrote: >> It also removes the need for the `SuppressWarnings` here. > > I suggest the following method: > > > @Override > public boolean equals(Object obj) { > if (this == obj) { > return true; > } > if (!(obj instanceof List otherList)) { > return false; > } > if (size() != otherList.size()) { > return false; > } > ListIterator e1 = listIterator(); > ListIterator e2 = otherList.listIterator(); > while (e1.hasNext() && e2.hasNext()) { > if (!Objects.equals(e1.next(), e2.next())) { > return false; > } > } > return true; > } > > > Technically, there's no need to check `hasNext` on both since they have the same length, but it doesn't matter. > > I also don't like the names `e1` and `e2` for list iterators :) There is a lot to not like about this method. Especially because apparently you can pass in a `List` to this equals method that is for a `ReadOnlyListProperty`. How is a list equal to a property? What sense does it make to do this: ReadOnlyListProperty x; x.equals(List.of("a", "b", "c")); Shouldn't that be: x.get().equals(List.of("a", "b", "c")); ? ------------- PR: https://git.openjdk.org/jfx/pull/969 From nlisker at openjdk.org Fri Dec 9 20:22:11 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 9 Dec 2022 20:22:11 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> References: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> Message-ID: On Fri, 9 Dec 2022 20:11:24 GMT, John Hendrikx wrote: >> I suggest the following method: >> >> >> @Override >> public boolean equals(Object obj) { >> if (this == obj) { >> return true; >> } >> if (!(obj instanceof List otherList)) { >> return false; >> } >> if (size() != otherList.size()) { >> return false; >> } >> ListIterator e1 = listIterator(); >> ListIterator e2 = otherList.listIterator(); >> while (e1.hasNext() && e2.hasNext()) { >> if (!Objects.equals(e1.next(), e2.next())) { >> return false; >> } >> } >> return true; >> } >> >> >> Technically, there's no need to check `hasNext` on both since they have the same length, but it doesn't matter. >> >> I also don't like the names `e1` and `e2` for list iterators :) > > There is a lot to not like about this method. Especially because apparently you can pass in a `List` to this equals method that is for a `ReadOnlyListProperty`. How is a list equal to a property? What sense does it make to do this: > > ReadOnlyListProperty x; > > x.equals(List.of("a", "b", "c")); > > Shouldn't that be: > > x.get().equals(List.of("a", "b", "c")); > > ? I was just going to write that now that I look at it, this is a list comparison according to `List::equals`. No need to redo the whole logic.. About the validity of the comparison, `ReadOnlyListProperty` also implements `List`: ReadOnlyListProperty extends ListExpression ListExpression implements ObservableListValue ObservableListValue extends ObservableObjectValue>, ObservableList ObservableList extends List, Observable So... it's also a list. ------------- PR: https://git.openjdk.org/jfx/pull/969 From angorya at openjdk.org Fri Dec 9 21:03:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 21:03:16 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: Message-ID: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - 8293119: review comments - Merge remote-tracking branch 'origin/master' into 8293119.constrained - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: small delta - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: pref - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: step1 - 8293119: more integers - 8293119: more integers - ... and 63 more: https://git.openjdk.org/jfx/compare/9f6ec88b...bb2d069c ------------- Changes: https://git.openjdk.org/jfx/pull/897/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=18 Stats: 2331 lines in 14 files changed: 2070 ins; 250 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Fri Dec 9 21:25:49 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 21:25:49 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Fri, 9 Dec 2022 21:03:16 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: > > - 8293119: review comments > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: small delta > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: pref > - Merge remote-tracking branch 'origin/master' into 8293119.constrained > - 8293119: step1 > - 8293119: more integers > - 8293119: more integers > - ... and 63 more: https://git.openjdk.org/jfx/compare/9f6ec88b...bb2d069c The docs look good. Go ahead and update the CSR and move it to Proposed. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 452: > 450: /** > 451: * A resize policy that adjusts columns, starting with the next one, in order to fit the table width. > 452: *

Minor: you can remote this `

`, too. ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Fri Dec 9 21:28:35 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 21:28:35 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Fri, 9 Dec 2022 21:17:18 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: >> >> - 8293119: review comments >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - 8293119: small delta >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - 8293119: pref >> - Merge remote-tracking branch 'origin/master' into 8293119.constrained >> - 8293119: step1 >> - 8293119: more integers >> - 8293119: more integers >> - ... and 63 more: https://git.openjdk.org/jfx/compare/9f6ec88b...bb2d069c > > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 452: > >> 450: /** >> 451: * A resize policy that adjusts columns, starting with the next one, in order to fit the table width. >> 452: *

> > Minor: you can remote this `

`, too. I liked it with `

` : - ) ------------- PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Fri Dec 9 21:35:24 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Dec 2022 21:35:24 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Fri, 9 Dec 2022 21:25:55 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 452: >> >>> 450: /** >>> 451: * A resize policy that adjusts columns, starting with the next one, in order to fit the table width. >>> 452: *

>> >> Minor: you can remote this `

`, too. > > I liked it with `

` : - ) It should at least be consistent with the rest of them. The formatting (with or without the `

`) is something we could ask others to weigh in on, too. I don't care too much, one way or the other. ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Fri Dec 9 21:45:13 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 21:45:13 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Fri, 9 Dec 2022 21:33:08 GMT, Kevin Rushforth wrote: >> I liked it with `

` : - ) > > It should at least be consistent with the rest of them. > > The formatting (with or without the `

`) is something we could ask others to weigh in on, too. I don't care too much, one way or the other. consistent - the other policies have two paragraphs, see TableView : 382 and 483 ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Fri Dec 9 21:53:31 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 21:53:31 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: <3srFkRsqJut9gFaXm4eOGGBGoNEIj_ARJeEs7X5fq_c=.71881c72-c787-4624-8588-5515c06cd564@github.com> On Thu, 8 Dec 2022 10:34:34 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add check whether consumeAutoHidingEventsProperty is bound lgtm ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/965 From angorya at openjdk.org Fri Dec 9 22:46:07 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Dec 2022 22:46:07 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: <12RQiak12oHmP0l_Q42mgJR1wTjIWMS8fJykLOri4LE=.4354096c-aee9-436d-a9c6-8373a94630c3@github.com> On Fri, 9 Dec 2022 21:23:21 GMT, Kevin Rushforth wrote: > The docs look good. Go ahead and update the CSR and move it to Proposed. JDK-8294398 updated, please take a look. ------------- PR: https://git.openjdk.org/jfx/pull/897 From tsayao at openjdk.org Sat Dec 10 00:50:09 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 10 Dec 2022 00:50:09 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v31] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: <8KYCpOQYu8aQ6cGJmx65rDv5AZtwVZbLkf4ZDCa5M5U=.7e4b17f0-427a-46cf-b56a-022e883e1f31@github.com> On Thu, 8 Dec 2022 19:20:30 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Unity uses Compiz It does make sense to start a window minimized, but does it make sense to call `show()` and still be minimized (I think to myself)? About the always on top, the current Linux solution is a little bit "hacky". I was thinking about a follow-up patch that reworks it. ------------- PR: https://git.openjdk.org/jfx/pull/915 From jhendrikx at openjdk.org Sat Dec 10 08:05:59 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Dec 2022 08:05:59 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> Message-ID: On Fri, 9 Dec 2022 20:19:57 GMT, Nir Lisker wrote: > So... it's also a list. I think it's a big mess, you can already see that in the hierarchy, extending both `ObservableObjectValue>` (which is `ObservableValue`) but also being a `ObservableList`. One or the other is going to break; either it is a property containing a list, or it is a list, it can't be both. Either I can do: listProperty.equals(normalList); or: listProperty.equals(aNormalPropertyContainingAList); It looks like the first was chosen (I suppose because the `List` interface defines `equals` in that way) and the 2nd case will break (and is unfixable as equals needs to be symmetric). Looking a bit further, I think extending `ObservableObjectValue>` was a mistake here. It's also what contributes to making the collection properties so confusing (ie. you can replace all elements, or you can replace the entire list, which are two different actions that require two different forms of listeners) -- no other properties allow you to replace it's "container" -- ie. if properties had used an `AtomicReference` internally to store their value, they would not offer me the option to replace either the entire `AtomicReference` or only the value of the reference. ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sat Dec 10 08:23:07 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Dec 2022 08:23:07 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v3] In-Reply-To: References: Message-ID: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: - Adjusted ReadOnlyListProperty#equals to be a bit more modern Java - Remove SuppressWarnings in ReadOnlyListProperty - Use assignment in instanceof ------------- Changes: - all: https://git.openjdk.org/jfx/pull/969/files - new: https://git.openjdk.org/jfx/pull/969/files/69d15ee1..b55d9479 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=01-02 Stats: 19 lines in 2 files changed: 5 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/969.diff Fetch: git fetch https://git.openjdk.org/jfx pull/969/head:pull/969 PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sat Dec 10 08:23:08 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Dec 2022 08:23:08 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:38:02 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert renames in Disposer > > modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java line 177: > >> 175: if (bean.equals(propertyChangeEvent.getSource()) && name.equals(propertyChangeEvent.getPropertyName())) { >> 176: final ReadOnlyJavaBeanProperty property = checkRef(); >> 177: if ((property instanceof Property) && (((Property)property).isBound()) && !updating) { > > This line can be > > if ((property instanceof Property prop) && prop.isBound() && !updating) { > > with perhaps better naming. Yes, good suggestion, changed. ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sat Dec 10 08:23:08 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Dec 2022 08:23:08 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> Message-ID: On Sat, 10 Dec 2022 08:03:27 GMT, John Hendrikx wrote: >> I was just going to write that now that I look at it, this is a list comparison according to `List::equals`. No need to redo the whole logic.. >> >> About the validity of the comparison, `ReadOnlyListProperty` also implements `List`: >> >> ReadOnlyListProperty extends ListExpression >> ListExpression implements ObservableListValue >> ObservableListValue extends ObservableObjectValue>, ObservableList >> ObservableList extends List, Observable >> >> So... it's also a list. > >> So... it's also a list. > > I think it's a big mess, you can already see that in the hierarchy, extending both `ObservableObjectValue>` (which is `ObservableValue`) but also being a `ObservableList`. One or the other is going to break; either it is a property containing a list, or it is a list, it can't be both. > > Either I can do: > > listProperty.equals(normalList); > > or: > > listProperty.equals(aNormalPropertyContainingAList); > > It looks like the first was chosen (I suppose because the `List` interface defines `equals` in that way) and the 2nd case will break (and is unfixable as equals needs to be symmetric). > > Looking a bit further, I think extending `ObservableObjectValue>` was a mistake here. It's also what contributes to making the collection properties so confusing (ie. you can replace all elements, or you can replace the entire list, which are two different actions that require two different forms of listeners) -- no other properties allow you to replace it's "container" -- ie. if properties had used an `AtomicReference` internally to store their value, they would not offer me the option to replace either the entire `AtomicReference` or only the value of the reference. I've adjusted it now to be a bit more modern Java as per your suggestion. ------------- PR: https://git.openjdk.org/jfx/pull/969 From dwookey at openjdk.org Sat Dec 10 10:38:07 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Sat, 10 Dec 2022 10:38:07 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v3] In-Reply-To: References: Message-ID: > When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. > > MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. > > When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. > > This pull request just removes the redundant code in the MenuButtonSkinBase. Dean Wookey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Implemented alternative fix - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8296409 # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java - Added changing scene tests for accelerator change listeners - 8296409: Stop additional change listeners being added ------------- Changes: https://git.openjdk.org/jfx/pull/937/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=937&range=02 Stats: 63 lines in 2 files changed: 48 ins; 9 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/937.diff Fetch: git fetch https://git.openjdk.org/jfx pull/937/head:pull/937 PR: https://git.openjdk.org/jfx/pull/937 From dwookey at openjdk.org Sat Dec 10 10:38:08 2022 From: dwookey at openjdk.org (Dean Wookey) Date: Sat, 10 Dec 2022 10:38:08 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 12:03:38 GMT, Dean Wookey wrote: >> When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. >> >> MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. >> >> When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. >> >> This pull request just removes the redundant code in the MenuButtonSkinBase. > > Dean Wookey has updated the pull request incrementally with one additional commit since the last revision: > > Added changing scene tests for accelerator change listeners I've put the alternative fix in on top of the latest changes. Sorry it took so long. ------------- PR: https://git.openjdk.org/jfx/pull/937 From nlisker at openjdk.org Sat Dec 10 13:42:00 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 10 Dec 2022 13:42:00 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> Message-ID: On Sat, 10 Dec 2022 08:18:34 GMT, John Hendrikx wrote: >>> So... it's also a list. >> >> I think it's a big mess, you can already see that in the hierarchy, extending both `ObservableObjectValue>` (which is `ObservableValue`) but also being a `ObservableList`. One or the other is going to break; either it is a property containing a list, or it is a list, it can't be both. >> >> Either I can do: >> >> listProperty.equals(normalList); >> >> or: >> >> listProperty.equals(aNormalPropertyContainingAList); >> >> It looks like the first was chosen (I suppose because the `List` interface defines `equals` in that way) and the 2nd case will break (and is unfixable as equals needs to be symmetric). >> >> Looking a bit further, I think extending `ObservableObjectValue>` was a mistake here. It's also what contributes to making the collection properties so confusing (ie. you can replace all elements, or you can replace the entire list, which are two different actions that require two different forms of listeners) -- no other properties allow you to replace it's "container" -- ie. if properties had used an `AtomicReference` internally to store their value, they would not offer me the option to replace either the entire `AtomicReference` or only the value of the reference. > > I've adjusted it now to be a bit more modern Java as per your suggestion. I agree that this is dubious design, and having worked a bit on observable collections I also found some questionable decisions with regards to the type hierarchy. For example. `ListExpression` and some subclasses should have been interfaces, all the way down to `ListPropertyBase` where a state is actually present. As for the equals, I wonder if it should have been defined in `ListExpression` instead, though that would bring the question about bindings - what makes a binding equal to another. Right now, what we're doing right now is copying the `AbstractList` equals implementation essentially. I think it's fine, but points, again, to a possible hierarchy problem. On another note, I'm looking at `ListExpression`'s `add` and other modifying methods. It's calling `EMPTY_LIST.add(element)` where `ObservableList EMPTY_LIST = FXCollections.emptyObservableList();`. Wouldn't that throw an exception since it's an empty unmodifiable observable list? ------------- PR: https://git.openjdk.org/jfx/pull/969 From kcr at openjdk.org Sat Dec 10 15:19:08 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 15:19:08 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v31] In-Reply-To: <8KYCpOQYu8aQ6cGJmx65rDv5AZtwVZbLkf4ZDCa5M5U=.7e4b17f0-427a-46cf-b56a-022e883e1f31@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> <8KYCpOQYu8aQ6cGJmx65rDv5AZtwVZbLkf4ZDCa5M5U=.7e4b17f0-427a-46cf-b56a-022e883e1f31@github.com> Message-ID: On Sat, 10 Dec 2022 00:47:36 GMT, Thiago Milczarek Sayao wrote: > It does make sense to start a window minimized, but does it make sense to call show() and still be minimized (I think to myself)? Yes. Stage.show() means to make the Stage visible, honoring all of its attributes (iconified, maximized, fullscreen, etc). > About the always on top, the current Linux solution is a little bit "hacky". I was thinking about a follow-up patch that reworks it. OK. Since that is a long-standing issue, there is no hurry on it. Feel free to assign [JDK-8298499](https://bugs.openjdk.org/browse/JDK-8298499) to yourself. ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Sat Dec 10 15:31:17 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 15:31:17 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Fri, 9 Dec 2022 21:42:36 GMT, Andy Goryachev wrote: >> It should at least be consistent with the rest of them. >> >> The formatting (with or without the `

`) is something we could ask others to weigh in on, too. I don't care too much, one way or the other. > > consistent - the other policies have two paragraphs, see TableView : 382 and 483 What I meant is that `TableView::CONSTRAINED_RESIZE_POLICY_FLEX_NEXT_COLUMN` and `TreeTableView::CONSTRAINED_RESIZE_POLICY_FLEX_NEXT_COLUMN` are now inconsistent, since the former has an extra `

` tag and the latter does not. They are otherwise identical. As I said, I don't really care all that much. If you want to add them back in, that's fine (don't worry about updating the CSR for now). ------------- PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Sat Dec 10 15:47:05 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 15:47:05 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: <0jP3oq8-kiTCl4QtipxkGQLBUlymtqBOkLOEnf4s91A=.5167414a-a94c-40ee-9f0a-2832adc12d34@github.com> On Thu, 8 Dec 2022 10:34:34 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add check whether consumeAutoHidingEventsProperty is bound The fix looks good to me. Please give @arapte time to comment on this, since he had raised earlier concerns. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/965 From kcr at openjdk.org Sat Dec 10 15:47:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 15:47:06 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 16:31:57 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Add check whether consumeAutoHidingEventsProperty is bound > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 410: > >> 408: thumb.setOnMouseExited(me -> { >> 409: Tooltip t = getSkinnable().getTooltip(); >> 410: if (t != null && t.isAutoHide() && !t.consumeAutoHidingEventsProperty().isBound()) { > > I still think a second property or a boolean might be better. What if the app code binds autoHidingEventsProperty after onMouseEntered? I know this is highly unlikely, but there is a potential. > > At the same time, I think we should proceed with this fix as it addresses a problem which occurs always. Agreed. Let's file a follow-on bug to consider the larger question of whether we should change the default value of `consumeAutoHidingEventsProperty` for Tooltip, so that they will not consume auto-hiding events by default. ------------- PR: https://git.openjdk.org/jfx/pull/965 From arapte at openjdk.org Sat Dec 10 16:02:03 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Sat, 10 Dec 2022 16:02:03 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 10:34:34 GMT, Karthik P K wrote: >> Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). >> >> Fix: Initialized dragStart in initialize method. >> >> Test: Added system test to validate the fix. >> >> Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Add check whether consumeAutoHidingEventsProperty is bound Looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Sat Dec 10 17:18:06 2022 From: kpk at openjdk.org (Karthik P K) Date: Sat, 10 Dec 2022 17:18:06 GMT Subject: RFR: 8295339: DatePicker updates its value property with wrong date when dialog closes [v2] In-Reply-To: References: Message-ID: <7XrLBgAga0HDJRoSyAUytNM-Xd8PVU_iJbrcW-aGJvA=.03aff2f7-1191-4fdb-b343-278a9cd73446@github.com> On Fri, 9 Dec 2022 14:14:18 GMT, Kevin Rushforth wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Marked as reviewed by kcr (Lead). @kevinrushforth / @andy-goryachev-oracle please sponsor this PR. ------------- PR: https://git.openjdk.org/jfx/pull/963 From jhendrikx at openjdk.org Sat Dec 10 17:27:01 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 10 Dec 2022 17:27:01 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v2] In-Reply-To: References: <47NwMZvcEACP_nsCNt8NdyH4tbtcmONj1qoZp-2MxwM=.bdab2b20-1a45-4cb4-94b2-2449feab7d73@github.com> Message-ID: On Sat, 10 Dec 2022 13:39:42 GMT, Nir Lisker wrote: > On another note, I'm looking at ListExpression's add and other modifying methods. It's calling EMPTY_LIST.add(element) where ObservableList EMPTY_LIST = FXCollections.emptyObservableList();. Wouldn't that throw an exception since it's an empty unmodifiable observable list? I saw that code and its intentional. I think the java doc at the top gives the hint: > If the wrapped list of a {@code ListExpression} is {@code null}, all methods implementing the {@code List} interface will behave as if they were applied to an immutable empty list. ------------- PR: https://git.openjdk.org/jfx/pull/969 From kcr at openjdk.org Sat Dec 10 17:40:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 17:40:12 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> Message-ID: On Fri, 2 Dec 2022 09:56:42 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Improve wording in javadoc and comments In order to move this forward, please revert the changes in `javafx.graphics` and file a follow-up Enhancement in JBS that we can use to separately discuss adding such a property to `Node`. I also think it might be cleanest to remove the second example from the `when` API docs as a result. Once you have reverted the changes in `Node`, please update the CSR to reflect this. You can then move the CSR to `Proposed`. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 295: > 293: * ObservableValue longLivedProperty = new SimpleStringProperty("A"); > 294: * label.textProperty().bind(longLivedProperty.when(label::isShownProperty)); > 295: * } I recommend to remove this second example. ------------- PR: https://git.openjdk.org/jfx/pull/830 From kpk at openjdk.org Sat Dec 10 18:03:02 2022 From: kpk at openjdk.org (Karthik P K) Date: Sat, 10 Dec 2022 18:03:02 GMT Subject: Integrated: 8295339: DatePicker updates its value property with wrong date when dialog closes In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 12:42:15 GMT, Karthik P K wrote: > Cause: On hiding the DatePicker dropdown, value selected was not getting updated to the text editor. Hence old value from the text editor was getting committed to DatePicker on focus loss. This issue was seen only when DatePicker is used in Alert dialog and Alert dialog is closed on making selection in DatePicker dropdown. > > Fix: Added call to updateDisplayNode() function before hiding the date picker dropdown. > > Test: Added system test to validate the fix. This pull request has now been integrated. Changeset: dadfcaf4 Author: Karthik P K Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/dadfcaf43f4bc682aa7a73cbe6f2ede88f89a639 Stats: 185 lines in 2 files changed: 185 ins; 0 del; 0 mod 8295339: DatePicker updates its value property with wrong date when dialog closes Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/963 From kcr at openjdk.org Sat Dec 10 18:43:02 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 10 Dec 2022 18:43:02 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v7] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 11:23:44 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment I found at least three regressions in behavior: 1. The ambient light doesn't go back to black when an ambient light is added then removed. 2. Adding a second point light (or spot light) causes no lighting to be done, as if there were no lights 3. The magenta point light (and spot light) no longer works at all. See inline comments for the first problem. To reproduce the second, run the `LightingSample`, show a Sphere, select the red point light (correctly shows a red point light on the right), then select the blue point light (no lighting happens). modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 182: > 180: } > 181: } > 182: if (ambientRed != 0.0f || ambientGreen != 0.0f || ambientBlue != 0.0f) { This "if" test has caused a regression in behavior. To reproduce, run the `LightingSample`, show a Sphere, select one of the ambient lights, and then deselect it. Unchecking it should go back to black but no longer does. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/789 From nlisker at openjdk.org Sun Dec 11 00:15:34 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 11 Dec 2022 00:15:34 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v3] In-Reply-To: References: Message-ID: <5TBGx6L7BCp6KZ6B4dCU7Y_tkEPa7XKvX2XXlpZlMRg=.35fcaedd-8a2c-4525-8338-86e2c5646c29@github.com> On Sat, 10 Dec 2022 08:23:07 GMT, John Hendrikx wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: > > - Adjusted ReadOnlyListProperty#equals to be a bit more modern Java > - Remove SuppressWarnings in ReadOnlyListProperty > - Use assignment in instanceof The generifying of the classes looks fine to me, and technically is a fix for the raw type warnings on the listeners, so I think it's fine to do it here. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlySetProperty.java line 117: > 115: @SuppressWarnings("unchecked") > 116: Set c = (Set) obj; // safe cast as elements are only referenced > 117: I suggest to change it similarly to list: if (obj == this) { return true; } if (!(obj instanceof Set otherSet) || otherSet.size() != size()) { return false; } try { return containsAll(otherSet); } catch (ClassCastException | NullPointerException unused) { return false; } I find it odd that there is a need to catch these exceptions, but `AbstractSet` does so too. Same for the `Map` variant. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sun Dec 11 14:30:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 14:30:22 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v4] In-Reply-To: References: Message-ID: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Adjusted ReadOnlySetProperty#equals - Adjusted ReadOnlyMapProperty#equals ------------- Changes: - all: https://git.openjdk.org/jfx/pull/969/files - new: https://git.openjdk.org/jfx/pull/969/files/b55d9479..733f8378 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=969&range=02-03 Stats: 36 lines in 2 files changed: 5 ins; 18 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/969.diff Fetch: git fetch https://git.openjdk.org/jfx pull/969/head:pull/969 PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sun Dec 11 14:30:25 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 14:30:25 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v3] In-Reply-To: <5TBGx6L7BCp6KZ6B4dCU7Y_tkEPa7XKvX2XXlpZlMRg=.35fcaedd-8a2c-4525-8338-86e2c5646c29@github.com> References: <5TBGx6L7BCp6KZ6B4dCU7Y_tkEPa7XKvX2XXlpZlMRg=.35fcaedd-8a2c-4525-8338-86e2c5646c29@github.com> Message-ID: On Sat, 10 Dec 2022 21:55:03 GMT, Nir Lisker wrote: >> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision: >> >> - Adjusted ReadOnlyListProperty#equals to be a bit more modern Java >> - Remove SuppressWarnings in ReadOnlyListProperty >> - Use assignment in instanceof > > modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlySetProperty.java line 117: > >> 115: @SuppressWarnings("unchecked") >> 116: Set c = (Set) obj; // safe cast as elements are only referenced >> 117: > > I suggest to change it similarly to list: > > > if (obj == this) { > return true; > } > > if (!(obj instanceof Set otherSet) || otherSet.size() != size()) { > return false; > } > try { > return containsAll(otherSet); > } catch (ClassCastException | NullPointerException unused) { > return false; > } > > > I find it odd that there is a need to catch these exceptions, but `AbstractSet` does so too. > > Same for the `Map` variant. NPE is probably because some underlying sets will throw NPE even for operations like `contains(null)` (the immutable variants from `List.of` and `Set.of` are bad offenders in this area). CCE maybe for sets that use comparators internally. I've adjusted it as you suggested, and same for map. ------------- PR: https://git.openjdk.org/jfx/pull/969 From nlisker at openjdk.org Sun Dec 11 14:47:52 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 11 Dec 2022 14:47:52 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v4] In-Reply-To: References: Message-ID: On Sun, 11 Dec 2022 14:30:22 GMT, John Hendrikx wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Adjusted ReadOnlySetProperty#equals > - Adjusted ReadOnlyMapProperty#equals Looks good. Kevin might want to have a look too. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Sun Dec 11 20:28:23 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 20:28:23 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v11] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <40lexCatGbVnwKQ9E3lrcTNDw6sa1Ud-xN7q7N7j6_g=.73fcf15c-2d18-4376-990d-d83097471a9c@github.com> > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Remove changes to javafx.graphics Node ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/67c277cb..94b50b5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=09-10 Stats: 155 lines in 2 files changed: 7 ins; 147 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Sun Dec 11 20:31:24 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 20:31:24 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v12] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Remove example referencing Node#shownProperty ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/94b50b5d..75ccca6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=10-11 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Sun Dec 11 20:39:02 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 20:39:02 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> Message-ID: On Sat, 10 Dec 2022 17:29:23 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve wording in javadoc and comments > > modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 295: > >> 293: * ObservableValue longLivedProperty = new SimpleStringProperty("A"); >> 294: * label.textProperty().bind(longLivedProperty.when(label::isShownProperty)); >> 295: * } > > I recommend to remove this second example. I've reverted the changes in graphics and removed the example using it. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Sun Dec 11 20:50:07 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 20:50:07 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v10] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6ZHoWZQDcIW6PgeX9_BEFodmmeFxsuwIFuGgx19TZt8=.0ddf7ba2-77f4-4664-8d5e-6ee43998166e@github.com> Message-ID: On Sat, 10 Dec 2022 17:36:16 GMT, Kevin Rushforth wrote: > In order to move this forward, please revert the changes in `javafx.graphics` and file a follow-up Enhancement in JBS that we can use to separately discuss adding such a property to `Node`. > > I also think it might be cleanest to remove the second example from the `when` API docs as a result. > > Once you have reverted the changes in `Node`, please update the CSR to reflect this. You can then move the CSR to `Proposed`. I updated the CSR to remove all references to the changes in `Node`, and moved it to proposed. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Sun Dec 11 20:54:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 11 Dec 2022 20:54:22 GMT Subject: RFR: JDK-8298528: Clean up raw type warnings in base in bindings and collections packages Message-ID: Packages fixed: - com.sun.javafx.binding - com.sun.javafx.collections - javafx.beans - javafx.beans.binding - javafx.collections - javafx.collections.transformation ------------- Commit messages: - Use static method for no-op map - Fix raw type warnings in base Changes: https://git.openjdk.org/jfx/pull/972/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298528 Stats: 334 lines in 23 files changed: 81 ins; 75 del; 178 mod Patch: https://git.openjdk.org/jfx/pull/972.diff Fetch: git fetch https://git.openjdk.org/jfx pull/972/head:pull/972 PR: https://git.openjdk.org/jfx/pull/972 From tsayao at openjdk.org Sun Dec 11 21:14:56 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 11 Dec 2022 21:14:56 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v32] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision: - Merge remote-tracking branch 'origin/clean_glass_gtk' into clean_glass_gtk - Unity uses Compiz - Fix show a window minimized - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Fix init iconified - Fix View position - Review changes - Review changes - 8260528: Clean glass-gtk sizing and positioning code - ... and 22 more: https://git.openjdk.org/jfx/compare/39bf5b74...e9856c68 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/e87b75fb..e9856c68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=31 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=30-31 Stats: 31623 lines in 1712 files changed: 13685 ins; 7150 del; 10788 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Sun Dec 11 21:50:07 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 11 Dec 2022 21:50:07 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v32] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 11 Dec 2022 21:14:56 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has 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 32 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/clean_glass_gtk' into clean_glass_gtk > - Unity uses Compiz > - Fix show a window minimized > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Fix init iconified > - Fix View position > - Review changes > - Review changes > - 8260528: Clean glass-gtk sizing and positioning code > - ... and 22 more: https://git.openjdk.org/jfx/compare/e1b532f5...e9856c68 I fixed the `setIconified` before `show` and also tested maximized and fullscreen. ------------- PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Sun Dec 11 22:34:04 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 11 Dec 2022 22:34:04 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v33] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Remove unused method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/e9856c68..f2b1b074 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=32 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=31-32 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From nlisker at openjdk.org Sun Dec 11 23:42:05 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 11 Dec 2022 23:42:05 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v12] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Sun, 11 Dec 2022 20:31:24 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Remove example referencing Node#shownProperty Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/830 From arapte at openjdk.org Mon Dec 12 05:43:47 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 12 Dec 2022 05:43:47 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 22:17:55 GMT, John Hendrikx wrote: > This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. > > I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. The commit#1 changes look good. I would recommend to revert commit#2 for few reasons: 1. Cleanup changes are a lot more than actual fix change. 2. It will be difficult to revisit in future. 3. If required the cleanup changes could go in as a separate fix. Could you please provide link to the discussion that led to this change? ------------- PR: https://git.openjdk.org/jfx/pull/966 From kpk at openjdk.org Mon Dec 12 05:56:59 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Dec 2022 05:56:59 GMT Subject: RFR: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true [v6] In-Reply-To: References: Message-ID: On Sat, 10 Dec 2022 15:42:23 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java line 410: >> >>> 408: thumb.setOnMouseExited(me -> { >>> 409: Tooltip t = getSkinnable().getTooltip(); >>> 410: if (t != null && t.isAutoHide() && !t.consumeAutoHidingEventsProperty().isBound()) { >> >> I still think a second property or a boolean might be better. What if the app code binds autoHidingEventsProperty after onMouseEntered? I know this is highly unlikely, but there is a potential. >> >> At the same time, I think we should proceed with this fix as it addresses a problem which occurs always. > > Agreed. Let's file a follow-on bug to consider the larger question of whether we should change the default value of `consumeAutoHidingEventsProperty` for Tooltip, so that they will not consume auto-hiding events by default. I have filed [JDK-8298529](https://bugs.openjdk.org/browse/JDK-8298529) for this. ------------- PR: https://git.openjdk.org/jfx/pull/965 From kpk at openjdk.org Mon Dec 12 06:19:57 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 12 Dec 2022 06:19:57 GMT Subject: Integrated: 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true In-Reply-To: References: Message-ID: <9-kKqHZ29FDtGx9PCxduQG8AjF27Xib435xlerpNI40=.1062603f-6e4b-4b26-a596-192666dd4117@github.com> On Thu, 1 Dec 2022 17:03:03 GMT, Karthik P K wrote: > Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged). > > Fix: Initialized dragStart in initialize method. > > Test: Added system test to validate the fix. > > Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method. This pull request has now been integrated. Changeset: 8763e8b0 Author: Karthik P K Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/8763e8b0d67db33fc3aa40c459058957e3230346 Stats: 180 lines in 2 files changed: 180 ins; 0 del; 0 mod 8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true Reviewed-by: arapte, angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/965 From jhendrikx at openjdk.org Mon Dec 12 07:32:51 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 07:32:51 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 05:41:45 GMT, Ambarish Rapte wrote: > The commit#1 changes look good. I would recommend to revert commit#2 for few reasons: > > 1. Cleanup changes are a lot more than actual fix change. > 2. It will be difficult to revisit in future. > 3. If required the cleanup changes could go in as a separate fix. > > Could you please provide link to the discussion that led to this change? @arapte the discussion was part of fixing warnings in javafx.graphics. You can find it here (open first resolved comment): https://github.com/openjdk/jfx/pull/960#pullrequestreview-1197937273 ------------- PR: https://git.openjdk.org/jfx/pull/966 From nlisker at gmail.com Mon Dec 12 16:10:03 2022 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 12 Dec 2022 18:10:03 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: Another idea is to use a static map that maps a node to its "graphic parent". That will save on memory at the expense of a lookup. On Thu, Dec 1, 2022 at 11:53 PM Nir Lisker wrote: > Are we convinced that a node can't be both a graphic and a clip, or > something else? The docs for clip specify that the node is not a child in > the scenegraph. > > On Thu, Dec 1, 2022 at 11:41 PM John Hendrikx > wrote: > >> Adding another field doesn't seem ideal, would it be possible to >> generalize the clipParent field to function for both (the ownedBy or owner >> field that I suggested earlier)? >> >> --John >> On 01/12/2022 20:26, Nir Lisker wrote: >> >> Michael's idea could solve the problem if it's about more than just >> traversing, it needs to set rules for allowing a node to serve only 1 >> logical role (or 1 role type, like clip and graphic?) at the same time. In >> any case, these rules need to be decided upon before starting to work on >> anything. I can do a quick fix for now that can be reverted later >> if needed. From what I gather, I will need to add a graphicsParent field >> like clipParent does. >> >> On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote: >> >>> By the way, these issues are caused by this inconsistent behavior (they >>> are probably duplicates): >>> >>> https://bugs.openjdk.org/browse/JDK-8209017 >>> https://bugs.openjdk.org/browse/JDK-8190331 >>> >>> The graphic of the checkbox of a CheckBoxTreeItem is not set correctly >>> on the new CheckBox that is provided with the cell when virtual flow >>> switches it. It might happen with other controls that use virtual flow. >>> >>> On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> This seems related, but somewhat tangential. A Control's "graphic" >>>> isn't >>>> a child node, just like a Shape's "clip" isn't a child node. >>>> >>>> Creating a separate "document graph" (or "logical graph") sounds like >>>> an >>>> interesting idea, but it would bring its own set of challenges. And it >>>> wouldn't directly solve this case anyway. >>>> >>>> -- Kevin >>>> >>>> >>>> On 12/1/2022 9:42 AM, Michael Strau? wrote: >>>> > There's a larger picture here: from a user perspective, there's a >>>> > difference between the scene graph and the "document graph". >>>> > The document graph is what users actually work with, for example by >>>> > setting the `Labeled.graphic` property. In some cases, document nodes >>>> > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to >>>> > mind). >>>> > The document graph is later inflated into a scene graph of unknown >>>> > structure (because skins are mostly black boxes with regards to their >>>> > internal structure). >>>> > >>>> > I've proposed an enhancement that would make the document graph a >>>> > first-class citizen: >>>> > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html >>>> > >>>> > With this in place, we could simply disallow the same node appearing >>>> > multiple times in the document graph, which would not only solve the >>>> > problem for `Labeled`, but for all controls with a similar problem. >>>> > >>>> > >>>> > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx >>>> wrote: >>>> >> The mechanism does seem like it is a bit poorly designed, as it is >>>> easy to create inconsistencies. >>>> >> >>>> >> Luckily it seems that you can't remove a graphic yourself from a >>>> Control (getChildren is protected). >>>> >> >>>> >> I don't think there is an easy solution though... >>>> >> >>>> >> I think that once you set a graphic on a Labeled, you need to >>>> somehow mark it as "in use". Normally you could just check parent != null >>>> for this, but it is trickier than that. The Skin ultimately determines if >>>> it adds the graphic as child, which may be delayed or may even be disabled >>>> (content display property is set to showing TEXT only). >>>> >> >>>> >> Perhaps Skins should always add the graphic and just hide it >>>> (visible false, managed false), but that's going to be hard to enforce. >>>> >> >>>> >> Marking the graphic as "in use" could be done with: >>>> >> >>>> >> - a property in `getProperties` >>>> >> - a new "owner" or "ownedBy" property >>>> >> - allowing "parent" to be set without adding it to children >>>> (probably going to mess up stuff) >>>> >> >>>> >> --John >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Dec 12 17:02:33 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 17:02:33 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 22:17:55 GMT, John Hendrikx wrote: > This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. > > I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. Changes requested by angorya (Committer). modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GestureRecognizer.java line 31: > 29: > 30: interface GestureRecognizer extends GlassTouchEventListener { > 31: static final long INITIAL_VELOCITY_THRESHOLD_NANOS = 100L * 1000; 100_000L ? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/RotateGestureRecognizer.java line 60: > 58: String s = System.getProperty("com.sun.javafx.gestures.rotate.threshold"); > 59: if (s != null) { > 60: rotationThresholdDegrees = Double.valueOf(s); should we catch a NumberFormatException and re-throw it with a meaningful text message? Or the current behavior is ok? ditto on line 64 modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/RotateGestureRecognizer.java line 304: > 302: > 303: if (nanosPassed > INITIAL_VELOCITY_THRESHOLD_NANOS) { > 304: initialInertiaRotationVelocity = currentRotation / nanosPassed * NANOS_TO_SECONDS; is this correct? shouldn't it be `currentRotation / (nanosPassed * NANOS_TO_SECONDS)` ? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 64: > 62: s = System.getProperty("com.sun.javafx.gestures.scroll.inertia"); > 63: if (s != null) { > 64: scrollInertiaEnabled = Boolean.valueOf(s); same comment about re-throwing an exception (x2) modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 252: > 250: factorX = deltaX / scrollMagnitude; > 251: factorY = deltaY / scrollMagnitude; > 252: initialInertiaScrollVelocity = scrollMagnitude / nanosPassed * NANOS_TO_SECONDS; is this correct? shouldn't it be `scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS)`? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ZoomGestureRecognizer.java line 65: > 63: s = System.getProperty("com.sun.javafx.gestures.zoom.inertia"); > 64: if (s != null) { > 65: zoomInertiaEnabled = Boolean.valueOf(s); ... and here modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ZoomGestureRecognizer.java line 277: > 275: > 276: if (nanosPassed > INITIAL_VELOCITY_THRESHOLD_NANOS) { > 277: initialInertiaZoomVelocity = (totalZoomFactor - prevTotalZoomFactor) / nanosPassed * NANOS_TO_SECONDS; `(totalZoomFactor - prevTotalZoomFactor) / (nanosPassed * NANOS_TO_SECONDS);` ? ------------- PR: https://git.openjdk.org/jfx/pull/966 From angorya at openjdk.org Mon Dec 12 17:16:37 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 17:16:37 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8293119:

------------- Changes: - all: https://git.openjdk.org/jfx/pull/897/files - new: https://git.openjdk.org/jfx/pull/897/files/bb2d069c..671d9773 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Mon Dec 12 17:16:39 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 17:16:39 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v19] In-Reply-To: References: <-alrUd-o0TsxI1dl-klQdphgAhJwLhQgQO7Tkcv3GP8=.7e86f165-764b-4106-9955-5f3dc4181a6b@github.com> Message-ID: On Sat, 10 Dec 2022 15:29:15 GMT, Kevin Rushforth wrote: >> consistent - the other policies have two paragraphs, see TableView : 382 and 483 > > What I meant is that `TableView::CONSTRAINED_RESIZE_POLICY_FLEX_NEXT_COLUMN` and `TreeTableView::CONSTRAINED_RESIZE_POLICY_FLEX_NEXT_COLUMN` are now inconsistent, since the former has an extra `

` tag and the latter does not. They are otherwise identical. > > As I said, I don't really care all that much. If you want to add them back in, that's fine (don't worry about updating the CSR for now). oh, sorry, I misunderstood. fixed it now, thanks! ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Mon Dec 12 17:47:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 17:47:32 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v3] In-Reply-To: References: Message-ID: On Sat, 10 Dec 2022 10:38:07 GMT, Dean Wookey wrote: >> When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. >> >> MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. >> >> When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. >> >> This pull request just removes the redundant code in the MenuButtonSkinBase. > > Dean Wookey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Implemented alternative fix > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8296409 > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java > - Added changing scene tests for accelerator change listeners > - 8296409: Stop additional change listeners being added looks much leaner now, thanks! ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/937 From mstrauss at openjdk.org Mon Dec 12 18:04:22 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 12 Dec 2022 18:04:22 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v7] In-Reply-To: References: Message-ID: > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

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

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

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

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

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

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

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

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

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

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

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added manual PlatformPreferencesTest ------------- Changes: - all: https://git.openjdk.org/jfx/pull/511/files - new: https://git.openjdk.org/jfx/pull/511/files/3424597d..a47a35a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=05-06 Stats: 77 lines in 1 file changed: 77 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/511.diff Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511 PR: https://git.openjdk.org/jfx/pull/511 From mstrauss at openjdk.org Mon Dec 12 18:10:31 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 12 Dec 2022 18:10:31 GMT Subject: RFR: 8267546: Add CSS themes as a first-class concept [v8] In-Reply-To: References: Message-ID: <1DJo7PccIlPAvo2BI1nk68IFVED1YVr3fvot22qMbVY=.71625747-7d12-4ce5-9297-07a91865db9d@github.com> > This PR adds style themes as a first-class concept to OpenJFX. A style theme is a collection of stylesheets and the logic that governs them. Style themes can respond to OS notifications and update their stylesheets dynamically. This PR also re-implements Caspian and Modena as style themes. > > ### New APIs in `javafx.graphics` > The new theming-related APIs in `javafx.graphics` provide a basic framework to support application-wide style themes. Higher-level theming concepts (for example, "dark mode" detection or accent coloring) are not a part of this basic framework, because any API invented here might soon be out of date. Implementations can build on top of this framework to add useful higher-level features. > #### 1. StyleTheme > A style theme is an implementation of the `javafx.css.StyleTheme` interface: > > /** > * {@code StyleTheme} is a collection of stylesheets that specify the appearance of UI controls and other > * nodes in the application. Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used by all > * JavaFX nodes in the scene graph. > *

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

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

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

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

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

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

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

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

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

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

> * The preferences that are reported by the platform may be dependent on the operating system version. > * Applications should always test whether a preference is available, or use the {@link #getString(String, String)}, > * {@link #getBoolean(String, boolean)} or {@link #getColor(String, Color)} overloads that accept a fallback > * value if the preference is not available. > */ > public interface PlatformPreferences extends Map { > String getString(String key); > String getString(String key, String fallbackValue); > > Boolean getBoolean(String key); > boolean getBoolean(String key, boolean fallbackValue); > > Color getColor(String key); > Color getColor(String key, Color fallbackValue); > > void addListener(PlatformPreferencesListener listener); > void removeListener(PlatformPreferencesListener listener); > } > > An instance of `PlatformPreferences` can be retrieved via `Platform.getPreferences()`. > > ### Usage > In its simplest form, a style theme is just a static collection of stylesheets: > > Application.setStyleTheme(() -> List.of("stylesheet1.css", "stylesheet2.css"); > > A dynamic theme can be created by returning an instance of `ObservableList`: > > public class MyCustomTheme implements StyleTheme { > private final ObservableList stylesheets = > FXCollections.observableArrayList("colors-light.css", "controls.css"); > > @Override > public List getStylesheets() { > return stylesheets; > } > > public void setDarkMode(boolean enabled) { > stylesheets.set(0, enabled ? "colors-dark.css" : "colors-light.css"); > } > } > > `CaspianTheme` and `ModenaTheme` can be extended by prepending or appending additional stylesheets: > > Application.setStyleTheme(new ModenaTheme() { > { > addFirst("stylesheet1.css"); > addLast("stylesheet2.css"); > } > }); Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into feature/theming - Added manual PlatformPreferencesTest - Javadoc table formatting - Added macOS platform preferences implementation - Set initial preferences from QuantumToolkit - Removed unused StylesheetList constructor - Update PlatformPreferences when dark mode is enabled - Removed unrelated code from ThemeBase - StyleTheme implementation ------------- Changes: https://git.openjdk.org/jfx/pull/511/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=511&range=07 Stats: 3444 lines in 44 files changed: 3071 ins; 224 del; 149 mod Patch: https://git.openjdk.org/jfx/pull/511.diff Fetch: git fetch https://git.openjdk.org/jfx pull/511/head:pull/511 PR: https://git.openjdk.org/jfx/pull/511 From kcr at openjdk.org Mon Dec 12 20:33:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 20:33:13 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v12] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <08OlmD8qW3OAfbspfz92PgovswJfPzbXIbnfPWbUYZg=.1f13f73e-55d6-47a2-9e93-2eec708378c0@github.com> On Sun, 11 Dec 2022 20:31:24 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Remove example referencing Node#shownProperty The update to revert `javafx.graphics` looks good. I'll finish reviewing soon. Can you merge in the latest master? Your PR branch is a couple months out of date, and it would be helpful to get a more recent GHA run. ------------- PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Mon Dec 12 21:57:18 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 21:57:18 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v13] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <6wv8NUyIk68oFsMeQDhg4ORc6ef-SEWnaCFVXHfrgoY=.ca8345a5-29aa-4fb1-b5b6-2db8dcffb47a@github.com> > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'openjdk:master' into feature/conditional-bindings - Remove example referencing Node#shownProperty - Remove changes to javafx.graphics Node - Improve wording in javadoc and comments - Adjust Node - Fixed javadoc - Added comment for code that avoid eager instantiation - Changed `isShown` to use property if it is available - Fix javadoc error - Fix comment in test - Improve documentation of shown property - Merge remote-tracking branch 'origin/master' into feature/conditional-bindings # Conflicts: # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java - Fix review comments - ... and 7 more: https://git.openjdk.org/jfx/compare/8763e8b0...24872f09 ------------- Changes: https://git.openjdk.org/jfx/pull/830/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=12 Stats: 400 lines in 3 files changed: 398 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Mon Dec 12 22:08:06 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:08:06 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 16:51:01 GMT, Andy Goryachev wrote: >> This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. >> >> I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/RotateGestureRecognizer.java line 60: > >> 58: String s = System.getProperty("com.sun.javafx.gestures.rotate.threshold"); >> 59: if (s != null) { >> 60: rotationThresholdDegrees = Double.valueOf(s); > > should we catch a NumberFormatException and re-throw it with a meaningful text message? Or the current behavior is ok? > > ditto on line 64 I suppose that would be out of scope for this PR. I agree though that it would be good to mention that the double that couldn't be parsed is the one we got from `System.getProperty("com.sun.javafx.gestures.rotate.threshold")` as otherwise the error would mean nothing to anyone. > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 252: > >> 250: factorX = deltaX / scrollMagnitude; >> 251: factorY = deltaY / scrollMagnitude; >> 252: initialInertiaScrollVelocity = scrollMagnitude / nanosPassed * NANOS_TO_SECONDS; > > is this correct? shouldn't it be `scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS)`? I think it's correct, unless you have reason to believe why it wouldn't be. `scrollMagnitude` is a double, and the division and multiplication that follow it will be all done as doubles. > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ZoomGestureRecognizer.java line 277: > >> 275: >> 276: if (nanosPassed > INITIAL_VELOCITY_THRESHOLD_NANOS) { >> 277: initialInertiaZoomVelocity = (totalZoomFactor - prevTotalZoomFactor) / nanosPassed * NANOS_TO_SECONDS; > > `(totalZoomFactor - prevTotalZoomFactor) / (nanosPassed * NANOS_TO_SECONDS);` ? The order is irrelevant, it could as well be `((totalZoomFactor - prevTotalZoomFactor) / nanosPassed) * NANOS_TO_SECONDS` -- I'll let the compiler decide what is more optimal. ------------- PR: https://git.openjdk.org/jfx/pull/966 From angorya at openjdk.org Mon Dec 12 22:08:06 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 22:08:06 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:03:31 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 252: >> >>> 250: factorX = deltaX / scrollMagnitude; >>> 251: factorY = deltaY / scrollMagnitude; >>> 252: initialInertiaScrollVelocity = scrollMagnitude / nanosPassed * NANOS_TO_SECONDS; >> >> is this correct? shouldn't it be `scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS)`? > > I think it's correct, unless you have reason to believe why it wouldn't be. `scrollMagnitude` is a double, and the division and multiplication that follow it will be all done as doubles. your change is equivalent to (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed is that correct? ------------- PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Mon Dec 12 22:11:02 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:11:02 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:05:44 GMT, Andy Goryachev wrote: >> I think it's correct, unless you have reason to believe why it wouldn't be. `scrollMagnitude` is a double, and the division and multiplication that follow it will be all done as doubles. > > your change is equivalent to > > (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed > > is that correct? That would be equivalent yes. Perhaps it is because `timePassed` was a `double` before measured in seconds while I'm now doing the calculation with nano seconds? ------------- PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Mon Dec 12 22:20:25 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:20:25 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:08:57 GMT, John Hendrikx wrote: >> your change is equivalent to >> >> (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed >> >> is that correct? > > That would be equivalent yes. > > Perhaps it is because `timePassed` was a `double` before measured in seconds while I'm now doing the calculation with nano seconds? Okay I see what you're getting at, your first suggestion would not be correct, it's supposed to be what you suggest in the 2nd one. So what I want is: (scrollMagnitude / nanosPassed) * NANOS_TO_SECONDS or: (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed ...but that's the same as what I wrote. ------------- PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Mon Dec 12 22:20:27 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:20:27 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:05:14 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ZoomGestureRecognizer.java line 277: >> >>> 275: >>> 276: if (nanosPassed > INITIAL_VELOCITY_THRESHOLD_NANOS) { >>> 277: initialInertiaZoomVelocity = (totalZoomFactor - prevTotalZoomFactor) / nanosPassed * NANOS_TO_SECONDS; >> >> `(totalZoomFactor - prevTotalZoomFactor) / (nanosPassed * NANOS_TO_SECONDS);` ? > > The order is irrelevant, it could as well be `((totalZoomFactor - prevTotalZoomFactor) / nanosPassed) * NANOS_TO_SECONDS` -- I'll let the compiler decide what is more optimal. See other conversation, your suggestion would not be correct as it changes the order of the operations. ------------- PR: https://git.openjdk.org/jfx/pull/966 From kcr at openjdk.org Mon Dec 12 22:24:19 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 22:24:19 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v13] In-Reply-To: <6wv8NUyIk68oFsMeQDhg4ORc6ef-SEWnaCFVXHfrgoY=.ca8345a5-29aa-4fb1-b5b6-2db8dcffb47a@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6wv8NUyIk68oFsMeQDhg4ORc6ef-SEWnaCFVXHfrgoY=.ca8345a5-29aa-4fb1-b5b6-2db8dcffb47a@github.com> Message-ID: On Mon, 12 Dec 2022 21:57:18 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'openjdk:master' into feature/conditional-bindings > - Remove example referencing Node#shownProperty > - Remove changes to javafx.graphics Node > - Improve wording in javadoc and comments > - Adjust Node > > - Fixed javadoc > - Added comment for code that avoid eager instantiation > - Changed `isShown` to use property if it is available > - Fix javadoc error > - Fix comment in test > - Improve documentation of shown property > - Merge remote-tracking branch 'origin/master' into > feature/conditional-bindings > > # Conflicts: > # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java > - Fix review comments > - ... and 7 more: https://git.openjdk.org/jfx/compare/8763e8b0...24872f09 Looks good. The additional tests for `when` look to be quite thorough and are very easy to follow. I left one minor formatting comment. I'll reapprove if you fix that. modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 931: > 929: @Nested > 930: class WithNotNullReturns_ObservableValue_Which { > 931: private ObjectProperty condition = new SimpleObjectProperty(true); // using object property here so it can be set to null for testing Minor: can you wrap this line? (it's a fair bit longer than the recommended max of 120 or so) ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/830 From angorya at openjdk.org Mon Dec 12 22:29:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 22:29:55 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:15:46 GMT, John Hendrikx wrote: >> That would be equivalent yes. >> >> Perhaps it is because `timePassed` was a `double` before measured in seconds while I'm now doing the calculation with nano seconds? > > Okay I see what you're getting at, your first suggestion would not be correct, it's supposed to be what you suggest in the 2nd one. So what I want is: > > (scrollMagnitude / nanosPassed) * NANOS_TO_SECONDS > > or: > > (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed > > ...but that's the same as what I wrote. I just needed you to confirm that this is indeed correct. ------------- PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Mon Dec 12 22:42:16 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:42:16 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v14] In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix formatting in test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/830/files - new: https://git.openjdk.org/jfx/pull/830/files/24872f09..7318af2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=12-13 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/830.diff Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830 PR: https://git.openjdk.org/jfx/pull/830 From jhendrikx at openjdk.org Mon Dec 12 22:42:22 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 12 Dec 2022 22:42:22 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v13] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> <6wv8NUyIk68oFsMeQDhg4ORc6ef-SEWnaCFVXHfrgoY=.ca8345a5-29aa-4fb1-b5b6-2db8dcffb47a@github.com> Message-ID: <8slFpzJx7gMutrJoFYCMmin7dZdeKuJph3-If9hotJI=.3e6556a6-9458-431e-9568-d019a439c659@github.com> On Mon, 12 Dec 2022 22:11:09 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Merge branch 'openjdk:master' into feature/conditional-bindings >> - Remove example referencing Node#shownProperty >> - Remove changes to javafx.graphics Node >> - Improve wording in javadoc and comments >> - Adjust Node >> >> - Fixed javadoc >> - Added comment for code that avoid eager instantiation >> - Changed `isShown` to use property if it is available >> - Fix javadoc error >> - Fix comment in test >> - Improve documentation of shown property >> - Merge remote-tracking branch 'origin/master' into >> feature/conditional-bindings >> >> # Conflicts: >> # modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java >> - Fix review comments >> - ... and 7 more: https://git.openjdk.org/jfx/compare/8763e8b0...24872f09 > > modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 931: > >> 929: @Nested >> 930: class WithNotNullReturns_ObservableValue_Which { >> 931: private ObjectProperty condition = new SimpleObjectProperty(true); // using object property here so it can be set to null for testing > > Minor: can you wrap this line? (it's a fair bit longer than the recommended max of 120 or so) Yeah, I tend to not wrap for comments after code and I forgot this one. I also noticed I could use diamond here now that I have my warnings on, so I fixed that as well. ------------- PR: https://git.openjdk.org/jfx/pull/830 From angorya at openjdk.org Mon Dec 12 22:44:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Dec 2022 22:44:24 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 17:16:37 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8293119:

@karthikpandelu would you be able to take a look at this PR, specifically check the new behavior using `ATableViewResizeTester` app? Please note anything you don't like or find questionable. Thanks! ------------- PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Mon Dec 12 23:07:00 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 23:07:00 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: <0MQ0EAGpj53aADbIYx8N24I3ihDbiGSm2U4DHDJKBS0=.12cf1724-8fa3-41b1-bbdb-96c395382eff@github.com> On Sat, 3 Dec 2022 22:17:55 GMT, John Hendrikx wrote: > This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. > > I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. inline ------------- PR: https://git.openjdk.org/jfx/pull/966 From kcr at openjdk.org Mon Dec 12 23:07:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 23:07:01 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:00:09 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/RotateGestureRecognizer.java line 60: >> >>> 58: String s = System.getProperty("com.sun.javafx.gestures.rotate.threshold"); >>> 59: if (s != null) { >>> 60: rotationThresholdDegrees = Double.valueOf(s); >> >> should we catch a NumberFormatException and re-throw it with a meaningful text message? Or the current behavior is ok? >> >> ditto on line 64 > > I suppose that would be out of scope for this PR. I agree though that it would be good to mention that the double that couldn't be parsed is the one we got from `System.getProperty("com.sun.javafx.gestures.rotate.threshold")` as otherwise the error would mean nothing to anyone. Yes, that sort of change seems out of scope. ------------- PR: https://git.openjdk.org/jfx/pull/966 From kcr at openjdk.org Mon Dec 12 23:07:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 23:07:01 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:27:49 GMT, Andy Goryachev wrote: >> Okay I see what you're getting at, your first suggestion would not be correct, it's supposed to be what you suggest in the 2nd one. So what I want is: >> >> (scrollMagnitude / nanosPassed) * NANOS_TO_SECONDS >> >> or: >> >> (scrollMagnitude * NANOS_TO_SECONDS) / nanosPassed >> >> ...but that's the same as what I wrote. > > I just needed you to confirm that this is indeed correct. > > Perhaps a default method `double nanosToSeconds(long)` in `GestureRecognizer` would be clearer? But is it correct? The previous code computed a deltaTime in seconds as `((currentNanos - startNanos) / 1e9)`, and then divided the `scrollMagnitude` by that. I think that the equivalent to the old code is: scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS) ------------- PR: https://git.openjdk.org/jfx/pull/966 From kcr at openjdk.org Mon Dec 12 23:08:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Dec 2022 23:08:09 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v14] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: <_1XDZAVzEZ5gyziaf1jzhQ6zuFPq2UmpSzhRWzSpM_c=.1bab68b8-37b1-475d-bfb4-1edace5a722d@github.com> On Mon, 12 Dec 2022 22:42:16 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/830 From nlisker at openjdk.org Mon Dec 12 23:52:05 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 12 Dec 2022 23:52:05 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v14] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Mon, 12 Dec 2022 22:42:16 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in test Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/830 From mstrauss at openjdk.org Tue Dec 13 00:12:29 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 13 Dec 2022 00:12:29 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v14] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Mon, 12 Dec 2022 22:42:16 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in test Marked as reviewed by mstrauss (Committer). ------------- PR: https://git.openjdk.org/jfx/pull/830 From nlisker at openjdk.org Tue Dec 13 02:43:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Dec 2022 02:43:24 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v7] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 11:23:44 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment At first I couldn't reproduce these, then I found out the launch command of the test app points to the wrong build artifacts, so any changes I made were not reflected in my visual checks. It's the same for other test apps, so it's a good thing it was discovered. Thanks! 1. Right, I reverted this line. 2. Right, it seems to be a problem in the native level, will have to check carefully. 3. I think it just looks like that because of the position of the central lights (the magenta ones). The sphere intersects the light upon creation, so there is no lighting of the sphere with this geometry. Try to animate the sphere, or use the boxes/meshes instead that are created further away from the light. ------------- PR: https://git.openjdk.org/jfx/pull/789 From nlisker at openjdk.org Tue Dec 13 02:48:29 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 13 Dec 2022 02:48:29 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v8] In-Reply-To: References: Message-ID: > Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. > > Since there are many small changes, I'm giving a full list here: > > **Java** > > * `NGShape3D.java` > * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. > * Normalized the direction here instead of in the native code. > * Ambient light is now only set when it exists (and is not black). > * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). > * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. > > **Native C++** > > * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). > * `D3DLight` > * Commented out unused methods. Were they supposed to be used at some point? > * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. > * `D3DPhongShader.h` > * Renamed some of the register constants for more clarity. > * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. > * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. > * `D3DMeshView.cc` > * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. > * Removed the direction normalization as stated in the change for `NGShape3D.java`. > * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. > > **Native shaders** > * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). > * Commented out many unused functions. I don't know what they are for, so I didn't remove them. > * `vsConstants` > * Removed the light color from here since it's unused, only the position is. > * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. > * `vs2ps` > * Removed the ambient color interpolation, which frees a register (no change in performance). > * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?). > * `Mtl1PS` and `psMath` > * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. > * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. > > No changes in performance were measured and the behavior stayed the same. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Added a default light mode - Reverted a change that breaks ambient lighting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/789/files - new: https://git.openjdk.org/jfx/pull/789/files/1f66f613..42994e9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=789&range=06-07 Stats: 56 lines in 4 files changed: 12 ins; 17 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/789.diff Fetch: git fetch https://git.openjdk.org/jfx pull/789/head:pull/789 PR: https://git.openjdk.org/jfx/pull/789 From jhendrikx at openjdk.org Tue Dec 13 08:45:46 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 13 Dec 2022 08:45:46 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 23:02:06 GMT, Kevin Rushforth wrote: >> I just needed you to confirm that this is indeed correct. >> >> Perhaps a default method `double nanosToSeconds(long)` in `GestureRecognizer` would be clearer? > > But is it correct? The previous code computed a deltaTime in seconds as `((currentNanos - startNanos) / 1e9)`, and then divided the `scrollMagnitude` by that. I think that the equivalent to the old code is: > > > scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS) It turns out it is not correct, the parenthesis are indeed required, not sure how I could have missed it. I'm going to see if I can add a test to this as they're missing to ensure it does the same before/after (aside from precision). ------------- PR: https://git.openjdk.org/jfx/pull/966 From john.hendrikx at gmail.com Tue Dec 13 08:55:27 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 13 Dec 2022 09:55:27 +0100 Subject: Testing, shims and package private classes Message-ID: <5a952fe3-5f59-223a-4557-daeb023c56f9@gmail.com> Hi all, I was wondering, is there a reason for the current test setup in the JavaFX code base? Currently, tests are all stored under src/test/java under a special package name prefixed with "test". This is an (IMHO) unusual practice as normally tests mirror the same packages as their main classes to aid in testability. Testing a package private class is really hard because of this and requires the use of a shim -- the shims do mirror the same package hierarchy as the main classes. A few questions related to this: 1) When testing a package private class in the com.sun.* hierarchy, is it okay to just make the class public (as it is already private API) so it can be tested without a shim? 2) Can at least the com.sun.* hierarchy be mirrored in src/test/java without the "test" package prefix?? Again, they're both non-public packages anyway. 3) Can we perhaps move all test classes to the package of their main counterparts, and do away with (probably all) shims? --John From kevin.rushforth at oracle.com Tue Dec 13 13:36:45 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Dec 2022 05:36:45 -0800 Subject: Testing, shims and package private classes In-Reply-To: <5a952fe3-5f59-223a-4557-daeb023c56f9@gmail.com> References: <5a952fe3-5f59-223a-4557-daeb023c56f9@gmail.com> Message-ID: <38b15ee2-79b2-847c-49f7-6a1c5a2ad9d4@oracle.com> inline On 12/13/2022 12:55 AM, John Hendrikx wrote: > Hi all, > > I was wondering, is there a reason for the current test setup in the > JavaFX code base? > > Currently, tests are all stored under src/test/java under a special > package name prefixed with "test". This is an (IMHO) unusual practice > as normally tests mirror the same packages as their main classes to > aid in testability. Testing a package private class is really hard > because of this and requires the use of a shim -- the shims do mirror > the same package hierarchy as the main classes. Yes, this was a deliberate decision. We intentionally moved all tests out of the javafx.* hierarchy, primarily so that they could run in the unnamed module as part of the JDK 9 modularization and encapsulation effort, and added the shims to support whitebox testing. See https://bugs.openjdk.org/browse/JDK-8134760 > A few questions related to this: > > 1) When testing a package private class in the com.sun.* hierarchy, is > it okay to just make the class public (as it is already private API) > so it can be tested without a shim? In general, yes. If you need to do whitebox testing of a com.sun class, there is no need to use a shim (although I see that was done in a small number of cases). > 2) Can at least the com.sun.* hierarchy be mirrored in src/test/java > without the "test" package prefix?? Again, they're both non-public > packages anyway. No, that would require running those tests in the javafx.* module and is not the direction I would want to go. > > 3) Can we perhaps move all test classes to the package of their main > counterparts, and do away with (probably all) shims? No. -- Kevin > > --John > From angorya at openjdk.org Tue Dec 13 16:39:32 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Dec 2022 16:39:32 GMT Subject: RFR: 8290040: Provide simplified deterministic way to manage listeners [v14] In-Reply-To: References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Mon, 12 Dec 2022 22:42:16 GMT, John Hendrikx wrote: >> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. >> >> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). >> >> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: >> >> label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); >> >> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. >> >> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. >> >> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. >> >> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting in test lgtm ------------- Marked as reviewed by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/830 From angorya at openjdk.org Tue Dec 13 16:43:11 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Dec 2022 16:43:11 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 08:41:55 GMT, John Hendrikx wrote: >> But is it correct? The previous code computed a deltaTime in seconds as `((currentNanos - startNanos) / 1e9)`, and then divided the `scrollMagnitude` by that. I think that the equivalent to the old code is: >> >> >> scrollMagnitude / (nanosPassed * NANOS_TO_SECONDS) > > It turns out it is not correct, the parenthesis are indeed required, not sure how I could have missed it. I'm going to see if I can add a test to this as they're missing to ensure it does the same before/after (aside from precision). could we create a new method, like 'nanosToSeconds'? ------------- PR: https://git.openjdk.org/jfx/pull/966 From angorya at openjdk.org Tue Dec 13 22:14:29 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Dec 2022 22:14:29 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v21] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8293119: abstract ------------- Changes: - all: https://git.openjdk.org/jfx/pull/897/files - new: https://git.openjdk.org/jfx/pull/897/files/671d9773..d4c70665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=19-20 Stats: 12 lines in 1 file changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Tue Dec 13 22:40:21 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Dec 2022 22:40:21 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v21] In-Reply-To: References: Message-ID: <02Xj8izR6_LMqcbXAKFvJibyrUh5mKMCq1vTZbhoO5k=.6797be20-a76c-4143-aec5-98f63b8d4b0e@github.com> On Tue, 13 Dec 2022 22:14:29 GMT, Andy Goryachev wrote: >> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class >> - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8293119: abstract The API changes to make the class abstract look good. ------------- PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Tue Dec 13 23:42:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Dec 2022 23:42:13 GMT Subject: RFR: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* [v4] In-Reply-To: References: Message-ID: On Sun, 11 Dec 2022 14:30:22 GMT, John Hendrikx wrote: >> - Added generics (to package private or internal classes only) >> - Minor clean-ups of code I touched (naming) >> - Fixed incorrect use of generics >> - Fixed raw type warnings >> >> Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Adjusted ReadOnlySetProperty#equals > - Adjusted ReadOnlyMapProperty#equals Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/969 From kcr at openjdk.org Wed Dec 14 00:02:09 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Dec 2022 00:02:09 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v32] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 11 Dec 2022 21:47:50 GMT, Thiago Milczarek Sayao wrote: > I fixed the `setIconified` before `show` and also tested maximized and fullscreen. Excellent. I also verified that, in connection with my proposed fix to `IconifyTest`, it also fixes the two cases that were broken in Ubuntu 22.04. I'll test a few more cases, but it looks quite solid now. ------------- PR: https://git.openjdk.org/jfx/pull/915 From jvos at openjdk.org Wed Dec 14 10:12:02 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 14 Dec 2022 10:12:02 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing Message-ID: When recalculating sizes, we often don't want the current index and/or offset to change. Allow to fix the index/offset when doing recalculations. Fix JDK-8298728 ------------- Commit messages: - When recalculating sizes, we often don't want the current index and/or offset to change. Changes: https://git.openjdk.org/jfx/pull/974/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=974&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298728 Stats: 113 lines in 4 files changed: 96 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/974.diff Fetch: git fetch https://git.openjdk.org/jfx pull/974/head:pull/974 PR: https://git.openjdk.org/jfx/pull/974 From aghaisas at openjdk.org Wed Dec 14 10:56:16 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 14 Dec 2022 10:56:16 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v14] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:16:58 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: cleanup > - 8187145: also tree table view > - 8187145: whitespace > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: review comments > - 8187145: github > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - ... and 11 more: https://git.openjdk.org/jfx/compare/6abbe080...5093f056 Fix looks good to me! ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/876 From jhendrikx at openjdk.org Wed Dec 14 12:27:11 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Dec 2022 12:27:11 GMT Subject: Integrated: JDK-8298200 Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:12:39 GMT, John Hendrikx wrote: > - Added generics (to package private or internal classes only) > - Minor clean-ups of code I touched (naming) > - Fixed incorrect use of generics > - Fixed raw type warnings > > Note: some raw types have leaked into public API. These could be fixed without incompatibilities. For specifics see `JavaBeanObjectPropertyBuilder`. The javadoc would have the method signatures change (`` would be appended to the affected methods). For now I've added a TODO there. This pull request has now been integrated. Changeset: f217d5e9 Author: John Hendrikx Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/f217d5e9564e87eb573b7990fa9bfb395f75c070 Stats: 174 lines in 38 files changed: 12 ins; 21 del; 141 mod 8298200: Clean up raw type warnings in javafx.beans.property.* and com.sun.javafx.property.* Reviewed-by: kcr, nlisker ------------- PR: https://git.openjdk.org/jfx/pull/969 From jhendrikx at openjdk.org Wed Dec 14 12:28:16 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Dec 2022 12:28:16 GMT Subject: Integrated: 8290040: Provide simplified deterministic way to manage listeners In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com> Message-ID: On Fri, 15 Jul 2022 09:03:35 GMT, John Hendrikx wrote: > This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`. > > It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here). > > Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property: > > label.textProperty().bind(longLivedProperty.when(label::isShowingProperty)); > > The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing. When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`. A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along. > > The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR. > > Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out. > > (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window. This pull request has now been integrated. Changeset: adfc0220 Author: John Hendrikx Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/adfc022060087490d0a620f38104a826411820ae Stats: 401 lines in 3 files changed: 399 ins; 1 del; 1 mod 8290040: Provide simplified deterministic way to manage listeners Reviewed-by: nlisker, angorya, kcr, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/830 From kcr at openjdk.org Wed Dec 14 13:55:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Dec 2022 13:55:33 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v33] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 11 Dec 2022 22:34:04 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused method I submitted PR #975 to fix the instability of `IconifyTest`. With that patch, `IconifyTest` is now stable, and reveals a problem on Ubuntu 22.04 where undecorated/transparent Stages consistently fail to deiconify. Applying that patch on top of this PR branch shows that the bug is fixed by this PR (so I don't plan to file a separate bug). I hope to integrate PR #975 in as soon as possible to aid in final testing of this PR. ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Wed Dec 14 14:04:40 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Dec 2022 14:04:40 GMT Subject: RFR: 8298496: IconifyTest fails intermittently on Linux Message-ID: `IconifyTest` is unstable on Linux, which makes it impossible to rely on it to test the ability to iconify and deiconify a Stage. The reason for the instability is that the stacking order of multiple always-on-top windows on Linux is wrong sometimes. See [JDK-8298499](https://bugs.openjdk.org/browse/JDK-8298499). Using two always-on-top Stages is unnecessary for this test, and the test will be more stable without it. The fix is to create the bottom Stage without setting `alwaysOnTop`, leaving only the top Stage `alwaysOnTop`. Further, the test now waits for the bottom Stage to be shown before creating the top Stage. The call to `topStage.toFront()` is removed as it is unnecessary. It should never have been needed, and its presence suggests that it might have been an attempted workaround for the stacking order problem (now tracked by JDK-8298499 as mentioned previously). Finally, I increased the wait time between operations from 500 msec to 1000 msec, to match what most other similar tests do (this latter helped stability on my old Ubuntu 16.04 system). With this fix, the test is now stable on Linux (and is still stable on Windows and Mac). It consistently passes on Linux except Ubuntu 22.04, where it now shows a real problem that undecorated/transparent Stages consistently fail to deiconify (the instability of the test was preventing our being able to see that). Given that #915 fixes this newly discovered problem, I won't file a new bug, but rather will add it to that bug. ------------- Commit messages: - adjust sleep time to 1 second - 8298496: IconifyTest fails intermittently on Linux Changes: https://git.openjdk.org/jfx/pull/975/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298496 Stats: 19 lines in 1 file changed: 6 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/975.diff Fetch: git fetch https://git.openjdk.org/jfx pull/975/head:pull/975 PR: https://git.openjdk.org/jfx/pull/975 From arapte at openjdk.org Wed Dec 14 15:31:23 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 14 Dec 2022 15:31:23 GMT Subject: RFR: 8297067: Update Gradle to 7.6 Message-ID: This upgrades gradle to 7.6, It is blocker for upgrading Boot JDK to 19. gradle 7.3 does not support JDK 19. Tested that, gradle 7.6 works with JDK 17, 18, 19. ------------- Commit messages: - jcheck fix - Notice - gradle-7.6 Changes: https://git.openjdk.org/jfx/pull/973/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297067 Stats: 55 lines in 6 files changed: 36 ins; 1 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/973.diff Fetch: git fetch https://git.openjdk.org/jfx pull/973/head:pull/973 PR: https://git.openjdk.org/jfx/pull/973 From kpk at openjdk.org Wed Dec 14 16:22:05 2022 From: kpk at openjdk.org (Karthik P K) Date: Wed, 14 Dec 2022 16:22:05 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:40:18 GMT, Andy Goryachev wrote: > @karthikpandelu would you be able to take a look at this PR, specifically check the new behavior using `ATableViewResizeTester` app? Please note anything you don't like or find questionable. Thanks! I checked the behavior with some of the combinations of Data and Policy options. Please find my observations below. This was run in Windows 11 system. - In `ATableViewResizeTester` app, JTable present in the bottom half gets displayed only when I change Policy or Data values or drag the app window using title bar of the app. Not sure if this issue is from app side. - Observed inconsistent behavior with Data value "fixed in the middle" and Policy value "CONSTRAINED_RESIZE_POLICY". Steps to reproduce: - Run the app and select CONSTRAINED_RESIZE_POLICY policy. - Increase and decrease the TableView size using vertical SplitPane. Column C6 size is not consistent each time when TableView size is changed. In some cases, C6 width is same as other columns like C7, C8, other times it is more than other columns. - Similar to AUTO_RESIZE_SUBSEQUENT_COLUMNS is there a provision to resize previous columns? I was just wondering if there is an option for that. ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Wed Dec 14 17:53:34 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Dec 2022 17:53:34 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v22] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8293119: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/897/files - new: https://git.openjdk.org/jfx/pull/897/files/d4c70665..44a995af Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=21 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=20-21 Stats: 8 lines in 1 file changed: 3 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Wed Dec 14 17:56:00 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Dec 2022 17:56:00 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v23] In-Reply-To: References: Message-ID: > The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). > > We propose to address all these issues by replacing the old column resize algorithm with a different one, which not only honors all the constraints when resizing, but also provides 4 different resize modes similar to JTable's. The new implementation brings changes to the public API for Tree/TableView and ResizeFeaturesBase classes. Specifically: > > - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase class > - provide an out-of-the box implementation via javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS > - add corresponding public static constants to Tree/TableView > - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) > - add getContentWidth() and setColumnWidth(TableColumnBase col, double width) methods to ResizeFeatureBase > - suppress the horizontal scroll bar when resize policy is instanceof ConstrainedColumnResizeBase > - update javadoc > > > Notes > > 1. The current resize policies' toString() methods return "unconstrained-resize" and "constrained-resize", used by the skin base to set a pseudostate. All constrained policies that extend ConstrainedColumnResizeBase will return "constrained-resize" value. > 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen instead of a marker interface is exactly for its toString() method which supplies "constrained-resize" value. The implementors might choose to use a different value, however they must ensure the stylesheet contains the same adjustments for the new policy as those made in modena.css for "constrained-resize" value. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits: - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: review comments - 8293119: abstract - 8293119:

- 8293119: review comments - Merge remote-tracking branch 'origin/master' into 8293119.constrained - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: small delta - Merge remote-tracking branch 'origin/master' into 8293119.constrained - 8293119: pref - ... and 67 more: https://git.openjdk.org/jfx/compare/8763e8b0...8bdae30e ------------- Changes: https://git.openjdk.org/jfx/pull/897/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=897&range=22 Stats: 2324 lines in 14 files changed: 2061 ins; 250 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/897.diff Fetch: git fetch https://git.openjdk.org/jfx pull/897/head:pull/897 PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Wed Dec 14 18:02:24 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Dec 2022 18:02:24 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 16:18:10 GMT, Karthik P K wrote: >> @karthikpandelu would you be able to take a look at this PR, specifically check the new behavior using `ATableViewResizeTester` app? Please note anything you don't like or find questionable. >> Thanks! > >> @karthikpandelu would you be able to take a look at this PR, specifically check the new behavior using `ATableViewResizeTester` app? Please note anything you don't like or find questionable. Thanks! > > I checked the behavior with some of the combinations of Data and Policy options. Please find my observations below. This was run in Windows 11 system. > > - In `ATableViewResizeTester` app, JTable present in the bottom half gets displayed only when I change Policy or Data values or drag the app window using title bar of the app. Not sure if this issue is from app side. > - Observed inconsistent behavior with Data value "fixed in the middle" and Policy value "CONSTRAINED_RESIZE_POLICY". Steps to reproduce: > - Run the app and select CONSTRAINED_RESIZE_POLICY policy. > - Increase and decrease the TableView size using vertical SplitPane. Column C6 size is not consistent each time when TableView size is changed. In some cases, C6 width is same as other columns like C7, C8, other times it is more than other columns. > - Similar to AUTO_RESIZE_SUBSEQUENT_COLUMNS is there a provision to resize previous columns? I was just wondering if there is an option for that. Thank you @karthikpandelu for your work and helpful comments! > * In `ATableViewResizeTester` app, JTable present in the bottom half gets displayed only when I change Policy or Data values or drag the app window using title bar of the app. Not sure if this issue is from app side. @kevinrushforth mentioned this is a know problem with Swing interop on Windows (do we have a jira ticket?), can be ignored for the purposes of this PR. > * Observed inconsistent behavior with Data value "fixed in the middle" and Policy value "CONSTRAINED_RESIZE_POLICY". Steps to reproduce: made some changes, please take a look. > * Similar to AUTO_RESIZE_SUBSEQUENT_COLUMNS is there a provision to resize previous columns? I was just wondering if there is an option for that. There is no such policy (neither here nor in JTable). I suppose it is possible. I find the other policy CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS is less useful than the the new default policy CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN - something about changes applied from left to right feeling more natural. ------------- PR: https://git.openjdk.org/jfx/pull/897 From kcr at openjdk.org Wed Dec 14 19:14:15 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Dec 2022 19:14:15 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 18:00:09 GMT, Andy Goryachev wrote: > > * In `ATableViewResizeTester` app, JTable present in the bottom half gets displayed only when I change Policy or Data values or drag the app window using title bar of the app. Not sure if this issue is from app side. > > @kevinrushforth mentioned this is a know problem with Swing interop on Windows (do we have a jira ticket?), can be ignored for the purposes of this PR. The bug I had originally filed was closed as a duplicate of another bug that was later closed as Incomplete. I discovered that it was still reproducible a couple months ago, and thought I had re-filed it, but I hadn't. I just now filed a new bug [JDK-8298796](https://bugs.openjdk.org/browse/JDK-8298796) to track this. So yes, this can be ignored for the purpose of this PR. ------------- PR: https://git.openjdk.org/jfx/pull/897 From angorya at openjdk.org Wed Dec 14 20:57:16 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Dec 2022 20:57:16 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 10:03:29 GMT, Johan Vos wrote: > When recalculating sizes, we often don't want the current index and/or offset to change. > > Allow to fix the index/offset when doing recalculations. > > Fix JDK-8298728 I am trying to understand what the behavioral difference is between this branch and the current master. The ticket JDK-8298728 does not seem to specify the exact scenario, so I tried the following code with the large model (3000 lines) with a wrapping Text as graphic node. Resizing both vertically and horizontally produces what I this is identical result where the top visible selected cell scrolls out of the view in both cases. cell factory: TableColumn c = new TableColumn<>(); table.getColumns().add(c); c.setText("C" + table.getColumns().size()); c.setCellValueFactory((f) -> new SimpleStringProperty(describe(c))); c.setCellFactory((r) -> { return new TableCell<>() { @Override protected void updateItem(String item, boolean empty) { super.updateItem(item, empty); Text t = new Text("11111111111111111111111111111111111111111111111111111111111111111111111111111111111111\n2\n3\n"); t.wrappingWidthProperty().bind(widthProperty()); setPrefHeight(USE_COMPUTED_SIZE); setGraphic(t); } }; }); I can attache the whole program to the jira ticket. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2327: > 2325: double cellLength = getOrCreateCellSize(index); > 2326: if (index > 0) getOrCreateCellSize(index - 1); > 2327: if (index < getCellCount() -1) getOrCreateCellSize(index + 1); I think it's better to keep one statement per line - for stepping through in a debugger, and also if an exception gets thrown it will be easier to see where. ------------- PR: https://git.openjdk.org/jfx/pull/974 From jvos at openjdk.org Wed Dec 14 21:21:09 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 14 Dec 2022 21:21:09 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: <6HQTNYP7ERzGf28AK8XRo1IzU-wHMzTrQpbwhlIfL-8=.f1b22437-5449-4bcb-8277-4009e07ea143@github.com> On Wed, 14 Dec 2022 20:54:26 GMT, Andy Goryachev wrote: > I am trying to understand what the behavioral difference is between this branch and the current master. I added a new test in VirtualFlowTest. It fails without the patch, and succeeds with the patch. The change is that if a cell is shown with some given content, then a cell is resized, and then a scroll operation is performed, the result of this scroll could be unexpected. I added comments in the added test so that the flow should be clear. Does this help? ------------- PR: https://git.openjdk.org/jfx/pull/974 From angorya at openjdk.org Wed Dec 14 22:02:18 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Dec 2022 22:02:18 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 10:03:29 GMT, Johan Vos wrote: > When recalculating sizes, we often don't want the current index and/or offset to change. > > Allow to fix the index/offset when doing recalculations. > > Fix JDK-8298728 I think this might be the case when unit tests are insufficient. With this change, I notice something else: select a cell somewhere in the middle of the table, click on the scroll bar to page up, then click on the other side of the scroll bar to page down. The existing code works correctly, the new code does not - the position is different, sometimes the selected cell is scrolled outside of the view. see "does not page back to the same spot.mp4" in jira ------------- PR: https://git.openjdk.org/jfx/pull/974 From kcr at openjdk.org Thu Dec 15 00:24:13 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Dec 2022 00:24:13 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v14] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:16:58 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: cleanup > - 8187145: also tree table view > - 8187145: whitespace > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - 8187145: review comments > - 8187145: github > - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model > - ... and 11 more: https://git.openjdk.org/jfx/compare/6abbe080...5093f056 Looks good. I noted two minor formatting issues. If you fix them, I'll reapprove. modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 1608: > 1606: > 1607: List> removed = new ArrayList<>(); > 1608: if(prevState != null) { Minor: missing space after the `if`. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 230: > 228: protected static boolean containsPseudoclass(Node n, String pseudoclass) { > 229: for (PseudoClass pc: n.getPseudoClassStates()) { > 230: if(pseudoclass.equals(pc.getPseudoClassName())) { Minor: missing space after `if` ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Dec 15 01:27:42 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Dec 2022 01:27:42 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v15] In-Reply-To: References: Message-ID: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 8187145: formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/876/files - new: https://git.openjdk.org/jfx/pull/876/files/5093f056..303f1dd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=876&range=13-14 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/876.diff Fetch: git fetch https://git.openjdk.org/jfx pull/876/head:pull/876 PR: https://git.openjdk.org/jfx/pull/876 From angorya at openjdk.org Thu Dec 15 01:27:44 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Dec 2022 01:27:44 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v14] In-Reply-To: References: Message-ID: <3qG6SAeEibdbq4eNB3az5GxJUPs1Qzcm80KDupNgzIU=.faa284d9-3a24-4856-8461-b9c97b862e2d@github.com> On Thu, 15 Dec 2022 00:21:29 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: cleanup >> - 8187145: also tree table view >> - 8187145: whitespace >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - 8187145: review comments >> - 8187145: github >> - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model >> - ... and 11 more: https://git.openjdk.org/jfx/compare/6abbe080...5093f056 > > Looks good. I noted two minor formatting issues. If you fix them, I'll reapprove. formatting fixed. please re-approve. @kevinrushforth @aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/876 From kpk at openjdk.org Thu Dec 15 04:55:15 2022 From: kpk at openjdk.org (Karthik P K) Date: Thu, 15 Dec 2022 04:55:15 GMT Subject: RFR: 8293119: Additional constrained resize policies for Tree/TableView [v20] In-Reply-To: References: Message-ID: <3FSxhnKYjXghb7EoKktmHalbfJWh-5k5q78HThn_Olg=.9b962d09-0eee-4d23-ac76-d39c7c810d3d@github.com> On Wed, 14 Dec 2022 18:00:09 GMT, Andy Goryachev wrote: > > * Observed inconsistent behavior with Data value "fixed in the middle" and Policy value "CONSTRAINED_RESIZE_POLICY". Steps to reproduce: > > made some changes, please take a look. > This looks fine now. > > * Similar to AUTO_RESIZE_SUBSEQUENT_COLUMNS is there a provision to resize previous columns? I was just wondering if there is an option for that. > > There is no such policy (neither here nor in JTable). I suppose it is possible. I find the other policy CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS is less useful than the the new default policy CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN - something about changes applied from left to right feeling more natural. Okay. Agreed, CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN looks more natural ------------- PR: https://git.openjdk.org/jfx/pull/897 From arapte at openjdk.org Thu Dec 15 09:48:18 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 15 Dec 2022 09:48:18 GMT Subject: RFR: 8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed [v3] In-Reply-To: References: Message-ID: <8xEyo0S-FJ9q5CWbBowiwsUVfHwvVqYAtZBRJqQyL-Y=.0564babd-b413-4ce5-b781-36ed30b3982b@github.com> On Sat, 10 Dec 2022 10:38:07 GMT, Dean Wookey wrote: >> When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times. >> >> MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice. >> >> When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance. >> >> This pull request just removes the redundant code in the MenuButtonSkinBase. > > Dean Wookey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Implemented alternative fix > - Merge branch 'master' of https://github.com/openjdk/jfx into JDK-8296409 > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java > - Added changing scene tests for accelerator change listeners > - 8296409: Stop additional change listeners being added Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/937 From jhendrikx at openjdk.org Thu Dec 15 12:16:44 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Dec 2022 12:16:44 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes [v2] In-Reply-To: References: Message-ID: > This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. > > I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Make RotateGestureRecognizer easier to test - Revert all changes to RotateGestureRecognizer ------------- Changes: - all: https://git.openjdk.org/jfx/pull/966/files - new: https://git.openjdk.org/jfx/pull/966/files/eef709a2..ce9979fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=966&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=966&range=00-01 Stats: 484 lines in 4 files changed: 372 ins; 24 del; 88 mod Patch: https://git.openjdk.org/jfx/pull/966.diff Fetch: git fetch https://git.openjdk.org/jfx pull/966/head:pull/966 PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Thu Dec 15 12:23:12 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Dec 2022 12:23:12 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes [v3] In-Reply-To: References: Message-ID: <0b71d2ypgR4ww4hlEw5paLEn4JejB50Y4yajKDhIj_A=.429d6126-cbd5-4019-ae63-865b89fe7ddd@github.com> > This includes a fix for the precision problem we've found as part of the graphics warnings clean ups. > > I've included two commits, one with just the minimal fix, and one with the clean ups. I can drop off the 2nd commit if it is deemed to be of no added value. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge remote-tracking branch 'upstream/master' into feature/precision-problem-in-gesture-recognizers - Make RotateGestureRecognizer easier to test - Revert all changes to RotateGestureRecognizer - General clean ups - Made constants written in capitals final - Made fields final that can be final - Made fields and methods private that can be private - Renamed constants that aren't constant to camel case - Fixed spelling errors - Re-ordered fields (statics at the top) - Removed redundant initial values - Removed unused fields and parameters - Optimized imports - Removed commented out code - Fix precision problems in gesture recognizers ------------- Changes: https://git.openjdk.org/jfx/pull/966/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=966&range=02 Stats: 530 lines in 7 files changed: 377 ins; 36 del; 117 mod Patch: https://git.openjdk.org/jfx/pull/966.diff Fetch: git fetch https://git.openjdk.org/jfx pull/966/head:pull/966 PR: https://git.openjdk.org/jfx/pull/966 From jhendrikx at openjdk.org Thu Dec 15 12:26:13 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Dec 2022 12:26:13 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes [v3] In-Reply-To: <0MQ0EAGpj53aADbIYx8N24I3ihDbiGSm2U4DHDJKBS0=.12cf1724-8fa3-41b1-bbdb-96c395382eff@github.com> References: <0MQ0EAGpj53aADbIYx8N24I3ihDbiGSm2U4DHDJKBS0=.12cf1724-8fa3-41b1-bbdb-96c395382eff@github.com> Message-ID: <18ffMHLSMYlBM0qFBxFe4lXMhI8sorH8VYdFOWdB4AI=.6c9c7611-1e4a-4600-afbd-32b51215199c@github.com> On Mon, 12 Dec 2022 23:02:42 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge remote-tracking branch 'upstream/master' into feature/precision-problem-in-gesture-recognizers >> - Make RotateGestureRecognizer easier to test >> - Revert all changes to RotateGestureRecognizer >> - General clean ups >> >> - Made constants written in capitals final >> - Made fields final that can be final >> - Made fields and methods private that can be private >> - Renamed constants that aren't constant to camel case >> - Fixed spelling errors >> - Re-ordered fields (statics at the top) >> - Removed redundant initial values >> - Removed unused fields and parameters >> - Optimized imports >> - Removed commented out code >> - Fix precision problems in gesture recognizers > > inline @kevinrushforth Please advise if I should continue on this road: I've reverted `RotateGestureRecognizer` to add a test case first. To make `RotateGestureRecognizer` testable I had to make it public and abstract away the need for `ViewScene` as constructor parameter, see the `Make RotateGestureRecognizer easier to test` commit. I also added a test case (90% coverage). If you are okay with these changes (I needed to change `GlassViewEventHandler` and add a small interface), I can do the same for the Zoom & ScrollGestureRecognizers. The test I added reveals the precision problem when you uncomment the line: `passTime(Long.MAX_VALUE / 1000 / 1000 - 10000000);` -- the accuracy problem of converting longs to doubles then breaks the test. The newer version of the code works (after I fixed the calculation by adding parenthesis). ------------- PR: https://git.openjdk.org/jfx/pull/966 From kcr at openjdk.org Thu Dec 15 13:05:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Dec 2022 13:05:14 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v15] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 01:27:42 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8187145: formatting Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.org/jfx/pull/876 From jvos at openjdk.org Thu Dec 15 13:19:12 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 15 Dec 2022 13:19:12 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 10:03:29 GMT, Johan Vos wrote: > When recalculating sizes, we often don't want the current index and/or offset to change. > > Allow to fix the index/offset when doing recalculations. > > Fix JDK-8298728 > That sounds exactly like something that *should* be a unit test. ------------- PR: https://git.openjdk.org/jfx/pull/974 From aghaisas at openjdk.org Thu Dec 15 13:20:16 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 15 Dec 2022 13:20:16 GMT Subject: RFR: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting [v15] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 01:27:42 GMT, Andy Goryachev wrote: >> Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. >> >> Setting a null selection model is a valid way to disable selection in a (tree)table. >> >> There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). >> >> changes: >> - added check for null selection model where it was missing >> - clear focused row index on setting null selection model in TreeTableView >> - clear selected cells on setting a new selection model > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 8187145: formatting Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.org/jfx/pull/876 From kpk at openjdk.org Thu Dec 15 14:33:58 2022 From: kpk at openjdk.org (Karthik P K) Date: Thu, 15 Dec 2022 14:33:58 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene Message-ID: Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. Added unit test to validate the fix ------------- Commit messages: - Remove commented line - Add removed empty line - Fix spinner running issue on removing from scene Changes: https://git.openjdk.org/jfx/pull/976/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=976&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8252863 Stats: 115 lines in 5 files changed: 112 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/976.diff Fetch: git fetch https://git.openjdk.org/jfx pull/976/head:pull/976 PR: https://git.openjdk.org/jfx/pull/976 From arapte at openjdk.org Thu Dec 15 15:28:12 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 15 Dec 2022 15:28:12 GMT Subject: RFR: 8298496: IconifyTest fails intermittently on Linux In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:48:21 GMT, Kevin Rushforth wrote: > `IconifyTest` is unstable on Linux, which makes it impossible to rely on it to test the ability to iconify and deiconify a Stage. The reason for the instability is that the stacking order of multiple always-on-top windows on Linux is wrong sometimes. See [JDK-8298499](https://bugs.openjdk.org/browse/JDK-8298499). Using two always-on-top Stages is unnecessary for this test, and the test will be more stable without it. The fix is to create the bottom Stage without setting `alwaysOnTop`, leaving only the top Stage `alwaysOnTop`. Further, the test now waits for the bottom Stage to be shown before creating the top Stage. The call to `topStage.toFront()` is removed as it is unnecessary. It should never have been needed, and its presence suggests that it might have been an attempted workaround for the stacking order problem (now tracked by JDK-8298499 as mentioned previously). Finally, I increased the wait time between operations from 500 msec to 1000 msec, to match what most other simila r tests do (this latter helped stability on my old Ubuntu 16.04 system). > > With this fix, the test is now stable on Linux (and is still stable on Windows and Mac). It consistently passes on Linux except Ubuntu 22.04, where it now shows a real problem that undecorated/transparent Stages consistently fail to deiconify (the instability of the test was preventing our being able to see that). Given that #915 fixes this newly discovered problem, I won't file a new bug, but rather will add it to that bug. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.org/jfx/pull/975 From angorya at openjdk.org Thu Dec 15 16:05:27 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Dec 2022 16:05:27 GMT Subject: Integrated: 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 16:24:11 GMT, Andy Goryachev wrote: > Setting a null selection model in TableView and TreeTableView produce NPE on sorting (and probably in some other situations) because the check for null is missing in several places. > > Setting a null selection model is a valid way to disable selection in a (tree)table. > > There is also a similar issue with ListView [JDK-8279640](https://bugs.openjdk.org/browse/JDK-8279640). > > changes: > - added check for null selection model where it was missing > - clear focused row index on setting null selection model in TreeTableView > - clear selected cells on setting a new selection model This pull request has now been integrated. Changeset: 58376eb8 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/58376eb844866f7e2fea726865eb2f821b09752f Stats: 469 lines in 15 files changed: 378 ins; 12 del; 79 mod 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.org/jfx/pull/876 From kcr at openjdk.org Thu Dec 15 16:31:10 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Dec 2022 16:31:10 GMT Subject: Integrated: 8298496: IconifyTest fails intermittently on Linux In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 13:48:21 GMT, Kevin Rushforth wrote: > `IconifyTest` is unstable on Linux, which makes it impossible to rely on it to test the ability to iconify and deiconify a Stage. The reason for the instability is that the stacking order of multiple always-on-top windows on Linux is wrong sometimes. See [JDK-8298499](https://bugs.openjdk.org/browse/JDK-8298499). Using two always-on-top Stages is unnecessary for this test, and the test will be more stable without it. The fix is to create the bottom Stage without setting `alwaysOnTop`, leaving only the top Stage `alwaysOnTop`. Further, the test now waits for the bottom Stage to be shown before creating the top Stage. The call to `topStage.toFront()` is removed as it is unnecessary. It should never have been needed, and its presence suggests that it might have been an attempted workaround for the stacking order problem (now tracked by JDK-8298499 as mentioned previously). Finally, I increased the wait time between operations from 500 msec to 1000 msec, to match what most other simila r tests do (this latter helped stability on my old Ubuntu 16.04 system). > > With this fix, the test is now stable on Linux (and is still stable on Windows and Mac). It consistently passes on Linux except Ubuntu 22.04, where it now shows a real problem that undecorated/transparent Stages consistently fail to deiconify (the instability of the test was preventing our being able to see that). Given that #915 fixes this newly discovered problem, I won't file a new bug, but rather will add it to that bug. This pull request has now been integrated. Changeset: 30147d2f Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/30147d2f8dfd3fe32f9ea6e70431efe90b015080 Stats: 19 lines in 1 file changed: 6 ins; 4 del; 9 mod 8298496: IconifyTest fails intermittently on Linux Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/975 From angorya at openjdk.org Thu Dec 15 17:51:55 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Dec 2022 17:51:55 GMT Subject: RFR: 8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute() Message-ID: - added test to ensure no exception is thrown from Control.queryAccessibleAttribute() for all accessible attributes values - fixed null focus model case in Tree/TableView ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into - Merge branch '8187145.null.selection.model' into 8296413.query.accessible - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - Merge branch '8187145.null.selection.model' into 8296413.query.accessible - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8296413: cleanup - Merge branch '8187145.null.selection.model' into 8296413.query.accessible - Merge remote-tracking branch 'origin/master' into 8187145.null.selection.model - 8296413: query accessible - 8187145: cleanup - ... and 17 more: https://git.openjdk.org/jfx/compare/30147d2f...b88d3267 Changes: https://git.openjdk.org/jfx/pull/938/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=938&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296413 Stats: 228 lines in 8 files changed: 181 ins; 26 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/938.diff Fetch: git fetch https://git.openjdk.org/jfx pull/938/head:pull/938 PR: https://git.openjdk.org/jfx/pull/938 From jvos at openjdk.org Thu Dec 15 18:06:15 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 15 Dec 2022 18:06:15 GMT Subject: RFR: 8298728: Cells in VirtualFlow jump after resizing In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 18:06:28 GMT, Andy Goryachev wrote: >> When recalculating sizes, we often don't want the current index and/or offset to change. >> >> Allow to fix the index/offset when doing recalculations. >> >> Fix JDK-8298728 > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2327: > >> 2325: double cellLength = getOrCreateCellSize(index); >> 2326: if (index > 0) getOrCreateCellSize(index - 1); >> 2327: if (index < getCellCount() -1) getOrCreateCellSize(index + 1); > > I think it's better to keep one statement per line - for stepping through in a debugger, and also if an exception gets thrown it will be easier to see where. True -- I'll change that. ------------- PR: https://git.openjdk.org/jfx/pull/974 From angorya at openjdk.org Fri Dec 16 01:02:12 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Dec 2022 01:02:12 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 14:23:57 GMT, Karthik P K wrote: > Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. > > Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. > > Added unit test to validate the fix also, this change should trigger a failure in SkinMemoryLeakTest. I see the checks are failing. modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 254: > 252: })); > 253: > 254: getSkinnable().sceneProperty().addListener((observable, oldValue, newValue) -> { this will permanently add a listener on the control's scene property, creating a memory leak when skins are replaced. You probably want to use the newly introduced ListenerHelper (there is an instance of it right there in the constructor): lh.addChangeListener(control.sceneProperty(), (x) -> { behavior.stopSpinning(); }); doing this will decouple the listener on Skin.dispose() ------------- Changes requested by angorya (Committer). PR: https://git.openjdk.org/jfx/pull/976 From kcr at openjdk.org Fri Dec 16 01:49:14 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Dec 2022 01:49:14 GMT Subject: RFR: 8297067: Update Gradle to 7.6 In-Reply-To: References: Message-ID: <1j3klKNDa_7nfHbIhoqz1ITOMt45ghThvOUgbIYp63E=.00553dec-6897-466e-a114-1da2b285f5ac@github.com> On Wed, 14 Dec 2022 08:26:35 GMT, Ambarish Rapte wrote: > This upgrades gradle to 7.6, It is blocker for upgrading Boot JDK to 19. > gradle 7.3 does not support JDK 19. > Tested that, gradle 7.6 works with JDK 17, 18, 19. Looks good. @johanvos or @tiainen can one of you be the second reviewer? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/973 From kcr at openjdk.org Fri Dec 16 01:52:12 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Dec 2022 01:52:12 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 00:57:00 GMT, Andy Goryachev wrote: >> Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. >> >> Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. >> >> Added unit test to validate the fix > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 254: > >> 252: })); >> 253: >> 254: getSkinnable().sceneProperty().addListener((observable, oldValue, newValue) -> { > > this will permanently add a listener on the control's scene property, creating a memory leak when skins are replaced. > You probably want to use the newly introduced ListenerHelper (there is an instance of it right there in the constructor): > > lh.addChangeListener(control.sceneProperty(), (x) -> { > behavior.stopSpinning(); > }); > > > doing this will decouple the listener on Skin.dispose() Yes, and the failing unit tests show exactly this leak. ------------- PR: https://git.openjdk.org/jfx/pull/976 From kpk at openjdk.org Fri Dec 16 04:51:53 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 16 Dec 2022 04:51:53 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v2] In-Reply-To: References: Message-ID: > Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. > > Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. > > Added unit test to validate the fix Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Use ListenerHelper for sceneProperty ------------- Changes: - all: https://git.openjdk.org/jfx/pull/976/files - new: https://git.openjdk.org/jfx/pull/976/files/e56e6cb3..6b59cbe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=976&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=976&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/976.diff Fetch: git fetch https://git.openjdk.org/jfx pull/976/head:pull/976 PR: https://git.openjdk.org/jfx/pull/976 From kpk at openjdk.org Fri Dec 16 05:11:11 2022 From: kpk at openjdk.org (Karthik P K) Date: Fri, 16 Dec 2022 05:11:11 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v2] In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 01:49:12 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 254: >> >>> 252: })); >>> 253: >>> 254: getSkinnable().sceneProperty().addListener((observable, oldValue, newValue) -> { >> >> this will permanently add a listener on the control's scene property, creating a memory leak when skins are replaced. >> You probably want to use the newly introduced ListenerHelper (there is an instance of it right there in the constructor): >> >> lh.addChangeListener(control.sceneProperty(), (x) -> { >> behavior.stopSpinning(); >> }); >> >> >> doing this will decouple the listener on Skin.dispose() > > Yes, and the failing unit tests show exactly this leak. Made changes to use `ListenereHelper` instead of permanently adding listener on control's `sceneProperty`. Please check. ------------- PR: https://git.openjdk.org/jfx/pull/976 From kcr at openjdk.org Fri Dec 16 19:24:03 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Dec 2022 19:24:03 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v33] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 11 Dec 2022 22:34:04 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused method I did a fair bit of testing yesterday and today. I ran automated tests on 3 different versions of Linux: Ubuntu 16.04 (physical), Ubuntu 20.04, and Ubuntu 22.04. I ran sanity tests on two others: Oracle Linux 7.7, Oracle Linux 8.5. Other than Ubuntu 16.04 (see below), most of my testing looks good. I did spot one new regression that needs to be looked at. I think it is related to the initial size or position reported to an app in a way that affects layout. While testing to see whether [JDK-8292922](https://bugs.openjdk.org/browse/JDK-8292922) might be fixed by this PR (it isn't, but that can be looked at separately), I ran the "DragFailure2" test program attached to that bug report. When initially drawn the top component of the border pane is about 30 pixels lower than it should be (roughly the size of the window decoration), leaving a black horizontal band between there and the actual top of the content portion of the Stage. On Ubuntu 22.04, it usually fixes itself right away (possibly due to an event that causes a redraw), so all you see is a brief flash. On Ubuntu 20.04 it does not fix itself until you interact with it in a way that will cause the window to be refreshed (e.g., temporarily moving some other w indow on top). See the attached screen shot. ![BadLayout](https://user-images.githubusercontent.com/34689748/208171448-1e24782d-0cb7-4218-b38c-75303ed32954.png) Unrelated to the above, on Ubuntu 16.04, which is very old and out of support, there are three significant problems: 1. As discussed in an [earlier comment](https://github.com/openjdk/jfx/pull/915#issuecomment-1343182944), the newly created windows do not get focus and are not brought in front of the terminal that started the application. The workaround is to set the Focus Prevention Level to OFF in compiz config settings tool. 2. A Stage that is set to full screen before being initially shown will not restore to the correct size when exiting full screen (to reproduce, run the HelloFullscreen app and press the ESC, or run the `RestoreSceneSizeTest` system test). 3. Live resize no longer happens when resizing a Window; resizing is also very slow I don't think any of these three Ubuntu 16.04 problems should block this PR from going in. A release note might be in order for the first problem, especially since it will provide a good place to document the workaround. I note that even though Ubuntu 16.04 is _very_ out of date, there might be other less common distros that still include Compiz. I also reviewed the code and didn't see anything of concern. As noted above, [JDK-8292922](https://bugs.openjdk.org/browse/JDK-8292922) is still reproducible even with this patch applied, so will need to be handled as a follow-up bug, either by using the approach I prototyped in PR #905 or some other approach. We can discuss it once this PR is integrated. ------------- PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Fri Dec 16 20:23:03 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 16 Dec 2022 20:23:03 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v33] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 11 Dec 2022 22:34:04 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused method That black area looks exactly the size of the window decoration/frame. I'll investigate. About [JDK-8292922 ](https://bugs.openjdk.org/browse/JDK-8292922) I was planning to discuss in a follow-up PR. The problem is that [Compiz](http://www.compiz.org/) is not maintained. The last release is from 2011. Should we consider to drop support completely? ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Fri Dec 16 21:42:06 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Dec 2022 21:42:06 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v33] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Fri, 16 Dec 2022 20:19:59 GMT, Thiago Milczarek Sayao wrote: > That black area looks exactly the size of the window decoration/frame. I'll investigate. That's what I thought, too (so maybe some code is applying the offset twice). Thanks. > About [JDK-8292922 ](https://bugs.openjdk.org/browse/JDK-8292922) I was planning to discuss in a follow-up PR. Sounds good. ------------- PR: https://git.openjdk.org/jfx/pull/915 From kcr at openjdk.org Sat Dec 17 00:01:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Dec 2022 00:01:01 GMT Subject: RFR: JDK-8298060: Fix precision bug in gesture recognizer classes [v3] In-Reply-To: <18ffMHLSMYlBM0qFBxFe4lXMhI8sorH8VYdFOWdB4AI=.6c9c7611-1e4a-4600-afbd-32b51215199c@github.com> References: <0MQ0EAGpj53aADbIYx8N24I3ihDbiGSm2U4DHDJKBS0=.12cf1724-8fa3-41b1-bbdb-96c395382eff@github.com> <18ffMHLSMYlBM0qFBxFe4lXMhI8sorH8VYdFOWdB4AI=.6c9c7611-1e4a-4600-afbd-32b51215199c@github.com> Message-ID: On Thu, 15 Dec 2022 12:23:54 GMT, John Hendrikx wrote: > To make RotateGestureRecognizer testable I had to make it public and abstract away the need for ViewScene as constructor parameter, see the Make RotateGestureRecognizer easier to test commit. I also added a test case (90% coverage). This seems quite an intrusive change just to support low level testing of this. I can take a closer look next week, but I'm not really sold on the idea. ------------- PR: https://git.openjdk.org/jfx/pull/966 From angorya at openjdk.org Sat Dec 17 19:59:58 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Sat, 17 Dec 2022 19:59:58 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v2] In-Reply-To: References: Message-ID: <_4kJLsgbEk7YyWxSkrlm5Xtkco3awSCFzQ1q3bjRNBc=.f9f51bb7-f69b-4934-947c-7de02027c5e3@github.com> On Fri, 16 Dec 2022 04:51:53 GMT, Karthik P K wrote: >> Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. >> >> Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. >> >> Added unit test to validate the fix > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Use ListenerHelper for sceneProperty minor corrections, let me know what you think. otherwise almost done! modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 258: > 256: behavior.stopSpinning(); > 257: }); > 258: minor: could we get rid of this extra newline? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SpinnerSkinTest.java line 178: > 176: assertEquals(Status.RUNNING, SpinnerBehaviorShim.getTimeline(behavior).getStatus()); > 177: root.getChildren().clear(); > 178: assertEquals(Status.STOPPED, SpinnerBehaviorShim.getTimeline(behavior).getStatus()); just curious: if we add the spinner back to the scene, should it spin again? do we want to add this condition to this test? ------------- PR: https://git.openjdk.org/jfx/pull/976 From jvos at openjdk.org Sat Dec 17 21:50:56 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 17 Dec 2022 21:50:56 GMT Subject: RFR: 8297067: Update Gradle to 7.6 In-Reply-To: References: Message-ID: <5Gl88w4I-FxJrkSlLslk5L3m-N5ovrJWQBKYSoPoJoE=.d5f9019c-a0bd-4f5a-af78-d3109aa80891@github.com> On Wed, 14 Dec 2022 08:26:35 GMT, Ambarish Rapte wrote: > This upgrades gradle to 7.6, It is blocker for upgrading Boot JDK to 19. > gradle 7.3 does not support JDK 19. > Tested that, gradle 7.6 works with JDK 17, 18, 19. Works fine, this is a much-needed update! ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.org/jfx/pull/973 From nlisker at gmail.com Sun Dec 18 01:57:47 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 18 Dec 2022 03:57:47 +0200 Subject: Setting graphics of a Labeled does not show the Label correctly In-Reply-To: References: <99891d32-83d4-e81c-26c7-139d8949faec@gmail.com> <3ee33875-fb11-61e9-d240-16be95c6a213@gmail.com> <6eec33ca-d0a5-770c-4abf-a6730c1f09e1@oracle.com> Message-ID: I tried to change the behavior of setting a graphic for Labeled to one that removes the graphics from its previous labeled (if exists). This resulted in test failures in a few places: * MenuButton: * MenuButtonTest::testSetContentDisplayGraphicOnly - deliberately sets the same graphic to two MenuButtons. Doesn't look correct. * LabeledImpl.Shuttler::invalidated - used by MenuButtonSkinBase, sets the graphics of the Labeled to that of its own Label. That is, it doesn't use the MenuButton's own Label, but creates a different one to use as a child and copies the properties to it. The test that fails is LabeledImplOtherTest. test_RT_21357 [1]. Also seems like an odd implementation choice. Also note that other controls that are not a Labeled have graphic properties, like Tab (as mstr mentioned), so this change doesn't solve all the cases, only those within Labeled. [1] https://bugs.openjdk.org/browse/JDK-8119175 On Mon, Dec 12, 2022 at 6:10 PM Nir Lisker wrote: > Another idea is to use a static map that maps a node to its "graphic > parent". That will save on memory at the expense of a lookup. > > On Thu, Dec 1, 2022 at 11:53 PM Nir Lisker wrote: > >> Are we convinced that a node can't be both a graphic and a clip, or >> something else? The docs for clip specify that the node is not a child in >> the scenegraph. >> >> On Thu, Dec 1, 2022 at 11:41 PM John Hendrikx >> wrote: >> >>> Adding another field doesn't seem ideal, would it be possible to >>> generalize the clipParent field to function for both (the ownedBy or owner >>> field that I suggested earlier)? >>> >>> --John >>> On 01/12/2022 20:26, Nir Lisker wrote: >>> >>> Michael's idea could solve the problem if it's about more than just >>> traversing, it needs to set rules for allowing a node to serve only 1 >>> logical role (or 1 role type, like clip and graphic?) at the same time. In >>> any case, these rules need to be decided upon before starting to work on >>> anything. I can do a quick fix for now that can be reverted later >>> if needed. From what I gather, I will need to add a graphicsParent field >>> like clipParent does. >>> >>> On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote: >>> >>>> By the way, these issues are caused by this inconsistent behavior (they >>>> are probably duplicates): >>>> >>>> https://bugs.openjdk.org/browse/JDK-8209017 >>>> https://bugs.openjdk.org/browse/JDK-8190331 >>>> >>>> The graphic of the checkbox of a CheckBoxTreeItem is not set correctly >>>> on the new CheckBox that is provided with the cell when virtual flow >>>> switches it. It might happen with other controls that use virtual flow. >>>> >>>> On Thu, Dec 1, 2022 at 8:40 PM Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> This seems related, but somewhat tangential. A Control's "graphic" >>>>> isn't >>>>> a child node, just like a Shape's "clip" isn't a child node. >>>>> >>>>> Creating a separate "document graph" (or "logical graph") sounds like >>>>> an >>>>> interesting idea, but it would bring its own set of challenges. And it >>>>> wouldn't directly solve this case anyway. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 12/1/2022 9:42 AM, Michael Strau? wrote: >>>>> > There's a larger picture here: from a user perspective, there's a >>>>> > difference between the scene graph and the "document graph". >>>>> > The document graph is what users actually work with, for example by >>>>> > setting the `Labeled.graphic` property. In some cases, document nodes >>>>> > don't correspond to scene nodes at all (`MenuItem` or `Tab` come to >>>>> > mind). >>>>> > The document graph is later inflated into a scene graph of unknown >>>>> > structure (because skins are mostly black boxes with regards to their >>>>> > internal structure). >>>>> > >>>>> > I've proposed an enhancement that would make the document graph a >>>>> > first-class citizen: >>>>> > https://mail.openjdk.org/pipermail/openjfx-dev/2022-June/034417.html >>>>> > >>>>> > With this in place, we could simply disallow the same node appearing >>>>> > multiple times in the document graph, which would not only solve the >>>>> > problem for `Labeled`, but for all controls with a similar problem. >>>>> > >>>>> > >>>>> > On Thu, Dec 1, 2022 at 6:17 PM John Hendrikx < >>>>> john.hendrikx at gmail.com> wrote: >>>>> >> The mechanism does seem like it is a bit poorly designed, as it is >>>>> easy to create inconsistencies. >>>>> >> >>>>> >> Luckily it seems that you can't remove a graphic yourself from a >>>>> Control (getChildren is protected). >>>>> >> >>>>> >> I don't think there is an easy solution though... >>>>> >> >>>>> >> I think that once you set a graphic on a Labeled, you need to >>>>> somehow mark it as "in use". Normally you could just check parent != null >>>>> for this, but it is trickier than that. The Skin ultimately determines if >>>>> it adds the graphic as child, which may be delayed or may even be disabled >>>>> (content display property is set to showing TEXT only). >>>>> >> >>>>> >> Perhaps Skins should always add the graphic and just hide it >>>>> (visible false, managed false), but that's going to be hard to enforce. >>>>> >> >>>>> >> Marking the graphic as "in use" could be done with: >>>>> >> >>>>> >> - a property in `getProperties` >>>>> >> - a new "owner" or "ownedBy" property >>>>> >> - allowing "parent" to be set without adding it to children >>>>> (probably going to mess up stuff) >>>>> >> >>>>> >> --John >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sun Dec 18 15:31:24 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 15:31:24 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v34] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: - Fixes for Ubuntu 16.04 - Merge branch 'master' into clean_glass_gtk - Merge branch 'openjdk:master' into master - Remove unused method - Merge remote-tracking branch 'origin/clean_glass_gtk' into clean_glass_gtk - Unity uses Compiz - Fix show a window minimized - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Fix init iconified - ... and 26 more: https://git.openjdk.org/jfx/compare/53550ad1...2ba608c0 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/f2b1b074..2ba608c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=33 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=32-33 Stats: 1448 lines in 63 files changed: 1174 ins; 41 del; 233 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Sun Dec 18 19:32:16 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 19:32:16 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v35] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes Ubuntu 16.0 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/2ba608c0..f4e2f602 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=33-34 Stats: 119 lines in 2 files changed: 62 ins; 47 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Sun Dec 18 20:09:55 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 20:09:55 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v35] In-Reply-To: References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: On Sun, 18 Dec 2022 19:32:16 GMT, Thiago Milczarek Sayao wrote: >> This cleans size and positioning code, reducing special cases, code complexity and size. >> >> Changes: >> >> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. >> - window geometry, min/max size are centralized in `update_window_constraints`; >> - Frame extents (the window decoration size used for "total window size"): >> - frame extents are received in `process_property_notify`; >> - removed quirks in java code; >> - When received, call `set_bounds` again to adjust the size (to account decorations later received); >> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. >> - `ensure_window_size` was a quirk - removed; >> - `requested_bounds` removed - not used anymore; >> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; >> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) >> - `restack` split in `to_front()` and `to_back()` to conform to managed code; >> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; >> - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Ubuntu 16.0 **About Ubuntu 16.04:** - `RestoreSceneSizeTest` should be fixed; - I kept `gtk_window_focus_on_map` `TRUE` on Compiz - so it will behave as before; - I introduced a `WindowManager` enum in case different work arounds are needed for other window managers; - About Live resizing: master branch does not live resize as well (at least on my VM); **About the black area** - It does not happen on a Ubuntu 20.04 VM I installed, but I did some overall improvements on consistency while testing on 16.04. Maybe it's gone. ------------- PR: https://git.openjdk.org/jfx/pull/915 From tsayao at openjdk.org Sun Dec 18 20:33:54 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 20:33:54 GMT Subject: RFR: 8292922 - [Linux] No more drag events when new Stage is created in drag handler Message-ID: This PR is based on top of #915 and was previously discussed on #905. The approach is to grab the keyboard focus so the window that originated the drag will keep it. I did some cleanup on grabbing related functions as well. `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor of `gdk_seat*`. But that's only available in later Gtk versions. I checked and newer Gtk will use `gdk_seat*` inside the deprecated `gdk_keyboard_focus()`. ------------- Commit messages: - Merge remote-tracking branch 'origin/8292922_drag_events' into 8292922_drag_events - Progress - Fixes for Ubuntu 16.04 - 8292922 - [Linux] No more drag events when new Stage is created in drag handler - Merge branch 'master' into clean_glass_gtk - Merge branch 'openjdk:master' into master - Remove unused method - Merge remote-tracking branch 'origin/clean_glass_gtk' into clean_glass_gtk - Unity uses Compiz - Fix show a window minimized - ... and 29 more: https://git.openjdk.org/jfx/compare/30147d2f...ddc4c29a Changes: https://git.openjdk.org/jfx/pull/977/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292922 Stats: 855 lines in 6 files changed: 232 ins; 464 del; 159 mod Patch: https://git.openjdk.org/jfx/pull/977.diff Fetch: git fetch https://git.openjdk.org/jfx pull/977/head:pull/977 PR: https://git.openjdk.org/jfx/pull/977 From tsayao at openjdk.org Sun Dec 18 20:50:57 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 20:50:57 GMT Subject: RFR: 8292922 - [Linux] No more drag events when new Stage is created in drag handler [v2] In-Reply-To: References: Message-ID: > This PR was previously discussed on #905. > > The approach is to grab the keyboard focus so the window that originated the drag will keep it. > > I did some cleanup on grabbing related functions as well. > > `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor of `gdk_seat*`. But that's only available in later Gtk versions. I checked and newer Gtk will use `gdk_seat*` inside the deprecated `gdk_keyboard_focus()`. Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8292922 - [Linux] No more drag events when new Stage is created in drag handler ------------- Changes: - all: https://git.openjdk.org/jfx/pull/977/files - new: https://git.openjdk.org/jfx/pull/977/files/ddc4c29a..1fdc328e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=977&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=977&range=00-01 Stats: 756 lines in 6 files changed: 389 ins; 233 del; 134 mod Patch: https://git.openjdk.org/jfx/pull/977.diff Fetch: git fetch https://git.openjdk.org/jfx pull/977/head:pull/977 PR: https://git.openjdk.org/jfx/pull/977 From tsayao at openjdk.org Sun Dec 18 21:02:20 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 21:02:20 GMT Subject: RFR: 8292922 - [Linux] No more drag events when new Stage is created in drag handler [v3] In-Reply-To: References: Message-ID: > This PR was previously discussed on #905. > > The approach is to grab the keyboard focus so the window that originated the drag will keep it. > > I did some cleanup on grabbing related functions as well. > > `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor of `gdk_seat*`. But that's only available in later Gtk versions. I checked and newer Gtk will use `gdk_seat*` inside the deprecated `gdk_keyboard_focus()`. Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8292922 - [Linux] No more drag events when new Stage is created in drag handler ------------- Changes: - all: https://git.openjdk.org/jfx/pull/977/files - new: https://git.openjdk.org/jfx/pull/977/files/1fdc328e..94645978 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=977&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=977&range=01-02 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/977.diff Fetch: git fetch https://git.openjdk.org/jfx pull/977/head:pull/977 PR: https://git.openjdk.org/jfx/pull/977 From mgroth49 at gmail.com Sun Dec 18 21:29:16 2022 From: mgroth49 at gmail.com (Matt Groth) Date: Sun, 18 Dec 2022 16:29:16 -0500 Subject: Un-actionable HIToolbox error output immediately after Mac software update Message-ID: I?m a JavaFX developer using a silicon Mac. Immediately after updating my Mac to Ventura 13.1 (22C65) a few hours ago, I started to have this issue. I have never seen this issue before. Any JavaFX app I run from source produces error output. I can not find a single workaround. The output does not explain the cause. Google searches on the text within the output produce no useful results. I have tried restarting my computer, but the problem persists. Attached is a compressed reproducer project. I can reliable reproduce the error output by running this. If I comment out the line that launches the JavaFX app, the error output is not produced. I execute the code using `gradle run` with Gradle 7.6. My JDK is 18.0.2. I am unsure if this matters, but my Xcode is up to date (14.2). The following is the full console output. The error output is in between ?Hello world? and ?Goodbye world?, and it is red in my console. ======================================================================================================================== /Users/matthewgroth/.gradle/wrapper/dists/gradle-7.6-all/9f832ih6bniajn45pbmqhk2cw/gradle-7.6/bin/gradle run > Configure project : Project : => no module-info.java found > Task :run Hello world 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 3 HIToolbox 0x000000018fc64184 _ZN15MenuBarInstance14EnableAutoShowEv + 56 4 HIToolbox 0x000000018fc07310 SetMenuBarObscured + 372 5 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 6 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 7 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 8 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 9 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 10 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 11 AppKit 0x000000018979c424 _DPSNextEvent + 632 12 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 13 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 14 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 15 ??? 0x0000000109e818ac 0x0 + 4461172908 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 19 ??? 0x0000000109e7dd80 0x0 + 4461157760 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 21 ??? 0x0000000109e7dfc8 0x0 + 4461158344 22 ??? 0x0000000109e78140 0x0 + 4461134144 23 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 24 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 25 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 26 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 27 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 28 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 29 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 30 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 31 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 32 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 33 AppKit 0x000000018978f910 -[NSApplication run] + 252 34 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 35 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 36 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 37 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 38 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 39 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 40 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 41 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 42 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 43 java 0x00000001007ebba8 main + 408 44 dyld 0x0000000186113e50 start + 2544 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 3 HIToolbox 0x000000018fc68380 _ZL19AutoShowHideHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 104 4 HIToolbox 0x000000018fbc84c0 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1092 5 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 6 HIToolbox 0x000000018fbc77d0 SendEventToEventTargetWithOptions + 44 7 HIToolbox 0x000000018fc079cc _ZL29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 472 8 HIToolbox 0x000000018fbc8968 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 2284 9 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 10 HIToolbox 0x000000018fbddbb8 SendEventToEventTarget + 40 11 AppKit 0x000000018979bad8 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2044 12 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 13 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 14 ??? 0x0000000109e818ac 0x0 + 4461172908 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 21 ??? 0x0000000109e78140 0x0 + 4461134144 22 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 23 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 24 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 25 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 26 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 27 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 28 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 29 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 30 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 31 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 32 AppKit 0x000000018978f910 -[NSApplication run] + 252 33 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 34 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 35 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 36 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 37 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 38 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 39 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 40 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 41 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 42 java 0x00000001007ebba8 main + 408 43 dyld 0x0000000186113e50 start + 2544 1 HIToolbox 0x000000018fc645c8 _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 120 2 HIToolbox 0x000000018fc0727c SetMenuBarObscured + 224 3 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 4 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 5 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 6 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 7 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 8 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 9 AppKit 0x000000018979c424 _DPSNextEvent + 632 10 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 11 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 12 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 13 ??? 0x0000000109e818ac 0x0 + 4461172908 14 ??? 0x0000000109e7dd80 0x0 + 4461157760 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 18 ??? 0x0000000109e7dfc8 0x0 + 4461158344 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 20 ??? 0x0000000109e78140 0x0 + 4461134144 21 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 22 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 23 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 24 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 25 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 26 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 27 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 28 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 29 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 30 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 31 AppKit 0x000000018978f910 -[NSApplication run] + 252 32 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 33 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 34 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 35 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 36 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 37 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 38 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 39 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 40 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 41 java 0x00000001007ebba8 main + 408 42 dyld 0x0000000186113e50 start + 2544 Goodbye world BUILD SUCCESSFUL in 5s 5 actionable tasks: 5 executed ======================================================================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: hitoolbox.zip Type: application/zip Size: 2315 bytes Desc: not available URL: -------------- next part -------------- From tsayao at openjdk.org Sun Dec 18 23:32:06 2022 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 18 Dec 2022 23:32:06 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v36] In-Reply-To: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com> Message-ID: > This cleans size and positioning code, reducing special cases, code complexity and size. > > Changes: > > - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event. > - window geometry, min/max size are centralized in `update_window_constraints`; > - Frame extents (the window decoration size used for "total window size"): > - frame extents are received in `process_property_notify`; > - removed quirks in java code; > - When received, call `set_bounds` again to adjust the size (to account decorations later received); > - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it. > - `ensure_window_size` was a quirk - removed; > - `requested_bounds` removed - not used anymore; > - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`; > - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point) > - `restack` split in `to_front()` and `to_back()` to conform to managed code; > - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`; > - Note: `geometry_get_*` and `geometry_set_*` moved location but unchanged. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Restore process_state ------------- Changes: - all: https://git.openjdk.org/jfx/pull/915/files - new: https://git.openjdk.org/jfx/pull/915/files/f4e2f602..211c8248 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=35 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=915&range=34-35 Stats: 58 lines in 1 file changed: 28 ins; 28 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/915.diff Fetch: git fetch https://git.openjdk.org/jfx pull/915/head:pull/915 PR: https://git.openjdk.org/jfx/pull/915 From mgroth49 at gmail.com Mon Dec 19 00:49:34 2022 From: mgroth49 at gmail.com (Matt Groth) Date: Sun, 18 Dec 2022 19:49:34 -0500 Subject: Un-actionable HIToolbox error output immediately after Mac software update In-Reply-To: References: Message-ID: <394233BB-4F76-499E-8690-968C24B02EEB@gmail.com> This is actually more severe than I initially thought. The error output is getting printed constantly during runtime, so much so that it is exceeding the console?s buffer. It seems to be triggered whenever the JavaFX application gains or loses focus. That may not be the only trigger. This issue is present in the latest version of JavaFX from Maven, 20-ea+11. However, as the reproducer I attached in the previous email shows that the issue is also present in 19. > On Dec 18, 2022, at 4:29 PM, Matt Groth wrote: > > I?m a JavaFX developer using a silicon Mac. Immediately after updating my Mac to Ventura 13.1 (22C65) a few hours ago, I started to have this issue. I have never seen this issue before. > > Any JavaFX app I run from source produces error output. I can not find a single workaround. The output does not explain the cause. Google searches on the text within the output produce no useful results. I have tried restarting my computer, but the problem persists. > > Attached is a compressed reproducer project. I can reliable reproduce the error output by running this. If I comment out the line that launches the JavaFX app, the error output is not produced. > > I execute the code using `gradle run` with Gradle 7.6. My JDK is 18.0.2. I am unsure if this matters, but my Xcode is up to date (14.2). > > The following is the full console output. The error output is in between ?Hello world? and ?Goodbye world?, and it is red in my console. > > ======================================================================================================================== > /Users/matthewgroth/.gradle/wrapper/dists/gradle-7.6-all/9f832ih6bniajn45pbmqhk2cw/gradle-7.6/bin/gradle run > >> Configure project : > Project : => no module-info.java found > >> Task :run > Hello world > 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 > 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 > 3 HIToolbox 0x000000018fc64184 _ZN15MenuBarInstance14EnableAutoShowEv + 56 > 4 HIToolbox 0x000000018fc07310 SetMenuBarObscured + 372 > 5 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 > 6 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 > 7 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 > 8 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 > 9 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 > 10 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 > 11 AppKit 0x000000018979c424 _DPSNextEvent + 632 > 12 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 > 13 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 > 14 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 > 15 ??? 0x0000000109e818ac 0x0 + 4461172908 > 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 19 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 21 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 22 ??? 0x0000000109e78140 0x0 + 4461134144 > 23 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 > 24 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 > 25 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 > 26 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 > 27 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 > 28 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 > 29 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 > 30 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 > 31 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 > 32 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 > 33 AppKit 0x000000018978f910 -[NSApplication run] + 252 > 34 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 > 35 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 > 36 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 > 37 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 > 38 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 > 39 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 > 40 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 > 41 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 > 42 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 > 43 java 0x00000001007ebba8 main + 408 > 44 dyld 0x0000000186113e50 start + 2544 > 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 > 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 > 3 HIToolbox 0x000000018fc68380 _ZL19AutoShowHideHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 104 > 4 HIToolbox 0x000000018fbc84c0 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1092 > 5 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 > 6 HIToolbox 0x000000018fbc77d0 SendEventToEventTargetWithOptions + 44 > 7 HIToolbox 0x000000018fc079cc _ZL29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 472 > 8 HIToolbox 0x000000018fbc8968 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 2284 > 9 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 > 10 HIToolbox 0x000000018fbddbb8 SendEventToEventTarget + 40 > 11 AppKit 0x000000018979bad8 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2044 > 12 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 > 13 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 > 14 ??? 0x0000000109e818ac 0x0 + 4461172908 > 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 21 ??? 0x0000000109e78140 0x0 + 4461134144 > 22 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 > 23 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 > 24 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 > 25 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 > 26 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 > 27 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 > 28 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 > 29 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 > 30 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 > 31 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 > 32 AppKit 0x000000018978f910 -[NSApplication run] + 252 > 33 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 > 34 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 > 35 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 > 36 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 > 37 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 > 38 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 > 39 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 > 40 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 > 41 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 > 42 java 0x00000001007ebba8 main + 408 > 43 dyld 0x0000000186113e50 start + 2544 > 1 HIToolbox 0x000000018fc645c8 _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 120 > 2 HIToolbox 0x000000018fc0727c SetMenuBarObscured + 224 > 3 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 > 4 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 > 5 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 > 6 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 > 7 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 > 8 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 > 9 AppKit 0x000000018979c424 _DPSNextEvent + 632 > 10 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 > 11 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 > 12 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 > 13 ??? 0x0000000109e818ac 0x0 + 4461172908 > 14 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 > 18 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 > 20 ??? 0x0000000109e78140 0x0 + 4461134144 > 21 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 > 22 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 > 23 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 > 24 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 > 25 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 > 26 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 > 27 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 > 28 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 > 29 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 > 30 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 > 31 AppKit 0x000000018978f910 -[NSApplication run] + 252 > 32 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 > 33 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 > 34 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 > 35 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 > 36 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 > 37 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 > 38 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 > 39 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 > 40 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 > 41 java 0x00000001007ebba8 main + 408 > 42 dyld 0x0000000186113e50 start + 2544 > Goodbye world > > BUILD SUCCESSFUL in 5s > 5 actionable tasks: 5 executed > ======================================================================================================================== > > > From mgroth49 at gmail.com Mon Dec 19 02:58:18 2022 From: mgroth49 at gmail.com (Matt Groth) Date: Sun, 18 Dec 2022 21:58:18 -0500 Subject: Un-actionable HIToolbox error output immediately after Mac software update In-Reply-To: <394233BB-4F76-499E-8690-968C24B02EEB@gmail.com> References: <394233BB-4F76-499E-8690-968C24B02EEB@gmail.com> Message-ID: I have tracked down a workaround which also I think points us closer to what may be causing this. If I go to my MacOS settings, I have ?Automatically hide and show the menu bar? to ?Always?. If I set this to ?Never?, it completely prevents all of the error output. If I set it back to ?Always? the error output comes right back. Even if I change this Mac OS setting in the middle of a JavaFX runtime, it will have the expected effect. Turning it to ?Always? during runtime will causes the JavaFX app to start have the error output, while turning it to ?Never? during runtime will prevent any further error output from being produced as long as it stays on ?Never?. So unless you are willing to put up with all of the error output, JavaFX is not fully compatible with the MacOS feature of automatically hiding the system menu bar right now. > On Dec 18, 2022, at 7:49 PM, Matt Groth wrote: > > This is actually more severe than I initially thought. > > The error output is getting printed constantly during runtime, so much so that it is exceeding the console?s buffer. > > It seems to be triggered whenever the JavaFX application gains or loses focus. That may not be the only trigger. > > This issue is present in the latest version of JavaFX from Maven, 20-ea+11. However, as the reproducer I attached in the previous email shows that the issue is also present in 19. > > >> On Dec 18, 2022, at 4:29 PM, Matt Groth wrote: >> >> I?m a JavaFX developer using a silicon Mac. Immediately after updating my Mac to Ventura 13.1 (22C65) a few hours ago, I started to have this issue. I have never seen this issue before. >> >> Any JavaFX app I run from source produces error output. I can not find a single workaround. The output does not explain the cause. Google searches on the text within the output produce no useful results. I have tried restarting my computer, but the problem persists. >> >> Attached is a compressed reproducer project. I can reliable reproduce the error output by running this. If I comment out the line that launches the JavaFX app, the error output is not produced. >> >> I execute the code using `gradle run` with Gradle 7.6. My JDK is 18.0.2. I am unsure if this matters, but my Xcode is up to date (14.2). >> >> The following is the full console output. The error output is in between ?Hello world? and ?Goodbye world?, and it is red in my console. >> >> ======================================================================================================================== >> /Users/matthewgroth/.gradle/wrapper/dists/gradle-7.6-all/9f832ih6bniajn45pbmqhk2cw/gradle-7.6/bin/gradle run >> >>> Configure project : >> Project : => no module-info.java found >> >>> Task :run >> Hello world >> 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 >> 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 >> 3 HIToolbox 0x000000018fc64184 _ZN15MenuBarInstance14EnableAutoShowEv + 56 >> 4 HIToolbox 0x000000018fc07310 SetMenuBarObscured + 372 >> 5 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 >> 6 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 >> 7 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 >> 8 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 >> 9 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 >> 10 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 >> 11 AppKit 0x000000018979c424 _DPSNextEvent + 632 >> 12 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 >> 13 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 >> 14 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 >> 15 ??? 0x0000000109e818ac 0x0 + 4461172908 >> 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 19 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 21 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 22 ??? 0x0000000109e78140 0x0 + 4461134144 >> 23 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 >> 24 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 >> 25 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 >> 26 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 >> 27 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 >> 28 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 >> 29 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 >> 30 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 >> 31 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 >> 32 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 >> 33 AppKit 0x000000018978f910 -[NSApplication run] + 252 >> 34 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 >> 35 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 >> 36 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 >> 37 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 >> 38 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 >> 39 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 >> 40 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 >> 41 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 >> 42 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 >> 43 java 0x00000001007ebba8 main + 408 >> 44 dyld 0x0000000186113e50 start + 2544 >> 1 HIToolbox 0x000000018fd8ad4c _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 284 >> 2 HIToolbox 0x000000018fc64230 _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 40 >> 3 HIToolbox 0x000000018fc68380 _ZL19AutoShowHideHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 104 >> 4 HIToolbox 0x000000018fbc84c0 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1092 >> 5 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 >> 6 HIToolbox 0x000000018fbc77d0 SendEventToEventTargetWithOptions + 44 >> 7 HIToolbox 0x000000018fc079cc _ZL29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 472 >> 8 HIToolbox 0x000000018fbc8968 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 2284 >> 9 HIToolbox 0x000000018fbc7940 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 356 >> 10 HIToolbox 0x000000018fbddbb8 SendEventToEventTarget + 40 >> 11 AppKit 0x000000018979bad8 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2044 >> 12 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 >> 13 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 >> 14 ??? 0x0000000109e818ac 0x0 + 4461172908 >> 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 18 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 20 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 21 ??? 0x0000000109e78140 0x0 + 4461134144 >> 22 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 >> 23 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 >> 24 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 >> 25 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 >> 26 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 >> 27 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 >> 28 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 >> 29 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 >> 30 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 >> 31 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 >> 32 AppKit 0x000000018978f910 -[NSApplication run] + 252 >> 33 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 >> 34 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 >> 35 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 >> 36 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 >> 37 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 >> 38 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 >> 39 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 >> 40 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 >> 41 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 >> 42 java 0x00000001007ebba8 main + 408 >> 43 dyld 0x0000000186113e50 start + 2544 >> 1 HIToolbox 0x000000018fc645c8 _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 120 >> 2 HIToolbox 0x000000018fc0727c SetMenuBarObscured + 224 >> 3 HIToolbox 0x000000018fc06ee8 _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh + 172 >> 4 HIToolbox 0x000000018fc00fcc _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 296 >> 5 HIToolbox 0x000000018fbc7cd0 _NotifyEventLoopObservers + 176 >> 6 HIToolbox 0x000000018fc0096c AcquireEventFromQueue + 432 >> 7 HIToolbox 0x000000018fbefc84 ReceiveNextEventCommon + 320 >> 8 HIToolbox 0x000000018fbefb2c _BlockUntilNextEventMatchingListInModeWithFilter + 72 >> 9 AppKit 0x000000018979c424 _DPSNextEvent + 632 >> 10 AppKit 0x000000018979b5b4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728 >> 11 libglass.dylib 0x000000010145bd88 JNI_OnLoad + 9324 >> 12 libglass.dylib 0x000000010145c8bc Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 64 >> 13 ??? 0x0000000109e818ac 0x0 + 4461172908 >> 14 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 15 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 16 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 17 ??? 0x0000000109e7dd80 0x0 + 4461157760 >> 18 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 19 ??? 0x0000000109e7dfc8 0x0 + 4461158344 >> 20 ??? 0x0000000109e78140 0x0 + 4461134144 >> 21 libjvm.dylib 0x0000000101c4cda8 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 908 >> 22 libjvm.dylib 0x0000000101ca687c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 796 >> 23 libjvm.dylib 0x0000000101caaf58 jni_CallVoidMethod + 312 >> 24 libglass.dylib 0x0000000101459d24 JNI_OnLoad + 1032 >> 25 CoreFoundation 0x0000000186511570 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 >> 26 CoreFoundation 0x00000001865af054 ___CFXRegistrationPost_block_invoke + 88 >> 27 CoreFoundation 0x00000001865aef9c _CFXRegistrationPost + 440 >> 28 CoreFoundation 0x00000001864e2b74 _CFXNotificationPost + 708 >> 29 Foundation 0x00000001873d072c -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 >> 30 AppKit 0x000000018978fc24 -[NSApplication finishLaunching] + 248 >> 31 AppKit 0x000000018978f910 -[NSApplication run] + 252 >> 32 libglass.dylib 0x000000010145bb70 JNI_OnLoad + 8788 >> 33 Foundation 0x0000000187440b30 __NSThreadPerformPerform + 264 >> 34 CoreFoundation 0x000000018651ca18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 >> 35 CoreFoundation 0x000000018651c9ac __CFRunLoopDoSource0 + 176 >> 36 CoreFoundation 0x000000018651c71c __CFRunLoopDoSources0 + 244 >> 37 CoreFoundation 0x000000018651b320 __CFRunLoopRun + 836 >> 38 CoreFoundation 0x000000018651a888 CFRunLoopRunSpecific + 612 >> 39 libjli.dylib 0x00000001008a2fec CreateExecutionEnvironment + 400 >> 40 libjli.dylib 0x000000010089f1fc JLI_Launch + 1184 >> 41 java 0x00000001007ebba8 main + 408 >> 42 dyld 0x0000000186113e50 start + 2544 >> Goodbye world >> >> BUILD SUCCESSFUL in 5s >> 5 actionable tasks: 5 executed >> ======================================================================================================================== >> >> >> > From kpk at openjdk.org Mon Dec 19 06:53:54 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Dec 2022 06:53:54 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v2] In-Reply-To: <_4kJLsgbEk7YyWxSkrlm5Xtkco3awSCFzQ1q3bjRNBc=.f9f51bb7-f69b-4934-947c-7de02027c5e3@github.com> References: <_4kJLsgbEk7YyWxSkrlm5Xtkco3awSCFzQ1q3bjRNBc=.f9f51bb7-f69b-4934-947c-7de02027c5e3@github.com> Message-ID: On Sat, 17 Dec 2022 19:55:11 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ListenerHelper for sceneProperty > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/SpinnerSkin.java line 258: > >> 256: behavior.stopSpinning(); >> 257: }); >> 258: > > minor: could we get rid of this extra newline? Yes, this can be removed. Since an empty line was there before I had kept it as it is. ------------- PR: https://git.openjdk.org/jfx/pull/976 From kpk at openjdk.org Mon Dec 19 07:20:11 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Dec 2022 07:20:11 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v3] In-Reply-To: References: Message-ID: > Spinner was not stopping because it was getting removed from scene before the mouse release event handler was getting invoked. > > Added listener for `sceneProperty` so that when Spinner is removed from the scene, `stopSpinning` method shall be called. > > Added unit test to validate the fix Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/976/files - new: https://git.openjdk.org/jfx/pull/976/files/6b59cbe8..deaf07ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=976&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=976&range=01-02 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/976.diff Fetch: git fetch https://git.openjdk.org/jfx pull/976/head:pull/976 PR: https://git.openjdk.org/jfx/pull/976 From kpk at openjdk.org Mon Dec 19 07:20:12 2022 From: kpk at openjdk.org (Karthik P K) Date: Mon, 19 Dec 2022 07:20:12 GMT Subject: RFR: 8252863: Spinner keeps spinning if removed from Scene [v2] In-Reply-To: <_4kJLsgbEk7YyWxSkrlm5Xtkco3awSCFzQ1q3bjRNBc=.f9f51bb7-f69b-4934-947c-7de02027c5e3@github.com> References: <_4kJLsgbEk7YyWxSkrlm5Xtkco3awSCFzQ1q3bjRNBc=.f9f51bb7-f69b-4934-947c-7de02027c5e3@github.com> Message-ID: On Sat, 17 Dec 2022 19:56:59 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ListenerHelper for sceneProperty > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SpinnerSkinTest.java line 178: > >> 176: assertEquals(Status.RUNNING, SpinnerBehaviorShim.getTimeline(behavior).getStatus()); >> 177: root.getChildren().clear(); >> 178: assertEquals(Status.STOPPED, SpinnerBehaviorShim.getTimeline(behavior).getStatus()); > > just curious: if we add the spinner back to the scene, should it spin again? do we want to add this condition to this test? It should not spin again. Added the same condition in the test. Please check ------------- PR: https://git.openjdk.org/jfx/pull/976 From arapte at openjdk.org Mon Dec 19 10:52:58 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon,