From arapte at openjdk.java.net Mon Jan 4 10:11:00 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 4 Jan 2021 10:11:00 GMT Subject: RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/354 From arapte at openjdk.java.net Mon Jan 4 17:44:02 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 4 Jan 2021 17:44:02 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 16:49:56 GMT, Kevin Rushforth wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed comments from review > > Looks good. Apologies for delay on this review, Change looks good but I did observe an issue with layout of TabPane header area when the header is set to be shown on Left or Right side. The last tab-header's border seems to be clipped. Please check the code below. This is a very specific scenario, If tab's label is changed from "Tab" to "tab" then the issue does not occur. I did not observe any other such scenarios yet. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.TabPane; import javafx.scene.control.Tab; import javafx.stage.Stage; import javafx.geometry.Side; public class TabPaneExample extends Application { public static void main(String[] args) { launch(args); } public void start(Stage primaryStage) { Tab tab0 = new Tab("Tab 0"); Tab tab1 = new Tab("Tab 1"); Tab tab2 = new Tab("Tab 2"); TabPane tabPane = new TabPane(); tabPane.getTabs().addAll(tab0, tab1, tab2); tabPane.setSide(Side.LEFT); Scene scene = new Scene(tabPane); primaryStage.setScene(scene); primaryStage.show(); } } ![with fix](https://user-images.githubusercontent.com/11330676/103559181-bd8ef880-4edb-11eb-8b87-cc6b0045b366.png) | ![without fix](https://user-images.githubusercontent.com/11330676/103559271-deefe480-4edb-11eb-99eb-fbc354d070fe.png) Output with this fix. | Output without this fix. Edit: Also, please note the difference of space between letter `a` and `b` in Tab's label. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Mon Jan 4 17:44:02 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 4 Jan 2021 17:44:02 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:04:41 GMT, Ambarish Rapte wrote: > > > Apologies for delay on this review, Change looks good but I did observe an issue with layout of TabPane header area when the header is set to be shown on Left or Right side. The last tab-header's border seems to be clipped. > Please check the code below. This is a very specific scenario, If tab's label is changed from "Tab" to "tab" then the issue does not occur. I did not observe any other such scenarios yet. > > ``` > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.TabPane; > import javafx.scene.control.Tab; > import javafx.stage.Stage; > import javafx.geometry.Side; > > public class TabPaneExample extends Application { > public static void main(String[] args) { > launch(args); > } > > public void start(Stage primaryStage) { > Tab tab0 = new Tab("Tab 0"); > Tab tab1 = new Tab("Tab 1"); > Tab tab2 = new Tab("Tab 2"); > TabPane tabPane = new TabPane(); > tabPane.getTabs().addAll(tab0, tab1, tab2); > tabPane.setSide(Side.LEFT); > > Scene scene = new Scene(tabPane); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > ``` > > ![with fix](https://user-images.githubusercontent.com/11330676/103559181-bd8ef880-4edb-11eb-8b87-cc6b0045b366.png) | ![without fix](https://user-images.githubusercontent.com/11330676/103559271-deefe480-4edb-11eb-99eb-fbc354d070fe.png) > Output with this fix. | Output without this fix. > > Edit: Also, please note the difference of space between letter `a` and `b` in Tab's label. At which screen scale did you observe this? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Tue Jan 5 01:17:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Jan 2021 01:17:56 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:04:41 GMT, Ambarish Rapte wrote: >> Looks good. > > Apologies for delay on this review, Change looks good but I did observe an issue with layout of TabPane header area when the header is set to be shown on Left or Right side. The last tab-header's border seems to be clipped. > Please check the code below. This is a very specific scenario, If tab's label is changed from "Tab" to "tab" then the issue does not occur. I did not observe any other such scenarios yet. > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.TabPane; > import javafx.scene.control.Tab; > import javafx.stage.Stage; > import javafx.geometry.Side; > > public class TabPaneExample extends Application { > public static void main(String[] args) { > launch(args); > } > > public void start(Stage primaryStage) { > Tab tab0 = new Tab("Tab 0"); > Tab tab1 = new Tab("Tab 1"); > Tab tab2 = new Tab("Tab 2"); > TabPane tabPane = new TabPane(); > tabPane.getTabs().addAll(tab0, tab1, tab2); > tabPane.setSide(Side.LEFT); > > Scene scene = new Scene(tabPane); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > ![with fix](https://user-images.githubusercontent.com/11330676/103559181-bd8ef880-4edb-11eb-8b87-cc6b0045b366.png) | ![without fix](https://user-images.githubusercontent.com/11330676/103559271-deefe480-4edb-11eb-99eb-fbc354d070fe.png) > Output with this fix. | Output without this fix. > > Edit: Also, please note the difference of space between letter `a` and `b` in Tab's label. @arapte I couldn't reproduce the problem you are seeing with the border, but I do see the text spacing issue. Did you merge in the latest changes from master into your local branch when you ran your tests? This is the best way to ensure you are running what will eventually be integrated (especially when the source branch is fairly out of date, which I see that it is in this case). Update: If I run your test program using a build directly from the target branch, I see what you are seeing with the clipped tab pane border. That is likely an unrelated bug that has since been fixed. The text spacing does seem to be changed as a result of this fix. It will need a closer look to know whether this fix has caused the problem, or exposed a bug elsewhere. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Tue Jan 5 06:34:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 5 Jan 2021 06:34:56 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: <1BmuzElMWUB1_tB-FHAUV8b_vIHzspkrmdnD11cbf5c=.6fa3d0e9-a9e8-471c-b430-a4afeac42b21@github.com> On Mon, 4 Jan 2021 17:23:48 GMT, Frederic Thevenet wrote: > At which screen scale did you observe this? Both border clip and font spacing issues are observed only at 125% scale. > Update: If I run your test program using a build directly from the target branch, I see what you are seeing with the clipped tab pane border. That is likely an unrelated bug that has since been fixed. I also see same behavior. Border clip issue does not occur with latest code but the difference in font spacing is observed(only at 125%) ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Tue Jan 5 08:21:11 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 5 Jan 2021 08:21:11 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: <1BmuzElMWUB1_tB-FHAUV8b_vIHzspkrmdnD11cbf5c=.6fa3d0e9-a9e8-471c-b430-a4afeac42b21@github.com> References: <1BmuzElMWUB1_tB-FHAUV8b_vIHzspkrmdnD11cbf5c=.6fa3d0e9-a9e8-471c-b430-a4afeac42b21@github.com> Message-ID: On Tue, 5 Jan 2021 06:32:25 GMT, Ambarish Rapte wrote: >>> >>> >>> Apologies for delay on this review, Change looks good but I did observe an issue with layout of TabPane header area when the header is set to be shown on Left or Right side. The last tab-header's border seems to be clipped. >>> Please check the code below. This is a very specific scenario, If tab's label is changed from "Tab" to "tab" then the issue does not occur. I did not observe any other such scenarios yet. >>> >>> ``` >>> import javafx.application.Application; >>> import javafx.scene.Scene; >>> import javafx.scene.control.TabPane; >>> import javafx.scene.control.Tab; >>> import javafx.stage.Stage; >>> import javafx.geometry.Side; >>> >>> public class TabPaneExample extends Application { >>> public static void main(String[] args) { >>> launch(args); >>> } >>> >>> public void start(Stage primaryStage) { >>> Tab tab0 = new Tab("Tab 0"); >>> Tab tab1 = new Tab("Tab 1"); >>> Tab tab2 = new Tab("Tab 2"); >>> TabPane tabPane = new TabPane(); >>> tabPane.getTabs().addAll(tab0, tab1, tab2); >>> tabPane.setSide(Side.LEFT); >>> >>> Scene scene = new Scene(tabPane); >>> primaryStage.setScene(scene); >>> primaryStage.show(); >>> } >>> } >>> ``` >>> >>> ![with fix](https://user-images.githubusercontent.com/11330676/103559181-bd8ef880-4edb-11eb-8b87-cc6b0045b366.png) | ![without fix](https://user-images.githubusercontent.com/11330676/103559271-deefe480-4edb-11eb-99eb-fbc354d070fe.png) >>> Output with this fix. | Output without this fix. >>> >>> Edit: Also, please note the difference of space between letter `a` and `b` in Tab's label. >> >> At which screen scale did you observe this? > >> At which screen scale did you observe this? > > Both border clip and font spacing issues are observed only at 125% scale. > > >> Update: If I run your test program using a build directly from the target branch, I see what you are seeing with the clipped tab pane border. That is likely an unrelated bug that has since been fixed. > > I also see same behavior. Border clip issue does not occur with latest code but the difference in font spacing is observed(only at 125%) I'm suspecting that the this fix might be revealing a issue related to [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). Keeping in mind that the revision on which this fix is based does *not* include the fix for JDK-8199592, a way to confirm that would be to rebase that fix on top of the latest rev and see if the test program still exhibits the same behaviour. I'll try to do that later on today. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From clementlevallois at protonmail.com Tue Jan 5 10:37:08 2021 From: clementlevallois at protonmail.com (Clement Levallois) Date: Tue, 05 Jan 2021 10:37:08 +0000 Subject: Enhancement: native JavaFX api to interact with the icon / app / system tray Message-ID: Dear all, This is to suggest an enhancement to javafx: a native way to interact with the icon / app / system tray See this pic for an illustration of the icon tray, if unclear: There exist java awt classes to access the System Tray, but this obliges to add these classes to the build, which can be problematic? Example of these awt classes in the context of a JavaFX app: https://stackoverflow.com/questions/12571329/javafx-app-in-system-tray Desktop apps get more traction if they can be minimized and left to run in the background then accessed later via the icon tray, rather than closed and restarted. An API for the icon tray would help manage this part of the life cycle of an application. Doing some further research for this first post on this mailing list, I realize there is already a request for enhancement opened since 2014: https://bugs.openjdk.java.net/browse/JDK-8092115 CL -- Cl?ment Levallois Sent with [ProtonMail](https://protonmail.com) Secure Email. From kcr at openjdk.java.net Tue Jan 5 13:12:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Jan 2021 13:12:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: <1BmuzElMWUB1_tB-FHAUV8b_vIHzspkrmdnD11cbf5c=.6fa3d0e9-a9e8-471c-b430-a4afeac42b21@github.com> Message-ID: On Tue, 5 Jan 2021 07:27:47 GMT, Frederic Thevenet wrote: >>> At which screen scale did you observe this? >> >> Both border clip and font spacing issues are observed only at 125% scale. >> >> >>> Update: If I run your test program using a build directly from the target branch, I see what you are seeing with the clipped tab pane border. That is likely an unrelated bug that has since been fixed. >> >> I also see same behavior. Border clip issue does not occur with latest code but the difference in font spacing is observed(only at 125%) > > I'm suspecting that the this fix might be revealing a issue related to [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). > Keeping in mind that the revision on which this fix is based does *not* include the fix for JDK-8199592, a way to confirm that would be to rebase that fix on top of the latest rev and see if the test program still exhibits the same behaviour. > I'll try to do that later on today. @fthevenet The truncated line is very likely related to the fix for [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). I always merge in the latest master when doing my testing, which is why I initially didn't see that particular problem. The text spacing is a different problem, since the altered behavior after applying your fix happens with or without the fix for JDK-8199592. It seems likely that it is a separate bug exposed by the fix for this bug rather than caused by it. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fastegal at openjdk.java.net Tue Jan 5 13:31:00 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 5 Jan 2021 13:31:00 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: <5BmGisJBjx3yLkK3b5EjWvLwdkpG7xddwGaIW_Wrjo8=.64fe970c-7448-4d34-8bd7-455fc68e63c0@github.com> Message-ID: On Tue, 15 Dec 2020 14:57:16 GMT, Jeanette Winzenburg wrote: >>> >>> >>> quick question: is this still in the lane for fx16? >> >> Yes, I will update PR later this week. > >> >> >> > quick question: is this still in the lane for fx16? >> >> Yes, I will update PR later this week. > > cool, looking forward to it :) I'm still in holiday mood - and hope you are all well :) - will review later today, have to update my notes to the latest changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From nlisker at gmail.com Tue Jan 5 13:42:00 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 5 Jan 2021 15:42:00 +0200 Subject: Enhancement: native JavaFX api to interact with the icon / app / system tray In-Reply-To: References: Message-ID: Hi, System tray support is one of the most recurring requests. The known workaround is for the application writer to use the AWT system tray support. It is not possible for core JavaFX to rely on it. If you would like to contribute, I'm sure the request will be approved. - Nir On Tue, Jan 5, 2021 at 12:44 PM Clement Levallois < clementlevallois at protonmail.com> wrote: > Dear all, > > This is to suggest an enhancement to javafx: a native way to interact with > the icon / app / system tray > > See this pic for an illustration of the icon tray, if unclear: > > There exist java awt classes to access the System Tray, but this obliges > to add these classes to the build, which can be problematic? > Example of these awt classes in the context of a JavaFX app: > https://stackoverflow.com/questions/12571329/javafx-app-in-system-tray > > Desktop apps get more traction if they can be minimized and left to run in > the background then accessed later via the icon tray, rather than closed > and restarted. An API for the icon tray would help manage this part of the > life cycle of an application. > > Doing some further research for this first post on this mailing list, I > realize there is already a request for enhancement opened since 2014: > https://bugs.openjdk.java.net/browse/JDK-8092115 > > CL > > -- > Cl?ment Levallois > Sent with [ProtonMail](https://protonmail.com) Secure Email. From fastegal at openjdk.java.net Tue Jan 5 16:22:05 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 5 Jan 2021 16:22:05 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> Message-ID: <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> On Mon, 21 Dec 2020 11:54:06 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. >> The fix converts listeners to WeakListeners and also removes them on dispose. >> >> There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. >> >> `SkinMemoryLeakTest` already had a test which only needed to be enabled. >> Test fails before and passes after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review update Fix looks good, verified tests failing (except one, commented) before and passing after the fix. Left a couple of comments inline. Plus there's an @Ignore related to the issue in TabPaneTest (`testNPEOnSwitchSkinAndChangeSelection`) that should be removed. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1239: > 1237: } > 1238: controlButtons.removeListeners(); > 1239: } would suggest to rename the method to dispose - even though this here indeed does nothing but removing listeners (future changes might need to do additional cleanup). That would be a clear indication of its responsibility, just the same name as the cleanup method you added for TabContentRegion. If we decide to go for the rename, it should be done for all occurences of removeListeners in the other internal panes. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1577: > 1575: listener.dispose(); > 1576: inner.getChildren().clear(); > 1577: getChildren().clear(); I'm aware this is internal and old api but .. could we consider cleaning it up a bit? - its task is to cleanup itself, doing whatever it deems is needed (here: removing listeners and children), so removeListeners is a misnomer as it describes only part of it. A (well-established) name for the task would be dispose - passing in the tab is .. strange, as can be seen in its usage in TabHeaderArea.dispose: `header.removeListeners(header.getTab())` Actually, it would be an error to call the method with a `tab != header.getTab()` modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1735: > 1733: removeListeners(); > 1734: } > 1735: Wondering why the removal of children down the hierarchy? Shouldn't that be unnecessary as long as the direct children of the skin/control are and all listeners of the grandChildren to the skin are removed? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1846: > 1844: getSkinnable().sideProperty().removeListener(weakSidePropListener); > 1845: getSkinnable().getTabs().removeListener(weakTabsListenerForPopup); > 1846: } yet another candidate for rename to dispose (see above) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 275: > 273: assertEquals(3, tabPane.getChildrenUnmodifiable().size()); > 274: } > 275: hmm .. looks a bit unusual (could be me, though :) - why showControl? just install/replace the skin should be enough? - the outcome of testing an illegal state (after instantiating the skin and before really setting it as the control's skin at which time we have a skin : control relation of 2:1) is unspecified. F.i. there are skins that replace all children in the constructor (which may or may not be a good idea) that would fail a test similar to this. How about TabPane tabPane .. installDefaultSkin(tabPane); int children = tabPane.getxxChildren().size(); replaceSkin(tabPane); assertEquals(children, tabPane.getxxChildren().size()); If we decide to go without showing, the other tests should be changed as well :) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 289: > 287: assertNull(tabPane.getSkin()); > 288: assertEquals(0, tabPane.getChildrenUnmodifiable().size()); > 289: } Same as above: what's the reason to actually show? And just curious: why is this passing already before the fix? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 302: > 300: @Test > 301: public void testNPEWhenRemTabAfterSkinIsReplaced() { > 302: TabPane tabPane = new TabPane(); Personally I don't like abbreviation in method names, not even test methods. `testNPEWhenRemoveTabAfterSkinIsReplaced` isn't that much longer :) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 311: > 309: @Test > 310: public void testAddRemTabsAfterSkinIsReplaced() { > 311: TabPane tabPane = new TabPane(); see above ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/318 From kcr at openjdk.java.net Wed Jan 6 00:14:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Jan 2021 00:14:06 GMT Subject: RFR: 8259277: Change JavaFX release version to 17 Message-ID: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> Bump the version number of JavaFX to 17. I will integrate this immediately after forking the `jfx16` stabilization branch. ------------- Commit messages: - 8259277: Change JavaFX release version to 17 Changes: https://git.openjdk.java.net/jfx/pull/371/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=371&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259277 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/371.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/371/head:pull/371 PR: https://git.openjdk.java.net/jfx/pull/371 From arapte at openjdk.java.net Wed Jan 6 06:38:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 06:38:56 GMT Subject: RFR: 8259277: Change JavaFX release version to 17 In-Reply-To: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> References: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> Message-ID: On Wed, 6 Jan 2021 00:09:52 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 17. I will integrate this immediately after forking the `jfx16` stabilization branch. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/371 From pbansal at openjdk.java.net Wed Jan 6 06:43:57 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 6 Jan 2021 06:43:57 GMT Subject: RFR: 8259277: Change JavaFX release version to 17 In-Reply-To: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> References: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> Message-ID: On Wed, 6 Jan 2021 00:09:52 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 17. I will integrate this immediately after forking the `jfx16` stabilization branch. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/371 From jvos at openjdk.java.net Wed Jan 6 07:14:55 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 6 Jan 2021 07:14:55 GMT Subject: RFR: 8259277: Change JavaFX release version to 17 In-Reply-To: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> References: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> Message-ID: On Wed, 6 Jan 2021 00:09:52 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 17. I will integrate this immediately after forking the `jfx16` stabilization branch. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/371 From arapte at openjdk.java.net Wed Jan 6 11:16:07 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 11:16:07 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v4] In-Reply-To: References: Message-ID: > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. > > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: - Space corrections in tests - Review update: cleanup and corrections ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/318/files - new: https://git.openjdk.java.net/jfx/pull/318/files/a3b57950..93e1645f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=02-03 Stats: 63 lines in 3 files changed: 0 ins; 15 del; 48 mod Patch: https://git.openjdk.java.net/jfx/pull/318.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/318/head:pull/318 PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Wed Jan 6 11:21:01 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 11:21:01 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> Message-ID: On Tue, 5 Jan 2021 15:19:21 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Review update > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1239: > >> 1237: } >> 1238: controlButtons.removeListeners(); >> 1239: } > > would suggest to rename the method to dispose - even though this here indeed does nothing but removing listeners (future changes might need to do additional cleanup). That would be a clear indication of its responsibility, just the same name as the cleanup method you added for TabContentRegion. If we decide to go for the rename, it should be done for all occurences of removeListeners in the other internal panes. The change sounds good to me. Please check the updated commits. All the `removeListeners()` methods are now renamed as `dispose()`. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Wed Jan 6 11:29:00 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 11:29:00 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> Message-ID: On Tue, 5 Jan 2021 15:42:40 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Review update > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1577: > >> 1575: listener.dispose(); >> 1576: inner.getChildren().clear(); >> 1577: getChildren().clear(); > > I'm aware this is internal and old api but .. could we consider cleaning it up a bit? > > - its task is to cleanup itself, doing whatever it deems is needed (here: removing listeners and children), so removeListeners is a misnomer as it describes only part of it. A (well-established) name for the task would be dispose > - passing in the tab is .. strange, as can be seen in its usage in TabHeaderArea.dispose: `header.removeListeners(header.getTab())` Actually, it would be an error to call the method with a `tab != header.getTab()` +1, passing `tab` is unnecessary here. I have removed the parameter and the method is now renamed as `dispose()`. Also it is not required to clear the children of `TabHeaderSkin`, so have removed `inner.getChildren().clear();` and `getChildren().clear();` calls from this method. > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1735: > >> 1733: removeListeners(); >> 1734: } >> 1735: > > Wondering why the removal of children down the hierarchy? Shouldn't that be unnecessary as long as the direct children of the skin/control are and all listeners of the grandChildren to the skin are removed? Corrected, removal of children of `TabContentRegion` is not needed. (same change is also done for `TabHeaderSkin` as mentioned in previous comment) > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1846: > >> 1844: getSkinnable().sideProperty().removeListener(weakSidePropListener); >> 1845: getSkinnable().getTabs().removeListener(weakTabsListenerForPopup); >> 1846: } > > yet another candidate for rename to dispose (see above) Corrected. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Wed Jan 6 12:16:01 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 12:16:01 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> Message-ID: On Tue, 5 Jan 2021 16:03:42 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Review update > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 275: > >> 273: assertEquals(3, tabPane.getChildrenUnmodifiable().size()); >> 274: } >> 275: > > hmm .. looks a bit unusual (could be me, though :) > > - why showControl? just install/replace the skin should be enough? > - the outcome of testing an illegal state (after instantiating the skin and before really setting it as the control's skin at which time we have a skin : control relation of 2:1) is unspecified. F.i. there are skins that replace all children in the constructor (which may or may not be a good idea) that would fail a test similar to this. > > How about > > TabPane tabPane .. > installDefaultSkin(tabPane); > int children = tabPane.getxxChildren().size(); > replaceSkin(tabPane); > assertEquals(children, tabPane.getxxChildren().size()); > > If we decide to go without showing, the other tests should be changed as well :) 1. `showControl` is not required. It is now changed to `installDefaultSkin` in all tests. 2. Test did verify an illegal state, Intention was to keep a note of that illegal state. I have changed it as you suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Wed Jan 6 12:26:59 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Jan 2021 12:26:59 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> Message-ID: On Tue, 5 Jan 2021 16:19:47 GMT, Jeanette Winzenburg wrote: > Fix looks good, verified tests failing (except one, commented) before and passing after the fix. Thanks for the review. I have updated the PR according to all comments. Please take a look. :) > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 289: > >> 287: assertNull(tabPane.getSkin()); >> 288: assertEquals(0, tabPane.getChildrenUnmodifiable().size()); >> 289: } > > Same as above: what's the reason to actually show? > > And just curious: why is this passing already before the fix? Corrected to use installDefaultSkin(). It works without this fix is because the children are cleared([here](https://github.com/openjdk/jfx/blob/e74f679fda6f03ee8449836147815fdaafb5d626/modules/javafx.controls/src/main/java/javafx/scene/control/Control.java#L300)) in Control class when the skin is set to null. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 302: > >> 300: @Test >> 301: public void testNPEWhenRemTabAfterSkinIsReplaced() { >> 302: TabPane tabPane = new TabPane(); > > Personally I don't like abbreviation in method names, not even test methods. `testNPEWhenRemoveTabAfterSkinIsReplaced` isn't that much longer :) Corrected. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 311: > >> 309: @Test >> 310: public void testAddRemTabsAfterSkinIsReplaced() { >> 311: TabPane tabPane = new TabPane(); > > see above Corrected ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From kevin.rushforth at oracle.com Wed Jan 6 13:06:49 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 6 Jan 2021 05:06:49 -0800 Subject: FINAL REMINDER: JavaFX 16 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 16] In-Reply-To: References: <497c89d3-2e83-2bf5-75a4-43691c51e114@oracle.com> Message-ID: As a reminder, RDP1 starts tomorrow. I will fork the 'jfx16' branch at 16:00 UTC. -- Kevin On 12/18/2020 9:13 AM, Kevin Rushforth wrote: > As a reminder, RDP1 for JavaFX 16 starts on January 7, 2021 at 16:00 > UTC (08:00 Pacific time). Given the upcoming holidays, that's a little > over 1 working week from now. > > During rampdown of JavaFX 16, the "master" branch of the jfx repo will > be open for JavaFX 17 fixes. > > New features currently targeted to JavaFX 16 should be retargeted to > JavaFX 17. > > We will follow the same process as previous releases for getting fixes > into JavaFX 16 during rampdown. I'll send a message with detailed > information later, but candidates for fixing during RDP1 are P1-P3 > bugs (as long as they are not risky) and test or doc bugs of any > priority. Some small enhancements might be considered during RDP1, but > they require explicit approval; the bar will be high for such requests. > > -- Kevin > > > On 10/9/2020 6:21 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 16. >> >> RDP1: Jan 7, 2021 (aka ?feature freeze?) >> RDP2: Jan 28, 2021 >> Freeze: Feb 18, 2021 >> GA: March 9, 2021 >> >> We plan to fork a jfx16 stabilization branch at RDP1. The GA date is >> expected to be one week ahead of JDK 16, matching what we did for 15. >> >> As was done for the previous release, the start of RDP1, the start of >> RDP2, and the code freeze will be 16:00 UTC on the respective dates. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From fastegal at openjdk.java.net Wed Jan 6 14:28:22 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 6 Jan 2021 14:28:22 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v4] In-Reply-To: References: Message-ID: <2-nyMPwvIoAXev-Wahf-D6IDS5NiSJblHUMUbVts38I=.0f8da367-586f-44d1-a5d7-0f46fe1cc9c5@github.com> On Wed, 6 Jan 2021 11:16:07 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. >> The fix converts listeners to WeakListeners and also removes them on dispose. >> >> There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. >> >> `SkinMemoryLeakTest` already had a test which only needed to be enabled. >> Test fails before and passes after this change. > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - Space corrections in tests > - Review update: cleanup and corrections looks fine now :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/318 From fastegal at openjdk.java.net Wed Jan 6 14:28:27 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 6 Jan 2021 14:28:27 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: References: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> <-743PBYcAWIj6_PfMvsQhzfAtVjxHZKg0rZc1Zb221A=.68627f20-42d8-42d3-9408-aa745341fb04@github.com> Message-ID: On Wed, 6 Jan 2021 12:22:17 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 289: >> >>> 287: assertNull(tabPane.getSkin()); >>> 288: assertEquals(0, tabPane.getChildrenUnmodifiable().size()); >>> 289: } >> >> Same as above: what's the reason to actually show? >> >> And just curious: why is this passing already before the fix? > > Corrected to use installDefaultSkin(). > It works without this fix is because the children are cleared([here](https://github.com/openjdk/jfx/blob/e74f679fda6f03ee8449836147815fdaafb5d626/modules/javafx.controls/src/main/java/javafx/scene/control/Control.java#L300)) in Control class when the skin is set to null. thanks for the info :) >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 1577: >> >>> 1575: listener.dispose(); >>> 1576: inner.getChildren().clear(); >>> 1577: getChildren().clear(); >> >> I'm aware this is internal and old api but .. could we consider cleaning it up a bit? >> >> - its task is to cleanup itself, doing whatever it deems is needed (here: removing listeners and children), so removeListeners is a misnomer as it describes only part of it. A (well-established) name for the task would be dispose >> - passing in the tab is .. strange, as can be seen in its usage in TabHeaderArea.dispose: `header.removeListeners(header.getTab())` Actually, it would be an error to call the method with a `tab != header.getTab()` > > +1, passing `tab` is unnecessary here. I have removed the parameter and the method is now renamed as `dispose()`. > Also it is not required to clear the children of `TabHeaderSkin`, so have removed > `inner.getChildren().clear();` and `getChildren().clear();` calls from this method. good catch :) ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From jpereda at openjdk.java.net Wed Jan 6 16:24:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 6 Jan 2021 16:24:08 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop Message-ID: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: - DropTargetListener, on dragEnter - DragGestureListener, on dragGestureRecognized or - MouseHandler, processing a right mouse click (these two are mutually exclusive). This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. ------------- Commit messages: - Only instantiate dndGesture if previous drag gestures have finished Changes: https://git.openjdk.java.net/jfx/pull/372/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8165749 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/372.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/372/head:pull/372 PR: https://git.openjdk.java.net/jfx/pull/372 From kcr at openjdk.java.net Wed Jan 6 17:07:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Jan 2021 17:07:59 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop In-Reply-To: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Wed, 6 Jan 2021 16:20:47 GMT, Jose Pereda wrote: > As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: > > - DropTargetListener, on dragEnter > - DragGestureListener, on dragGestureRecognized or > - MouseHandler, processing a right mouse click (these two are mutually exclusive). > > This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. > > The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3788: > 3786: //old gesture ended and new one started > 3787: gestureStarted = true; > 3788: if (!PLATFORM_DRAG_GESTURE_INITIATION && Scene.this.dndGesture == null) { This will prevent the creation of the new `DndGesture`, but we will still clear the PDR targets. Have you confirmed that this is the desired behavior? It seems reasonable, since we also clear it on a mouse move, but wanted to get your take on it. ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From jpereda at openjdk.java.net Wed Jan 6 17:42:55 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 6 Jan 2021 17:42:55 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop In-Reply-To: References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Wed, 6 Jan 2021 17:05:09 GMT, Kevin Rushforth wrote: >> As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: >> >> - DropTargetListener, on dragEnter >> - DragGestureListener, on dragGestureRecognized or >> - MouseHandler, processing a right mouse click (these two are mutually exclusive). >> >> This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. >> >> The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3788: > >> 3786: //old gesture ended and new one started >> 3787: gestureStarted = true; >> 3788: if (!PLATFORM_DRAG_GESTURE_INITIATION && Scene.this.dndGesture == null) { > > This will prevent the creation of the new `DndGesture`, but we will still clear the PDR targets. Have you confirmed that this is the desired behavior? It seems reasonable, since we also clear it on a mouse move, but wanted to get your take on it. This is really an edge case. There can be two gestures at once, an existing one (i.e from TouchPad), with its full drag information, that hasn't finished yet, and a new mouse one. Having a single `dndGesture` object for both events seems wrong. But having a list/array of events for such scenario seems overkill. Somehow some information from one or the other event might get lost or mixed up. The PDR targets are not required for the initial touch event, and we prevent the RTE, so I'd say this is a reasonable non-intrusive fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From kcr at openjdk.java.net Wed Jan 6 18:40:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Jan 2021 18:40:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: <1BmuzElMWUB1_tB-FHAUV8b_vIHzspkrmdnD11cbf5c=.6fa3d0e9-a9e8-471c-b430-a4afeac42b21@github.com> Message-ID: On Tue, 5 Jan 2021 13:10:33 GMT, Kevin Rushforth wrote: >> I'm suspecting that this fix might be revealing an issue related to [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). >> Keeping in mind that the revision on which this fix is based does *not* include the fix for JDK-8199592, a way to confirm that would be to rebase that fix on top of the latest rev and see if the test program still exhibits the same behaviour. >> I'll try to do that later on today. > > @fthevenet The truncated line is very likely related to the fix for [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). I always merge in the latest master when doing my testing, which is why I initially didn't see that particular problem. > > The text spacing is a different problem, since the altered behavior after applying your fix happens with or without the fix for JDK-8199592. It seems likely that it is a separate bug exposed by the fix for this bug rather than caused by it. I did some additional testing this morning, and there is definitely an existing problem with positioning labels and text nodes, which is more noticeable when drawing vertical text. The values I see for layoutX and layoutY of the text node (or label) are not correct either before or after this fix. So with this fix, they are just wrong in a slightly different way. So I don't think this should block the integration of this PR. Rather, this is another follow-up bug that we should file. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Jan 6 19:19:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Jan 2021 19:19:57 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 11:16:07 GMT, Ambarish Rapte wrote: >> `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. >> The fix converts listeners to WeakListeners and also removes them on dispose. >> >> There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. >> >> `SkinMemoryLeakTest` already had a test which only needed to be enabled. >> Test fails before and passes after this change. > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - Space corrections in tests > - Review update: cleanup and corrections Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/318 From kcr at openjdk.java.net Thu Jan 7 00:50:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 7 Jan 2021 00:50:57 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop In-Reply-To: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Wed, 6 Jan 2021 16:20:47 GMT, Jose Pereda wrote: > As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: > > - DropTargetListener, on dragEnter > - DragGestureListener, on dragGestureRecognized or > - MouseHandler, processing a right mouse click (these two are mutually exclusive). > > This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. > > The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. Yes, it does seem to fix the exception. I'd like to take a closer look to make sure that it isn't just masking the problem. Also, a second reviewer could be helpful on this, even though it is a simple fix. @arapte or @pankaj-bansal can one of you also look at it? ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From arapte at openjdk.java.net Thu Jan 7 03:21:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 7 Jan 2021 03:21:58 GMT Subject: Integrated: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 12:56:10 GMT, Ambarish Rapte wrote: > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. > > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. This pull request has now been integrated. Changeset: c197b624 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/c197b624 Stats: 131 lines in 4 files changed: 106 ins; 15 del; 10 mod 8242621: TabPane: Memory leak when switching skin Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Thu Jan 7 03:23:57 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 7 Jan 2021 03:23:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 09:55:14 GMT, Frederic Thevenet wrote: >> This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). >> >> Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). >> >> The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: >> >> - The node, or one of its parents, must have set `Node::cacheProperty` to `true` >> >> - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) >> >> - The effective layout X or Y coordinates for the cached node must be != 0; >> >> Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. >> >> Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. >> >> Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Addressed comments from review Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Thu Jan 7 11:55:56 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Thu, 7 Jan 2021 11:55:56 GMT Subject: Integrated: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 18:57:13 GMT, Frederic Thevenet wrote: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. This pull request has now been integrated. Changeset: 9c84c77b Author: Frederic Thevenet Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/9c84c77b Stats: 161 lines in 3 files changed: 136 ins; 12 del; 13 mod 8211294: ScrollPane content is blurry with 125% scaling Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fastegal at swingempire.de Thu Jan 7 13:45:53 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 07 Jan 2021 14:45:53 +0100 Subject: Discuss: SkinBase - add api to support register InvalidationListeners Message-ID: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> Recently filed (RFE) https://bugs.openjdk.java.net/browse/JDK-8258777 - it's about adding api to support un/register invalidationListener just the same way as changeListener. Trigger was work on cleaning up skins such that they don't misbehave (f.i. leaking memory or throwing exception, https://bugs.openjdk.java.net/browse/JDK-8241364) on switching the skin. Most of the related issues boil down to incomplete removal of listeners. As far as manual added (but not removed) changeListeners are involved, the fix is to use skin.registerChangeListener: all those are auto-removed in skinbase.dispose. For InvalidationListeners, the fix is cumbersome: it requires storing both the listener and its weak wrapper, manually adding the weak wrapper and manually removing it in dispose. Getting really boring if a skin (like TextInputXX) registers many of them .. IMO, not having symmetric support of invalidation- vs changeListeners in SkinBase api very much feels like an omission - which would be fixed by this :) Opinions, please. -- Jeanette From kevin.rushforth at oracle.com Thu Jan 7 16:21:33 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 7 Jan 2021 08:21:33 -0800 Subject: JavaFX 16 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 16 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx16 branch [2] for stabilizing the JavaFX 16 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for openjfx17. Most fixes will be integrated to master for 17. - The jfx16 branch of the jfx repo is now open for integrating fixes for openjfx16 that meet the RDP1 criteria as outlined below. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. - I will periodically sync jfx16 --> master, meaning that developers should integrate fixes to one or the other, not both DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx16 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx16. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx16 branch. The master branch is open for all openjfx17 fixes, including enhancements. As a reminder, we are using a single openjdk/jfx GitHub repo with stabilization branches [3] rather than creating separate stabilization repos. The jfx16 branch is used to stabilize the upcoming openjfx16 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx16 to ensure that it doesn't contain any commits from master after the jfx16 fork date. What that means is that if you intend a PR to be for jfx16, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 17 as of today). This is usually what we want. A PR should be targeted to `jfx16` if, and only if, it is intended for OpenJFX 16 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx16`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 17. Reviewers also need to be extra careful when reviewing PRs targeted to jfx16 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. We will use the same rules for RDP1 that the JDK uses [4], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 16 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx16-enhancement-request", "openjfx16-enhancement-yes", "openjfx16-enhancement-no" and "openjfx16-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx16 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into master for openjfx17, since we do not want to risk anything that would destabilize the openjfx16 release without a compelling reason. Also, we have only 3 weeks until RDP2 of openjfx16 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx16 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027837.html [2] https://github.com/openjdk/jfx/tree/jfx16 [3] https://github.com/openjdk/jfx/branches/all [4] http://openjdk.java.net/jeps/3 From kcr at openjdk.java.net Thu Jan 7 16:21:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 7 Jan 2021 16:21:55 GMT Subject: Integrated: 8259277: Change JavaFX release version to 17 In-Reply-To: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> References: <0_6BVZ_KMy_smMYvkYgS9HA9BvYgqNYiGrofCCK2X-A=.b581d643-7e02-45fd-b74c-ca8d7da9c366@github.com> Message-ID: On Wed, 6 Jan 2021 00:09:52 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 17. I will integrate this immediately after forking the `jfx16` stabilization branch. This pull request has now been integrated. Changeset: 2491661d Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2491661d Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8259277: Change JavaFX release version to 17 Reviewed-by: arapte, pbansal, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/371 From kcr at openjdk.java.net Thu Jan 7 16:28:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 7 Jan 2021 16:28:55 GMT Subject: [jfx16] RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. I am switching the target branch to `jfx16` now that we are in RDP1 and have forked the stabilization branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/354 From kevin.rushforth at oracle.com Thu Jan 7 22:46:28 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 7 Jan 2021 14:46:28 -0800 Subject: Discuss: SkinBase - add api to support register InvalidationListeners In-Reply-To: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> References: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> Message-ID: <9d1ec353-08ed-fb33-a1b0-c09a0e253b1d@oracle.com> I think this sounds like a very natural addition to the API. Making it easier for controls to clean up after themselves seems like a win. -- Kevin On 1/7/2021 5:45 AM, Jeanette Winzenburg wrote: > > Recently filed (RFE) https://bugs.openjdk.java.net/browse/JDK-8258777 > - it's about adding api to support un/register invalidationListener > just the same way as changeListener. > > Trigger was work on cleaning up skins such that they don't misbehave > (f.i. leaking memory or throwing exception, > https://bugs.openjdk.java.net/browse/JDK-8241364) on switching the > skin. Most of the related issues boil down to incomplete removal of > listeners. As far as manual added (but not removed) changeListeners > are involved, the fix is to use skin.registerChangeListener: all those > are auto-removed in skinbase.dispose. > > For InvalidationListeners, the fix is cumbersome: it requires storing > both the listener and its weak wrapper, manually adding the weak > wrapper and manually removing it in dispose. Getting really boring if > a skin (like TextInputXX) registers many of them .. > > IMO, not having symmetric support of invalidation- vs changeListeners > in SkinBase api very much feels like an omission - which would be > fixed by this :) > > Opinions, please. > > -- Jeanette > From kevin.rushforth at oracle.com Thu Jan 7 22:59:07 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 7 Jan 2021 14:59:07 -0800 Subject: Enhancement: native JavaFX api to interact with the icon / app / system tray In-Reply-To: References: Message-ID: I do agree this would be a useful feature. The main JBS issue for this issue is: JDK-8090475: System tray API [1] My advice (caution?) for anyone wanting to tackle this, is that it will take a fair amount of work to get this right and do it in such a way that both it, and any future "Desktop"-like API will fit in naturally. As part of this, we should consider what a JavaFX equivalent of AWT JEP 272 [1][2] (Platform-Specific Desktop Features) would look like. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8090475 [2] https://openjdk.java.net/jeps/272 [3] https://bugs.openjdk.java.net/browse/JDK-8048731 On 1/5/2021 5:42 AM, Nir Lisker wrote: > Hi, > > System tray support is one of the most recurring requests. The known > workaround is for the application writer to use the AWT system tray > support. It is not possible for core JavaFX to rely on it. > > If you would like to contribute, I'm sure the request will be approved. > > - Nir > > On Tue, Jan 5, 2021 at 12:44 PM Clement Levallois < > clementlevallois at protonmail.com> wrote: > >> Dear all, >> >> This is to suggest an enhancement to javafx: a native way to interact with >> the icon / app / system tray >> >> See this pic for an illustration of the icon tray, if unclear: >> >> There exist java awt classes to access the System Tray, but this obliges >> to add these classes to the build, which can be problematic? >> Example of these awt classes in the context of a JavaFX app: >> https://stackoverflow.com/questions/12571329/javafx-app-in-system-tray >> >> Desktop apps get more traction if they can be minimized and left to run in >> the background then accessed later via the icon tray, rather than closed >> and restarted. An API for the icon tray would help manage this part of the >> life cycle of an application. >> >> Doing some further research for this first post on this mailing list, I >> realize there is already a request for enhancement opened since 2014: >> https://bugs.openjdk.java.net/browse/JDK-8092115 >> >> CL >> >> -- >> Cl?ment Levallois >> Sent with [ProtonMail](https://protonmail.com) Secure Email. From kcr at openjdk.java.net Fri Jan 8 16:07:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 8 Jan 2021 16:07:58 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop In-Reply-To: References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Wed, 6 Jan 2021 17:40:43 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3788: >> >>> 3786: //old gesture ended and new one started >>> 3787: gestureStarted = true; >>> 3788: if (!PLATFORM_DRAG_GESTURE_INITIATION && Scene.this.dndGesture == null) { >> >> This will prevent the creation of the new `DndGesture`, but we will still clear the PDR targets. Have you confirmed that this is the desired behavior? It seems reasonable, since we also clear it on a mouse move, but wanted to get your take on it. > > This is really an edge case. There can be two gestures at once, an existing one (i.e from TouchPad), with its full drag information, that hasn't finished yet, and a new mouse one. > > Having a single `dndGesture` object for both events seems wrong. But having a list/array of events for such scenario seems overkill. > > Somehow some information from one or the other event might get lost or mixed up. The PDR targets are not required for the initial touch event, and we prevent the RTE, so I'd say this is a reasonable non-intrusive fix. In looking at it more closely, I think it might be better to avoid setting `gestureStarted` if there is already a drag gesture in process (started via dragEnter). Maybe something like this? if (Scene.this.dndGesture == null) { //old gesture ended and new one started gestureStarted = true; if (!PLATFORM_DRAG_GESTURE_INITIATION) { Scene.this.dndGesture = new DnDGesture(); } clearPDREventTargets(); } ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From perini.davide at dpsoftware.org Sat Jan 9 01:38:53 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sat, 9 Jan 2021 02:38:53 +0100 Subject: Show a stage on a second and third monitor, wrong order in JavaFX Screen.getScreens() Message-ID: Hi all, I have a triple display setup. I want to display a stage on the second and third monitor. To do this I use the displayNumber variable and this small snippet for (Screen screen : Screen.getScreens()) { Rectangle2D bounds = screen.getVisualBounds(); if (index == displayNumber) { stage.setX(bounds.getMinX()); stage.setY(bounds.getMinY()); } index++; } It works quite well since I can choose where the stage is displayed based on the displayNumber variable but that number does not corresponds to the Windows order. In Windows display #2 is the one on my left, in JavaFX it is the one on my right. Is there a way to get a ordered collections of the displays? Screen.getScreens() Thanks Davide From perini.davide at dpsoftware.org Sat Jan 9 03:21:45 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sat, 9 Jan 2021 04:21:45 +0100 Subject: Show a stage on a second and third monitor, wrong order in JavaFX Screen.getScreens() In-Reply-To: References: Message-ID: Forgive me, it was my fault, JavaFx starts from index 0. Regards, Davide Il 09/01/2021 02:38, Davide Perini ha scritto: > Hi all, > I have a triple display setup. > > I want to display a stage on the second and third monitor. > To do this I use the displayNumber variable and this small snippet > > for (Screen screen : Screen.getScreens()) { > ??? Rectangle2D bounds = screen.getVisualBounds(); if (index == > displayNumber) { > ??????? stage.setX(bounds.getMinX()); stage.setY(bounds.getMinY()); } > ??? index++; } > > It works quite well since I can choose where the stage is displayed > based on the displayNumber variable but > that number does not corresponds to the Windows order. > > In Windows display #2 is the one on my left, in JavaFX it is the one > on my right. > > Is there a way to get a ordered collections of the displays? > > Screen.getScreens() > > Thanks > Davide > > > > From arapte at openjdk.java.net Sat Jan 9 14:21:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 9 Jan 2021 14:21:58 GMT Subject: [jfx16] RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/354 From jpereda at openjdk.java.net Sat Jan 9 16:54:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 9 Jan 2021 16:54:10 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop [v2] In-Reply-To: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: > As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: > > - DropTargetListener, on dragEnter > - DragGestureListener, on dragGestureRecognized or > - MouseHandler, processing a right mouse click (these two are mutually exclusive). > > This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. > > The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Avoid setting gestureStarted if there is a drag gesture in process ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/372/files - new: https://git.openjdk.java.net/jfx/pull/372/files/096a628e..4f60fa9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=372&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=372&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/372.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/372/head:pull/372 PR: https://git.openjdk.java.net/jfx/pull/372 From jpereda at openjdk.java.net Sat Jan 9 16:54:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 9 Jan 2021 16:54:10 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop [v2] In-Reply-To: References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Fri, 8 Jan 2021 16:04:53 GMT, Kevin Rushforth wrote: >> This is really an edge case. There can be two gestures at once, an existing one (i.e from TouchPad), with its full drag information, that hasn't finished yet, and a new mouse one. >> >> Having a single `dndGesture` object for both events seems wrong. But having a list/array of events for such scenario seems overkill. >> >> Somehow some information from one or the other event might get lost or mixed up. The PDR targets are not required for the initial touch event, and we prevent the RTE, so I'd say this is a reasonable non-intrusive fix. > > In looking at it more closely, I think it might be better to avoid setting `gestureStarted` if there is already a drag gesture in process (started via dragEnter). Maybe something like this? > > if (Scene.this.dndGesture == null) { > //old gesture ended and new one started > gestureStarted = true; > if (!PLATFORM_DRAG_GESTURE_INITIATION) { > Scene.this.dndGesture = new DnDGesture(); > } > clearPDREventTargets(); > } Makes sense, I'll change it, but avoiding two nested if expressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From kcr at openjdk.java.net Sat Jan 9 17:13:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 9 Jan 2021 17:13:56 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop [v2] In-Reply-To: References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Sat, 9 Jan 2021 16:54:10 GMT, Jose Pereda wrote: >> As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: >> >> - DropTargetListener, on dragEnter >> - DragGestureListener, on dragGestureRecognized or >> - MouseHandler, processing a right mouse click (these two are mutually exclusive). >> >> This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. >> >> The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Avoid setting gestureStarted if there is a drag gesture in process Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From pbansal at openjdk.java.net Sat Jan 9 18:21:56 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 9 Jan 2021 18:21:56 GMT Subject: [jfx16] RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/354 From fastegal at swingempire.de Mon Jan 11 11:50:53 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 11 Jan 2021 12:50:53 +0100 Subject: Discuss: SkinBase - add api to support register InvalidationListeners In-Reply-To: <9d1ec353-08ed-fb33-a1b0-c09a0e253b1d@oracle.com> References: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> <9d1ec353-08ed-fb33-a1b0-c09a0e253b1d@oracle.com> Message-ID: <20210111125053.Horde.IOsqixdIuW79BS-gH3_XTQ6@webmail.df.eu> Thanks, Kevin :) Starting work. -- Jeanette Zitat von Kevin Rushforth : > I think this sounds like a very natural addition to the API. Making > it easier for controls to clean up after themselves seems like a win. > > -- Kevin > > > On 1/7/2021 5:45 AM, Jeanette Winzenburg wrote: >> >> Recently filed (RFE) >> https://bugs.openjdk.java.net/browse/JDK-8258777 - it's about >> adding api to support un/register invalidationListener just the >> same way as changeListener. >> >> Trigger was work on cleaning up skins such that they don't >> misbehave (f.i. leaking memory or throwing exception, >> https://bugs.openjdk.java.net/browse/JDK-8241364) on switching the >> skin. Most of the related issues boil down to incomplete removal of >> listeners. As far as manual added (but not removed) changeListeners >> are involved, the fix is to use skin.registerChangeListener: all >> those are auto-removed in skinbase.dispose. >> >> For InvalidationListeners, the fix is cumbersome: it requires >> storing both the listener and its weak wrapper, manually adding the >> weak wrapper and manually removing it in dispose. Getting really >> boring if a skin (like TextInputXX) registers many of them .. >> >> IMO, not having symmetric support of invalidation- vs >> changeListeners in SkinBase api very much feels like an omission - >> which would be fixed by this :) >> >> Opinions, please. >> >> -- Jeanette >> From kcr at openjdk.java.net Mon Jan 11 22:19:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 11 Jan 2021 22:19:58 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v4] In-Reply-To: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: On Wed, 25 Nov 2020 15:56:05 GMT, Jonathan Vusich wrote: >> While this does fix the specific problem, it introduces a new one. If the labels are initially too big, but after resizing the window would now fit, it does not recompute the orientation. This means that you are left with labels that are rotated even when they don't need to be. > > @kevinrushforth Thank you for catching that. Do you think it would be acceptable to simply rotate the labels back to zero if the user expands the window? @JonathanVusich will you be able to update the test to add adding a test for a vertical axis? That's the only outstanding change at this point. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Mon Jan 11 22:22:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 11 Jan 2021 22:22:56 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: On Thu, 26 Nov 2020 09:38:22 GMT, Christopher Hewett wrote: >> On a side note, not all resources seem to be freed / recreated on pipeline disposal. There are some error outputs, and some parts in a webview are only rendered after interactions. So it is probably better to mark this as WIP. I would be happy if you have some advice for me. >> java.lang.IllegalStateException: unmanaged resource freed from pool D3D Vram Pool >> at com.sun.prism.impl.BaseResourcePool.resourceFreed(BaseResourcePool.java:463) >> at com.sun.prism.impl.ManagedResource.dispose(ManagedResource.java:127) >> at com.sun.prism.impl.BaseTexture.dispose(BaseTexture.java:297) >> at com.sun.scenario.effect.impl.prism.ps.PPSDrawable.flush(PPSDrawable.java:69) >> at com.sun.scenario.effect.impl.ImagePool.dispose(ImagePool.java:267) >> at com.sun.scenario.effect.impl.Renderer.getRenderer(Renderer.java:367) >> at com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) >> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Layer.(WCGraphicsPrismContext.java:1369) >> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$ClipLayer.(WCGraphicsPrismContext.java:1440) >> at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.setClip(WCGraphicsPrismContext.java:328) >> at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:225) >> at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) >> at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) >> at com.sun.webkit.WebPage.paint(WebPage.java:703) >> at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >> at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) >> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) >> at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) >> at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) >> at java.base/java.lang.Thread.run(Thread.java:832) > > Now more of my company are remoting into machines this issue is causing problems for us. I moved it to Draft before noticing that there were additional commits after your last comment that I had missed seeing earlier, so I moved it back to RFR. ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From kcr at openjdk.java.net Tue Jan 12 00:35:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 00:35:07 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 15:03:15 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ### Performance >> >> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): >> >> Without the `falloff != 0` branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.5 >> mesh 200: 111.5 >> >> With the `falloff != 0` branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.3 >> mesh 200: 112.5 >> >> Ubuntu 20: >> With the patch: >> Mesh 200: 60 fps >> Mesh 5000: 15 fps >> Sphere 1000: 60 fps >> >> Without the patch (master branch) >> Mesh 200: 60 fps >> Mesh 5000: 16.3 fps >> Sphere 1000: 60 fps >> >> So no major changes. I will repeat these tests to make sure there was no mistake. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update to the gl pipeline The updated API looks fine, with a few wording suggestions. I haven't looked at the updated shaders yet. I have a few general comments and I left a few inline. 1. It's too late for JavaFX 16, so you will need to update the `@since` tags to 17 and the fixVersion of both the Enhancement request and the CSR in JBS to openjfx17. 2. I see you renamed the `setPointLight` method in the Prism pipelines to `setLight` and got rid of the separate `setSpotLight` method. Have you considered whether this will still make sense when adding a DirectionalLight? Maybe leaving the name as `setPointLight` is best? 3. I get the following error when trying to run any 3D program on Mac, such as the "3D Box" sample in Ensemble8: Shader compile log: ERROR: 0:314: '==' does not operate on 'float' and 'int' ERROR: 0:314: '==' does not operate on 'float' and 'int' ERROR: 0:315: Expression in 'return' statement must match return type of function (and no available implicit conversion) ERROR: 0:319: '!=' does not operate on 'float' and 'int' ERROR: 0:320: No matching function for call to clamp(float, int, int) ERROR: 0:322: '>=' does not operate on 'float' and 'int' ERROR: 0:326: '!=' does not operate on 'float' and 'int' ERROR: 0:329: No matching function for call to clamp(float, int, int) ERROR: 0:331: '==' does not operate on 'float' and 'int' ERROR: 0:332: Expression in 'return' statement must match return type of function (and no available implicit conversion) ERROR: 0:336: '>=' does not operate on 'float' and 'int' ERROR: 0:342: '!=' does not operate on 'float' and 'int' ERROR: 0:343: No matching function for call to clamp(float, int, int) ERROR: 0:345: '>=' does not operate on 'float' and 'int' java.lang.RuntimeException: Error creating fragment shader at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141) at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177) at javafx.graphics/com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:142) at javafx.graphics/com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:474) at javafx.graphics/com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:123) at javafx.graphics/com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:204) ... at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 125: > 123: NGPointLight.getDefaultQa(), > 124: NGPointLight.getDefaultMaxRange(), > 125: 0, 0, 1, 0, 180, 0); // simulating point light); Do you think it is worth using defined constants for these? modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2PhongShader.java line 229: > 227: float dirZ = light.dirZ; > 228: float length = (float) Math.sqrt(dirX * dirX + dirY * dirY + dirZ * dirZ); > 229: shader.setConstant("lights[" + i + "].dir", dirX / length, dirY / length, dirZ / length); In the `if` block the parameter is named `lightDir` and here it is named `dir`. I presume one of them is wrong. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 52: > 50: *
I = pow((cos(a) - cos(outer)) / (cos(inner) - cos(outer)), falloff)
> 51: * which represents a drop in illumination from the inner angle to the outer angle. {@code falloff} determines the > 52: * behavior of the drop. The expect values are {@code 0 <= innerAngle <= outerAngle <= 180} and {@code falloff >= 0}; That should be "expected" values, although since this is a specification, I would prefer to use "valid range". Perhaps something like: "The valid ranges for these properties are `{@code 0 <= innerAngle <= outerAngle <= 180}` and `{@code falloff >= 0}`; values outside either of these ranges can produce unexpected results". modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 129: > 127: /** > 128: * The angle of the spotlight's inner cone. Surfaces whose angle to the light's origin is less than this angle > 129: * receive the full light's intensity. At larger angles, the light intensity starts to drop. The expected values are Same comment as earlier about using "valid range". modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 156: > 154: /** > 155: * The angle of the spotlight's outer cone. Surfaces whose angle to the light's origin is greater than this angle > 156: * receive no light. At smaller angles, the light intensity starts to increase. The expected values are between "valid range" modules/javafx.graphics/src/main/native-prism-es2/GLContext.c line 2273: > 2271: /* > 2272: * Class: com_sun_prism_es2_GLContext > 2273: * Method: nSetPointLight nSetLight ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jan 12 00:35:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 00:35:08 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: <80le1OaTc-wMMtZ_GnzhFXPMjottZ6SiqGr0xBZkL9M=.35da68e7-f8ab-4505-bc81-8ab70d893ecb@github.com> On Tue, 29 Dec 2020 12:03:14 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ### Performance >> >> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): >> >> Without the `falloff != 0` branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.5 >> mesh 200: 111.5 >> >> With the `falloff != 0` branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.3 >> mesh 200: 112.5 >> >> Ubuntu 20: >> With the patch: >> Mesh 200: 60 fps >> Mesh 5000: 15 fps >> Sphere 1000: 60 fps >> >> Without the patch (master branch) >> Mesh 200: 60 fps >> Mesh 5000: 16.3 fps >> Sphere 1000: 60 fps >> >> So no major changes. I will repeat these tests to make sure there was no mistake. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update for the manual test utility modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 192: > 190: private DoubleProperty falloff; > 191: > 192: public final void setFalloff(double value) { I would also add the same language about the "valid range" being `falloff >= 0`. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Jan 12 17:06:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 17:06:11 GMT Subject: [jfx16] RFR: 8259639: GitHub actions: build fails on Linux due to missing apt-get update Message-ID: Simple fix to the `submit.yml` script to run `apt-get update` prior to installing needed packages on Linux. Without this, the request to install packages can fail to find the requested pacakges due to an out-of-date cache. Compare the [failing build](https://github.com/kevinrushforth/jfx/actions/runs/480626290) before the fix with the [successful build](https://github.com/kevinrushforth/jfx/actions/runs/480641431) after the fix. Note that this is targeted to `jfx16` so that any subsequent pull request for `jfx16` will be able to have a successful build on Linux. ------------- Commit messages: - 8259639: GitHub actions: build fails on Linux due to missing apt-get update Changes: https://git.openjdk.java.net/jfx/pull/375/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=375&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259639 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/375.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/375/head:pull/375 PR: https://git.openjdk.java.net/jfx/pull/375 From arapte at openjdk.java.net Tue Jan 12 17:44:55 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 12 Jan 2021 17:44:55 GMT Subject: [jfx16] RFR: 8259639: GitHub actions: build fails on Linux due to missing apt-get update In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:01:40 GMT, Kevin Rushforth wrote: > Simple fix to the `submit.yml` script to run `apt-get update` prior to installing needed packages on Linux. Without this, the request to install packages can fail to find the requested pacakges due to an out-of-date cache. > > Compare the [failing build](https://github.com/kevinrushforth/jfx/actions/runs/480626290) before the fix with the [successful build](https://github.com/kevinrushforth/jfx/actions/runs/480641431) after the fix. > > Note that this is targeted to `jfx16` so that any subsequent pull request for `jfx16` will be able to have a successful build on Linux. Looks good. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/375 From pbansal at openjdk.java.net Tue Jan 12 17:48:58 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 12 Jan 2021 17:48:58 GMT Subject: [jfx16] RFR: 8259639: GitHub actions: build fails on Linux due to missing apt-get update In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:01:40 GMT, Kevin Rushforth wrote: > Simple fix to the `submit.yml` script to run `apt-get update` prior to installing needed packages on Linux. Without this, the request to install packages can fail to find the requested pacakges due to an out-of-date cache. > > Compare the [failing build](https://github.com/kevinrushforth/jfx/actions/runs/480626290) before the fix with the [successful build](https://github.com/kevinrushforth/jfx/actions/runs/480641431) after the fix. > > Note that this is targeted to `jfx16` so that any subsequent pull request for `jfx16` will be able to have a successful build on Linux. +1 ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/375 From kcr at openjdk.java.net Tue Jan 12 18:15:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 18:15:57 GMT Subject: [jfx16] Integrated: 8259639: GitHub actions: build fails on Linux due to missing apt-get update In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 17:01:40 GMT, Kevin Rushforth wrote: > Simple fix to the `submit.yml` script to run `apt-get update` prior to installing needed packages on Linux. Without this, the request to install packages can fail to find the requested pacakges due to an out-of-date cache. > > Compare the [failing build](https://github.com/kevinrushforth/jfx/actions/runs/480626290) before the fix with the [successful build](https://github.com/kevinrushforth/jfx/actions/runs/480641431) after the fix. > > Note that this is targeted to `jfx16` so that any subsequent pull request for `jfx16` will be able to have a successful build on Linux. This pull request has now been integrated. Changeset: 9dd2058f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/9dd2058f Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259639: GitHub actions: build fails on Linux due to missing apt-get update Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/375 From jvos at openjdk.java.net Tue Jan 12 19:42:54 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 12 Jan 2021 19:42:54 GMT Subject: [jfx16] RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. This looks good, and I didn't hear objections (on the warning) on this PR nor in JBS or the mailinglist, so this is ok to be merged. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/354 From kcr at openjdk.java.net Tue Jan 12 20:30:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 20:30:59 GMT Subject: [jfx16] Integrated: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth wrote: > This fix adds documentation and a warning to clarify that loading the JavaFX modules from the classpath is not a supported configuration. This will not affect deployments that put the JavaFX modular jars on the classpath, but will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own modular jar file. This supports running both modular and non-modular applications. > > The JavaFX runtime expects its classes to be loaded from a set of named `javafx.*` modules, and does not support loading those modules from the classpath. The Java launcher will fail to load applications that extend `javafx.application.Application` unless the `javafx.graphics` module is on the module path. > > Applications that do not extend `javafx.application.Application` can be loaded even if the `javafx.*` classes are loaded from the classpath, but this is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of loading a subclass of `javafx.application.Application`, since it fails to load in the case where the JavaFX classes are loaded from the classpath. Further, allowing applications to run in an unsupported mode that likely has bugs creates a maintenance burden. Another problem is that when the JavaFX classes are loaded from the classpath, it breaks encapsulation, since we mo longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx modules on the classpath usually boils down to one of tooling support, although both gradle and maven now support modules as do all of the popular IDEs. This pull request has now been integrated. Changeset: 1d459973 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1d459973 Stats: 39 lines in 4 files changed: 39 ins; 0 del; 0 mod 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath Reviewed-by: arapte, pbansal, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/354 From kcr at openjdk.java.net Tue Jan 12 21:59:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 21:59:06 GMT Subject: RFR: Merge jfx:jfx16 Message-ID: Merge jfx16 into master (using Skara tooling). Since there are no merge conflicts, this should not require a review. ------------- Commit messages: - Merge jfx:jfx16 - 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath - 8259639: GitHub actions: build fails on Linux due to missing apt-get update The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/376/files Stats: 40 lines in 5 files changed: 40 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/376.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/376/head:pull/376 PR: https://git.openjdk.java.net/jfx/pull/376 From kcr at openjdk.java.net Tue Jan 12 22:11:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 22:11:14 GMT Subject: RFR: Merge jfx:jfx16 [v2] In-Reply-To: References: Message-ID: <4p_H2Dg-ktQOveXq1pntSQU6NsBcJGUomDiGRPzad2o=.8177fe88-3458-4e7f-9e0b-2bbc00c0cbab@github.com> > Merge jfx16 into master (using Skara tooling). Since there are no merge conflicts, this should not require a review. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge jfx:jfx16 - 8259277: Change JavaFX release version to 17 Reviewed-by: arapte, pbansal, jvos ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/376/files - new: https://git.openjdk.java.net/jfx/pull/376/files/117862ef..117862ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=376&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=376&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/376.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/376/head:pull/376 PR: https://git.openjdk.java.net/jfx/pull/376 From kcr at openjdk.java.net Tue Jan 12 22:11:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Jan 2021 22:11:15 GMT Subject: Integrated: Merge jfx:jfx16 In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 20:57:32 GMT, Kevin Rushforth wrote: > Merge jfx16 into master (using Skara tooling). Since there are no merge conflicts, this should not require a review. This pull request has now been integrated. Changeset: e3e600b5 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e3e600b5 Stats: 40 lines in 5 files changed: 40 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/376 From kcr at openjdk.java.net Wed Jan 13 00:57:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 00:57:59 GMT Subject: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: <27yV7-jLZx1OlO-EjxQbVbyR5cg8TQgxn2VWlwZLCQs=.7f14f8eb-7703-4411-9a48-076dab127032@github.com> <8swF8lhhTX0-jUeB7pJUU7Kj8I2_nI5o_FOR1qPPTAk=.b6e5916b-c180-4aed-8a31-cdfc76d18cb1@github.com> <67RLDjl_LiYeiBgYxWpZUOdxAAcRdHhs9l8e3wwc0HE=.3c4409e0-7a11-4a62-8581-164e97ab545b@github.com> Message-ID: On Sun, 26 Apr 2020 10:42:10 GMT, Jeanette Winzenburg wrote: >>> repeating my comment from the [previous pull request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): I don't think this is yet ready for a technical review - there are some more basic questions that are not yet answered :) >> >>> - is it really a bug or a nice-to-have enhancement? couldn't find an example in win, didn't try too hard and nowadays, such plain combos are not a really frequent >>> - while none of the virtualized controls (nor ChoiceBox) combines selection with scrolling to the selected item. For combo and choice, I see no reason not make it the default behavior. We need to make certain it behaves "naturally" when navigating in the open popup. >>> - instead of catching every list.select (and not forget the unselect) we might consider doing it in a showing handler >>> - alternatively, we might consider to go deeper and support it directly in the listView >> >> - For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the illusion of a preselected value not actually being selected because it's not visible if the list is large and has been shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort and time. >> >> - With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires scrolling, so the selected value is already visible. >> >> - I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process to select the final value. >> >> - Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying ListView. My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience? > >> For me / my users / and the open bug, it is a bug due to the current behavior being unexpected. It creates the illusion of a preselected value not actually being selected because it's not visible if the list is large and has been shown. It creates doubt and the user has to scroll to reconfirm their selection which takes extra unnecessary effort and time. >> > > Yes, I understand the perspective of the users (would be unhappy with it as well) - but from the perspective of the fx, it's the job of the application developer to keep a selected item visible. Which s/he could do easily enough, even for a comboBox. Also I agree, that in the case of the combo it feels unexpected to not the selected item on opening the popup. So we could do something about it - but we have to specify _exactly_ what that something should be. > >> With my testing, for the ComboBox, behavior was smooth and natural. I've not made any attempt to change selection with it shown and I'm not certain it can happen unless done programmatically. User selection within the list requires scrolling, so the selected value is already visible. >> > > Hmm, probably wasn't clear enough: have a combo with many items, open the popup, navigate (via keys like page/up/down ..) and compare the behavior before/after the fix. I see considerable differences in behavior. F.i. keyDown does move the selection one-down without scrolling before and scrolls down by one after (making the selected item visually "stick" at the top). Do you see that as well or did I goof somehow (also a possibility :) ? > > Navigation behavior should be the same before/after, I think. There might be other behavior changes introduced (didn't check further, it's your issue :), that we should actively look out for. > >> I'm not opposed to taking this approach. My current work around by extending ComboBox is based on scrolling when the value is set (restored) programmatically. I could see how it may be more efficient if multiple selections were being performed programmatically, but not sure why someone would write code this way. I would think it's a one shot process to select the final value. >> > > not sure what you mean by "one shot process" and "final value": the fix scrolls the list to top whenever the value changes, and the value is changed whenever the selectedItem is changed which happens on navigation (that is user interaction) as well as changing it programatically. > > Maybe we should really go back to square one and _exactly_ specify when we want the value be scrolled into view. The current fix does so for _each_ selection (which has rather broad effects). If it could be bounded a bit more, the effects would be narrower. That's why I suggested to limit it f.i. to the time of opening the popup (which is rather rare compared to selection change). > >> Implementing the change in ListView would not change/improve ChoiceBox simply because it does not use an underlying ListView. > > yeah, forget about ChoiceBox, I was wrong - whoever needs to scroll to the selected value is using the wrong control .. > >> My search on uses of ListView only reviled ComboBox other than itself. Since ListView by itself is not collapsed/hidden for typical uses, would automatic scrolling within ListView create a confusing experience? > > Ahh, guilty of having been unclear again, sry - what I meant is to add support of doing a well-behaved scrolling in ListView (and the other virtualized controls): scrollTo is not overly well-behaved. And I agree, doing it always and unconditionally, might introduce a bad user experience. I meant to close this PR out a while ago, but it kept getting put on the back burner. I don't think this PR is the right approach to the problem. I can confirm that this doesn't behave naturally at all when using the arrow or page up / page down keys when the combo is open. Before we make any changes in FX itself we need to specify what the behavior should be for various cases, including multiple selections, scrolling while the combo is open, changing the selection while the combo is open, etc. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From github.com+636962+ccavanaugh at openjdk.java.net Wed Jan 13 00:58:01 2021 From: github.com+636962+ccavanaugh at openjdk.java.net (Craig Cavanaugh) Date: Wed, 13 Jan 2021 00:58:01 GMT Subject: Withdrawn: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set In-Reply-To: References: Message-ID: On Thu, 9 Apr 2020 09:37:30 GMT, Craig Cavanaugh wrote: > https://bugs.openjdk.java.net/browse/JDK-8129123 > > This pull request fixes JDK-8129123. This bug also effects Windows and Linux platforms. > Also, I believe JDK-8196037 is a duplicate of this issue. > > I've tested this against OpenJDK 11.0.6 on Ubuntu 18.04, Arch Linux and Windows 10. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/166 From nlisker at openjdk.java.net Wed Jan 13 08:07:57 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 13 Jan 2021 08:07:57 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 00:31:54 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update to the gl pipeline > > The updated API looks fine, with a few wording suggestions. I haven't looked at the updated shaders yet. > > I have a few general comments and I left a few inline. > > 1. It's too late for JavaFX 16, so you will need to update the `@since` tags to 17 and the fixVersion of both the Enhancement request and the CSR in JBS to openjfx17. > > 2. I see you renamed the `setPointLight` method in the Prism pipelines to `setLight` and got rid of the separate `setSpotLight` method. Have you considered whether this will still make sense when adding a DirectionalLight? Maybe leaving the name as `setPointLight` is best? > > 3. I get the following error when trying to run any 3D program on Mac, such as the "3D Box" sample in Ensemble8: > > Shader compile log: ERROR: 0:314: '==' does not operate on 'float' and 'int' > ERROR: 0:314: '==' does not operate on 'float' and 'int' > ERROR: 0:315: Expression in 'return' statement must match return type of function (and no available implicit conversion) > ERROR: 0:319: '!=' does not operate on 'float' and 'int' > ERROR: 0:320: No matching function for call to clamp(float, int, int) > ERROR: 0:322: '>=' does not operate on 'float' and 'int' > ERROR: 0:326: '!=' does not operate on 'float' and 'int' > ERROR: 0:329: No matching function for call to clamp(float, int, int) > ERROR: 0:331: '==' does not operate on 'float' and 'int' > ERROR: 0:332: Expression in 'return' statement must match return type of function (and no available implicit conversion) > ERROR: 0:336: '>=' does not operate on 'float' and 'int' > ERROR: 0:342: '!=' does not operate on 'float' and 'int' > ERROR: 0:343: No matching function for call to clamp(float, int, int) > ERROR: 0:345: '>=' does not operate on 'float' and 'int' > > java.lang.RuntimeException: Error creating fragment shader > at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141) > at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177) > at javafx.graphics/com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:142) > at javafx.graphics/com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:474) > at javafx.graphics/com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:123) > at javafx.graphics/com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:204) > ... > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Thread.java:832) I forgot to mention that I edited the topmost comment to include another API discussion point about using the rotation of the node as the direction of the light. We might also need to be careful about a (0, 0, 0) direction since it's not normalizable. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From tsayao at openjdk.java.net Wed Jan 13 12:59:18 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:18 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend Message-ID: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> ### Summary * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. ### Goals * Make Linux a first-class OpenJFX platform (see Motivation); * Simplify the code and reduce it's size; * Update to gtk3 (it was originally a port from gtk2); * Remove unused code (such as applets and web start); * Prepare the ground for a possible future Wayland support. ### Testing ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test ------------- Commit messages: - Restore WM_CLASS functionality (as described on the code comment). - Merge branch 'master' into jdk_8236651 - Merge pull request #13 from openjdk/master - parent c95598e8df7d303e8f2540c1845ebdcc2200ab2f - Merge pull request #12 from openjdk/master - Merge pull request #11 from openjdk/master - Merge pull request #10 from openjdk/master - Merge pull request #9 from openjdk/master - Merge pull request #8 from openjdk/master - Merge pull request #7 from openjdk/master - ... and 3 more: https://git.openjdk.java.net/jfx/compare/cb545cc6...e19295f3 Changes: https://git.openjdk.java.net/jfx/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236651 Stats: 7054 lines in 29 files changed: 7038 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 12:59:20 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 12:59:20 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Mon, 6 Jan 2020 00:28:14 GMT, Thiago Milczarek Sayao wrote: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test > Please, mark it as WIP. You can do this by editing the title and adding `WIP: ` as a prefix. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:22 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:22 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Mon, 6 Jan 2020 22:41:07 GMT, Kevin Rushforth wrote: >>> Please, mark it as WIP. >> >> You can do this by editing the title and adding `WIP: ` as a prefix. > > This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc. I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing). ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 12:59:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 12:59:28 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Mon, 3 Feb 2020 17:26:32 GMT, Thiago Milczarek Sayao wrote: >> I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing). > > **Code Changes** > > * glass_window.cpp / glass_window.h > * Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to > one class named WindowContext (since inheritance was no required anymore) > * Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; > * Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); > * Frame Extents: Removed the code to request extents and gtk already does it by default; > * Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJfx uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. > * Other Size calculation changes: > * Use gtk_window_set_default_size() for initial size which is the appropriate function; > * Gravity is now ignored as it is on Windows glass impl; > * Avoid sending same sizes to Java; > * Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); > * Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on > apply_geometry(). > * Mouse grab: Reworked it to use to correct functions according to gtk+ version; > * Draw: Reworked it to use the correct calls accord to gtk+ version changes; > * Fixed JDK-8237491; > * Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; > * Reorganized function order on glass_window.cpp to match glass_window.h > > > * GlassCursor.cpp > * Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; > * Reworked Gtk+2 to use a function instead of manual calls to find the cursor; > > * GtkWindow.java > * Moved the extents special case to native glass; > > * GlassApplication.cpp > * Removed Gdk events where possible (it's now on glass_window as signals); > * Removed applet/web start code; > > * GlassView.cpp > * Changes to reflect frame extents rework on glass_window > > * GlassWindow.cpp > * WindowContextTop -> WindowContext > * Removed applet / web start code; > * Removed frame extents (which is not called anymore due to GtkWindow.java change); > > * glass_general.cpp > * Removed functions that became unused; > * Added is_grab_disabled() that is used on glass_window > > * glass_window_ime.cpp > * WindowContextTop -> WindowContext; > > * glass_dnd.cpp / glass_dnd.h > * Ported to Gtk signals; > * Use all possible image formats (supported by GdkPixbuf / OpenJfx) - .gif is now possible (for ex.); > * Allow COMPOUND_TEXT; > * Do not request content while dragging; > * Reduce overall code size. This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:25 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:25 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Mon, 6 Jan 2020 22:57:31 GMT, Thiago Milczarek Sayao wrote: >> This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc. > > I understand. Will do that when the code works 100%. I have submitted the PR to avoid duplicated efforts and let people test it (if anyone is willing). **Code Changes** * glass_window.cpp / glass_window.h * Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to one class named WindowContext (since inheritance was no required anymore) * Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; * Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); * Frame Extents: Removed the code to request extents and gtk already does it by default; * Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJfx uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. * Other Size calculation changes: * Use gtk_window_set_default_size() for initial size which is the appropriate function; * Gravity is now ignored as it is on Windows glass impl; * Avoid sending same sizes to Java; * Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); * Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on apply_geometry(). * Mouse grab: Reworked it to use to correct functions according to gtk+ version; * Draw: Reworked it to use the correct calls accord to gtk+ version changes; * Fixed JDK-8237491; * Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; * Reorganized function order on glass_window.cpp to match glass_window.h * GlassCursor.cpp * Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; * Reworked Gtk+2 to use a function instead of manual calls to find the cursor; * GtkWindow.java * Moved the extents special case to native glass; * GlassApplication.cpp * Removed Gdk events where possible (it's now on glass_window as signals); * Removed applet/web start code; * GlassView.cpp * Changes to reflect frame extents rework on glass_window * GlassWindow.cpp * WindowContextTop -> WindowContext * Removed applet / web start code; * Removed frame extents (which is not called anymore due to GtkWindow.java change); * glass_general.cpp * Removed functions that became unused; * Added is_grab_disabled() that is used on glass_window * glass_window_ime.cpp * WindowContextTop -> WindowContext; * glass_dnd.cpp / glass_dnd.h * Ported to Gtk signals; * Use all possible image formats (supported by GdkPixbuf / OpenJfx) - .gif is now possible (for ex.); * Allow COMPOUND_TEXT; * Do not request content while dragging; * Reduce overall code size. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:36 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:36 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Thu, 13 Feb 2020 23:56:42 GMT, Kevin Rushforth wrote: >> **Code Changes** >> >> * glass_window.cpp / glass_window.h >> * Removed WindowContextPlug and WindowContextChild (that were used for applets / web start) and moved everything to >> one class named WindowContext (since inheritance was no required anymore) >> * Changed set_enabled() to use gtk_widget_set_sensitive instead of custom code; >> * Moved to gtk signals instead of gdk events (to use gtk_widget_set_sensitive and gtk_grab_add); >> * Frame Extents: Removed the code to request extents and gtk already does it by default; >> * Size calculation: Reworked size calculation code. In general, X windows are content size instead of whole window size (considering extents - frame decorations). OpenJfx uses "whole window size" as window sizes, so it requires a "hack" to recalculate sizes when set_bounds() is called with window sizes instead of content sizes. The rework was to simplify code paths and make it more straightforward. >> * Other Size calculation changes: >> * Use gtk_window_set_default_size() for initial size which is the appropriate function; >> * Gravity is now ignored as it is on Windows glass impl; >> * Avoid sending same sizes to Java; >> * Introduced calculate_adjustments() which is a fallback when frame extents is not present (it's optional to window managers to implement it); >> * Geometry: Min / Max sizes - reworked it to simplify / Concentrated geometry changes on >> apply_geometry(). >> * Mouse grab: Reworked it to use to correct functions according to gtk+ version; >> * Draw: Reworked it to use the correct calls accord to gtk+ version changes; >> * Fixed JDK-8237491; >> * Moved background code to paint() as gtk3 uses styles to set the background and other functions were deprecated; >> * Reorganized function order on glass_window.cpp to match glass_window.h >> >> >> * GlassCursor.cpp >> * Gtk+3 uses a name-like-css approach - so it was properly ported to gtk3 way; >> * Reworked Gtk+2 to use a function instead of manual calls to find the cursor; >> >> * GtkWindow.java >> * Moved the extents special case to native glass; >> >> * GlassApplication.cpp >> * Removed Gdk events where possible (it's now on glass_window as signals); >> * Removed applet/web start code; >> >> * GlassView.cpp >> * Changes to reflect frame extents rework on glass_window >> >> * GlassWindow.cpp >> * WindowContextTop -> WindowContext >> * Removed applet / web start code; >> * Removed frame extents (which is not called anymore due to GtkWindow.java change); >> >> * glass_general.cpp >> * Removed functions that became unused; >> * Added is_grab_disabled() that is used on glass_window >> >> * glass_window_ime.cpp >> * WindowContextTop -> WindowContext; >> >> * glass_dnd.cpp / glass_dnd.h >> * Ported to Gtk signals; >> * Use all possible image formats (supported by GdkPixbuf / OpenJfx) - .gif is now possible (for ex.); >> * Allow COMPOUND_TEXT; >> * Do not request content while dragging; >> * Reduce overall code size. > > This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 and Scenebuilder. Will have to do some tests on 16.04. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:43 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:43 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> On Tue, 3 Mar 2020 11:10:07 GMT, Thiago Milczarek Sayao wrote: >> This is going to need further discussion on the mailing list as indicated above, so it is still premature to review it (i.e., it should still be considered effectively a "WIP" until that discussion happens). Additionally, this is a significant and risky change, so I'd like additional eyes on it when we do get to the point of reviewing it. > > I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 and Scenebuilder. > > Will have to do some tests on 16.04. Ubuntu 20.04 Test Results Updated April 2nd. ![image](https://user-images.githubusercontent.com/30704286/78299385-28a23d80-750c-11ea-9edd-ac264f16c194.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:49 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:49 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Tue, 24 Mar 2020 13:33:33 GMT, Thiago Milczarek Sayao wrote: >> I have been testing this for several days on ubuntu 18.04 and it's working good. It pass system tests, runs Ensemble 8 and Scenebuilder. >> >> Will have to do some tests on 16.04. > > Ubuntu 20.04 Test Results > > Updated April 2nd. > > ![image](https://user-images.githubusercontent.com/30704286/78299385-28a23d80-750c-11ea-9edd-ac264f16c194.png) Test on 16.04 (without Webkit - it does not build on 16.04 anymore) Updated April 2nd. ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) Note: DatePickerTest works when run alone. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 12:59:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 12:59:58 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Fri, 3 Apr 2020 02:11:12 GMT, Thiago Milczarek Sayao wrote: >> Test on 16.04 (without Webkit - it does not build on 16.04 anymore) >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) >> >> Note: DatePickerTest works when run alone. > > I will keep testing it, but I think it's looking good. I see a lot of work going into this. In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any existing message) to openjfx-dev at openjdk.java.net with the following: 1. A short summary of the proposed enhancement 2. The goals of the proposed enhancement 3. A description of the proposed changes (basically, the bullet items from the description of this PR) 4. A pointer to this PR for reference I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther along in the review process. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:00:00 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:00:00 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Fri, 3 Apr 2020 15:21:29 GMT, Kevin Rushforth wrote: >> I will keep testing it, but I think it's looking good. > > I see a lot of work going into this. > > In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the RFR thread and not a comment in the PR. > > @tsayao When you are ready, please send a short email (not a reply to any existing message) to openjfx-dev at openjdk.java.net with the following: > > 1. A short summary of the proposed enhancement > 2. The goals of the proposed enhancement > 3. A description of the proposed changes (basically, the bullet items from the description of this PR) > 4. A pointer to this PR for reference > > I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; review comments in the PR aren't the best way to have that discussion. > > We aren't following the formal JEP process for JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. > > Finally, I note that this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther along in the review process. @kevinrushforth Ok, will do as the instructions. Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 12:59:54 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 12:59:54 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Wed, 1 Apr 2020 03:21:31 GMT, Thiago Milczarek Sayao wrote: >> Ubuntu 20.04 Test Results >> >> Updated April 2nd. >> >> ![image](https://user-images.githubusercontent.com/30704286/78299385-28a23d80-750c-11ea-9edd-ac264f16c194.png) > > Test on 16.04 (without Webkit - it does not build on 16.04 anymore) > > Updated April 2nd. > > ![image](https://user-images.githubusercontent.com/30704286/78316727-c14db300-7536-11ea-86e9-4d5c56e4d92c.png) > > Note: DatePickerTest works when run alone. I will keep testing it, but I think it's looking good. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:00:03 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:00:03 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Fri, 3 Apr 2020 23:41:49 GMT, Thiago Milczarek Sayao wrote: >> I see a lot of work going into this. >> >> In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the RFR thread and not a comment in the PR. >> >> @tsayao When you are ready, please send a short email (not a reply to any existing message) to openjfx-dev at openjdk.java.net with the following: >> >> 1. A short summary of the proposed enhancement >> 2. The goals of the proposed enhancement >> 3. A description of the proposed changes (basically, the bullet items from the description of this PR) >> 4. A pointer to this PR for reference >> >> I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; review comments in the PR aren't the best way to have that discussion. >> >> We aren't following the formal JEP process for JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. >> >> Finally, I note that this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther along in the review process. > > @kevinrushforth Ok, will do as the instructions. Thanks. I ran the systemTests on Ubuntu 18.04 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results Results_18 04 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 13:00:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 13:00:07 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Sat, 6 Jun 2020 13:03:36 GMT, Pankaj Bansal wrote: >> @kevinrushforth Ok, will do as the instructions. Thanks. > > I ran the systemTests on Ubuntu 18.04 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results > > Results_18 04 In case it is useful to those reviewing the code, I have created a [WIP pull request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs between the existing gtk native code and the experimental GTK native code from *this* pull request. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 13:00:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 13:00:07 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Tue, 9 Jun 2020 23:12:15 GMT, Kevin Rushforth wrote: >> I ran the systemTests on Ubuntu 18.04 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results >> >> Results_18 04 > > In case it is useful to those reviewing the code, I have created a [WIP pull request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs between the existing gtk native code and the experimental GTK native code from *this* pull request. I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle checking GTK version 3 trying GTK library libgtk-3.so.0 using GTK library version 3 set libgtk-3.so.0 Glass GTK library to load is glassgtk3_exp loaded gdk_x11_display_set_window_scale java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 13:00:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 13:00:10 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Tue, 9 Jun 2020 23:14:31 GMT, Kevin Rushforth wrote: >> In case it is useful to those reviewing the code, I have created a [WIP pull request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs between the existing gtk native code and the experimental GTK native code from *this* pull request. > > I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. > > One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: > > $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle > checking GTK version 3 > trying GTK library libgtk-3.so.0 > using GTK library version 3 set libgtk-3.so.0 > Glass GTK library to load is glassgtk3_exp > loaded gdk_x11_display_set_window_scale > java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors Here are the results with Ubuntu 20.04: ![Ubuntu-20 04-test-results](https://user-images.githubusercontent.com/34689748/84213198-e0a41780-aa74-11ea-9362-08c621af6746.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:00:10 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:00:10 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: On Tue, 9 Jun 2020 23:14:31 GMT, Kevin Rushforth wrote: > I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. > > One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: > > ``` > $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle > checking GTK version 3 > trying GTK library libgtk-3.so.0 > using GTK library version 3 set libgtk-3.so.0 > Glass GTK library to load is glassgtk3_exp > loaded gdk_x11_display_set_window_scale > java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors > ``` I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:00:16 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:00:16 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> Message-ID: <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> On Wed, 10 Jun 2020 02:25:00 GMT, Thiago Milczarek Sayao wrote: >> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. >> >> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >> >> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >> checking GTK version 3 >> trying GTK library libgtk-3.so.0 >> using GTK library version 3 set libgtk-3.so.0 >> Glass GTK library to load is glassgtk3_exp >> loaded gdk_x11_display_set_window_scale >> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors > >> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. >> >> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >> >> ``` >> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >> checking GTK version 3 >> trying GTK library libgtk-3.so.0 >> using GTK library version 3 set libgtk-3.so.0 >> Glass GTK library to load is glassgtk3_exp >> loaded gdk_x11_display_set_window_scale >> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors >> ``` > > I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. Here is the result on Ubuntu 20.04 with the latest changes: ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) Some tests seems intermittent. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:00:25 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:00:25 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Wed, 10 Jun 2020 13:11:29 GMT, Thiago Milczarek Sayao wrote: >>> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. >>> >>> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >>> >>> ``` >>> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >>> checking GTK version 3 >>> trying GTK library libgtk-3.so.0 >>> using GTK library version 3 set libgtk-3.so.0 >>> Glass GTK library to load is glassgtk3_exp >>> loaded gdk_x11_display_set_window_scale >>> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors >>> ``` >> >> I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. > > Here is the result on Ubuntu 20.04 with the latest changes: > > ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) > > Some tests seems intermittent. I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back with the results OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:00:34 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:00:34 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 05:56:41 GMT, Pankaj Bansal wrote: >> Here is the result on Ubuntu 20.04 with the latest changes: >> >> ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) >> >> Some tests seems intermittent. > > I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back with the results > OL82 I ran the systemTests on OL8.2 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 12:59:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 12:59:21 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: On Mon, 6 Jan 2020 14:25:18 GMT, Kevin Rushforth wrote: >> ### Summary >> * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. >> >> ### Goals >> * Make Linux a first-class OpenJFX platform (see Motivation); >> * Simplify the code and reduce it's size; >> * Update to gtk3 (it was originally a port from gtk2); >> * Remove unused code (such as applets and web start); >> * Prepare the ground for a possible future Wayland support. >> ### Testing >> ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test > >> Please, mark it as WIP. > > You can do this by editing the title and adding `WIP: ` as a prefix. This sort of enhancement needs to be discussed on the openjfx-dev mailing list first. While the WIP PR might be used to illustrate what you have in mind to propose, it is premature to actually review the implementation without first discussing whether and it makes sense to do it, what the high-level goals are, etc. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:00:52 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:00:52 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 12:49:42 GMT, Pankaj Bansal wrote: > After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for reference. > [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) It's now fixed. I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:07 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:07 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 13:51:58 GMT, Kevin Rushforth wrote: >>> After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for reference. >>> [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) >> >> It's now fixed. I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. > >> I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. > > Good. I was going to ask you about that, so I'm happy to see it gone. I have investigated the Tab Pane Drag Test and it works manually. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Tab; import javafx.scene.control.TabPane; import javafx.stage.Stage; public class Test extends Application { @Override public void start(Stage stage) { TabPane tabPane = new TabPane(); tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); Scene scene = new Scene(tabPane, 800, 600); stage.setScene(scene); Tab tab1 = new Tab("Tab1"); Tab tab2 = new Tab("Tab2"); tabPane.getTabs().addAll(tab1, tab2); stage.setAlwaysOnTop(true); stage.show(); } public static class Main { public static void main(String[] args) { Application.launch(Test.class, args); } } } It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't work well on Robot. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:00:44 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:00:44 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 11:55:47 GMT, Pankaj Bansal wrote: >> I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back with the results >> OL82 > > I ran the systemTests on OL8.2 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results > > OL82 After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for reference. [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:01:10 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:01:10 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 20:22:12 GMT, Thiago Milczarek Sayao wrote: >>> I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. >> >> Good. I was going to ask you about that, so I'm happy to see it gone. > > I have investigated the Tab Pane Drag Test and it works manually. > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Tab; > import javafx.scene.control.TabPane; > import javafx.stage.Stage; > > public class Test > extends Application { > > @Override > public void start(Stage stage) { > TabPane tabPane = new TabPane(); > tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); > Scene scene = new Scene(tabPane, 800, 600); > stage.setScene(scene); > Tab tab1 = new Tab("Tab1"); > Tab tab2 = new Tab("Tab2"); > > tabPane.getTabs().addAll(tab1, tab2); > > > stage.setAlwaysOnTop(true); > stage.show(); > } > > public static class Main { > public static void main(String[] args) { > Application.launch(Test.class, args); > } > } > } > > It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't work well on Robot. Following are results in Ubuntu 18.04 after fix for tab pane tests. Results_18 04 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:13 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:13 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Sun, 14 Jun 2020 11:55:45 GMT, Pankaj Bansal wrote: >> Following are results in Ubuntu 18.04 after fix for tab pane tests. >> Results_18 04 > > This is the result on OL 82 with latest commit > OL82 @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 13:01:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 13:01:16 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Sun, 14 Jun 2020 23:59:17 GMT, Thiago Milczarek Sayao wrote: >> This is the result on OL 82 with latest commit >> OL82 > > @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. > If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jan 13 13:01:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Jan 2021 13:01:00 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 12 Jun 2020 13:49:23 GMT, Thiago Milczarek Sayao wrote: > I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. Good. I was going to ask you about that, so I'm happy to see it gone. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Wed Jan 13 13:01:13 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 13 Jan 2021 13:01:13 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Sun, 14 Jun 2020 06:49:42 GMT, Pankaj Bansal wrote: >> I have investigated the Tab Pane Drag Test and it works manually. >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Tab; >> import javafx.scene.control.TabPane; >> import javafx.stage.Stage; >> >> public class Test >> extends Application { >> >> @Override >> public void start(Stage stage) { >> TabPane tabPane = new TabPane(); >> tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); >> Scene scene = new Scene(tabPane, 800, 600); >> stage.setScene(scene); >> Tab tab1 = new Tab("Tab1"); >> Tab tab2 = new Tab("Tab2"); >> >> tabPane.getTabs().addAll(tab1, tab2); >> >> >> stage.setAlwaysOnTop(true); >> stage.show(); >> } >> >> public static class Main { >> public static void main(String[] args) { >> Application.launch(Test.class, args); >> } >> } >> } >> >> It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't work well on Robot. > > Following are results in Ubuntu 18.04 after fix for tab pane tests. > Results_18 04 This is the result on OL 82 with latest commit OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+17347324+torbuntu at openjdk.java.net Wed Jan 13 13:01:18 2021 From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 13 Jan 2021 13:01:18 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: On Fri, 3 Jul 2020 13:49:54 GMT, Kevin Rushforth wrote: >> @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. > >> If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. > > Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would follow up update PR adding that be more appropriate? Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+17347324+torbuntu at openjdk.java.net Wed Jan 13 13:01:23 2021 From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 13 Jan 2021 13:01:23 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> Message-ID: On Wed, 29 Jul 2020 20:46:16 GMT, Thiago Milczarek Sayao wrote: >> Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would follow up update PR adding that be more appropriate? >> >> Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. > > @Torbuntu Not to this PR, I don't want to delay it too much. But can be done (I just do not own a touch device currently). Sounds good! I have a few devices I'd be more than excited to test on, and even help add the feature myself if I can figure it out if time is a big issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:21 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:21 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> Message-ID: <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> On Wed, 29 Jul 2020 02:39:31 GMT, Tor (torbuntu) wrote: >>> If you want these commits to be preserved when you integrate, you will need to make a 'merge-style' pull request. >> >> Please ignore this information from Skara. I don't know what caused it, but I've pinged the Skara folks about it. > > Would it be possible and related to add the gtk touch events to this PR as part of the Glass GTK3 update? Or would follow up update PR adding that be more appropriate? > > Currently linux desktop does not have touch support because of the missing gesture/touch events from gtk3. @Torbuntu Not to this PR, I don't want to delay it too much. But can be done (I just do not own a touch device currently). ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:26 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:26 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> Message-ID: <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> On Wed, 29 Jul 2020 21:01:42 GMT, Tor (torbuntu) wrote: >> @Torbuntu Not to this PR, I don't want to delay it too much. But can be done (I just do not own a touch device currently). > > Sounds good! I have a few devices I'd be more than excited to test on, and even help add the feature myself if I can figure it out if time is a big issue? I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:31 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:31 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> Message-ID: On Thu, 27 Aug 2020 21:21:39 GMT, Tor (torbuntu) wrote: >> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). > >> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). > > Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. Rebased onto "master" and squashed commits. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+17347324+torbuntu at openjdk.java.net Wed Jan 13 13:01:30 2021 From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Wed, 13 Jan 2021 13:01:30 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> Message-ID: On Tue, 25 Aug 2020 14:12:14 GMT, Thiago Milczarek Sayao wrote: > I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 13 13:01:33 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 13 Jan 2021 13:01:33 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> Message-ID: On Mon, 21 Sep 2020 23:40:50 GMT, Thiago Milczarek Sayao wrote: >>> I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). >> >> Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. > > Rebased onto "master" and squashed commits. Tested on Ubuntu 20.04 756 tests completed, 6 failed, 110 skipped Failed: test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED java.lang.AssertionError: Timeout: Failed to receive onAction callback. at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) at test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) at test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) test.robot.javafx.scene.RobotTest > testKeyPress FAILED org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> at org.junit.Assert.assertEquals(Assert.java:123) at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > resizeColumnToFitContentTest FAILED java.lang.AssertionError: resizeColumnToFitContent failed at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(62,62,62,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) For some reason the html report is not being generated. **Second run:** 756 tests completed, 4 failed, 110 skipped test.robot.javafx.scene.RobotTest > testKeyPress FAILED org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> at org.junit.Assert.assertEquals(Assert.java:123) at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From arapte at openjdk.java.net Wed Jan 13 15:49:02 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 13 Jan 2021 15:49:02 GMT Subject: RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop [v2] In-Reply-To: References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: <_WspzdBkwyza8rSz1HNEyTCk_6A2V1uRPjEkkGhDTKI=.18efe47f-7ea7-441e-8939-509ef4c8a9ea@github.com> On Sat, 9 Jan 2021 16:54:10 GMT, Jose Pereda wrote: >> As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: >> >> - DropTargetListener, on dragEnter >> - DragGestureListener, on dragGestureRecognized or >> - MouseHandler, processing a right mouse click (these two are mutually exclusive). >> >> This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. >> >> The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Avoid setting gestureStarted if there is a drag gesture in process Change and sanity testing with it looks good. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/372 From nlisker at openjdk.java.net Thu Jan 14 00:34:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 14 Jan 2021 00:34:04 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 00:31:54 GMT, Kevin Rushforth wrote: > I see you renamed the setPointLight method in the Prism pipelines to setLight and got rid of the separate setSpotLight method. Have you considered whether this will still make sense when adding a DirectionalLight? Maybe leaving the name as setPointLight is best? Directional light will be simulated as a point light at an infinite distance, making the illumination appear like it's coming from one direction, so I made this renaming deliberately. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From johan.vos at gluonhq.com Thu Jan 14 13:53:00 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 14 Jan 2021 14:53:00 +0100 Subject: cleanup obsolete code Message-ID: Hi, We currently have a number of GLFactory implementations in the ES2 Prism pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use X11, and systems with monocle can use either egl, X11, fb,... but that is then managed by the MonocleGLFactory. Unless these files are used, I suggest they are removed (that is the java classes and the native code). The static initialiser of GLFactory will then have only 2 choices for factoryClasses that can be used on Linux: X11, or Monocle. The latter is only used if the System Property `embedded` is set to `monocle` (as checked in PlatformUtil). We can replace this in a check on the Glass platform (which is already done in Glass: com.sun.glass.ui.Platform will check the value of `glass.platform`, and Monocle will be selected in Glass in case the value is set to `Monocle`.) Clearly, Prism and Glass are 2 different things, but I personally would prefer to have the decision whether to use X11 or Monocle to be based on this `glass.platform` property rather then on yet another property (`embedded`) that is apart from this not used for anything else. I will create an issue for this, but in case I'm missing something, please let me know. - Johan From kevin.rushforth at oracle.com Thu Jan 14 23:42:34 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Jan 2021 15:42:34 -0800 Subject: cleanup obsolete code In-Reply-To: References: Message-ID: <844ae1b6-53ad-192b-ee9b-10d48604ec0f@oracle.com> Hi Johan, This seems like good cleanup. I can't think of any problems that would arise. -- Kevin On 1/14/2021 5:53 AM, Johan Vos wrote: > Hi, > > We currently have a number of GLFactory implementations in the ES2 Prism > pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use > X11, and systems with monocle can use either egl, X11, fb,... but that is > then managed by the MonocleGLFactory. > > Unless these files are used, I suggest they are removed (that is the java > classes and the native code). > > The static initialiser of GLFactory will then have only 2 choices for > factoryClasses that can be used on Linux: X11, or Monocle. The latter is > only used if the System Property `embedded` is set to `monocle` (as checked > in PlatformUtil). We can replace this in a check on the Glass platform > (which is already done in Glass: com.sun.glass.ui.Platform will check the > value of `glass.platform`, and Monocle will be selected in Glass in case > the value is set to `Monocle`.) > Clearly, Prism and Glass are 2 different things, but I personally would > prefer to have the decision whether to use X11 or Monocle to be based on > this `glass.platform` property rather then on yet another property > (`embedded`) that is apart from this not used for anything else. > > I will create an issue for this, but in case I'm missing something, please > let me know. > > - Johan From jpereda at openjdk.java.net Fri Jan 15 09:13:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 15 Jan 2021 09:13:08 GMT Subject: Integrated: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop In-Reply-To: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> References: <2YYU56q264VttiOGXGv26CBwwmgqp4ukfMKdnt_J1w0=.332a7c8b-f96c-4832-8960-384fdc8c7d5b@github.com> Message-ID: On Wed, 6 Jan 2021 16:20:47 GMT, Jose Pereda wrote: > As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: > > - DropTargetListener, on dragEnter > - DragGestureListener, on dragGestureRecognized or > - MouseHandler, processing a right mouse click (these two are mutually exclusive). > > This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE. > > The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR. This pull request has now been integrated. Changeset: d8bb41d1 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/d8bb41d1 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/372 From kevin.rushforth at oracle.com Fri Jan 15 17:39:33 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Jan 2021 09:39:33 -0800 Subject: New API to read Caps-Lock and Num-Lock state Message-ID: For JavaFX 17, I am planning to add a minor enhancement to read the state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, and maybe Scroll-Lock (although I might defer the latter to a future version since it will be more difficult to test, and doesn't seem as useful). This is currently tracked by JDK-8259680 [1]. The proposed API would be something like: ??? ??? public static boolean Platform::isKeyLocked(KeyCode keyCode); One question is whether we should throw an exception if the key state cannot be read on a particular system (e.g., Num Lock on macOS), which is what the similar AWT API does. I don't have a strong opinion on that poont, although I wouldn't want to throw an exception if the keyboard doesn't have the key in question, as long the system is able to read the state accurately. Comments are welcome. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8259680 From sproket at videotron.ca Sat Jan 16 03:07:02 2021 From: sproket at videotron.ca (Dan Howard) Date: Fri, 15 Jan 2021 22:07:02 -0500 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: <0T4dlmNeMwKa80T4elPL07@videotron.ca> References: <0T4dlmNeMwKa80T4elPL07@videotron.ca> Message-ID: <7239f104-d1df-aa71-cdec-fb9396f7f99f@videotron.ca> Please no additional exceptions. It only makes me think in a platform specific way. Better would be an extra method that can I can check if key exists. But if the key exists or is not pressed it should simply return false. IMO On 1/15/2021 12:39 PM, Kevin Rushforth wrote: > For JavaFX 17, I am planning to add a minor enhancement to read the > state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, > and maybe Scroll-Lock (although I might defer the latter to a future > version since it will be more difficult to test, and doesn't seem as > useful). > > This is currently tracked by JDK-8259680 [1]. > > The proposed API would be something like: > > ??? ??? public static boolean Platform::isKeyLocked(KeyCode keyCode); > > One question is whether we should throw an exception if the key state > cannot be read on a particular system (e.g., Num Lock on macOS), which > is what the similar AWT API does. I don't have a strong opinion on > that poont, although I wouldn't want to throw an exception if the > keyboard doesn't have the key in question, as long the system is able > to read the state accurately. > > Comments are welcome. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > From nlisker at gmail.com Sat Jan 16 04:34:14 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 16 Jan 2021 06:34:14 +0200 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: <7239f104-d1df-aa71-cdec-fb9396f7f99f@videotron.ca> References: <0T4dlmNeMwKa80T4elPL07@videotron.ca> <7239f104-d1df-aa71-cdec-fb9396f7f99f@videotron.ca> Message-ID: What do the methods that check if a mouse button is pressed, but the button does not exist on the mouse, do? Maybe it's a hint for consistency. On Sat, Jan 16, 2021 at 5:09 AM Dan Howard wrote: > Please no additional exceptions. It only makes me think in a platform > specific way. Better would be an extra method that can I can check if > key exists. But if the key exists or is not pressed it should simply > return false. IMO > > On 1/15/2021 12:39 PM, Kevin Rushforth wrote: > > For JavaFX 17, I am planning to add a minor enhancement to read the > > state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, > > and maybe Scroll-Lock (although I might defer the latter to a future > > version since it will be more difficult to test, and doesn't seem as > > useful). > > > > This is currently tracked by JDK-8259680 [1]. > > > > The proposed API would be something like: > > > > public static boolean Platform::isKeyLocked(KeyCode keyCode); > > > > One question is whether we should throw an exception if the key state > > cannot be read on a particular system (e.g., Num Lock on macOS), which > > is what the similar AWT API does. I don't have a strong opinion on > > that poont, although I wouldn't want to throw an exception if the > > keyboard doesn't have the key in question, as long the system is able > > to read the state accurately. > > > > Comments are welcome. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > > From nlisker at openjdk.java.net Sat Jan 16 05:19:25 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 16 Jan 2021 05:19:25 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v8] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'nlisker/8234920_Add_SpotLight_to_the_selection_of_3D_light_types' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types - Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/e699127d..db109b28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=06-07 Stats: 31 lines in 4 files changed: 20 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From jonathan at jonathangiles.net Sat Jan 16 08:46:37 2021 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Sat, 16 Jan 2021 21:46:37 +1300 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: Message-ID: Hi friends, Just to throw out an alternate API approach (which I would not go anywhere near close to saying is a better approach), we could consider a three-value enum getter API: public static KeyLockState Platform::getKeyLockState(KeyCode keyCode); Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } I'll be the first to argue against yet another enum, but I wanted to throw this out there as an alternate approach that avoids the needs for checked exceptions (which is what I assume is meant by 'throw an exception', as opposed to throwing a runtime exception). -- Jonathan On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth wrote: > For JavaFX 17, I am planning to add a minor enhancement to read the > state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, and > maybe Scroll-Lock (although I might defer the latter to a future version > since it will be more difficult to test, and doesn't seem as useful). > > This is currently tracked by JDK-8259680 [1]. > > The proposed API would be something like: > > public static boolean Platform::isKeyLocked(KeyCode keyCode); > > One question is whether we should throw an exception if the key state > cannot be read on a particular system (e.g., Num Lock on macOS), which > is what the similar AWT API does. I don't have a strong opinion on that > poont, although I wouldn't want to throw an exception if the keyboard > doesn't have the key in question, as long the system is able to read the > state accurately. > > Comments are welcome. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > From nlisker at gmail.com Sat Jan 16 11:47:22 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 16 Jan 2021 13:47:22 +0200 Subject: cleanup obsolete code In-Reply-To: References: Message-ID: Out of curiosity, what were they used for? On Thu, Jan 14, 2021 at 3:54 PM Johan Vos wrote: > Hi, > > We currently have a number of GLFactory implementations in the ES2 Prism > pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use > X11, and systems with monocle can use either egl, X11, fb,... but that is > then managed by the MonocleGLFactory. > > Unless these files are used, I suggest they are removed (that is the java > classes and the native code). > > The static initialiser of GLFactory will then have only 2 choices for > factoryClasses that can be used on Linux: X11, or Monocle. The latter is > only used if the System Property `embedded` is set to `monocle` (as checked > in PlatformUtil). We can replace this in a check on the Glass platform > (which is already done in Glass: com.sun.glass.ui.Platform will check the > value of `glass.platform`, and Monocle will be selected in Glass in case > the value is set to `Monocle`.) > Clearly, Prism and Glass are 2 different things, but I personally would > prefer to have the decision whether to use X11 or Monocle to be based on > this `glass.platform` property rather then on yet another property > (`embedded`) that is apart from this not used for anything else. > > I will create an issue for this, but in case I'm missing something, please > let me know. > > - Johan > From johan.vos at gluonhq.com Sat Jan 16 12:26:47 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 16 Jan 2021 13:26:47 +0100 Subject: cleanup obsolete code In-Reply-To: References: Message-ID: I would guess those were used before Monocle was introduced. On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker wrote: > Out of curiosity, what were they used for? > > On Thu, Jan 14, 2021 at 3:54 PM Johan Vos wrote: > >> Hi, >> >> We currently have a number of GLFactory implementations in the ES2 Prism >> pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use >> X11, and systems with monocle can use either egl, X11, fb,... but that is >> then managed by the MonocleGLFactory. >> >> Unless these files are used, I suggest they are removed (that is the java >> classes and the native code). >> >> The static initialiser of GLFactory will then have only 2 choices for >> factoryClasses that can be used on Linux: X11, or Monocle. The latter is >> only used if the System Property `embedded` is set to `monocle` (as >> checked >> in PlatformUtil). We can replace this in a check on the Glass platform >> (which is already done in Glass: com.sun.glass.ui.Platform will check the >> value of `glass.platform`, and Monocle will be selected in Glass in case >> the value is set to `Monocle`.) >> Clearly, Prism and Glass are 2 different things, but I personally would >> prefer to have the decision whether to use X11 or Monocle to be based on >> this `glass.platform` property rather then on yet another property >> (`embedded`) that is apart from this not used for anything else. >> >> I will create an issue for this, but in case I'm missing something, please >> let me know. >> >> - Johan >> > From nlisker at openjdk.java.net Sat Jan 16 14:41:12 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 16 Jan 2021 14:41:12 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 23:09:19 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update to the gl pipeline > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 125: > >> 123: NGPointLight.getDefaultQa(), >> 124: NGPointLight.getDefaultMaxRange(), >> 125: 0, 0, 1, 0, 180, 0); // simulating point light); > > Do you think it is worth using defined constants for these? I had these constants already in `NGPointLight`, but they were accessed in a non-static way so the `setLight` method could be unified for `NGPointLight`s. Since there is no instance of a light in this case (we are artificially making a light), we would need to access them also statically. I made this change, but I'm not sure if it's designed properly. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Sat Jan 16 16:41:03 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jan 2021 08:41:03 -0800 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: Message-ID: Hi Jonathan, Thanks for the suggestion. I thought about it as well. We could do that, but it seems like overkill. I'll reconsider if enough others favor the idea. As for the exception, my thinking is to use UnsupportedOperationException, which is what the equivalent AWT method uses. FWIW, I don't generally like checked exceptions; we don't define any such exceptions in JavaFX and I wouldn't want to start now. -- Kevin On 1/16/2021 12:46 AM, Jonathan Giles wrote: > Hi friends, > > Just to throw out an alternate API approach (which I would not go > anywhere near close to saying is a better approach), we could consider > a three-value enum getter API: > > public static KeyLockState Platform::getKeyLockState(KeyCode keyCode); > > Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } > > I'll be the first to argue against yet another enum, but I wanted to > throw this out there as an alternate approach that avoids the needs > for checked exceptions (which is what I assume is meant by 'throw an > exception', as opposed to throwing a runtime exception). > > -- Jonathan > > On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth > > wrote: > > For JavaFX 17, I am planning to add a minor enhancement to read the > state of the keyboard lock keys, specifically, Caps-Lock, > Num-Lock, and > maybe Scroll-Lock (although I might defer the latter to a future > version > since it will be more difficult to test, and doesn't seem as useful). > > This is currently tracked by JDK-8259680 [1]. > > The proposed API would be something like: > > ???? ??? public static boolean Platform::isKeyLocked(KeyCode keyCode); > > One question is whether we should throw an exception if the key state > cannot be read on a particular system (e.g., Num Lock on macOS), > which > is what the similar AWT API does. I don't have a strong opinion on > that > poont, although I wouldn't want to throw an exception if the keyboard > doesn't have the key in question, as long the system is able to > read the > state accurately. > > Comments are welcome. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > From kevin.rushforth at oracle.com Sat Jan 16 16:41:26 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jan 2021 08:41:26 -0800 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: <0T4dlmNeMwKa80T4elPL07@videotron.ca> <7239f104-d1df-aa71-cdec-fb9396f7f99f@videotron.ca> Message-ID: Let's separate out the questions of? what to do if we can't reliably get the state of a key on a particular platform versus what to do if the key isn't present (on a system where we could get the state if it were there). The latter case seems clear: returning false is the right answer, since it is an accurate representation of the state. This is somewhat similar to reporting the state of the 5th button on a 3-button mouse (it's not a perfect analogy, since we're talking about sticky state here, not transient state that is part of the event in question, but close enough). The former case is the more interesting one, since we could report inaccurate information, so simply returning false seems wrong. I think we have three choices: 1) throw an exception; 2) provide a separate query method; or 3) return a three-value enum rather than a boolean (e.g., OFF, ON, UNKNOWN). My current thinking is to throw a exception, but I'd like to hear other opinions as well. One other question is whether we should include SCROLL_LOCK along with CAPS_LOCK and NUM_LOCK. I included it below, but I'm leaning towards removing it, since it is not a common key state these days (and it isn't clear what an app would do with the information). Here is the currently proposed javadoc for comment: ??? /** ???? * Returns a flag indicating whether the key corresponding to {@code keyCode} ???? * is in the locked or "on" state. ???? * {@code keyCode} must be one of: {@link KeyCode#CAPS}, ???? * {@link KeyCode#NUM_LOCK}, or {@link KeyCode#SCROLL_LOCK}. ???? * If the underlying system is not able to determine the state of the ???? * specified {@code keyCode}, an UnsupportedOperationException is thrown. ???? * If the keyboard attached to the system doesn't have the specified key, ???? * {@code false} is returned. ???? * This method must be called on the JavaFX Application thread. ???? * ???? * @param keyCode the KeyCode of the lock state to query ???? * ???? * @throws IllegalArgumentException if {@code keyCode} is not one of the ???? * valid KeyCode values. ???? * ???? * @throws UnsupportedOperationException if the underlying system is not ???? * able to determine the state of the specified? {@code keyCode} ???? * ???? * @throws IllegalStateException if this method is called on a thread ???? * other than the JavaFX Application Thread. ???? * ???? * @return {@code true} if the key corresponding to {@code keyCode} ???? * is in the locked or "on" state; {@code false} otherwise ???? * ???? * @since 17 ???? */ ??? public static boolean isKeyLocked(KeyCode keyCode); -- Kevin On 1/15/2021 8:34 PM, Nir Lisker wrote: > What do the methods that check if a mouse button is pressed, but the > button does not exist on the mouse, do? > Maybe it's a hint for consistency. > > On Sat, Jan 16, 2021 at 5:09 AM Dan Howard > wrote: > > Please no additional exceptions. It only makes me think in a platform > specific way. Better would be an extra method that can I can check if > key exists. But if the key exists or is not pressed it should simply > return false. IMO > > On 1/15/2021 12:39 PM, Kevin Rushforth wrote: > > For JavaFX 17, I am planning to add a minor enhancement to read the > > state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, > > and maybe Scroll-Lock (although I might defer the latter to a > future > > version since it will be more difficult to test, and doesn't > seem as > > useful). > > > > This is currently tracked by JDK-8259680 [1]. > > > > The proposed API would be something like: > > > > ??? ??? public static boolean Platform::isKeyLocked(KeyCode > keyCode); > > > > One question is whether we should throw an exception if the key > state > > cannot be read on a particular system (e.g., Num Lock on macOS), > which > > is what the similar AWT API does. I don't have a strong opinion on > > that poont, although I wouldn't want to throw an exception if the > > keyboard doesn't have the key in question, as long the system is > able > > to read the state accurately. > > > > Comments are welcome. > > > > -- Kevin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > > > From jvos at openjdk.java.net Sat Jan 16 18:39:36 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 16 Jan 2021 18:39:36 GMT Subject: RFR: 8259864: Cleanup unused Prism files Message-ID: Fix for JDK-8259864 Remove java and native files that are not used/maintained in prism configurations. ------------- Commit messages: - Remove unused prism files. Changes: https://git.openjdk.java.net/jfx/pull/378/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=378&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259864 Stats: 2060 lines in 19 files changed: 0 ins; 2059 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/378.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/378/head:pull/378 PR: https://git.openjdk.java.net/jfx/pull/378 From kcr at openjdk.java.net Sat Jan 16 21:25:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 16 Jan 2021 21:25:33 GMT Subject: RFR: 8259864: Cleanup unused Prism files In-Reply-To: References: Message-ID: <4l-vbYjWL83OcVDjXkqAJWEhru30JuXFddbn3PyPehg=.0789c781-fde6-4358-ab5b-75b483ed2dc4@github.com> On Sat, 16 Jan 2021 18:35:42 GMT, Johan Vos wrote: > Fix for JDK-8259864 > Remove java and native files that are not used/maintained in prism configurations. There are references to `eglx11` and `eglfb` in some of the `buildSrc/*.gradle` files. I recommend cleaning those up, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/378 From kcr at openjdk.java.net Sat Jan 16 21:32:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 16 Jan 2021 21:32:30 GMT Subject: RFR: 8259864: Cleanup unused Prism files In-Reply-To: <4l-vbYjWL83OcVDjXkqAJWEhru30JuXFddbn3PyPehg=.0789c781-fde6-4358-ab5b-75b483ed2dc4@github.com> References: <4l-vbYjWL83OcVDjXkqAJWEhru30JuXFddbn3PyPehg=.0789c781-fde6-4358-ab5b-75b483ed2dc4@github.com> Message-ID: On Sat, 16 Jan 2021 21:22:21 GMT, Kevin Rushforth wrote: >> Fix for JDK-8259864 >> Remove java and native files that are not used/maintained in prism configurations. > > There are references to `eglx11` and `eglfb` in some of the `buildSrc/*.gradle` files. I recommend cleaning those up, too. I also see references in `ES2Pipeline.java`, `GLFactory.java` and `PrismES2Defs.h`. Should those be removed, too? ------------- PR: https://git.openjdk.java.net/jfx/pull/378 From thevenet.fred at free.fr Sun Jan 17 11:28:32 2021 From: thevenet.fred at free.fr (Frederic Thevenet) Date: Sun, 17 Jan 2021 12:28:32 +0100 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: Message-ID: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> Hi, From the perspective of the application developer, I think throwing a runtime exception if the key does not exists on a given platform is potentially risky, as the API provided no hints that a given key might not exists an other platforms, and this oversight will only manifest itself at runtime, on said platform. With the other two proposed solution (three-state return and Checked exception) the API itself reminds its would be consumer that they should consider a case where the operation is invalid. I'm personally not keen on checked exceptions in such a scenario either, as it would require an extra API to check for the existence of a given key on the current platform, or condemn developers to implement conditional logic via exception catching (or require developer to know what specific keys exists on what platform before-hand to do the check). Given all that, my personal preference would go to a three state return solution. On that topic, is there anything that would preclude the use of an Optional to represent these three states, if we want to avoid introducing new enums?? It seems to me its semantics aligns quite nicely with the problem at hand. Fred On 16/01/2021 17:41, Kevin Rushforth wrote: > Hi Jonathan, > > Thanks for the suggestion. I thought about it as well. We could do > that, but it seems like overkill. I'll reconsider if enough others > favor the idea. As for the exception, my thinking is to use > UnsupportedOperationException, which is what the equivalent AWT method > uses. FWIW, I don't generally like checked exceptions; we don't define > any such exceptions in JavaFX and I wouldn't want to start now. > > -- Kevin > > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: >> Hi friends, >> >> Just to throw out an alternate API approach (which I would not go >> anywhere near close to saying is a better approach), we could >> consider a three-value enum getter API: >> >> public static KeyLockState Platform::getKeyLockState(KeyCode keyCode); >> >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } >> >> I'll be the first to argue against yet another enum, but I wanted to >> throw this out there as an alternate approach that avoids the needs >> for checked exceptions (which is what I assume is meant by 'throw an >> exception', as opposed to throwing a runtime exception). >> >> -- Jonathan >> >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth >> > wrote: >> >> ??? For JavaFX 17, I am planning to add a minor enhancement to read the >> ??? state of the keyboard lock keys, specifically, Caps-Lock, >> ??? Num-Lock, and >> ??? maybe Scroll-Lock (although I might defer the latter to a future >> ??? version >> ??? since it will be more difficult to test, and doesn't seem as >> useful). >> >> ??? This is currently tracked by JDK-8259680 [1]. >> >> ??? The proposed API would be something like: >> >> ??? ???? ??? public static boolean Platform::isKeyLocked(KeyCode >> keyCode); >> >> ??? One question is whether we should throw an exception if the key >> state >> ??? cannot be read on a particular system (e.g., Num Lock on macOS), >> ??? which >> ??? is what the similar AWT API does. I don't have a strong opinion on >> ??? that >> ??? poont, although I wouldn't want to throw an exception if the >> keyboard >> ??? doesn't have the key in question, as long the system is able to >> ??? read the >> ??? state accurately. >> >> ??? Comments are welcome. >> >> ??? -- Kevin >> >> ??? [1] https://bugs.openjdk.java.net/browse/JDK-8259680 >> ??? >> > From lbourges at openjdk.java.net Sun Jan 17 15:55:12 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 17 Jan 2021 15:55:12 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) Message-ID: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Changes: - Removed single-precision Marlin renderer - class name refactoring - fix prism - copyright year ------------- Commit messages: - Removed single-precision Marlin renderer + class name refactoring + fix prism + copyright year Changes: https://git.openjdk.java.net/jfx/pull/379/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=379&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259718 Stats: 10875 lines in 32 files changed: 6 ins; 9689 del; 1180 mod Patch: https://git.openjdk.java.net/jfx/pull/379.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/379/head:pull/379 PR: https://git.openjdk.java.net/jfx/pull/379 From lbourges at openjdk.java.net Sun Jan 17 16:00:21 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 17 Jan 2021 16:00:21 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) [v2] In-Reply-To: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Message-ID: > Changes: > - Removed single-precision Marlin renderer > - class name refactoring > - fix prism > - copyright year Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: fixed ClipShapeTest (marlin detection) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/379/files - new: https://git.openjdk.java.net/jfx/pull/379/files/07686e63..b5589b50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=379&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=379&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/379.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/379/head:pull/379 PR: https://git.openjdk.java.net/jfx/pull/379 From jonathan at jonathangiles.net Sun Jan 17 17:31:04 2021 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Mon, 18 Jan 2021 06:31:04 +1300 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> Message-ID: A method returning Optional should never return null, as that undoes the contract that Optional is supposed to represent, which is to avoid NPEs by never being null itself, only empty in the absence of a returned value. For this reason, an Optional should be considered two state rather than three state. -- Jonathan (Tapped on a touch device) On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, wrote: > Hi, > > From the perspective of the application developer, I think throwing a > runtime exception if the key does not exists on a given platform is > potentially risky, as the API provided no hints that a given key might > not exists an other platforms, and this oversight will only manifest > itself at runtime, on said platform. > > With the other two proposed solution (three-state return and Checked > exception) the API itself reminds its would be consumer that they should > consider a case where the operation is invalid. > > I'm personally not keen on checked exceptions in such a scenario either, > as it would require an extra API to check for the existence of a given > key on the current platform, or condemn developers to implement > conditional logic via exception catching (or require developer to know > what specific keys exists on what platform before-hand to do the check). > > Given all that, my personal preference would go to a three state return > solution. > > On that topic, is there anything that would preclude the use of an > Optional to represent these three states, if we want to avoid > introducing new enums? It seems to me its semantics aligns quite nicely > with the problem at hand. > > Fred > > > On 16/01/2021 17:41, Kevin Rushforth wrote: > > Hi Jonathan, > > > > Thanks for the suggestion. I thought about it as well. We could do > > that, but it seems like overkill. I'll reconsider if enough others > > favor the idea. As for the exception, my thinking is to use > > UnsupportedOperationException, which is what the equivalent AWT method > > uses. FWIW, I don't generally like checked exceptions; we don't define > > any such exceptions in JavaFX and I wouldn't want to start now. > > > > -- Kevin > > > > > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: > >> Hi friends, > >> > >> Just to throw out an alternate API approach (which I would not go > >> anywhere near close to saying is a better approach), we could > >> consider a three-value enum getter API: > >> > >> public static KeyLockState Platform::getKeyLockState(KeyCode keyCode); > >> > >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } > >> > >> I'll be the first to argue against yet another enum, but I wanted to > >> throw this out there as an alternate approach that avoids the needs > >> for checked exceptions (which is what I assume is meant by 'throw an > >> exception', as opposed to throwing a runtime exception). > >> > >> -- Jonathan > >> > >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth > >> > wrote: > >> > >> For JavaFX 17, I am planning to add a minor enhancement to read the > >> state of the keyboard lock keys, specifically, Caps-Lock, > >> Num-Lock, and > >> maybe Scroll-Lock (although I might defer the latter to a future > >> version > >> since it will be more difficult to test, and doesn't seem as > >> useful). > >> > >> This is currently tracked by JDK-8259680 [1]. > >> > >> The proposed API would be something like: > >> > >> public static boolean Platform::isKeyLocked(KeyCode > >> keyCode); > >> > >> One question is whether we should throw an exception if the key > >> state > >> cannot be read on a particular system (e.g., Num Lock on macOS), > >> which > >> is what the similar AWT API does. I don't have a strong opinion on > >> that > >> poont, although I wouldn't want to throw an exception if the > >> keyboard > >> doesn't have the key in question, as long the system is able to > >> read the > >> state accurately. > >> > >> Comments are welcome. > >> > >> -- Kevin > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > >> > >> > > > From nlisker at gmail.com Sun Jan 17 17:59:06 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 17 Jan 2021 19:59:06 +0200 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> Message-ID: I think Frederic meant that the Optional is empty in the case where you can't reliably get the state of the key, otherwise the true and false values are for the on and off states. The Optional itself is never null. On Sun, Jan 17, 2021 at 7:31 PM Jonathan Giles wrote: > A method returning Optional should never return null, as that undoes the > contract that Optional is supposed to represent, which is to avoid NPEs by > never being null itself, only empty in the absence of a returned value. For > this reason, an Optional should be considered two state rather than three > state. > > -- Jonathan > (Tapped on a touch device) > > On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, > wrote: > > > Hi, > > > > From the perspective of the application developer, I think throwing a > > runtime exception if the key does not exists on a given platform is > > potentially risky, as the API provided no hints that a given key might > > not exists an other platforms, and this oversight will only manifest > > itself at runtime, on said platform. > > > > With the other two proposed solution (three-state return and Checked > > exception) the API itself reminds its would be consumer that they should > > consider a case where the operation is invalid. > > > > I'm personally not keen on checked exceptions in such a scenario either, > > as it would require an extra API to check for the existence of a given > > key on the current platform, or condemn developers to implement > > conditional logic via exception catching (or require developer to know > > what specific keys exists on what platform before-hand to do the check). > > > > Given all that, my personal preference would go to a three state return > > solution. > > > > On that topic, is there anything that would preclude the use of an > > Optional to represent these three states, if we want to avoid > > introducing new enums? It seems to me its semantics aligns quite nicely > > with the problem at hand. > > > > Fred > > > > > > On 16/01/2021 17:41, Kevin Rushforth wrote: > > > Hi Jonathan, > > > > > > Thanks for the suggestion. I thought about it as well. We could do > > > that, but it seems like overkill. I'll reconsider if enough others > > > favor the idea. As for the exception, my thinking is to use > > > UnsupportedOperationException, which is what the equivalent AWT method > > > uses. FWIW, I don't generally like checked exceptions; we don't define > > > any such exceptions in JavaFX and I wouldn't want to start now. > > > > > > -- Kevin > > > > > > > > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: > > >> Hi friends, > > >> > > >> Just to throw out an alternate API approach (which I would not go > > >> anywhere near close to saying is a better approach), we could > > >> consider a three-value enum getter API: > > >> > > >> public static KeyLockState Platform::getKeyLockState(KeyCode keyCode); > > >> > > >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } > > >> > > >> I'll be the first to argue against yet another enum, but I wanted to > > >> throw this out there as an alternate approach that avoids the needs > > >> for checked exceptions (which is what I assume is meant by 'throw an > > >> exception', as opposed to throwing a runtime exception). > > >> > > >> -- Jonathan > > >> > > >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth > > >> > > wrote: > > >> > > >> For JavaFX 17, I am planning to add a minor enhancement to read > the > > >> state of the keyboard lock keys, specifically, Caps-Lock, > > >> Num-Lock, and > > >> maybe Scroll-Lock (although I might defer the latter to a future > > >> version > > >> since it will be more difficult to test, and doesn't seem as > > >> useful). > > >> > > >> This is currently tracked by JDK-8259680 [1]. > > >> > > >> The proposed API would be something like: > > >> > > >> public static boolean Platform::isKeyLocked(KeyCode > > >> keyCode); > > >> > > >> One question is whether we should throw an exception if the key > > >> state > > >> cannot be read on a particular system (e.g., Num Lock on macOS), > > >> which > > >> is what the similar AWT API does. I don't have a strong opinion on > > >> that > > >> poont, although I wouldn't want to throw an exception if the > > >> keyboard > > >> doesn't have the key in question, as long the system is able to > > >> read the > > >> state accurately. > > >> > > >> Comments are welcome. > > >> > > >> -- Kevin > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > >> > > >> > > > > > > From jonathan at jonathangiles.net Sun Jan 17 18:09:01 2021 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Mon, 18 Jan 2021 07:09:01 +1300 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> Message-ID: Ah, got it! That teach me to reply before 7am and before the coffee hits! This might be a reasonable approach in that case. Certainly it does away with the need for the enum and the exception. -- Jonathan (Tapped on a touch device) On Mon, 18 Jan 2021, 6:59 am Nir Lisker, wrote: > I think Frederic meant that the Optional is empty in the case where you > can't reliably get the state of the key, otherwise the true and false > values are for the on and off states. The Optional itself is never null. > > On Sun, Jan 17, 2021 at 7:31 PM Jonathan Giles > wrote: > >> A method returning Optional should never return null, as that undoes the >> contract that Optional is supposed to represent, which is to avoid NPEs by >> never being null itself, only empty in the absence of a returned value. >> For >> this reason, an Optional should be considered two state rather than three >> state. >> >> -- Jonathan >> (Tapped on a touch device) >> >> On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, >> wrote: >> >> > Hi, >> > >> > From the perspective of the application developer, I think throwing a >> > runtime exception if the key does not exists on a given platform is >> > potentially risky, as the API provided no hints that a given key might >> > not exists an other platforms, and this oversight will only manifest >> > itself at runtime, on said platform. >> > >> > With the other two proposed solution (three-state return and Checked >> > exception) the API itself reminds its would be consumer that they should >> > consider a case where the operation is invalid. >> > >> > I'm personally not keen on checked exceptions in such a scenario either, >> > as it would require an extra API to check for the existence of a given >> > key on the current platform, or condemn developers to implement >> > conditional logic via exception catching (or require developer to know >> > what specific keys exists on what platform before-hand to do the check). >> > >> > Given all that, my personal preference would go to a three state return >> > solution. >> > >> > On that topic, is there anything that would preclude the use of an >> > Optional to represent these three states, if we want to avoid >> > introducing new enums? It seems to me its semantics aligns quite nicely >> > with the problem at hand. >> > >> > Fred >> > >> > >> > On 16/01/2021 17:41, Kevin Rushforth wrote: >> > > Hi Jonathan, >> > > >> > > Thanks for the suggestion. I thought about it as well. We could do >> > > that, but it seems like overkill. I'll reconsider if enough others >> > > favor the idea. As for the exception, my thinking is to use >> > > UnsupportedOperationException, which is what the equivalent AWT method >> > > uses. FWIW, I don't generally like checked exceptions; we don't define >> > > any such exceptions in JavaFX and I wouldn't want to start now. >> > > >> > > -- Kevin >> > > >> > > >> > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: >> > >> Hi friends, >> > >> >> > >> Just to throw out an alternate API approach (which I would not go >> > >> anywhere near close to saying is a better approach), we could >> > >> consider a three-value enum getter API: >> > >> >> > >> public static KeyLockState Platform::getKeyLockState(KeyCode >> keyCode); >> > >> >> > >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } >> > >> >> > >> I'll be the first to argue against yet another enum, but I wanted to >> > >> throw this out there as an alternate approach that avoids the needs >> > >> for checked exceptions (which is what I assume is meant by 'throw an >> > >> exception', as opposed to throwing a runtime exception). >> > >> >> > >> -- Jonathan >> > >> >> > >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth >> > >> > >> wrote: >> > >> >> > >> For JavaFX 17, I am planning to add a minor enhancement to read >> the >> > >> state of the keyboard lock keys, specifically, Caps-Lock, >> > >> Num-Lock, and >> > >> maybe Scroll-Lock (although I might defer the latter to a future >> > >> version >> > >> since it will be more difficult to test, and doesn't seem as >> > >> useful). >> > >> >> > >> This is currently tracked by JDK-8259680 [1]. >> > >> >> > >> The proposed API would be something like: >> > >> >> > >> public static boolean Platform::isKeyLocked(KeyCode >> > >> keyCode); >> > >> >> > >> One question is whether we should throw an exception if the key >> > >> state >> > >> cannot be read on a particular system (e.g., Num Lock on macOS), >> > >> which >> > >> is what the similar AWT API does. I don't have a strong opinion >> on >> > >> that >> > >> poont, although I wouldn't want to throw an exception if the >> > >> keyboard >> > >> doesn't have the key in question, as long the system is able to >> > >> read the >> > >> state accurately. >> > >> >> > >> Comments are welcome. >> > >> >> > >> -- Kevin >> > >> >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680 >> > >> >> > >> >> > > >> > >> > From thevenet.fred at free.fr Sun Jan 17 18:09:42 2021 From: thevenet.fred at free.fr (Frederic Thevenet) Date: Sun, 17 Jan 2021 19:09:42 +0100 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> Message-ID: <1ba154d0-59fc-a8ba-fdd0-06cddad70795@free.fr> I realize that my suggestion was somewhat unclear, apology about that. I wasn't suggesting that we return null to count as the third state, but indeed that we leverage the isPresent state of the optional, alongside with the two states provided by the Boolean, e.g: isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> { ??? // The num_lock key exists on the current platform ??? if (locked){ ??????? // React to the key being locked ??? } else { ??????? // Or to the key not being locked ??? }); On 17/01/2021 18:31, Jonathan Giles wrote: > A method returning Optional should never return null, as that undoes > the contract that Optional is supposed to represent, which is to avoid > NPEs by never being null itself, only empty in the absence of a > returned value. For this reason, an Optional should be considered two > state rather than three state. > > -- Jonathan > (Tapped on a touch device) > > On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, > > wrote: > > Hi, > > ?From the perspective of the application developer, I think > throwing a > runtime exception if the key does not exists on a given platform is > potentially risky, as the API provided no hints that a given key > might > not exists an other platforms, and this oversight will only manifest > itself at runtime, on said platform. > > With the other two proposed solution (three-state return and Checked > exception) the API itself reminds its would be consumer that they > should > consider a case where the operation is invalid. > > I'm personally not keen on checked exceptions in such a scenario > either, > as it would require an extra API to check for the existence of a > given > key on the current platform, or condemn developers to implement > conditional logic via exception catching (or require developer to > know > what specific keys exists on what platform before-hand to do the > check). > > Given all that, my personal preference would go to a three state > return > solution. > > On that topic, is there anything that would preclude the use of an > Optional to represent these three states, if we want to > avoid > introducing new enums?? It seems to me its semantics aligns quite > nicely > with the problem at hand. > > Fred > > > On 16/01/2021 17:41, Kevin Rushforth wrote: > > Hi Jonathan, > > > > Thanks for the suggestion. I thought about it as well. We could do > > that, but it seems like overkill. I'll reconsider if enough others > > favor the idea. As for the exception, my thinking is to use > > UnsupportedOperationException, which is what the equivalent AWT > method > > uses. FWIW, I don't generally like checked exceptions; we don't > define > > any such exceptions in JavaFX and I wouldn't want to start now. > > > > -- Kevin > > > > > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: > >> Hi friends, > >> > >> Just to throw out an alternate API approach (which I would not go > >> anywhere near close to saying is a better approach), we could > >> consider a three-value enum getter API: > >> > >> public static KeyLockState Platform::getKeyLockState(KeyCode > keyCode); > >> > >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } > >> > >> I'll be the first to argue against yet another enum, but I > wanted to > >> throw this out there as an alternate approach that avoids the > needs > >> for checked exceptions (which is what I assume is meant by > 'throw an > >> exception', as opposed to throwing a runtime exception). > >> > >> -- Jonathan > >> > >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth > >> > >> wrote: > >> > >> ??? For JavaFX 17, I am planning to add a minor enhancement to > read the > >> ??? state of the keyboard lock keys, specifically, Caps-Lock, > >> ??? Num-Lock, and > >> ??? maybe Scroll-Lock (although I might defer the latter to a > future > >> ??? version > >> ??? since it will be more difficult to test, and doesn't seem as > >> useful). > >> > >> ??? This is currently tracked by JDK-8259680 [1]. > >> > >> ??? The proposed API would be something like: > >> > >> ??? ???? ??? public static boolean Platform::isKeyLocked(KeyCode > >> keyCode); > >> > >> ??? One question is whether we should throw an exception if the > key > >> state > >> ??? cannot be read on a particular system (e.g., Num Lock on > macOS), > >> ??? which > >> ??? is what the similar AWT API does. I don't have a strong > opinion on > >> ??? that > >> ??? poont, although I wouldn't want to throw an exception if the > >> keyboard > >> ??? doesn't have the key in question, as long the system is able to > >> ??? read the > >> ??? state accurately. > >> > >> ??? Comments are welcome. > >> > >> ??? -- Kevin > >> > >> ??? [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > >> ??? > > >> > > > From tom.schindl at bestsolution.at Sun Jan 17 20:55:39 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 17 Jan 2021 21:55:39 +0100 Subject: Integrated: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: <52052143-B2E2-44CA-919F-EC358C40ACB8@mac.com> References: <52052143-B2E2-44CA-919F-EC358C40ACB8@mac.com> Message-ID: Hi Kevin, I today saw this tweet by Alex Blewitt [1] in my twitter feed and a possible fix without the de/reactivation. So I thought I would bring it up here as well. Tom [1] https://twitter.com/alblue/status/1350877893979746305 Am 07.12.20 um 16:58 schrieb Bruce Johnson: > >> On Dec 7, 2020, at 10:33 AM, Kevin Rushforth wrote: >> >> On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: >> >>> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >>> >>> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >>> >>> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >>> >>> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >>> >>> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >>> >>> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. >> >> This pull request has now been integrated. >> >> Changeset: e7dbdfcb >> Author: Kevin Rushforth >> URL: https://git.openjdk.java.net/jfx/commit/e7dbdfcb >> Stats: 109 lines in 4 files changed: 94 ins; 0 del; 15 mod >> >> 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina >> >> Reviewed-by: jvos, aghaisas >> >> ------------- >> >> PR: https://git.openjdk.java.net/jfx/pull/361 > > > It would be useful, at least to me, to see a brief comment in this email thread about why this approach (which results in the application flashing) is necessary. Why does JavaFX require this approach, or is there an alternative, but more complex approach that could ultimately be used in later releases. I?d just like to be able to look back in the email thread when I (or the users of my software) see the flash to understand why it's there. > > Bruce > From nlisker at gmail.com Mon Jan 18 08:20:32 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 18 Jan 2021 10:20:32 +0200 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: <1ba154d0-59fc-a8ba-fdd0-06cddad70795@free.fr> References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> <1ba154d0-59fc-a8ba-fdd0-06cddad70795@free.fr> Message-ID: Looking at the use case for this request, which is to warn the user while typing in password fields, I tried to write some simple code for it using the Optional approach: Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK); result.ifPresentOrElse(on -> label.setText("Caps Lock is " + (on ? "on" : "off")), () -> label.setText("Check Caps Lock")); In practical terms, a key event listener would need to be added to the password field to react to Caps Lock presses, and that will call the code above. I think that this is the best option. On Sun, Jan 17, 2021 at 8:10 PM Frederic Thevenet wrote: > I realize that my suggestion was somewhat unclear, apology about that. > > I wasn't suggesting that we return null to count as the third state, but > indeed that we leverage the isPresent state of the optional, alongside > with the two states provided by the Boolean, e.g: > > isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> { > // The num_lock key exists on the current platform > if (locked){ > // React to the key being locked > } else { > // Or to the key not being locked > }); > > > On 17/01/2021 18:31, Jonathan Giles wrote: > > A method returning Optional should never return null, as that undoes > > the contract that Optional is supposed to represent, which is to avoid > > NPEs by never being null itself, only empty in the absence of a > > returned value. For this reason, an Optional should be considered two > > state rather than three state. > > > > -- Jonathan > > (Tapped on a touch device) > > > > On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, > > > wrote: > > > > Hi, > > > > From the perspective of the application developer, I think > > throwing a > > runtime exception if the key does not exists on a given platform is > > potentially risky, as the API provided no hints that a given key > > might > > not exists an other platforms, and this oversight will only manifest > > itself at runtime, on said platform. > > > > With the other two proposed solution (three-state return and Checked > > exception) the API itself reminds its would be consumer that they > > should > > consider a case where the operation is invalid. > > > > I'm personally not keen on checked exceptions in such a scenario > > either, > > as it would require an extra API to check for the existence of a > > given > > key on the current platform, or condemn developers to implement > > conditional logic via exception catching (or require developer to > > know > > what specific keys exists on what platform before-hand to do the > > check). > > > > Given all that, my personal preference would go to a three state > > return > > solution. > > > > On that topic, is there anything that would preclude the use of an > > Optional to represent these three states, if we want to > > avoid > > introducing new enums? It seems to me its semantics aligns quite > > nicely > > with the problem at hand. > > > > Fred > > > > > > On 16/01/2021 17:41, Kevin Rushforth wrote: > > > Hi Jonathan, > > > > > > Thanks for the suggestion. I thought about it as well. We could do > > > that, but it seems like overkill. I'll reconsider if enough others > > > favor the idea. As for the exception, my thinking is to use > > > UnsupportedOperationException, which is what the equivalent AWT > > method > > > uses. FWIW, I don't generally like checked exceptions; we don't > > define > > > any such exceptions in JavaFX and I wouldn't want to start now. > > > > > > -- Kevin > > > > > > > > > On 1/16/2021 12:46 AM, Jonathan Giles wrote: > > >> Hi friends, > > >> > > >> Just to throw out an alternate API approach (which I would not go > > >> anywhere near close to saying is a better approach), we could > > >> consider a three-value enum getter API: > > >> > > >> public static KeyLockState Platform::getKeyLockState(KeyCode > > keyCode); > > >> > > >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } > > >> > > >> I'll be the first to argue against yet another enum, but I > > wanted to > > >> throw this out there as an alternate approach that avoids the > > needs > > >> for checked exceptions (which is what I assume is meant by > > 'throw an > > >> exception', as opposed to throwing a runtime exception). > > >> > > >> -- Jonathan > > >> > > >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth > > >> > > > >> wrote: > > >> > > >> For JavaFX 17, I am planning to add a minor enhancement to > > read the > > >> state of the keyboard lock keys, specifically, Caps-Lock, > > >> Num-Lock, and > > >> maybe Scroll-Lock (although I might defer the latter to a > > future > > >> version > > >> since it will be more difficult to test, and doesn't seem as > > >> useful). > > >> > > >> This is currently tracked by JDK-8259680 [1]. > > >> > > >> The proposed API would be something like: > > >> > > >> public static boolean Platform::isKeyLocked(KeyCode > > >> keyCode); > > >> > > >> One question is whether we should throw an exception if the > > key > > >> state > > >> cannot be read on a particular system (e.g., Num Lock on > > macOS), > > >> which > > >> is what the similar AWT API does. I don't have a strong > > opinion on > > >> that > > >> poont, although I wouldn't want to throw an exception if the > > >> keyboard > > >> doesn't have the key in question, as long the system is able > to > > >> read the > > >> state accurately. > > >> > > >> Comments are welcome. > > >> > > >> -- Kevin > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680 > > > > >> > > > > >> > > > > > > From johan.vos at gluonhq.com Mon Jan 18 08:38:17 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 18 Jan 2021 09:38:17 +0100 Subject: cleanup obsolete code In-Reply-To: References: Message-ID: Related to this question, there is the comment from Kevin about removing references to es2-eglfb/es2-eglx11 in other files, e.g. ES2Pipeline.java [1] While I believe this is a good idea, it opens room for more cleanup (or at least more consistency): In some cases, library names indicate a configuration. For example, prism-es2-monocle indicates that the glass-platform monocle is used. In most cases though, the library names do not contain this information. On mac/linux/windows/ios, we simply use prism-es2 . Obviously, the contents of the library vary for the different platforms, but this is taken care of by the build process. This inconsistency leads to avoidable logic in the Java classes, e.g. in ES2Pipeline. After cleaning up for the unused egl{fb,x11} variants, there will still be a check about which library should be loaded: if the glass variant is monocle, prism-es2-monocle is loaded. In all other cases, prism-es2 is loaded. I think the name of the library should either always contain the glass variant name, or never. I have a preference for removing the variant in the name completely, as this will allow us to remove even more logic in the .java files. [1] https://github.com/openjdk/jfx/pull/378#issuecomment-761673755 On Sat, Jan 16, 2021 at 1:26 PM Johan Vos wrote: > I would guess those were used before Monocle was introduced. > > On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker wrote: > >> Out of curiosity, what were they used for? >> >> On Thu, Jan 14, 2021 at 3:54 PM Johan Vos wrote: >> >>> Hi, >>> >>> We currently have a number of GLFactory implementations in the ES2 Prism >>> pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use >>> X11, and systems with monocle can use either egl, X11, fb,... but that is >>> then managed by the MonocleGLFactory. >>> >>> Unless these files are used, I suggest they are removed (that is the java >>> classes and the native code). >>> >>> The static initialiser of GLFactory will then have only 2 choices for >>> factoryClasses that can be used on Linux: X11, or Monocle. The latter is >>> only used if the System Property `embedded` is set to `monocle` (as >>> checked >>> in PlatformUtil). We can replace this in a check on the Glass platform >>> (which is already done in Glass: com.sun.glass.ui.Platform will check the >>> value of `glass.platform`, and Monocle will be selected in Glass in case >>> the value is set to `Monocle`.) >>> Clearly, Prism and Glass are 2 different things, but I personally would >>> prefer to have the decision whether to use X11 or Monocle to be based on >>> this `glass.platform` property rather then on yet another property >>> (`embedded`) that is apart from this not used for anything else. >>> >>> I will create an issue for this, but in case I'm missing something, >>> please >>> let me know. >>> >>> - Johan >>> >> From jvos at openjdk.java.net Mon Jan 18 09:02:58 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 18 Jan 2021 09:02:58 GMT Subject: RFR: 8259864: Cleanup unused Prism files [v2] In-Reply-To: References: Message-ID: > Fix for JDK-8259864 > Remove java and native files that are not used/maintained in prism configurations. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Process review comments. Remove more references to egl{fb/x11} ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/378/files - new: https://git.openjdk.java.net/jfx/pull/378/files/f795f19e..49cee7a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=378&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=378&range=00-01 Stats: 52 lines in 5 files changed: 0 ins; 50 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/378.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/378/head:pull/378 PR: https://git.openjdk.java.net/jfx/pull/378 From jvos at openjdk.java.net Mon Jan 18 09:02:59 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 18 Jan 2021 09:02:59 GMT Subject: RFR: 8259864: Cleanup unused Prism files In-Reply-To: References: <4l-vbYjWL83OcVDjXkqAJWEhru30JuXFddbn3PyPehg=.0789c781-fde6-4358-ab5b-75b483ed2dc4@github.com> Message-ID: On Sat, 16 Jan 2021 21:30:17 GMT, Kevin Rushforth wrote: >> There are references to `eglx11` and `eglfb` in some of the `buildSrc/*.gradle` files. I recommend cleaning those up, too. > > I also see references in `ES2Pipeline.java`, `GLFactory.java` and `PrismES2Defs.h`. Should those be removed, too? I removed more references. Note that not all references are removed, since e.g. the flag EGL_FB might also be passed to the c compiler when compiling for non-eglfb systems. This requires another cleanup. ------------- PR: https://git.openjdk.java.net/jfx/pull/378 From dlemmermann at gmail.com Mon Jan 18 10:12:21 2021 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 18 Jan 2021 11:12:21 +0100 Subject: RFE: Shape Intersection Message-ID: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> I just noticed that there is no ?intuitive? API to check whether two shapes intersect with each other. The only way (I think) to do it is as follows: Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() != -1 If this is indeed the case I would like to propose that a method shall be added called ?boolean Shape.intersects(Shape,Shape"). See also: https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx Dirk From nlisker at gmail.com Mon Jan 18 11:41:45 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 18 Jan 2021 13:41:45 +0200 Subject: RFE: Shape Intersection In-Reply-To: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: If this is to be implemented in JavaFX, then it's better to do (not tested): 1. Extract the intersection computation from Shape.intersect private static Area intersectionArea(Shape shape1, Shape shape2) { Area result = shape1.getTransformedArea(); return result.intersect(shape2.getTransformedArea()); } 2. Shape.intersect becomes public static Shape Shape.intersects(Shape shape1, Shape shape2) { var intersectionArea = intersectionArea(Shape shape1, Shape shape2); return createFromGeomShape(intersectionArea); } 3. Add the new method Shape.intersects public static boolean Shape.intersects( Shape shape1, Shape shape2) { var intersectionArea = intersectionArea(Shape shape1, Shape shape2); return !intersectionArea.isEmpty(); } Regardless, I wonder why the geometry methods were implemented as static methods. Why not shape1.intersect(shape2)? I assume the new method should follow these, but on a clean slate I think I would have used the non-static approach. Another thing I would think about is whether it makes sense to just one method or is it a part of a more comprehensive shape geometry bundle. Is "intersects?" the only question we would like to ask? - Nir On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann wrote: > I just noticed that there is no ?intuitive? API to check whether two > shapes intersect with each other. The only way (I think) to do it is as > follows: > > Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() != -1 > > If this is indeed the case I would like to propose that a method shall be > added called ?boolean Shape.intersects(Shape,Shape"). > > See also: > https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx > < > https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx > > > > Dirk > > > From almaslvl at gmail.com Mon Jan 18 11:55:50 2021 From: almaslvl at gmail.com (Almas Baimagambetov) Date: Mon, 18 Jan 2021 11:55:50 +0000 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: If we are adding non-static methods, then the whole "bundle" should probably be included for consistency. E.g. union, subtract, etc. On Mon, 18 Jan 2021, 11:43 am Nir Lisker, wrote: > If this is to be implemented in JavaFX, then it's better to do (not > tested): > > 1. Extract the intersection computation from Shape.intersect > > private static Area intersectionArea(Shape shape1, Shape shape2) { > Area result = shape1.getTransformedArea(); > return result.intersect(shape2.getTransformedArea()); > } > > 2. Shape.intersect becomes > > public static Shape Shape.intersects(Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return createFromGeomShape(intersectionArea); > } > > 3. Add the new method Shape.intersects > > public static boolean Shape.intersects( Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return !intersectionArea.isEmpty(); > } > > Regardless, I wonder why the geometry methods were implemented as static > methods. Why not shape1.intersect(shape2)? I assume the new method should > follow these, but on a clean slate I think I would have used the non-static > approach. > > Another thing I would think about is whether it makes sense to just one > method or is it a part of a more comprehensive shape geometry bundle. Is > "intersects?" the only question we would like to ask? > > - Nir > > On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann > wrote: > > > I just noticed that there is no ?intuitive? API to check whether two > > shapes intersect with each other. The only way (I think) to do it is as > > follows: > > > > Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() != > -1 > > > > If this is indeed the case I would like to propose that a method shall be > > added called ?boolean Shape.intersects(Shape,Shape"). > > > > See also: > > > https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx > > < > > > https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx > > > > > > > Dirk > > > > > > > From Jim.Kay at snclavalin.com Mon Jan 18 11:57:34 2021 From: Jim.Kay at snclavalin.com (Kay, Jim) Date: Mon, 18 Jan 2021 11:57:34 +0000 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: I have used the JTS library (https://github.com/locationtech/jts) a lot over the years; this is my 'go to' library for all 2D geometry routines. It is very extensive and very well written by it?s main author Martin Davis. This library has entities such as Geometry, LineString, Polygon etc and shows how to do all geometric operations such as: intersect, intersection, difference, union, touches, overlaps etc. It would be great to incorporate this type of library into JavaFX. I know it would require a bit of a rewrite but I think it would be worth it! Jim Kay -----Original Message----- From: openjfx-dev On Behalf Of Nir Lisker Sent: 18 January 2021 11:42 To: Dirk Lemmermann Cc: OpenJFX Subject: Re: RFE: Shape Intersection If this is to be implemented in JavaFX, then it's better to do (not tested): 1. Extract the intersection computation from Shape.intersect private static Area intersectionArea(Shape shape1, Shape shape2) { Area result = shape1.getTransformedArea(); return result.intersect(shape2.getTransformedArea()); } 2. Shape.intersect becomes public static Shape Shape.intersects(Shape shape1, Shape shape2) { var intersectionArea = intersectionArea(Shape shape1, Shape shape2); return createFromGeomShape(intersectionArea); } 3. Add the new method Shape.intersects public static boolean Shape.intersects( Shape shape1, Shape shape2) { var intersectionArea = intersectionArea(Shape shape1, Shape shape2); return !intersectionArea.isEmpty(); } Regardless, I wonder why the geometry methods were implemented as static methods. Why not shape1.intersect(shape2)? I assume the new method should follow these, but on a clean slate I think I would have used the non-static approach. Another thing I would think about is whether it makes sense to just one method or is it a part of a more comprehensive shape geometry bundle. Is "intersects?" the only question we would like to ask? - Nir On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann wrote: > I just noticed that there is no ?intuitive? API to check whether two > shapes intersect with each other. The only way (I think) to do it is > as > follows: > > Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() > != -1 > > If this is indeed the case I would like to propose that a method shall > be added called ?boolean Shape.intersects(Shape,Shape"). > > See also: > https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com > _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx > &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 > AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM > lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= > < > https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com > _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx > &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 > AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM > lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= > > > > Dirk > > > From mp at jugs.org Mon Jan 18 12:10:36 2021 From: mp at jugs.org (Michael Paus) Date: Mon, 18 Jan 2021 13:10:36 +0100 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: I just mentioned JTS in a tweet myself (https://twitter.com/MichaelPaus/status/1351133904409915395) but I think it would be a mistake to integrate that into JavaFX for various reasons. The main problem is that Java never provided and used a graphics system independent geometry and math library. That's why I like JTS because it is not tied to any specific graphics system and therefore it is much easier for me to get my code running on different graphics systems. The latest being Jetbrains Compose and Skija. Michael Am 18.01.21 um 12:57 schrieb Kay, Jim: > I have used the JTS library (https://github.com/locationtech/jts) a lot over the years; this is my 'go to' library for all 2D geometry routines. It is very extensive and very well written by it?s main author Martin Davis. This library has entities such as Geometry, LineString, Polygon etc and shows how to do all geometric operations such as: intersect, intersection, difference, union, touches, overlaps etc. > It would be great to incorporate this type of library into JavaFX. I know it would require a bit of a rewrite but I think it would be worth it! > Jim Kay > > -----Original Message----- > From: openjfx-dev On Behalf Of Nir Lisker > Sent: 18 January 2021 11:42 > To: Dirk Lemmermann > Cc: OpenJFX > Subject: Re: RFE: Shape Intersection > > If this is to be implemented in JavaFX, then it's better to do (not tested): > > 1. Extract the intersection computation from Shape.intersect > > private static Area intersectionArea(Shape shape1, Shape shape2) { > Area result = shape1.getTransformedArea(); > return result.intersect(shape2.getTransformedArea()); > } > > 2. Shape.intersect becomes > > public static Shape Shape.intersects(Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return createFromGeomShape(intersectionArea); > } > > 3. Add the new method Shape.intersects > > public static boolean Shape.intersects( Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return !intersectionArea.isEmpty(); > } > > Regardless, I wonder why the geometry methods were implemented as static methods. Why not shape1.intersect(shape2)? I assume the new method should follow these, but on a clean slate I think I would have used the non-static approach. > > Another thing I would think about is whether it makes sense to just one method or is it a part of a more comprehensive shape geometry bundle. Is "intersects?" the only question we would like to ask? > > - Nir > > On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann > wrote: > >> I just noticed that there is no ?intuitive? API to check whether two >> shapes intersect with each other. The only way (I think) to do it is >> as >> follows: >> >> Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() >> != -1 >> >> If this is indeed the case I would like to propose that a method shall >> be added called ?boolean Shape.intersects(Shape,Shape"). >> >> See also: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com >> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx >> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 >> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM >> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >> < >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com >> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx >> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 >> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM >> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >> Dirk >> >> >> From tbee at tbee.org Mon Jan 18 12:46:16 2021 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 18 Jan 2021 13:46:16 +0100 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: I'm curious about the reasons, because reinventing the wheel does not seem to be smart as well... On 18-1-2021 13:10, Michael Paus wrote: > I just mentioned JTS in a tweet myself (https://twitter.com/MichaelPaus/status/1351133904409915395) > but I think it would be a mistake to integrate that into JavaFX for various reasons. The main problem is > that Java never provided and used a graphics system independent geometry and math library. That's why > I like JTS because it is not tied to any specific graphics system and therefore it is much easier for me to > get my code running on different graphics systems. The latest being Jetbrains Compose and Skija. > Michael > > Am 18.01.21 um 12:57 schrieb Kay, Jim: >> I have used the JTS library (https://github.com/locationtech/jts) a lot over the years; this is my 'go to' library for all 2D geometry routines. It is very extensive and very well written by it?s main author Martin Davis. This library has entities such as Geometry, LineString, Polygon etc and shows how to do all geometric operations such as: intersect, intersection, difference, union, touches, overlaps etc. >> It would be great to incorporate this type of library into JavaFX. I know it would require a bit of a rewrite but I think it would be worth it! >> Jim Kay >> >> -----Original Message----- >> From: openjfx-dev On Behalf Of Nir Lisker >> Sent: 18 January 2021 11:42 >> To: Dirk Lemmermann >> Cc: OpenJFX >> Subject: Re: RFE: Shape Intersection >> >> If this is to be implemented in JavaFX, then it's better to do (not tested): >> >> 1. Extract the intersection computation from Shape.intersect >> >> private static Area intersectionArea(Shape shape1, Shape shape2) { >> ???? Area result = shape1.getTransformedArea(); >> ???? return result.intersect(shape2.getTransformedArea()); >> } >> >> 2.? Shape.intersect becomes >> >> public static Shape Shape.intersects(Shape shape1, Shape shape2) { >> ???? var intersectionArea = intersectionArea(Shape shape1, Shape shape2); >> ???? return createFromGeomShape(intersectionArea); >> } >> >> 3. Add the new method Shape.intersects >> >> public static boolean Shape.intersects( Shape shape1, Shape shape2) { >> ???? var intersectionArea = intersectionArea(Shape shape1, Shape shape2); >> ???? return !intersectionArea.isEmpty(); >> } >> >> Regardless, I wonder why the geometry methods were implemented as static methods. Why not shape1.intersect(shape2)? I assume the new method should follow these, but on a clean slate I think I would have used the non-static approach. >> >> Another thing I would think about is whether it makes sense to just one method or is it a part of a more comprehensive shape geometry bundle. Is "intersects?" the only question we would like to ask? >> >> - Nir >> >> On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann >> wrote: >> >>> I just noticed that there is no ?intuitive? API to check whether two >>> shapes intersect with each other. The only way (I think) to do it is >>> as >>> follows: >>> >>> Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() >>> != -1 >>> >>> If this is indeed the case I would like to propose that a method shall >>> be added called ?boolean Shape.intersects(Shape,Shape"). >>> >>> See also: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com >>> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx >>> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 >>> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM >>> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >>> < >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com >>> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx >>> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 >>> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM >>> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >>> Dirk >>> >>> >>> > From Jim.Kay at snclavalin.com Mon Jan 18 12:46:51 2021 From: Jim.Kay at snclavalin.com (Kay, Jim) Date: Mon, 18 Jan 2021 12:46:51 +0000 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: Michael I think I agree, I would not like to see JavaFX incorporated into JTS, for the reasons you mention. But I would like to see JTS, or at least the structure and logic incorporated into JavaFX. This would then give the JavaFX world a useful set of tools that would greatly extend its rather limited existing functionality. Jim -----Original Message----- From: openjfx-dev On Behalf Of Michael Paus Sent: 18 January 2021 12:11 To: openjfx-dev at openjdk.java.net Subject: Re: RFE: Shape Intersection I just mentioned JTS in a tweet myself (https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_MichaelPaus_status_1351133904409915395&d=DwIDaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1AetrfAv2Mw&m=biryV2m8HpSXo8rw1EUe0QmCrmnlN1upcYHdN8w-DpM&s=2wIFL0e2ON6mlE3HXVcSvuook7ipK-x_O62Br__7FxM&e= ) but I think it would be a mistake to integrate that into JavaFX for various reasons. The main problem is that Java never provided and used a graphics system independent geometry and math library. That's why I like JTS because it is not tied to any specific graphics system and therefore it is much easier for me to get my code running on different graphics systems. The latest being Jetbrains Compose and Skija. Michael Am 18.01.21 um 12:57 schrieb Kay, Jim: > I have used the JTS library (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_locationtech_jts&d=DwIDaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1AetrfAv2Mw&m=biryV2m8HpSXo8rw1EUe0QmCrmnlN1upcYHdN8w-DpM&s=nvXIMl8MC1jFYb7rGgQYyrRZ5r7Y00q-1F2s51hGZR0&e= ) a lot over the years; this is my 'go to' library for all 2D geometry routines. It is very extensive and very well written by it?s main author Martin Davis. This library has entities such as Geometry, LineString, Polygon etc and shows how to do all geometric operations such as: intersect, intersection, difference, union, touches, overlaps etc. > It would be great to incorporate this type of library into JavaFX. I know it would require a bit of a rewrite but I think it would be worth it! > Jim Kay > > -----Original Message----- > From: openjfx-dev On Behalf Of Nir > Lisker > Sent: 18 January 2021 11:42 > To: Dirk Lemmermann > Cc: OpenJFX > Subject: Re: RFE: Shape Intersection > > If this is to be implemented in JavaFX, then it's better to do (not tested): > > 1. Extract the intersection computation from Shape.intersect > > private static Area intersectionArea(Shape shape1, Shape shape2) { > Area result = shape1.getTransformedArea(); > return result.intersect(shape2.getTransformedArea()); > } > > 2. Shape.intersect becomes > > public static Shape Shape.intersects(Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return createFromGeomShape(intersectionArea); > } > > 3. Add the new method Shape.intersects > > public static boolean Shape.intersects( Shape shape1, Shape shape2) { > var intersectionArea = intersectionArea(Shape shape1, Shape shape2); > return !intersectionArea.isEmpty(); } > > Regardless, I wonder why the geometry methods were implemented as static methods. Why not shape1.intersect(shape2)? I assume the new method should follow these, but on a clean slate I think I would have used the non-static approach. > > Another thing I would think about is whether it makes sense to just one method or is it a part of a more comprehensive shape geometry bundle. Is "intersects?" the only question we would like to ask? > > - Nir > > On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann > > wrote: > >> I just noticed that there is no ?intuitive? API to check whether two >> shapes intersect with each other. The only way (I think) to do it is >> as >> follows: >> >> Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() >> != -1 >> >> If this is indeed the case I would like to propose that a method >> shall be added called ?boolean Shape.intersects(Shape,Shape"). >> >> See also: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.co >> m >> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavaf >> x >> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF >> 1 >> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcM >> M >> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >> < >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.co >> m >> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavaf >> x >> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF >> 1 >> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcM >> M >> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= >> Dirk >> >> >> From almaslvl at gmail.com Mon Jan 18 12:50:35 2021 From: almaslvl at gmail.com (Almas Baimagambetov) Date: Mon, 18 Jan 2021 12:50:35 +0000 Subject: RFE: Shape Intersection In-Reply-To: References: <329B9EDA-50B6-4675-9BCB-4DC68A1BA797@gmail.com> Message-ID: If I'm not mistaken, the original proposal was only for API, rather a change in implementation. On Mon, 18 Jan 2021, 12:47 pm Tom Eugelink, wrote: > I'm curious about the reasons, because reinventing the wheel does not seem > to be smart as well... > > > On 18-1-2021 13:10, Michael Paus wrote: > > I just mentioned JTS in a tweet myself ( > https://twitter.com/MichaelPaus/status/1351133904409915395) > > but I think it would be a mistake to integrate that into JavaFX for > various reasons. The main problem is > > that Java never provided and used a graphics system independent geometry > and math library. That's why > > I like JTS because it is not tied to any specific graphics system and > therefore it is much easier for me to > > get my code running on different graphics systems. The latest being > Jetbrains Compose and Skija. > > Michael > > > > Am 18.01.21 um 12:57 schrieb Kay, Jim: > >> I have used the JTS library (https://github.com/locationtech/jts) a > lot over the years; this is my 'go to' library for all 2D geometry > routines. It is very extensive and very well written by it?s main author > Martin Davis. This library has entities such as Geometry, LineString, > Polygon etc and shows how to do all geometric operations such as: > intersect, intersection, difference, union, touches, overlaps etc. > >> It would be great to incorporate this type of library into JavaFX. I > know it would require a bit of a rewrite but I think it would be worth it! > >> Jim Kay > >> > >> -----Original Message----- > >> From: openjfx-dev On Behalf Of Nir > Lisker > >> Sent: 18 January 2021 11:42 > >> To: Dirk Lemmermann > >> Cc: OpenJFX > >> Subject: Re: RFE: Shape Intersection > >> > >> If this is to be implemented in JavaFX, then it's better to do (not > tested): > >> > >> 1. Extract the intersection computation from Shape.intersect > >> > >> private static Area intersectionArea(Shape shape1, Shape shape2) { > >> Area result = shape1.getTransformedArea(); > >> return result.intersect(shape2.getTransformedArea()); > >> } > >> > >> 2. Shape.intersect becomes > >> > >> public static Shape Shape.intersects(Shape shape1, Shape shape2) { > >> var intersectionArea = intersectionArea(Shape shape1, Shape > shape2); > >> return createFromGeomShape(intersectionArea); > >> } > >> > >> 3. Add the new method Shape.intersects > >> > >> public static boolean Shape.intersects( Shape shape1, Shape shape2) { > >> var intersectionArea = intersectionArea(Shape shape1, Shape > shape2); > >> return !intersectionArea.isEmpty(); > >> } > >> > >> Regardless, I wonder why the geometry methods were implemented as > static methods. Why not shape1.intersect(shape2)? I assume the new method > should follow these, but on a clean slate I think I would have used the > non-static approach. > >> > >> Another thing I would think about is whether it makes sense to just one > method or is it a part of a more comprehensive shape geometry bundle. Is > "intersects?" the only question we would like to ask? > >> > >> - Nir > >> > >> On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann > > >> wrote: > >> > >>> I just noticed that there is no ?intuitive? API to check whether two > >>> shapes intersect with each other. The only way (I think) to do it is > >>> as > >>> follows: > >>> > >>> Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() > >>> != -1 > >>> > >>> If this is indeed the case I would like to propose that a method shall > >>> be added called ?boolean Shape.intersects(Shape,Shape"). > >>> > >>> See also: > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com > >>> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx > >>> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 > >>> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM > >>> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= > >>> < > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com > >>> _questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx > >>> &d=DwIFaQ&c=ukT25UmkSFgENae3bmQPWw&r=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1 > >>> AetrfAv2Mw&m=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y&s=DRGfselPcMM > >>> lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8&e= > >>> Dirk > >>> > >>> > >>> > > > > From nlisker at openjdk.java.net Mon Jan 18 15:11:52 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 18 Jan 2021 15:11:52 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs Message-ID: The usual doc fixes (for OpenJFX 16). Can wait until RDP2 to see if something else comes up. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/380/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252389 Stats: 19 lines in 4 files changed: 1 ins; 1 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/380.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/380/head:pull/380 PR: https://git.openjdk.java.net/jfx/pull/380 From fastegal at openjdk.java.net Mon Jan 18 15:32:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 18 Jan 2021 15:32:42 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <7obiyksiibdmp-iljr0KzQMuVTAkO7k1B4_9iHNYkj4=.c49cd8f3-c96b-4513-9097-bde3201dd14c@github.com> On Mon, 18 Jan 2021 15:07:34 GMT, Nir Lisker wrote: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. wondering how small a doc error is small enough to go into this: just noticed that Skinnable talks about "Control" in all of its methods - should be "Skinnable" everywhere (except as example implementation in overview doc), IMO. But then, the overview doc is .. lame as well, so might need its own bug anyway? ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From nlisker at openjdk.java.net Mon Jan 18 15:50:39 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 18 Jan 2021 15:50:39 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: <7obiyksiibdmp-iljr0KzQMuVTAkO7k1B4_9iHNYkj4=.c49cd8f3-c96b-4513-9097-bde3201dd14c@github.com> References: <7obiyksiibdmp-iljr0KzQMuVTAkO7k1B4_9iHNYkj4=.c49cd8f3-c96b-4513-9097-bde3201dd14c@github.com> Message-ID: On Mon, 18 Jan 2021 15:30:03 GMT, Jeanette Winzenburg wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > wondering how small a doc error is small enough to go into this: just noticed that Skinnable talks about "Control" in all of its methods - should be "Skinnable" everywhere (except as example implementation in overview doc), IMO. But then, the overview doc is .. lame as well, so might need its own bug anyway? I don't mind making the "Control" -> "Skinnable" changes if you detail them, but rewriting the class doc should be it's own issue, in which case you can fix these mistakes there as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From fastegal at openjdk.java.net Mon Jan 18 16:16:45 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 18 Jan 2021 16:16:45 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: References: <7obiyksiibdmp-iljr0KzQMuVTAkO7k1B4_9iHNYkj4=.c49cd8f3-c96b-4513-9097-bde3201dd14c@github.com> Message-ID: On Mon, 18 Jan 2021 15:48:20 GMT, Nir Lisker wrote: >> wondering how small a doc error is small enough to go into this: just noticed that Skinnable talks about "Control" in all of its methods - should be "Skinnable" everywhere (except as example implementation in overview doc), IMO. But then, the overview doc is .. lame as well, so might need its own bug anyway? > > I don't mind making the "Control" -> "Skinnable" changes if you detail them, but rewriting the class doc should be it's own issue, in which case you can fix these mistakes there as well. thanks, that's about the lines of my thoughts as well :) Will file a separate doc bug for skinnable cleanup ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From lbourges at openjdk.java.net Tue Jan 19 07:33:42 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 19 Jan 2021 07:33:42 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) In-Reply-To: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Message-ID: On Sun, 17 Jan 2021 15:49:33 GMT, Laurent Bourg?s wrote: > Changes: > - Removed single-precision Marlin renderer > - class name refactoring > - fix prism > - copyright year How to run tests again ? I tried pull commands but it does nothing. ------------- PR: https://git.openjdk.java.net/jfx/pull/379 From kevin.rushforth at oracle.com Tue Jan 19 13:12:10 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Jan 2021 05:12:10 -0800 Subject: New API to read Caps-Lock and Num-Lock state In-Reply-To: References: <8e94ea7a-69cc-5f51-0964-31d156d7a2cc@free.fr> <1ba154d0-59fc-a8ba-fdd0-06cddad70795@free.fr> Message-ID: <9250a988-51a9-4dc7-c045-5e760efde3d2@oracle.com> I also think that the suggestion of using Optional is a very good one, and more clearly expresses the "unknown" case without having to invent a new enum and without the problems that throwing an unchecked exception could cause. Thanks. -- Kevin On 1/18/2021 12:20 AM, Nir Lisker wrote: > Looking at the use case for this request, which is to warn the user while > typing in password fields, I tried to write some simple code for it using > the Optional approach: > > Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK); > result.ifPresentOrElse(on -> label.setText("Caps Lock is " + (on ? > "on" : "off")), > () -> label.setText("Check Caps Lock")); > > In practical terms, a key event listener would need to be added to the > password field to react to Caps Lock presses, and that will call the code > above. > I think that this is the best option. > > On Sun, Jan 17, 2021 at 8:10 PM Frederic Thevenet > wrote: > >> I realize that my suggestion was somewhat unclear, apology about that. >> >> I wasn't suggesting that we return null to count as the third state, but >> indeed that we leverage the isPresent state of the optional, alongside >> with the two states provided by the Boolean, e.g: >> >> isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> { >> // The num_lock key exists on the current platform >> if (locked){ >> // React to the key being locked >> } else { >> // Or to the key not being locked >> }); >> >> >> On 17/01/2021 18:31, Jonathan Giles wrote: >>> A method returning Optional should never return null, as that undoes >>> the contract that Optional is supposed to represent, which is to avoid >>> NPEs by never being null itself, only empty in the absence of a >>> returned value. For this reason, an Optional should be considered two >>> state rather than three state. >>> >>> -- Jonathan >>> (Tapped on a touch device) >>> >>> On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, >>> > wrote: >>> >>> Hi, >>> >>> From the perspective of the application developer, I think >>> throwing a >>> runtime exception if the key does not exists on a given platform is >>> potentially risky, as the API provided no hints that a given key >>> might >>> not exists an other platforms, and this oversight will only manifest >>> itself at runtime, on said platform. >>> >>> With the other two proposed solution (three-state return and Checked >>> exception) the API itself reminds its would be consumer that they >>> should >>> consider a case where the operation is invalid. >>> >>> I'm personally not keen on checked exceptions in such a scenario >>> either, >>> as it would require an extra API to check for the existence of a >>> given >>> key on the current platform, or condemn developers to implement >>> conditional logic via exception catching (or require developer to >>> know >>> what specific keys exists on what platform before-hand to do the >>> check). >>> >>> Given all that, my personal preference would go to a three state >>> return >>> solution. >>> >>> On that topic, is there anything that would preclude the use of an >>> Optional to represent these three states, if we want to >>> avoid >>> introducing new enums? It seems to me its semantics aligns quite >>> nicely >>> with the problem at hand. >>> >>> Fred >>> >>> >>> On 16/01/2021 17:41, Kevin Rushforth wrote: >>> > Hi Jonathan, >>> > >>> > Thanks for the suggestion. I thought about it as well. We could do >>> > that, but it seems like overkill. I'll reconsider if enough others >>> > favor the idea. As for the exception, my thinking is to use >>> > UnsupportedOperationException, which is what the equivalent AWT >>> method >>> > uses. FWIW, I don't generally like checked exceptions; we don't >>> define >>> > any such exceptions in JavaFX and I wouldn't want to start now. >>> > >>> > -- Kevin >>> > >>> > >>> > On 1/16/2021 12:46 AM, Jonathan Giles wrote: >>> >> Hi friends, >>> >> >>> >> Just to throw out an alternate API approach (which I would not go >>> >> anywhere near close to saying is a better approach), we could >>> >> consider a three-value enum getter API: >>> >> >>> >> public static KeyLockState Platform::getKeyLockState(KeyCode >>> keyCode); >>> >> >>> >> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT } >>> >> >>> >> I'll be the first to argue against yet another enum, but I >>> wanted to >>> >> throw this out there as an alternate approach that avoids the >>> needs >>> >> for checked exceptions (which is what I assume is meant by >>> 'throw an >>> >> exception', as opposed to throwing a runtime exception). >>> >> >>> >> -- Jonathan >>> >> >>> >> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth >>> >> >>> >> >> wrote: >>> >> >>> >> For JavaFX 17, I am planning to add a minor enhancement to >>> read the >>> >> state of the keyboard lock keys, specifically, Caps-Lock, >>> >> Num-Lock, and >>> >> maybe Scroll-Lock (although I might defer the latter to a >>> future >>> >> version >>> >> since it will be more difficult to test, and doesn't seem as >>> >> useful). >>> >> >>> >> This is currently tracked by JDK-8259680 [1]. >>> >> >>> >> The proposed API would be something like: >>> >> >>> >> public static boolean Platform::isKeyLocked(KeyCode >>> >> keyCode); >>> >> >>> >> One question is whether we should throw an exception if the >>> key >>> >> state >>> >> cannot be read on a particular system (e.g., Num Lock on >>> macOS), >>> >> which >>> >> is what the similar AWT API does. I don't have a strong >>> opinion on >>> >> that >>> >> poont, although I wouldn't want to throw an exception if the >>> >> keyboard >>> >> doesn't have the key in question, as long the system is able >> to >>> >> read the >>> >> state accurately. >>> >> >>> >> Comments are welcome. >>> >> >>> >> -- Kevin >>> >> >>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8259680 >>> >>> >> >> > >>> >> >>> > >>> From kcr at openjdk.java.net Tue Jan 19 15:06:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 19 Jan 2021 15:06:01 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) In-Reply-To: References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Message-ID: On Tue, 19 Jan 2021 07:30:40 GMT, Laurent Bourg?s wrote: >> Changes: >> - Removed single-precision Marlin renderer >> - class name refactoring >> - fix prism >> - copyright year > > How to run tests again ? I tried pull commands but it does nothing. If you have enabled GitHub actions for your personal fork of `jfx`, then the next time you push a commit to your branch it will run the tests. So you might try pushing an empty commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/379 From lbourges at openjdk.java.net Tue Jan 19 15:06:00 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Tue, 19 Jan 2021 15:06:00 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) [v3] In-Reply-To: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Message-ID: <2C-8Ew2Rz5kANl6j9qz_LhK8jjPlt20DiAlv_vQWbPY=.802f80c2-1004-4675-b8d1-300dbe90994b@github.com> > Changes: > - Removed single-precision Marlin renderer > - class name refactoring > - fix prism > - copyright year Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: updated Version ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/379/files - new: https://git.openjdk.java.net/jfx/pull/379/files/b5589b50..c8accadc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=379&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=379&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/379.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/379/head:pull/379 PR: https://git.openjdk.java.net/jfx/pull/379 From kcr at openjdk.java.net Wed Jan 20 00:26:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Jan 2021 00:26:42 GMT Subject: RFR: 8259864: Cleanup unused Prism files [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 09:02:58 GMT, Johan Vos wrote: >> Fix for JDK-8259864 >> Remove java and native files that are not used/maintained in prism configurations. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process review comments. > Remove more references to egl{fb/x11} Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/378 From jvos at openjdk.java.net Wed Jan 20 07:26:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Jan 2021 07:26:42 GMT Subject: Integrated: 8259864: Cleanup unused Prism files In-Reply-To: References: Message-ID: On Sat, 16 Jan 2021 18:35:42 GMT, Johan Vos wrote: > Fix for JDK-8259864 > Remove java and native files that are not used/maintained in prism configurations. This pull request has now been integrated. Changeset: 9d06bd30 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/9d06bd30 Stats: 2112 lines in 23 files changed: 0 ins; 2109 del; 3 mod 8259864: Cleanup unused Prism files Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/378 From jhendrikx at openjdk.java.net Wed Jan 20 08:48:43 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 20 Jan 2021 08:48:43 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> Message-ID: On Tue, 8 Sep 2020 20:16:20 GMT, Kevin Rushforth wrote: >> @kevinrushforth >> >> I have another working alternative, but won't make a PR for it until it is more clear which direction the TableView / TreeTableView performance fixes are going to take. >> >> The alternative would convert the `treeShowing` property in `Node` into a "lazy" property (something which JavaFX does not support directly at the moment). A lazy property only binds to its dependencies when it is observed itself (so in this specific case, only when PopupWindow or ProgressIndicatorSkin are making use of it). >> >> This means the property stays a part of `NodeHelper` but will only register its listeners on Window and Scene when it is observed itself. Such lazy properties could be of great use in JavaFX in general, not just in this case. > > @hjohn Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: > > 8252935: Add treeShowing listener only when needed So, will this actually get reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From rlichten at openjdk.java.net Wed Jan 20 12:01:55 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 20 Jan 2021 12:01:55 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Message-ID: By using the anchor location facility of PopupWindows we can avoid miscalculation of the menu's height entirely. This fix also cleans up some documentation issues. This fix introduces tests that check the correct positioning (test_position_*) test_position_withCSS reproduces the problem that is fixed with this patch. The other test_position_* cases serve as "proof" that no regressions are introduces. They work before and after the fix is introduced. ------------- Commit messages: - 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS - Merge pull request #1 from openjdk/master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - 8232524: Test cleanup: terminate background thread upon failure. - 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating - ... and 1 more: https://git.openjdk.java.net/jfx/compare/d8bb41d1...48d6453a Changes: https://git.openjdk.java.net/jfx/pull/381/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=381&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228363 Stats: 144 lines in 2 files changed: 115 ins; 14 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/381.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/381/head:pull/381 PR: https://git.openjdk.java.net/jfx/pull/381 From kcr at openjdk.java.net Wed Jan 20 16:39:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Jan 2021 16:39:48 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 11:57:04 GMT, Robert Lichtenberger wrote: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_*) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_* cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. This changes the specification in a way that will require prior discussion,. It also will need a CSR. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From kcr at openjdk.java.net Wed Jan 20 16:42:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Jan 2021 16:42:46 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 16:37:04 GMT, Kevin Rushforth wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_*) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_* cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > This changes the specification in a way that will require prior discussion,. It also will need a CSR. I recommend that you follow the instructions in the earlier comment about pushing these changes to a new branch, resetting your master branch, and creating a new PR from your new branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From rlichten at openjdk.java.net Wed Jan 20 16:46:43 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 20 Jan 2021 16:46:43 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 16:37:04 GMT, Kevin Rushforth wrote: > This changes the specification in a way that will require prior discussion,. It also will need a CSR. My hope is that it really doesn't change the specification in any way. All it should do is fix the bug. What part of the spec do you think this would change? ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From rlichten at openjdk.java.net Wed Jan 20 16:46:45 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 20 Jan 2021 16:46:45 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 16:39:45 GMT, Kevin Rushforth wrote: > I recommend that you follow the instructions in the earlier comment about pushing these changes to a new branch, resetting your master branch, and creating a new PR from your new branch. Ah yes, will try to do so tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From kcr at openjdk.java.net Wed Jan 20 16:52:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Jan 2021 16:52:42 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: <081IWVBgIw_hwqCx75vr5RZ9BhVZVBv2KvohxGOuNL0=.91335d3c-3428-4434-a0ad-0572c39a1f49@github.com> On Wed, 20 Jan 2021 16:44:14 GMT, Robert Lichtenberger wrote: >> I recommend that you follow the instructions in the earlier comment about pushing these changes to a new branch, resetting your master branch, and creating a new PR from your new branch. > >> I recommend that you follow the instructions in the earlier comment about pushing these changes to a new branch, resetting your master branch, and creating a new PR from your new branch. > > Ah yes, will try to do so tomorrow. Regarding the spec change, I was thinking of this section, which you removed: * To clarify the purpose of the {@code hpos} and {@code vpos} parameters, * consider that they are relative to the anchor node. As such, a {@code hpos} * and {@code vpos} of {@code CENTER} would mean that the ContextMenu appears * on top of the anchor, with the (0,0) position of the {@code ContextMenu} * positioned at (0,0) of the anchor. A {@code hpos} of right would then shift * the {@code ContextMenu} such that its top-left (0,0) position would be attached * to the top-right position of the anchor. As you pointed out, the reference to `hpos` and `vpos` is incorrect, but unless I'm missing something, it still seems like the concept still needs to be described. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From kcr at openjdk.java.net Wed Jan 20 18:48:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Jan 2021 18:48:43 GMT Subject: RFR: JDK-8259718 Remove the Marlin rasterizer (single-precision) [v3] In-Reply-To: <2C-8Ew2Rz5kANl6j9qz_LhK8jjPlt20DiAlv_vQWbPY=.802f80c2-1004-4675-b8d1-300dbe90994b@github.com> References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> <2C-8Ew2Rz5kANl6j9qz_LhK8jjPlt20DiAlv_vQWbPY=.802f80c2-1004-4675-b8d1-300dbe90994b@github.com> Message-ID: On Tue, 19 Jan 2021 15:06:00 GMT, Laurent Bourg?s wrote: >> Changes: >> - Removed single-precision Marlin renderer >> - class name refactoring >> - fix prism >> - copyright year > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > updated Version Looks good. As a sanity check to make reviewing the renamed files easier, I split the patch locally into two commits -- one to remove the old single-precision classes and one with the rest of the changes, including the refactoring. This shows the diffs relative to the current double version, and I confirmed that all the refactoring was as expected. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/379 From lbourges at openjdk.java.net Wed Jan 20 19:54:44 2021 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 20 Jan 2021 19:54:44 GMT Subject: Integrated: JDK-8259718 Remove the Marlin rasterizer (single-precision) In-Reply-To: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> References: <8NcQhHjH0no-y3OGzYnr5Xf5jWMExYtBgFvJIW-RUZw=.84c5e8eb-45d7-42ef-a8d5-eb9be61d71ce@github.com> Message-ID: On Sun, 17 Jan 2021 15:49:33 GMT, Laurent Bourg?s wrote: > Changes: > - Removed single-precision Marlin renderer > - class name refactoring > - fix prism > - copyright year This pull request has now been integrated. Changeset: c1b14de9 Author: Laurent Bourg?s URL: https://git.openjdk.java.net/jfx/commit/c1b14de9 Stats: 10877 lines in 33 files changed: 6 ins; 9689 del; 1182 mod 8259718: Remove the Marlin rasterizer (single-precision) Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/379 From kcr at openjdk.java.net Thu Jan 21 00:10:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 00:10:43 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: <469WSEqGhPucVTAr4CbRZuAW6AP0qc6ifpJaHqtx8t8=.7b9589bf-af11-41c0-a381-d39f7d765fa8@github.com> References: <469WSEqGhPucVTAr4CbRZuAW6AP0qc6ifpJaHqtx8t8=.7b9589bf-af11-41c0-a381-d39f7d765fa8@github.com> Message-ID: <-n5iNYUi5keQZlOouIlSCHfqkMYD9nrTg-oWevAUe24=.e5aff852-96bf-41a1-a265-a90c7b9e8f90@github.com> On Mon, 7 Dec 2020 16:21:57 GMT, Kevin Rushforth wrote: >> Marked as reviewed by aghaisas (Reviewer). > > I don't yet know whether there is an alternative that would allow the menubar to work without deactivating the app, but I filed a follow-up bug to track this: > > [JDK-8257835](https://bugs.openjdk.java.net/browse/JDK-8257835): Brief flash in terminal window when launching FX app on macOS > > It seems like it might be possible to fix this, since AWT initialization doesn't run into this. I note that AWT uses an Apple-provided "JavaRuntime Support" (JRS) Framework. We would need to see whether there is something else possible using public macOS APIs. @tomsontom Thanks for letting me know. He reached to me directly as well, so I'll plan to add the information to the follow-on bug, [JDK-8257835](https://bugs.openjdk.java.net/browse/JDK-8257835). ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From ajoseph at openjdk.java.net Thu Jan 21 04:26:04 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 21 Jan 2021 04:26:04 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit Message-ID: Update JavaFX WebKit to GTK WebKit 2.30 (610.2) ------------- Commit messages: - 8259635: Update to 610.2 version of WebKit Changes: https://git.openjdk.java.net/jfx/pull/382/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259635 Stats: 257339 lines in 5451 files changed: 125161 ins; 93742 del; 38436 mod Patch: https://git.openjdk.java.net/jfx/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/382/head:pull/382 PR: https://git.openjdk.java.net/jfx/pull/382 From rlichten at openjdk.java.net Thu Jan 21 06:26:57 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Jan 2021 06:26:57 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_*) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_* cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. Robert Lichtenberger 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. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/381/files - new: https://git.openjdk.java.net/jfx/pull/381/files/48d6453a..d8bb41d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=381&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=381&range=00-01 Stats: 144 lines in 2 files changed: 14 ins; 115 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/381.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/381/head:pull/381 PR: https://git.openjdk.java.net/jfx/pull/381 From rlichten at openjdk.java.net Thu Jan 21 06:26:58 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Jan 2021 06:26:58 GMT Subject: Integrated: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: <3QTuRkjtVq7n-zreqQZ3XmVhFKJs1X1RYp_wQXtXfbA=.42abb90c-6ea8-4085-a023-748ebfc85600@github.com> On Wed, 20 Jan 2021 11:57:04 GMT, Robert Lichtenberger wrote: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_*) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_* cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. This pull request has now been integrated. Changeset: d8bb41d1 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/d8bb41d1 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From rlichten at openjdk.java.net Thu Jan 21 06:40:44 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Jan 2021 06:40:44 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: <081IWVBgIw_hwqCx75vr5RZ9BhVZVBv2KvohxGOuNL0=.91335d3c-3428-4434-a0ad-0572c39a1f49@github.com> References: <081IWVBgIw_hwqCx75vr5RZ9BhVZVBv2KvohxGOuNL0=.91335d3c-3428-4434-a0ad-0572c39a1f49@github.com> Message-ID: On Wed, 20 Jan 2021 16:49:35 GMT, Kevin Rushforth wrote: > Regarding the spec change, I was thinking of this section, which you removed: > > ``` > * To clarify the purpose of the {@code hpos} and {@code vpos} parameters, > * consider that they are relative to the anchor node. As such, a {@code hpos} > * and {@code vpos} of {@code CENTER} would mean that the ContextMenu appears > * on top of the anchor, with the (0,0) position of the {@code ContextMenu} > * positioned at (0,0) of the anchor. A {@code hpos} of right would then shift > * the {@code ContextMenu} such that its top-left (0,0) position would be attached > * to the top-right position of the anchor. > ``` > > As you pointed out, the reference to `hpos` and `vpos` is incorrect, but unless I'm missing something, it still seems like the concept still needs to be described. I assume that a very long time ago, there were hpos and vpos parameters for this method. And that really required an explanation, because then you could e.g. specify hpos=RIGHT and vpos=BOTTOM, which would give a very strange position for the context menu (the top left corner of the menu would be in the bottom right corner of the button). It also was very counter-intuitive that giving CENTER/CENTER for hpos/vpos would put the top left corner of the menu at the top left corner of the button. However all this confusion was ended when Side was used instead of HPos/VPos. At that very moment all the confusing cases went away. No more BOTTOM/RIGHT or CENTER/CENTER placement. So I think we can really just remove the (obsolete) explanation of hPos/vPos. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From rlichten at openjdk.java.net Thu Jan 21 06:46:52 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Jan 2021 06:46:52 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Message-ID: By using the anchor location facility of PopupWindows we can avoid miscalculation of the menu's height entirely. This fix also cleans up some documentation issues. This fix introduces tests that check the correct positioning (test_position_) test_position_withCSS reproduces the problem that is fixed with this patch. The other test_position_ cases serve as "proof" that no regressions are introduces. They work before and after the fix is introduced. ------------- Commit messages: - 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS - Merge pull request #1 from openjdk/master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - 8232524: Test cleanup: terminate background thread upon failure. - 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating - ... and 1 more: https://git.openjdk.java.net/jfx/compare/d8bb41d1...48d6453a Changes: https://git.openjdk.java.net/jfx/pull/383/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228363 Stats: 144 lines in 2 files changed: 115 ins; 14 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/383.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/383/head:pull/383 PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Thu Jan 21 06:47:41 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Jan 2021 06:47:41 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: <081IWVBgIw_hwqCx75vr5RZ9BhVZVBv2KvohxGOuNL0=.91335d3c-3428-4434-a0ad-0572c39a1f49@github.com> Message-ID: On Thu, 21 Jan 2021 06:37:59 GMT, Robert Lichtenberger wrote: >> Regarding the spec change, I was thinking of this section, which you removed: >> >> * To clarify the purpose of the {@code hpos} and {@code vpos} parameters, >> * consider that they are relative to the anchor node. As such, a {@code hpos} >> * and {@code vpos} of {@code CENTER} would mean that the ContextMenu appears >> * on top of the anchor, with the (0,0) position of the {@code ContextMenu} >> * positioned at (0,0) of the anchor. A {@code hpos} of right would then shift >> * the {@code ContextMenu} such that its top-left (0,0) position would be attached >> * to the top-right position of the anchor. >> >> As you pointed out, the reference to `hpos` and `vpos` is incorrect, but unless I'm missing something, it still seems like the concept still needs to be described. > >> Regarding the spec change, I was thinking of this section, which you removed: >> >> ``` >> * To clarify the purpose of the {@code hpos} and {@code vpos} parameters, >> * consider that they are relative to the anchor node. As such, a {@code hpos} >> * and {@code vpos} of {@code CENTER} would mean that the ContextMenu appears >> * on top of the anchor, with the (0,0) position of the {@code ContextMenu} >> * positioned at (0,0) of the anchor. A {@code hpos} of right would then shift >> * the {@code ContextMenu} such that its top-left (0,0) position would be attached >> * to the top-right position of the anchor. >> ``` >> >> As you pointed out, the reference to `hpos` and `vpos` is incorrect, but unless I'm missing something, it still seems like the concept still needs to be described. > > I assume that a very long time ago, there were hpos and vpos parameters for this method. And that really required an explanation, because then you could e.g. specify hpos=RIGHT and vpos=BOTTOM, which would give a very strange position for the context menu (the top left corner of the menu would be in the bottom right corner of the button). > It also was very counter-intuitive that giving CENTER/CENTER for hpos/vpos would put the top left corner of the menu at the top left corner of the button. > However all this confusion was ended when Side was used instead of HPos/VPos. At that very moment all the confusing cases went away. No more BOTTOM/RIGHT or CENTER/CENTER placement. > So I think we can really just remove the (obsolete) explanation of hPos/vPos. I've just "recreated" this PR as https://github.com/openjdk/jfx/pull/383 which is based on a separate branch as suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/381 From kcr at openjdk.java.net Thu Jan 21 12:49:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 12:49:46 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 06:42:19 GMT, Robert Lichtenberger wrote: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. I saw your comment in #381 regarding the removed section of API docs. We can discuss it as part of the review of this PR. I'll take a look and see whether simply removing it is fine or if I can suggest a replacement. It still might need a CSR (I'll let you know), but it would be a simple one to record the doc changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From ebresie at gmail.com Thu Jan 21 13:18:53 2021 From: ebresie at gmail.com (Eric Bresie) Date: Thu, 21 Jan 2021 07:18:53 -0600 Subject: cleanup obsolete code In-Reply-To: CABxFH2HRp=OraV1xub62=60J34+YOJYgGufp+2n4F2YV-VkjHg@mail.gmail.com References: CABxFH2FyYoEq7g=h+K2JGcYYNWQnD8uQKQ+-LhOx9TkMmWvhZg@mail.gmail.com CA+0ynh_Azkv=cxYSyoe=yqzn1GeReoONwvneX=VtgYWXasj1Pw@mail.gmail.com CABxFH2F3U+r_zbGU63WAXWB1UsYqB1i_6Xar4Nb_7jQGsAqxmA@mail.gmail.com CABxFH2F3U+r_zbGU63WAXWB1UsYqB1i_6Xar4Nb_7jQGsAqxmA@mail.gmail.com Message-ID: Would removal of this break anything on other platforms (OS or hardware [embedded/non-embedded], Wayland)? Assume since focused x11 (mainly Unix platforms) it shouldn?t but figured I?d ask. A little off topic but is an architecture diagram with applicable elements available someplace? If not am I correct in saying from a high to lower layer there is - Prism - which renders scenes. A believe this was deprecated/removed at some point in more recent updated - ES2 - provide acceleration (possibly hardware if supporting) - GL - open gl for graphical / harder rendering - X11 - UNIX windowing client/server protocols communications between - Monocle - the ?glass? layer where the above are rendered - OS/Kernel Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On January 18, 2021 at 2:38:17 AM CST, Johan Vos wrote: > Related to this question, there is the comment from Kevin about removing > references to es2-eglfb/es2-eglx11 in other files, e.g. ES2Pipeline.java [1] > While I believe this is a good idea, it opens room for more cleanup (or at > least more consistency): > In some cases, library names indicate a configuration. For example, > prism-es2-monocle indicates that the glass-platform monocle is used. In > most cases though, the library names do not contain this information. On > mac/linux/windows/ios, we simply use prism-es2 . Obviously, the contents of > the library vary for the different platforms, but this is taken care of by > the build process. > > This inconsistency leads to avoidable logic in the Java classes, e.g. in > ES2Pipeline. After cleaning up for the unused egl{fb,x11} variants, there > will still be a check about which library should be loaded: if the glass > variant is monocle, prism-es2-monocle is loaded. In all other cases, > prism-es2 is loaded. > I think the name of the library should either always contain the glass > variant name, or never. I have a preference for removing the variant in the > name completely, as this will allow us to remove even more logic in the > .java files. > > [1] https://github.com/openjdk/jfx/pull/378#issuecomment-761673755 > > > On Sat, Jan 16, 2021 at 1:26 PM Johan Vos wrote: > > > I would guess those were used before Monocle was introduced. > > > > On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker wrote: > > > > > Out of curiosity, what were they used for? > > > > > > On Thu, Jan 14, 2021 at 3:54 PM Johan Vos wrote: > > > > > > > Hi, > > > > > > > > We currently have a number of GLFactory implementations in the ES2 Prism > > > > pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we use > > > > X11, and systems with monocle can use either egl, X11, fb,... but that is > > > > then managed by the MonocleGLFactory. > > > > > > > > Unless these files are used, I suggest they are removed (that is the java > > > > classes and the native code). > > > > > > > > The static initialiser of GLFactory will then have only 2 choices for > > > > factoryClasses that can be used on Linux: X11, or Monocle. The latter is > > > > only used if the System Property `embedded` is set to `monocle` (as > > > > checked > > > > in PlatformUtil). We can replace this in a check on the Glass platform > > > > (which is already done in Glass: com.sun.glass.ui.Platform will check the > > > > value of `glass.platform`, and Monocle will be selected in Glass in case > > > > the value is set to `Monocle`.) > > > > Clearly, Prism and Glass are 2 different things, but I personally would > > > > prefer to have the decision whether to use X11 or Monocle to be based on > > > > this `glass.platform` property rather then on yet another property > > > > (`embedded`) that is apart from this not used for anything else. > > > > > > > > I will create an issue for this, but in case I'm missing something, > > > > please > > > > let me know. > > > > > > > > - Johan > > > > > > > From kcr at openjdk.java.net Thu Jan 21 13:28:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 13:28:50 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 04:14:28 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.30 (610.2) I reviewed all of the changes outside `modules/javafx.web/src/main/native/`. Most look related to the change to use the Prism Color object instead of an int. I did have a question about one of those changes: modules/javafx.web/src/main/java/com/sun/webkit/plugin/DefaultPlugin.java - g.fillRect(x, y, w, h, 0x11aaffff); + g.fillRect(x, y, w, h, new Color(0.33f, 1.0f, 1.0f, 0.1f)); These are not equivalent colors. Is this intentional? ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From jvos at openjdk.java.net Thu Jan 21 13:54:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 21 Jan 2021 13:54:12 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 12:47:01 GMT, Kevin Rushforth wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > I saw your comment in #381 regarding the removed section of API docs. We can discuss it as part of the review of this PR. I'll take a look and see whether simply removing it is fine or if I can suggest a replacement. It still might need a CSR (I'll let you know), but it would be a simple one to record the doc changes. This approach looks good to me, and it makes it simpler. I agree that some info about the `Side` parameter would be appropriate in the JavaDoc (although it is close to trivial and the source is self-explaining) ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From ajoseph at openjdk.java.net Thu Jan 21 14:09:17 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 21 Jan 2021 14:09:17 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 13:25:39 GMT, Kevin Rushforth wrote: >> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) > > I reviewed all of the changes outside `modules/javafx.web/src/main/native/`. Most look related to the change to use the Prism Color object instead of an int. I did have a question about one of those changes: > > modules/javafx.web/src/main/java/com/sun/webkit/plugin/DefaultPlugin.java > - g.fillRect(x, y, w, h, 0x11aaffff); > + g.fillRect(x, y, w, h, new Color(0.33f, 1.0f, 1.0f, 0.1f)); > > These are not equivalent colors. Is this intentional? It should be `new Color(2 / 3.0f, 1.0f, 1.0f, 1 / 15.0f)`. I'll update the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From ajoseph at openjdk.java.net Thu Jan 21 15:57:04 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 21 Jan 2021 15:57:04 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit [v2] In-Reply-To: References: Message-ID: > Update JavaFX WebKit to GTK WebKit 2.30 (610.2) Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix color in DefaultPlugin ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/382/files - new: https://git.openjdk.java.net/jfx/pull/382/files/f55e82f8..ccb53c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=382&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=382&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/382/head:pull/382 PR: https://git.openjdk.java.net/jfx/pull/382 From jvos at openjdk.java.net Thu Jan 21 18:29:35 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 21 Jan 2021 18:29:35 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 14:05:54 GMT, Arun Joseph wrote: >> I reviewed all of the changes outside `modules/javafx.web/src/main/native/`. Most look related to the change to use the Prism Color object instead of an int. I did have a question about one of those changes: >> >> modules/javafx.web/src/main/java/com/sun/webkit/plugin/DefaultPlugin.java >> - g.fillRect(x, y, w, h, 0x11aaffff); >> + g.fillRect(x, y, w, h, new Color(0.33f, 1.0f, 1.0f, 0.1f)); >> >> These are not equivalent colors. Is this intentional? > > It should be `new Color(2 / 3.0f, 1.0f, 1.0f, 1 / 15.0f)`. I'll update the PR. Build and tests pass on windows/linux/mac in our CI. ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From kcr at openjdk.java.net Thu Jan 21 19:14:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 19:14:50 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 15:57:04 GMT, Arun Joseph wrote: >> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix color in DefaultPlugin Looks good. Build + automated tests passed on all three platforms. I ran into one manual test issue related to input events on Linux only. I'll file a follow-on bug for that. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/382 From kcr at openjdk.java.net Thu Jan 21 19:26:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 19:26:12 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit [v2] In-Reply-To: References: Message-ID: <3gmK5RSZ2FaN89G7yfI3rsW-Yfa4JatjJxkCcypiaxA=.7bd41402-2f7c-433c-b1c4-97f66c4770b7@github.com> On Thu, 21 Jan 2021 19:11:21 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix color in DefaultPlugin > > Looks good. Build + automated tests passed on all three platforms. I ran into one manual test issue related to input events on Linux only. I'll file a follow-on bug for that. I filed [JDK-8260257](https://bugs.openjdk.java.net/browse/JDK-8260257) to track the Linux input event issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From kcr at openjdk.java.net Thu Jan 21 23:28:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Jan 2021 23:28:40 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 06:42:19 GMT, Robert Lichtenberger wrote: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. I still need to test this, but the approach looks good. I left a few inline comments. modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 241: > 239: * the {@code ContextMenu} such that its top-left (0,0) position would be attached > 240: * to the top-right position of the anchor. > 241: *

I think it is worth adding a short replacement for this, explaining how the side parameter and delta values affect the location of the popup. modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 646: > 644: @Test public void test_position_showOnScreen() { > 645: ContextMenu cm = createContextMenu(false); > 646: cm.show(anchorBtn,100, 100); Minor: missing space after the `,` modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 686: > 684: private String createStylesheet() { > 685: try { > 686: File f = File.createTempFile("test_position_showOnTopWithCSS", ".css"); There is no need to create a temporary file for this css resource, since its contents are fixed. Instead, you should add `test_position_showOnTopWithCSS.css` to the repo under [`modules/javafx.controls/src/test/resources/test/javafx/scene/control/`](https://github.com/openjdk/jfx/tree/master/modules/javafx.controls/src/test/resources/test/javafx/scene/control). Then you can just do this: return ContextMenuTest.class.getResource("test_position_showOnTopWithCSS.css").toExternalForm(); modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 649: > 647: > 648: assertEquals(cm.getAnchorX(), 100, 0.0); > 649: assertEquals(cm.getAnchorY(), 100, 0.0); The expected and actual values are backwards (expected should be first). ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From arapte at openjdk.java.net Fri Jan 22 10:13:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 22 Jan 2021 10:13:56 GMT Subject: RFR: 8256283: IndexOutOfBoundsException when sorting a TreeTableView Message-ID: This particular issue JDK-8256283, is a specific case of IOOBE when, rootItem is not shown, some children including first child are selected, then all children are removed and sort() is invoked. The sort() fails with an IOOBE. This PR only addresses this specific IOOBE. Root cause of this issue is that the selection is not cleared after rootItems children are removed. In addition to this, there are few other scenarios when selection is not updated correctly, which are collected under an umbrella task [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Fix for [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217) would require good amount refactoring of selection model. The fix for this issue is to avoid sort() when rootItem.getChildren().isEmpty(). Added a unit test with the fix, which fails without fix and passes with fix. ------------- Commit messages: - skip sorting when rootItem has no children Changes: https://git.openjdk.java.net/jfx/pull/384/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=384&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256283 Stats: 20 lines in 2 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/384/head:pull/384 PR: https://git.openjdk.java.net/jfx/pull/384 From rlichten at openjdk.java.net Fri Jan 22 10:36:48 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 10:36:48 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 23:11:44 GMT, Kevin Rushforth wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 646: > >> 644: @Test public void test_position_showOnScreen() { >> 645: ContextMenu cm = createContextMenu(false); >> 646: cm.show(anchorBtn,100, 100); > > Minor: missing space after the `,` Space inserted. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 649: > >> 647: >> 648: assertEquals(cm.getAnchorX(), 100, 0.0); >> 649: assertEquals(cm.getAnchorY(), 100, 0.0); > > The expected and actual values are backwards (expected should be first). Swapped positions. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Fri Jan 22 10:50:50 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 10:50:50 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 23:15:09 GMT, Kevin Rushforth wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 686: > >> 684: private String createStylesheet() { >> 685: try { >> 686: File f = File.createTempFile("test_position_showOnTopWithCSS", ".css"); > > There is no need to create a temporary file for this css resource, since its contents are fixed. Instead, you should add `test_position_showOnTopWithCSS.css` to the repo under [`modules/javafx.controls/src/test/resources/test/javafx/scene/control/`](https://github.com/openjdk/jfx/tree/master/modules/javafx.controls/src/test/resources/test/javafx/scene/control). Then you can just do this: > > return ContextMenuTest.class.getResource("test_position_showOnTopWithCSS.css").toExternalForm(); Thanks for pointing this out. I took the example from the bug entry (where it was nice to have everything in one file). But in the test it is of course much more elegant to use a .css file from the resources. Adapted the test accordingly. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Fri Jan 22 10:55:44 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 10:55:44 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 23:07:23 GMT, Kevin Rushforth wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 241: > >> 239: * the {@code ContextMenu} such that its top-left (0,0) position would be attached >> 240: * to the top-right position of the anchor. >> 241: *

> > I think it is worth adding a short replacement for this, explaining how the side parameter and delta values affect the location of the popup. While trying to come up with a good documentation I've detected a real change in behaviour in connection with the NodeOrientation of the anchor node. Although this has never been documented, when NodeOrientation.RIGHT_TO_LEFT is set, the context menu was right-aligned for Side=TOP and Side=BOTTOM. Since I assume we don't want to change this behaviour I would now document it and adapt my patch accordingly. I've already written a test case like this: @Test public void test_position_withOrientation() throws InterruptedException { ContextMenu cm = createContextMenu(false); anchorBtn.setNodeOrientation(NodeOrientation.RIGHT_TO_LEFT); cm.show(anchorBtn, Side.TOP, 0, 0); Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); Node cmNode = cm.getScene().getRoot(); Bounds cmBounds = cm.getScene().getRoot().localToScreen(cmNode.getLayoutBounds()); assertEquals(anchorBounds.getMaxX(), cmBounds.getMaxX(), 0.0); assertEquals(anchorBounds.getMinY(), cmBounds.getMaxY(), 0.0); anchorBtn.setNodeOrientation(NodeOrientation.LEFT_TO_RIGHT); } which passes with the old implementation but (currently) fails with the new implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Fri Jan 22 11:04:48 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 11:04:48 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 10:53:00 GMT, Robert Lichtenberger wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 241: >> >>> 239: * the {@code ContextMenu} such that its top-left (0,0) position would be attached >>> 240: * to the top-right position of the anchor. >>> 241: *

>> >> I think it is worth adding a short replacement for this, explaining how the side parameter and delta values affect the location of the popup. > > While trying to come up with a good documentation I've detected a real change in behaviour in connection with the NodeOrientation of the anchor node. > Although this has never been documented, when NodeOrientation.RIGHT_TO_LEFT is set, the context menu was right-aligned for Side=TOP and Side=BOTTOM. > Since I assume we don't want to change this behaviour I would now document it and adapt my patch accordingly. I've already written a test case like this: > @Test public void test_position_withOrientation() throws InterruptedException { > ContextMenu cm = createContextMenu(false); > anchorBtn.setNodeOrientation(NodeOrientation.RIGHT_TO_LEFT); > cm.show(anchorBtn, Side.TOP, 0, 0); > > Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); > Node cmNode = cm.getScene().getRoot(); > Bounds cmBounds = cm.getScene().getRoot().localToScreen(cmNode.getLayoutBounds()); > > assertEquals(anchorBounds.getMaxX(), cmBounds.getMaxX(), 0.0); > assertEquals(anchorBounds.getMinY(), cmBounds.getMaxY(), 0.0); > anchorBtn.setNodeOrientation(NodeOrientation.LEFT_TO_RIGHT); > } > which passes with the old implementation but (currently) fails with the new implementation. Oh wow. Further experimentation has shown, that if NodeOrientation.RIGHT_TO_LEFT is used on the anchor, then Side.LEFT used to make the menu appear on the **right** hand side and Side.RIGHT used to make the menu appear on the **left** hand side of the button, which really suprises me, since I didn't expect the side parameter to be relative. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Fri Jan 22 12:02:13 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 12:02:13 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Corrections as per Kevin Rushforth's comments. Also added two more test cases that test right-to-left node orientation. Fixed the implementation and the API documentation. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/383/files - new: https://git.openjdk.java.net/jfx/pull/383/files/48d6453a..67a7da14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=00-01 Stats: 123 lines in 3 files changed: 87 ins; 29 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/383.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/383/head:pull/383 PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Fri Jan 22 12:04:45 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 22 Jan 2021 12:04:45 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 11:02:29 GMT, Robert Lichtenberger wrote: >> While trying to come up with a good documentation I've detected a real change in behaviour in connection with the NodeOrientation of the anchor node. >> Although this has never been documented, when NodeOrientation.RIGHT_TO_LEFT is set, the context menu was right-aligned for Side=TOP and Side=BOTTOM. >> Since I assume we don't want to change this behaviour I would now document it and adapt my patch accordingly. I've already written a test case like this: >> @Test public void test_position_withOrientation() throws InterruptedException { >> ContextMenu cm = createContextMenu(false); >> anchorBtn.setNodeOrientation(NodeOrientation.RIGHT_TO_LEFT); >> cm.show(anchorBtn, Side.TOP, 0, 0); >> >> Bounds anchorBounds = anchorBtn.localToScreen(anchorBtn.getLayoutBounds()); >> Node cmNode = cm.getScene().getRoot(); >> Bounds cmBounds = cm.getScene().getRoot().localToScreen(cmNode.getLayoutBounds()); >> >> assertEquals(anchorBounds.getMaxX(), cmBounds.getMaxX(), 0.0); >> assertEquals(anchorBounds.getMinY(), cmBounds.getMaxY(), 0.0); >> anchorBtn.setNodeOrientation(NodeOrientation.LEFT_TO_RIGHT); >> } >> which passes with the old implementation but (currently) fails with the new implementation. > > Oh wow. Further experimentation has shown, that if NodeOrientation.RIGHT_TO_LEFT is used on the anchor, then Side.LEFT used to make the menu appear on the **right** hand side and Side.RIGHT used to make the menu appear on the **left** hand side of the button, which really surprises me, since I didn't expect the side parameter to be relative. Ok, I just pushed all the changes necessary to keep the old behaviour for right-to-left node orientation. If you would rather have the behaviour changed (it doesn't seem very intuitive to me...) just tell me and I can change the implementation / tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From kcr at openjdk.java.net Fri Jan 22 18:01:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Jan 2021 18:01:44 GMT Subject: RFR: 8256283: IndexOutOfBoundsException when sorting a TreeTableView In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 10:08:51 GMT, Ambarish Rapte wrote: > This particular issue JDK-8256283, is a specific case of IOOBE when, rootItem is not shown, some children including first child are selected, then all children are removed and sort() is invoked. The sort() fails with an IOOBE. > This PR only addresses this specific IOOBE. > Root cause of this issue is that the selection is not cleared after rootItems children are removed. In addition to this, there are few other scenarios when selection is not updated correctly, which are collected under an umbrella task [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Fix for [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217) would require good amount refactoring of selection model. > > The fix for this issue is to avoid sort() when rootItem.getChildren().isEmpty(). > Added a unit test with the fix, which fails without fix and passes with fix. Comments inline. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 582: > 580: try { > 581: TreeItem rootItem = table.getRoot(); > 582: if (rootItem == null | rootItem.getChildren().isEmpty()) return false; That should be `||` (boolean OR). In addition to being less clear, this will get an NPE if `rootItem` is ever null, since the bit-wise `|` operator doesn't short-curcuit the rest of the `if` test if the first term is true. Given that this would have caused a regression, and that we don't have a test that would catch it, can you add a test that sets the root to null and calls sort? It will fail with this version of the fix, but would pass without the fix and should pass once you update your fix. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/384 From kcr at openjdk.java.net Fri Jan 22 18:47:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Jan 2021 18:47:46 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 12:01:55 GMT, Robert Lichtenberger wrote: >> Oh wow. Further experimentation has shown, that if NodeOrientation.RIGHT_TO_LEFT is used on the anchor, then Side.LEFT used to make the menu appear on the **right** hand side and Side.RIGHT used to make the menu appear on the **left** hand side of the button, which really surprises me, since I didn't expect the side parameter to be relative. > > Ok, I just pushed all the changes necessary to keep the old behaviour for right-to-left node orientation. > If you would rather have the behaviour changed (it doesn't seem very intuitive to me...) just tell me and I can change the implementation / tests. Good catch. The current behavior is consistent with how RTL works for most things, so we do want to preserve that behavior. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From kcr at openjdk.java.net Fri Jan 22 20:01:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Jan 2021 20:01:11 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 12:02:13 GMT, Robert Lichtenberger wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS > > Corrections as per Kevin Rushforth's comments. > Also added two more test cases that test right-to-left node orientation. > Fixed the implementation and the API documentation. The fix and the tests look good to me. I have one comment on the docs (and I left a minor formatting comment). modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 237: > 235: * NodeOrientation.RIGHT_TO_LEFT is set. > 236: * Using NodeOrientation.RIGHT_TO_LEFT will also "mirror" the meaning of Side.LEFT and > 237: * Side.RIGHT respectively. We don't document the effect of node orientation in other controls or in charts, so I wouldn't want to mention it here. Instead you can document the behavior assuming the default effective orientation of `LEFT_TO_RIGHT` (without mentioning it). You could make the case that we should document more precisely the effect or NodeOrientation, but that would be a large task, and not something I would want to do for an isolated control in the course of a bug fix (and it would require a CSR). The rest of the doc changes look good and don't need a CSR. modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 302: > 300: > 301: > 302: Minor: there should only be one blank line here. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From kcr at openjdk.java.net Fri Jan 22 21:28:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Jan 2021 21:28:42 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <2sdQMJamnqA2xRHM1NpXG2CqHLAKSHr5bqmG-rC4y28=.c1dc6bb3-b6d3-46df-ac77-c9d5053dcabd@github.com> Message-ID: On Wed, 20 Jan 2021 08:46:13 GMT, John Hendrikx wrote: >> @hjohn Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: >> >> 8252935: Add treeShowing listener only when needed > > So, will this actually get reviewed? Now that we are past RDP1 for JavaFX 16, this seems a good time to look at some of these performance issue. One of the challenges will be ensuring no regressions. I did a preliminary review of this, along with some testing, and it looks less scary than I was afraid it would be. The overall approach seems sound: preserve the `NodeHelper::isTreeVisible` method, but don't provide it as an observable property, instead adding the listeners only to those that need them. Can you do the following? 1. Merge in the latest changes from the upstream master branch into your local feature branch? Among other things, this will enable running tests via GitHub Actions. 2. Add a test program under `tests/performance` that can be used to verify the performance gain. Even better would be if you can create an automated test under `tests/system`. I was thinking something like what we did for [JDK](URL) where there was a pathological performance bug fixed and the test checked that the operation in question didn't take more than some small number of seconds. That might be overkill for this fix, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kcr at openjdk.java.net Fri Jan 22 21:39:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Jan 2021 21:39:46 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 17 Apr 2020 08:06:23 GMT, John Hendrikx wrote: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. I left a few inline comments below. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 137: > 135: > 136: treeShowingExpression = new TreeShowingExpression(control); > 137: treeShowingExpression.addListener((obs, old, current) -> updateAnimation()); Is there a reason not to still use `registerChangeListener` for this? modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 239: > 237: super.dispose(); > 238: > 239: treeShowingExpression.dispose(); This could be removed if you are able to use `registerChangeListener` to add the listener. modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 312: > 310: _value.setTreeVisible(isTreeVisible()); > 311: _value.setDisabled(isDisabled()); > 312: _value.setTreeShowing(isTreeShowing()); This looks fine. It might be worth adding a unit test to ensure that `isTreeShowing` works correctly for nodes in a `SubScene`. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From ghb at openjdk.java.net Sat Jan 23 05:19:45 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Sat, 23 Jan 2021 05:19:45 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 15:57:04 GMT, Arun Joseph wrote: >> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix color in DefaultPlugin Changes looks good to me. Did a local build on all three Platform and sanity test by loading top 10 websites loaded without any deviation from old build. ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/382 From kcr at openjdk.java.net Sat Jan 23 15:43:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Jan 2021 15:43:54 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Message-ID: The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. ------------- Commit messages: - 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Changes: https://git.openjdk.java.net/jfx/pull/385/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259680 Stats: 419 lines in 15 files changed: 418 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/385/head:pull/385 PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Sat Jan 23 16:46:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 23 Jan 2021 16:46:41 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 361: > 359: switch (keyCode) { > 360: case com_sun_glass_events_KeyEvent_VK_CAPS_LOCK: > 361: lockState = gdk_keymap_get_caps_lock_state(keyMap); It seems that `gdk_keymap_get_caps_lock_state` isn't reliable on GTK 3 either. At least not when I test it on a Linux VM. I may end up using raw Xlib calls instead (which would have the added benefit of removing the "ifdef" for GTK 3). ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From github.com+76791+alblue at openjdk.java.net Sat Jan 23 22:22:38 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 23 Jan 2021 22:22:38 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: <-n5iNYUi5keQZlOouIlSCHfqkMYD9nrTg-oWevAUe24=.e5aff852-96bf-41a1-a265-a90c7b9e8f90@github.com> References: <469WSEqGhPucVTAr4CbRZuAW6AP0qc6ifpJaHqtx8t8=.7b9589bf-af11-41c0-a381-d39f7d765fa8@github.com> <-n5iNYUi5keQZlOouIlSCHfqkMYD9nrTg-oWevAUe24=.e5aff852-96bf-41a1-a265-a90c7b9e8f90@github.com> Message-ID: On Thu, 21 Jan 2021 00:07:30 GMT, Kevin Rushforth wrote: >> I don't yet know whether there is an alternative that would allow the menubar to work without deactivating the app, but I filed a follow-up bug to track this: >> >> [JDK-8257835](https://bugs.openjdk.java.net/browse/JDK-8257835): Brief flash in terminal window when launching FX app on macOS >> >> It seems like it might be possible to fix this, since AWT initialization doesn't run into this. I note that AWT uses an Apple-provided "JavaRuntime Support" (JRS) Framework. We would need to see whether there is something else possible using public macOS APIs. > > @tomsontom Thanks for letting me know. He reached to me directly as well, so I'll plan to add the information to the follow-on bug, [JDK-8257835](https://bugs.openjdk.java.net/browse/JDK-8257835). BTW there were observations that the setActivationPolicy call needs to be inside the callback as well, at least on 10.15. I've updated the bug on the StackOverflow question, and the Eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=552063 has a fix about to go in with the suggested change. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From nlisker at openjdk.java.net Sat Jan 23 23:15:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 23 Jan 2021 23:15:43 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 764: > 762: default: > 763: return Optional.empty(); > 764: } This could be a switch expression: return switch (lockState) { case KeyEvent.KEY_LOCK_OFF -> Optional.of(false); case KeyEvent.KEY_LOCK_ON -> Optional.of(true); default -> Optional.empty(); } Also, do we use a space after `switch`? I see many instances both with and without in the current source. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1250: > 1248: default: > 1249: return com.sun.glass.events.KeyEvent.VK_UNDEFINED; > 1250: } Also expression switch here. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From nlisker at openjdk.java.net Sat Jan 23 23:23:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 23 Jan 2021 23:23:43 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 336: > 334: /** > 335: * Returns a flag indicating whether the key corresponding to {@code keyCode} > 336: * is in the locked or "on" state. I would write "locked, or "on", state" or "locked (or "on") state" because in the current form it can be understood as 2 different conditions. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From nlisker at openjdk.java.net Sat Jan 23 23:44:41 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 23 Jan 2021 23:44:41 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 345: > 343: * This method must be called on the JavaFX Application thread. > 344: * > 345: * @param keyCode the KeyCode of the lock state to query `{@code KeyCode}` ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From nlisker at openjdk.java.net Sat Jan 23 23:48:41 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 23 Jan 2021 23:48:41 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 342: > 340: * specified {@code keyCode}, an empty {@code Optional} is returned. > 341: * If the keyboard attached to the system doesn't have the specified key, > 342: * {@code Boolean.FALSE} is returned. Not `Optional.of(false)`? ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From nlisker at openjdk.java.net Sat Jan 23 23:51:39 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 23 Jan 2021 23:51:39 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 351: > 349: * > 350: * @throws IllegalArgumentException if {@code keyCode} is not one of the > 351: * valid KeyCode values. `{@code KeyCode}` ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From jhendrikx at openjdk.java.net Sun Jan 24 09:01:58 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 09:01:58 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v2] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: WIP: Moved treeShowingProperty into its own class ------------- Changes: https://git.openjdk.java.net/jfx/pull/185/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=01 Stats: 275 lines in 6 files changed: 161 ins; 109 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Sun Jan 24 09:04:41 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 09:04:41 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v2] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <6eueo1UWV8uh83yvVGuNXZhvPHp6uheSWg9O0vQHJCk=.ec337044-84e5-43a2-a578-b8623e30a89c@github.com> On Fri, 22 Jan 2021 21:36:53 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 one commit: >> >> WIP: Moved treeShowingProperty into its own class > > I left a few inline comments below. Sorry about the force push, merging over a year of changes from master did not seem right to me. It was only for getting up to date, I will do the other commits normally. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Sun Jan 24 09:27:40 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 09:27:40 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v2] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Fri, 22 Jan 2021 21:32:28 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 one commit: >> >> WIP: Moved treeShowingProperty into its own class > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 239: > >> 237: super.dispose(); >> 238: >> 239: treeShowingExpression.dispose(); > > This could be removed if you are able to use `registerChangeListener` to add the listener. I'm not so sure, the listener will be removed from the `TreeShowingExpression` that was created, but the `TreeShowingExpression` itself is also registering listeners on the `ProgressIndicator`. I don't see any `dispose` calls being done by the helper code. If I'm correct, switching skins multiple times on a `ProgressIndicator` would create multiple `TreeShowingExpression`s which would create listeners on the `ProgressIndicator` which in turn reference the expression -- this would prevent the discarded skins from being GC'd. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Sun Jan 24 09:30:42 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 09:30:42 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v2] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: <6LMSnABwaJS4TmP4jobLPYa3AeW9iSij7u4v2CK8Bgg=.bd26f09f-18c5-40f7-a871-69d19b638ce1@github.com> On Fri, 22 Jan 2021 21:31: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 one commit: >> >> WIP: Moved treeShowingProperty into its own class > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 137: > >> 135: >> 136: treeShowingExpression = new TreeShowingExpression(control); >> 137: treeShowingExpression.addListener((obs, old, current) -> updateAnimation()); > > Is there a reason not to still use `registerChangeListener` for this? `registerChangeListener` can be used here, I just didn't see it. However, there is no need to unregister the listener from the expression (it is local to the skin, it will never have more than one listener and will be GC'd with the Skin). I will change it though, as it looks a bit cleaner, and there is no harm unregistering the listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From fastegal at openjdk.java.net Sun Jan 24 12:02:43 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 24 Jan 2021 12:02:43 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v2] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Sun, 24 Jan 2021 09:24:56 GMT, John Hendrikx wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 239: >> >>> 237: super.dispose(); >>> 238: >>> 239: treeShowingExpression.dispose(); >> >> This could be removed if you are able to use `registerChangeListener` to add the listener. > > I'm not so sure, the listener will be removed from the `TreeShowingExpression` that was created, but the `TreeShowingExpression` itself is also registering listeners on the `ProgressIndicator`. I don't see any `dispose` calls being done by the helper code. If I'm correct, switching skins multiple times on a `ProgressIndicator` would create multiple `TreeShowingExpression`s which would create listeners on the `ProgressIndicator` which in turn reference the expression -- this would prevent the discarded skins from being GC'd. agreed, nested listeners to control's - nested - properties must be removed (whether or not parent was added via the skin api) Unrelated (and too lazy to check ;) wondering if there are any tests for those nested listeners doing/not their respected jobs after before/after dispose? ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From fthevenet at openjdk.java.net Sun Jan 24 14:52:42 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sun, 24 Jan 2021 14:52:42 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sat, 23 Jan 2021 23:11:10 GMT, Nir Lisker wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 764: > >> 762: default: >> 763: return Optional.empty(); >> 764: } > > This could be a switch expression: > return switch (lockState) { > case KeyEvent.KEY_LOCK_OFF -> Optional.of(false); > case KeyEvent.KEY_LOCK_ON -> Optional.of(true); > default -> Optional.empty(); > } > Also, do we use a space after `switch`? I see many instances both with and without in the current source. Do we plan to drop support for JDK11 for OpenJFX 17? If not, we'll need to keep to the classic Switch statement, as Switch expressions were only introduced in JDK12 or 13 as a preview. That said, since 17 is going to be the next LTS release, maybe the plan is to bump the dependency for OpenJFX then? ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From github.com+2179736+matthiasblaesing at openjdk.java.net Sun Jan 24 15:06:42 2021 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Sun, 24 Jan 2021 15:06:42 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sun, 24 Jan 2021 14:50:08 GMT, Frederic Thevenet wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 764: >> >>> 762: default: >>> 763: return Optional.empty(); >>> 764: } >> >> This could be a switch expression: >> return switch (lockState) { >> case KeyEvent.KEY_LOCK_OFF -> Optional.of(false); >> case KeyEvent.KEY_LOCK_ON -> Optional.of(true); >> default -> Optional.empty(); >> } >> Also, do we use a space after `switch`? I see many instances both with and without in the current source. > > Do we plan to drop support for JDK11 for OpenJFX 17? If not, we'll need to keep to the classic Switch statement, as Switch expressions were only introduced in JDK12 or 13 as a preview. > That said, since 17 is going to be the next LTS release, maybe the plan is to bump the dependency for OpenJFX then? Totally selfish request: It would be great if OpenJFX 17 would retain compatibilty with JDK 11 -- NetBeans allows including JavaFX and will retain JDK 11 compatibility for the foreseable future. I can understand, that at some point, language features will become too important to retain compatibility, but this looks dubious to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From jhendrikx at openjdk.java.net Sun Jan 24 15:25:06 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 15:25:06 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v3] In-Reply-To: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: > This is a PoC for performance testing. > > It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. > > This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Add performance test - Use registerChangeListener in ProgressIndicatorSkin ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/185/files - new: https://git.openjdk.java.net/jfx/pull/185/files/5ac5d9e4..e68a886d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=185&range=01-02 Stats: 170 lines in 2 files changed: 167 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/185.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/185/head:pull/185 PR: https://git.openjdk.java.net/jfx/pull/185 From jhendrikx at openjdk.java.net Sun Jan 24 16:25:45 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 24 Jan 2021 16:25:45 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v3] In-Reply-To: <6eueo1UWV8uh83yvVGuNXZhvPHp6uheSWg9O0vQHJCk=.ec337044-84e5-43a2-a578-b8623e30a89c@github.com> References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> <6eueo1UWV8uh83yvVGuNXZhvPHp6uheSWg9O0vQHJCk=.ec337044-84e5-43a2-a578-b8623e30a89c@github.com> Message-ID: On Sun, 24 Jan 2021 09:02:17 GMT, John Hendrikx wrote: >> I left a few inline comments below. > > Sorry about the force push, merging over a year of changes from master did not seem right to me. It was only for getting up to date, I will do the other commits normally. > 1. Merge in the latest changes from the upstream master branch into your local feature branch? Among other things, this will enable running tests via GitHub Actions. I hadn't seen that in practice yet, it looks really nice. > 2. Add a test program under `tests/performance` that can be used to verify the performance gain. Even better would be if you can create an automated test under `tests/system`. I was thinking something like what we did for PR #34 where there was a pathological performance bug fixed and the test checked that the operation in question didn't take more than some small number of seconds. That might be overkill for this fix, though. I put a test under `tests/system` using the example you gave. It creates a Scene with about 16k nodes, and then does 10.000 operations on them. This runs in around 2-2.5 seconds before the fix and in about 100-200 ms after. I put the cut-off point somewhere in the middle (800 ms). I am planning to address the rest of the comments somewhere in the coming week. ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From nlisker at openjdk.java.net Sun Jan 24 18:11:39 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 24 Jan 2021 18:11:39 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sun, 24 Jan 2021 15:03:52 GMT, Matthias Bl?sing wrote: >> Do we plan to drop support for JDK11 for OpenJFX 17? If not, we'll need to keep to the classic Switch statement, as Switch expressions were only introduced in JDK12 or 13 as a preview. >> That said, since 17 is going to be the next LTS release, maybe the plan is to bump the dependency for OpenJFX then? > > Totally selfish request: It would be great if OpenJFX 17 would retain compatibilty with JDK 11 -- NetBeans allows including JavaFX and will retain JDK 11 compatibility for the foreseable future. I can understand, that at some point, language features will become too important to retain compatibility, but this looks dubious to me. It was a suggestion, so Kevin can choose not to change it. Formally, OpenJFX N supports JDK N-1, so for 17 we should be able to use features from 16. It was decided a while back not to force-fail on older JDK versions and let it evolve naturally. While in this case the change is small and might not be worth it alone, many of the recent language changes are geared towards better readability and reduction of possible mistakes, and we will be hurting ourselves in the long run if we don't pick those up. Every PR is relatively small and doesn't require the new features it can take advantage of, but if we go this way then we will be stuck with JDK 11 until something like Valhalla comes out. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From fthevenet at openjdk.java.net Sun Jan 24 19:00:44 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sun, 24 Jan 2021 19:00:44 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sun, 24 Jan 2021 18:09:03 GMT, Nir Lisker wrote: > Formally, OpenJFX N supports JDK N-1, so for 17 we should be able to use features from 16. It was decided a while back not to force-fail on older JDK versions and let it evolve naturally. That's the bit of information I was missing, thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From tsayao at openjdk.java.net Mon Jan 25 01:21:40 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 25 Jan 2021 01:21:40 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> Message-ID: <8Wn8DBDp_UqK56hh7U7Xcqt8c1iJpFLwD3fZCUdsgH8=.b9d83da6-0278-47c9-b752-b814ac0c1e43@github.com> On Tue, 22 Sep 2020 01:12:44 GMT, Thiago Milczarek Sayao wrote: >> Rebased onto "master" and squashed commits. > > Tested on Ubuntu 20.04 > > 756 tests completed, 6 failed, 110 skipped > > Failed: > test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED > java.lang.AssertionError: Timeout: Failed to receive onAction callback. > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) > at test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) > at test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) > > test.robot.javafx.scene.RobotTest > testKeyPress FAILED > org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) > at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) > > test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > resizeColumnToFitContentTest FAILED > java.lang.AssertionError: resizeColumnToFitContent failed > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) > > test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(62,62,62,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED > junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) > > test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > > For some reason the html report is not being generated. > > **Second run:** > 756 tests completed, 4 failed, 110 skipped > > test.robot.javafx.scene.RobotTest > testKeyPress FAILED > org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) > at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) > > test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED > junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) > > test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) > at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) I would prefer this approach: https://github.com/openjdk/jfx/pull/367 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Mon Jan 25 01:24:03 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 25 Jan 2021 01:24:03 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend [v2] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. 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 20 additional commits since the last revision: - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #15 from openjdk/master Update from jfx - Avoid redundant resize notify - Fix parent window being resizable (it should not) - Minor fix to positioning - Small adjustment - Fixes - Revert files - Replace the window size & positining code - Merge pull request #14 from openjdk/master Merge master - ... and 10 more: https://git.openjdk.java.net/jfx/compare/d304d2ea...2be1ba7e ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/bdfd0deb..2be1ba7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=00-01 Stats: 15117 lines in 291 files changed: 1191 ins; 12297 del; 1629 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Mon Jan 25 02:37:57 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 25 Jan 2021 02:37:57 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend [v3] In-Reply-To: References: Message-ID: <-VdaW40KcjZGbLNGvf1Ragoj3Tvyu0C_axGRgDOTyTE=.00b825d8-646f-4755-b262-6028e7d0ac2b@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert change to reduce size notify events due to frame extents adjustment - it makes some tests fail. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/2be1ba7e..e8528ef2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From rlichten at openjdk.java.net Mon Jan 25 11:35:44 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 25 Jan 2021 11:35:44 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 19:01:13 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS >> >> Corrections as per Kevin Rushforth's comments. >> Also added two more test cases that test right-to-left node orientation. >> Fixed the implementation and the API documentation. > > modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 302: > >> 300: >> 301: >> 302: > > Minor: there should only be one blank line here. Agreed. Additional lines removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Mon Jan 25 11:40:08 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 25 Jan 2021 11:40:08 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v3] In-Reply-To: References: Message-ID: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Removed node orientation from API doc. Removed extra blank lines. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/383/files - new: https://git.openjdk.java.net/jfx/pull/383/files/67a7da14..b02dcb02 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/383.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/383/head:pull/383 PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Mon Jan 25 11:40:09 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 25 Jan 2021 11:40:09 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 18:54:35 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS >> >> Corrections as per Kevin Rushforth's comments. >> Also added two more test cases that test right-to-left node orientation. >> Fixed the implementation and the API documentation. > > modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 237: > >> 235: * NodeOrientation.RIGHT_TO_LEFT is set. >> 236: * Using NodeOrientation.RIGHT_TO_LEFT will also "mirror" the meaning of Side.LEFT and >> 237: * Side.RIGHT respectively. > > We don't document the effect of node orientation in other controls or in charts, so I wouldn't want to mention it here. Instead you can document the behavior assuming the default effective orientation of `LEFT_TO_RIGHT` (without mentioning it). > > You could make the case that we should document more precisely the effect or NodeOrientation, but that would be a large task, and not something I would want to do for an isolated control in the course of a bug fix (and it would require a CSR). > > The rest of the doc changes look good and don't need a CSR. Thanks for clarifying. I have adapted the documentation accordingly. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From fastegal at openjdk.java.net Mon Jan 25 12:55:46 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 25 Jan 2021 12:55:46 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: References: <7obiyksiibdmp-iljr0KzQMuVTAkO7k1B4_9iHNYkj4=.c49cd8f3-c96b-4513-9097-bde3201dd14c@github.com> Message-ID: On Mon, 18 Jan 2021 16:13:58 GMT, Jeanette Winzenburg wrote: > > > thanks, that's about the lines of my thoughts as well :) Will file a separate doc bug for skinnable cleanup fyi: just filed https://bugs.openjdk.java.net/browse/JDK-8260364 ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From fastegal at swingempire.de Mon Jan 25 14:09:55 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 25 Jan 2021 15:09:55 +0100 Subject: Discuss: SkinBase - add api to support register InvalidationListeners In-Reply-To: <20210111125053.Horde.IOsqixdIuW79BS-gH3_XTQ6@webmail.df.eu> References: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> <9d1ec353-08ed-fb33-a1b0-c09a0e253b1d@oracle.com> <20210111125053.Horde.IOsqixdIuW79BS-gH3_XTQ6@webmail.df.eu> Message-ID: <20210125150955.Horde.29vgpWdE6C7kz4mWLkZ1kQ1@webmail.df.eu> After playing a bit with the issue, it looks like it might be a good idea to go a step further and also add support for listChangeListener, added some finger-flexing to the issue https://bugs.openjdk.java.net/browse/JDK-8258777 To feel the code's weight (-lessness :), there's a gist comparing the effect w/out api https://gist.github.com/kleopatra/fcce1e40c48e84b37f62631df348be90 -- Jeanette Zitat von Jeanette Winzenburg : > Thanks, Kevin :) > > Starting work. > > -- Jeanette > > Zitat von Kevin Rushforth : > >> I think this sounds like a very natural addition to the API. Making >> it easier for controls to clean up after themselves seems like a win. >> >> -- Kevin >> >> >> On 1/7/2021 5:45 AM, Jeanette Winzenburg wrote: >>> >>> Recently filed (RFE) >>> https://bugs.openjdk.java.net/browse/JDK-8258777 - it's about >>> adding api to support un/register invalidationListener just the >>> same way as changeListener. >>> >>> Trigger was work on cleaning up skins such that they don't >>> misbehave (f.i. leaking memory or throwing exception, >>> https://bugs.openjdk.java.net/browse/JDK-8241364) on switching the >>> skin. Most of the related issues boil down to incomplete removal >>> of listeners. As far as manual added (but not removed) >>> changeListeners are involved, the fix is to use >>> skin.registerChangeListener: all those are auto-removed in >>> skinbase.dispose. >>> >>> For InvalidationListeners, the fix is cumbersome: it requires >>> storing both the listener and its weak wrapper, manually adding >>> the weak wrapper and manually removing it in dispose. Getting >>> really boring if a skin (like TextInputXX) registers many of them .. >>> >>> IMO, not having symmetric support of invalidation- vs >>> changeListeners in SkinBase api very much feels like an omission - >>> which would be fixed by this :) >>> >>> Opinions, please. >>> >>> -- Jeanette >>> From kcr at openjdk.java.net Mon Jan 25 14:54:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 14:54:41 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sun, 24 Jan 2021 18:58:25 GMT, Frederic Thevenet wrote: >> It was a suggestion, so Kevin can choose not to change it. >> >> Formally, OpenJFX N supports JDK N-1, so for 17 we should be able to use features from 16. It was decided a while back not to force-fail on older JDK versions and let it evolve naturally. >> >> While in this case the change is small and might not be worth it alone, many of the recent language changes are geared towards better readability and reduction of possible mistakes, and we will be hurting ourselves in the long run if we don't pick those up. Every PR is relatively small and doesn't require the new features it can take advantage of, but if we go this way then we will be stuck with JDK 11 until something like Valhalla comes out. > >> Formally, OpenJFX N supports JDK N-1, so for 17 we should be able to use features from 16. It was decided a while back not to force-fail on older JDK versions and let it evolve naturally. > > That's the bit of information I was missing, thanks. Bumping the minimum version of the JDK that is required to run the current version of JavaFX requires prior discussion on the openjfx-dev mailing list and a separate JBS Enhancement, like we did when we bumped the minimum to JDK 11 with [JDK-8209966](https://bugs.openjdk.java.net/browse/JDK-8209966) + [JDK-8210093](https://bugs.openjdk.java.net/browse/JDK-8210093). We wouldn't do it in connection with a bug fix such as this. Having said that, I was already thinking that JavaFX 17 is a good time to consider bumping the minimum to allow using some of the newer JDK language features, so I'll start that discussion on the list soon. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 14:54:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 14:54:44 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Sat, 23 Jan 2021 23:12:35 GMT, Nir Lisker wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1250: > >> 1248: default: >> 1249: return com.sun.glass.events.KeyEvent.VK_UNDEFINED; >> 1250: } > > Also expression switch here. See above. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 336: > >> 334: /** >> 335: * Returns a flag indicating whether the key corresponding to {@code keyCode} >> 336: * is in the locked or "on" state. > > I would write "locked, or "on", state" or "locked (or "on") state" because in the current form it can be understood as 2 different conditions. Agreed. This was nagging at the back of my mind when I read it, but I didn't do anything about it. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 14:59:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 14:59:42 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 23:46:04 GMT, Nir Lisker wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 342: > >> 340: * specified {@code keyCode}, an empty {@code Optional} is returned. >> 341: * If the keyboard attached to the system doesn't have the specified key, >> 342: * {@code Boolean.FALSE} is returned. > > Not `Optional.of(false)`? Yes, that would be more accurate. So the replacement could be either `{@code Optional.of(false)}` or `an @{code Optional} containing {@code false}`. At least one JDK method uses something like the latter, so I'll probably go with that. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 15:06:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 15:06:47 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 23:49:04 GMT, Nir Lisker wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 351: > >> 349: * >> 350: * @throws IllegalArgumentException if {@code keyCode} is not one of the >> 351: * valid KeyCode values. > > `{@code KeyCode}` In addition, I see that two of the three `@throws` statements end with a period, which I'll remove, since the usual pattern is to omit it. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 15:09:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 15:09:41 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: <3OHO4PaeuoVOgR-nivPn2RxLuwwlomYPVTV0g2mSwMM=.de72c809-956d-49fa-8c48-3ab0e84dddf6@github.com> Message-ID: On Mon, 25 Jan 2021 14:50:58 GMT, Kevin Rushforth wrote: >>> Formally, OpenJFX N supports JDK N-1, so for 17 we should be able to use features from 16. It was decided a while back not to force-fail on older JDK versions and let it evolve naturally. >> >> That's the bit of information I was missing, thanks. > > Bumping the minimum version of the JDK that is required to run the current version of JavaFX requires prior discussion on the openjfx-dev mailing list and a separate JBS Enhancement, like we did when we bumped the minimum to JDK 11 with [JDK-8209966](https://bugs.openjdk.java.net/browse/JDK-8209966) + [JDK-8210093](https://bugs.openjdk.java.net/browse/JDK-8210093). We wouldn't do it in connection with a bug fix such as this. > > Having said that, I was already thinking that JavaFX 17 is a good time to consider bumping the minimum to allow using some of the newer JDK language features, so I'll start that discussion on the list soon. > Also, do we use a space after switch? I see many instances both with and without in the current source. According to the coding guidelines, there should always be a space after operators such as `if`, `for`, `while`, and `switch` (to distinguish them from method calls). If there are occurrences of `switch(expr)` without the space, they are not following the guidelines. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 15:30:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 15:30:00 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v2] In-Reply-To: References: Message-ID: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix docs to address review coments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/385/files - new: https://git.openjdk.java.net/jfx/pull/385/files/a8adc594..cb0e10a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/385/head:pull/385 PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 23:08:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 23:08:58 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v3] In-Reply-To: References: Message-ID: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Use XkbGetNamedIndicator on Linux instead of relying on the (unreliable) GDK method. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/385/files - new: https://git.openjdk.java.net/jfx/pull/385/files/cb0e10a7..c4961b16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=01-02 Stats: 49 lines in 2 files changed: 30 ins; 3 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/385/head:pull/385 PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 23:16:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 23:16:43 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v3] In-Reply-To: References: Message-ID: On Sat, 23 Jan 2021 16:44:11 GMT, Kevin Rushforth wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use XkbGetNamedIndicator on Linux instead of relying on the (unreliable) GDK method. > > modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 361: > >> 359: switch (keyCode) { >> 360: case com_sun_glass_events_KeyEvent_VK_CAPS_LOCK: >> 361: lockState = gdk_keymap_get_caps_lock_state(keyMap); > > It seems that `gdk_keymap_get_caps_lock_state` isn't reliable on GTK 3 either. At least not when I test it on a Linux VM. I may end up using raw Xlib calls instead (which would have the added benefit of removing the "ifdef" for GTK 3). I did end going this route. Instead of the `gdk_keymap` functions, I now use `XkbGetNamedIndicator`. It works on both GTK2 and GTK3 (unsurprisingly, since it isn't using GTK / GDK at all), and correctly reports the state of the keys even if the lock state is toggled when the program is not running or does not have focus. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Mon Jan 25 23:52:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 25 Jan 2021 23:52:43 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <8Wn8DBDp_UqK56hh7U7Xcqt8c1iJpFLwD3fZCUdsgH8=.b9d83da6-0278-47c9-b752-b814ac0c1e43@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> <8Wn8DBDp_UqK56hh7U7Xcqt8c1iJpFLwD3fZCUdsgH8=.b9d83da6-0278-47c9-b752-b814ac0c1e43@github.com> Message-ID: On Mon, 25 Jan 2021 01:18:30 GMT, Thiago Milczarek Sayao wrote: >> Tested on Ubuntu 20.04 >> >> 756 tests completed, 6 failed, 110 skipped >> >> Failed: >> test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED >> java.lang.AssertionError: Timeout: Failed to receive onAction callback. >> at org.junit.Assert.fail(Assert.java:91) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) >> at test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) >> at test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) >> >> test.robot.javafx.scene.RobotTest > testKeyPress FAILED >> org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> >> at org.junit.Assert.assertEquals(Assert.java:123) >> at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) >> at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) >> >> test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > resizeColumnToFitContentTest FAILED >> java.lang.AssertionError: resizeColumnToFitContent failed >> at org.junit.Assert.fail(Assert.java:91) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) >> >> test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(62,62,62,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) >> >> test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) >> >> test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) >> >> >> For some reason the html report is not being generated. >> >> **Second run:** >> 756 tests completed, 4 failed, 110 skipped >> >> test.robot.javafx.scene.RobotTest > testKeyPress FAILED >> org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> >> at org.junit.Assert.assertEquals(Assert.java:123) >> at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) >> at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) >> >> test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) >> >> test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) >> >> test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED >> junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) >> at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) >> at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > I would prefer this approach: > https://github.com/openjdk/jfx/pull/367 Given the alternate approach that you propose to pursue (which I agree is a better option), this PR should either be closed or moved to Draft. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Tue Jan 26 00:04:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Jan 2021 00:04:42 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: Message-ID: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> On Tue, 15 Dec 2020 12:24:01 GMT, Thiago Milczarek Sayao wrote: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. This does look like a much more manageable approach. One thing to be aware of from a bookkeeping point of view is that a JBS issues is resolved by a single PR. Once a PR has been integrated for a given JBS bug ID, that bug ID cannot be reused. This means that each separate PR will need it's own JBS issue to be filed, even if those enhancements taken together are part of a larger set of improvements. Incremental improvements are fine (and in this case a good way to proceed), but you might give some thought to the title of each such improvement. I wouldn't want to see 5 fixes go in each with the same title of `Simplify and update glass gtk backend`. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From kcr at openjdk.java.net Tue Jan 26 00:25:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Jan 2021 00:25:44 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 11:40:08 GMT, Robert Lichtenberger wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS > > Removed node orientation from API doc. > Removed extra blank lines. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From nlisker at gmail.com Tue Jan 26 18:56:01 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 26 Jan 2021 20:56:01 +0200 Subject: Wrong behavior of LocalDateTimeStringConverter Message-ID: Hi, I was looking at LocalDateTimeStringConverter and I think that there is a possibility for wrong behavior. The class uses an internal LdtConverter helper class that instantiates all its fields, but they are not final. In its toString method, the chronology field is reassigned if the formatting fails on that specific value. Then, if another value is passed in, the new chronology field value is used, which could give different results from having it been passed in first. In addition, the default formatter and parser are built using the chronology which was used at the time of their creation, and can become inconsistent if the chronology changes later. I think that this class should be immutable, with all null checks being done on instantiation and assigning defaults based on that. I propose to change this behavior as part of a refactoring effort I'm making in the converters package. Note that this internal class is used by LocalDate and LocalTime converters as well. - Nir From nlisker at gmail.com Tue Jan 26 20:08:24 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 26 Jan 2021 22:08:24 +0200 Subject: Exposed implementation details in DateTimeStringConverter Message-ID: Hi, DateTimeStringConverter exposes final protected fields that are used for internal implementation. These fields should have been private or package-private. The reasons are: 1. A comment above them refers to them as private fields. 2. They have no documentation attached. 3. They are useless to the user (except for the DateFormat one) as some of their values are unused, depending on the construction method, and they are discarded after it. 4. There is a DateFormat getter method specifically for this field only, which is the only field that is relevant during the life of the class. It makes no sense to expose the field in addition. I suggest deprecating these fields for removal from the public API. There are minimal risks that these fields are being read by the user through direct access. - Nir From kevin.rushforth at oracle.com Tue Jan 26 22:18:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jan 2021 14:18:42 -0800 Subject: Exposed implementation details in DateTimeStringConverter In-Reply-To: References: Message-ID: <468fcade-a846-123a-3024-f4d29e4365f7@oracle.com> I presume you mean these three? ??? protected final Locale locale; ??? protected final String pattern; ??? protected final DateFormat dateFormat; and maybe also these two? ??? /** ???? * @since JavaFX 8u40 ???? */ ??? protected final int dateStyle; ??? /** ???? * @since JavaFX 8u40 ???? */ ??? protected final int timeStyle; Applications can't use them directly (outside a subclass), so the questions are: Do subclasses need access to these fields, and do we intend that an application be able to subclass the parent class with their own implementation? The fields are used by the two subclasses that we provide in the same package, so unless we expect applications or third-party libraries to access them, which I don't think we do, it doesn't seem like they should be part of the public API. We should either file a bug to document them or to deprecate them (probably for removal, but I wouldn't be in too big a big hurry to remove them). I suspect deprecating them is fine. -- Kevin On 1/26/2021 12:08 PM, Nir Lisker wrote: > Hi, > > DateTimeStringConverter exposes final protected fields that are used for > internal implementation. These fields should have been private or > package-private. The reasons are: > 1. A comment above them refers to them as private fields. > 2. They have no documentation attached. > 3. They are useless to the user (except for the DateFormat one) as some of > their values are unused, depending on the construction method, and they are > discarded after it. > 4. There is a DateFormat getter method specifically for this field only, > which is the only field that is relevant during the life of the class. It > makes no sense to expose the field in addition. > > I suggest deprecating these fields for removal from the public API. There > are minimal risks that these fields are being read by the user through > direct access. > > - Nir From kevin.rushforth at oracle.com Tue Jan 26 22:31:10 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Jan 2021 14:31:10 -0800 Subject: Discuss: SkinBase - add api to support register InvalidationListeners In-Reply-To: <20210125150955.Horde.29vgpWdE6C7kz4mWLkZ1kQ1@webmail.df.eu> References: <20210107144553.Horde.cXPxwYWXVBNEu7NmcOaTRg1@webmail.df.eu> <9d1ec353-08ed-fb33-a1b0-c09a0e253b1d@oracle.com> <20210111125053.Horde.IOsqixdIuW79BS-gH3_XTQ6@webmail.df.eu> <20210125150955.Horde.29vgpWdE6C7kz4mWLkZ1kQ1@webmail.df.eu> Message-ID: I like the look of that. It's nice to see more boilerplate code being taken care of by shared code in the SkinBase superclass. -- Kevin On 1/25/2021 6:09 AM, Jeanette Winzenburg wrote: > > After playing a bit with the issue, it looks like it might be a good > idea to go a step further and also add support for listChangeListener, > added some finger-flexing to the issue > https://bugs.openjdk.java.net/browse/JDK-8258777 > > To feel the code's weight (-lessness :), there's a gist comparing the > effect w/out api > https://gist.github.com/kleopatra/fcce1e40c48e84b37f62631df348be90 > > -- Jeanette > > > Zitat von Jeanette Winzenburg : > >> Thanks, Kevin :) >> >> Starting work. >> >> -- Jeanette >> >> Zitat von Kevin Rushforth : >> >>> I think this sounds like a very natural addition to the API. Making >>> it easier for controls to clean up after themselves seems like a win. >>> >>> -- Kevin >>> >>> >>> On 1/7/2021 5:45 AM, Jeanette Winzenburg wrote: >>>> >>>> Recently filed (RFE) >>>> https://bugs.openjdk.java.net/browse/JDK-8258777 - it's about >>>> adding api to support un/register invalidationListener just the >>>> same way as changeListener. >>>> >>>> Trigger was work on cleaning up skins such that they don't >>>> misbehave (f.i. leaking memory or throwing exception, >>>> https://bugs.openjdk.java.net/browse/JDK-8241364) on switching the >>>> skin. Most of the related issues boil down to incomplete removal of >>>> listeners. As far as manual added (but not removed) changeListeners >>>> are involved, the fix is to use skin.registerChangeListener: all >>>> those are auto-removed in skinbase.dispose. >>>> >>>> For InvalidationListeners, the fix is cumbersome: it requires >>>> storing both the listener and its weak wrapper, manually adding the >>>> weak wrapper and manually removing it in dispose. Getting really >>>> boring if a skin (like TextInputXX) registers many of them .. >>>> >>>> IMO, not having symmetric support of invalidation- vs >>>> changeListeners in SkinBase api very much feels like an omission - >>>> which would be fixed by this :) >>>> >>>> Opinions, please. >>>> >>>> -- Jeanette >>>> > > > From nlisker at gmail.com Wed Jan 27 01:18:43 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 27 Jan 2021 03:18:43 +0200 Subject: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: <374ba495-c3df-f4f0-e4a4-43e39cf61476@oracle.com> References: <374ba495-c3df-f4f0-e4a4-43e39cf61476@oracle.com> Message-ID: I filed JDK-8260468[1]. Looking at it more closely, it seems that the implementations of toString and fromString are incorrect in another place. If the converter is created with a given formatter and/or parser, then they can have their own chronologies, but these methods always use the default one in this case (since a chronology wasn't given in construction time). I think that the default chronology should only be used if one was not set for the parser or formatter. [1] https://bugs.openjdk.java.net/browse/JDK-8260468 On Tue, Jan 26, 2021 at 11:57 PM Kevin Rushforth wrote: > Yes, this does seem like a bug. It should be fixed in a separate bug > (prior to whatever refactoring you might propose) with an associated CSR. > > -- Kevin > > > On 1/26/2021 10:56 AM, Nir Lisker wrote: > > Hi, > > > > I was looking at LocalDateTimeStringConverter and I think that there is a > > possibility for wrong behavior. > > The class uses an internal LdtConverter helper class that instantiates > all > > its fields, but they are not final. In its toString method, the > chronology > > field is reassigned if the formatting fails on that specific value. Then, > > if another value is passed in, the new chronology field value is used, > > which could give different results from having it been passed in first. > In > > addition, the default formatter and parser are built using the chronology > > which was used at the time of their creation, and can become > > inconsistent if the chronology changes later. > > > > I think that this class should be immutable, with all null checks being > > done on instantiation and assigning defaults based on that. I propose to > > change this behavior as part of a refactoring effort I'm making in the > > converters package. > > > > Note that this internal class is used by LocalDate and LocalTime > converters > > as well. > > > > - Nir > > From nlisker at gmail.com Wed Jan 27 01:37:38 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 27 Jan 2021 03:37:38 +0200 Subject: Exposed implementation details in DateTimeStringConverter In-Reply-To: <468fcade-a846-123a-3024-f4d29e4365f7@oracle.com> References: <468fcade-a846-123a-3024-f4d29e4365f7@oracle.com> Message-ID: Yes, sorry, I should have been more clear. Only dateFormat is used during runtime, the other 4 are used only during construction to create a DateFormat if one is not given, they shouldn't even be fields. dateFormat encodes all the information of the converter and has a getter (also protected access and maybe should be deprecated as well). I don't see how subclasses could use those even if someone wanted to make a subclass for some reason. I filed JDK-8260475 [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8260475 On Wed, Jan 27, 2021 at 12:19 AM Kevin Rushforth wrote: > I presume you mean these three? > > protected final Locale locale; > protected final String pattern; > protected final DateFormat dateFormat; > > and maybe also these two? > > /** > * @since JavaFX 8u40 > */ > protected final int dateStyle; > > /** > * @since JavaFX 8u40 > */ > protected final int timeStyle; > > Applications can't use them directly (outside a subclass), so the > questions are: Do subclasses need access to these fields, and do we > intend that an application be able to subclass the parent class with > their own implementation? > > The fields are used by the two subclasses that we provide in the same > package, so unless we expect applications or third-party libraries to > access them, which I don't think we do, it doesn't seem like they should > be part of the public API. > > We should either file a bug to document them or to deprecate them > (probably for removal, but I wouldn't be in too big a big hurry to > remove them). I suspect deprecating them is fine. > > -- Kevin > > > On 1/26/2021 12:08 PM, Nir Lisker wrote: > > Hi, > > > > DateTimeStringConverter exposes final protected fields that are used for > > internal implementation. These fields should have been private or > > package-private. The reasons are: > > 1. A comment above them refers to them as private fields. > > 2. They have no documentation attached. > > 3. They are useless to the user (except for the DateFormat one) as some > of > > their values are unused, depending on the construction method, and they > are > > discarded after it. > > 4. There is a DateFormat getter method specifically for this field only, > > which is the only field that is relevant during the life of the class. It > > makes no sense to expose the field in addition. > > > > I suggest deprecating these fields for removal from the public API. There > > are minimal risks that these fields are being read by the user through > > direct access. > > > > - Nir > > From aghaisas at openjdk.java.net Wed Jan 27 10:39:45 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 27 Jan 2021 10:39:45 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 15:07:34 GMT, Nir Lisker wrote: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From aghaisas at openjdk.java.net Wed Jan 27 11:24:48 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 27 Jan 2021 11:24:48 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 11:40:08 GMT, Robert Lichtenberger wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS > > Removed node orientation from API doc. > Removed extra blank lines. modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 49: > 47: import static com.sun.javafx.scene.control.ContextMenuContentShim.*; > 48: > 49: import java.io.File; These 3 imports are unused. Remove them. modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 312: > 310: if (getItems().size() == 0) return; > 311: getScene().setNodeOrientation(anchor.getEffectiveNodeOrientation()); > 312: setAnchorLocation(AnchorLocation.CONTENT_TOP_LEFT); Do we need to handle RTL case here? ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Wed Jan 27 12:08:45 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 27 Jan 2021 12:08:45 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 10:41:25 GMT, Ajit Ghaisas wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS >> >> Removed node orientation from API doc. >> Removed extra blank lines. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ContextMenuTest.java line 49: > >> 47: import static com.sun.javafx.scene.control.ContextMenuContentShim.*; >> 48: >> 49: import java.io.File; > > These 3 imports are unused. Remove them. Good catch. I removed the (now unused) imports. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Wed Jan 27 12:14:54 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 27 Jan 2021 12:14:54 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v4] In-Reply-To: References: Message-ID: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Removed unnecessary imports. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/383/files - new: https://git.openjdk.java.net/jfx/pull/383/files/b02dcb02..ba803abf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=383&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/383.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/383/head:pull/383 PR: https://git.openjdk.java.net/jfx/pull/383 From rlichten at openjdk.java.net Wed Jan 27 12:14:55 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 27 Jan 2021 12:14:55 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 11:21:19 GMT, Ajit Ghaisas wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS >> >> Removed node orientation from API doc. >> Removed extra blank lines. > > modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java line 312: > >> 310: if (getItems().size() == 0) return; >> 311: getScene().setNodeOrientation(anchor.getEffectiveNodeOrientation()); >> 312: setAnchorLocation(AnchorLocation.CONTENT_TOP_LEFT); > > Do we need to handle RTL case here? I don't think so. At least we didn't handle the RTL case here until now. The call to setAnchorLocation(AnchorLocation.CONTENT_TOP_LEFT); is only neccessary to "reset" the anchor location in case we called show with a Side before. ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From kevin.rushforth at oracle.com Wed Jan 27 12:42:14 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Jan 2021 04:42:14 -0800 Subject: [External] : Re: Wrong behavior of LocalDateTimeStringConverter In-Reply-To: References: <374ba495-c3df-f4f0-e4a4-43e39cf61476@oracle.com> Message-ID: <02a81523-a413-b171-c727-dccc7f3aa3fd@oracle.com> Yes, that also seems like a bug. -- Kevin On 1/26/2021 5:18 PM, Nir Lisker wrote: > I filed JDK-8260468[1]. > > Looking at it more closely, it seems that the implementations of > toString and fromString are incorrect in another place. If the > converter is created with a given formatter and/or parser, then they > can have their own chronologies, but these methods always use the > default one in this case (since a chronology wasn't given in > construction time). > I think that the default chronology should only be used if one was not > set for the parser or formatter. > > [1] https://bugs.openjdk.java.net/browse/JDK-8260468 > > > On Tue, Jan 26, 2021 at 11:57 PM Kevin Rushforth > > wrote: > > Yes, this does seem like a bug. It should be fixed in a separate bug > (prior to whatever refactoring you might propose) with an > associated CSR. > > -- Kevin > > > On 1/26/2021 10:56 AM, Nir Lisker wrote: > > Hi, > > > > I was looking at LocalDateTimeStringConverter and I think that > there is a > > possibility for wrong behavior. > > The class uses an internal LdtConverter helper class that > instantiates all > > its fields, but they are not final. In its toString method, the > chronology > > field is reassigned if the formatting fails on that specific > value. Then, > > if another value is passed in, the new chronology field value is > used, > > which could give different results from having it been passed in > first. In > > addition, the default formatter and parser are built using the > chronology > > which was used at the time of their creation, and can become > > inconsistent if the chronology changes later. > > > > I think that this class should be immutable, with all null > checks being > > done on instantiation and assigning defaults based on that. I > propose to > > change this behavior as part of a refactoring effort I'm making > in the > > converters package. > > > > Note that this internal class is used by LocalDate and LocalTime > converters > > as well. > > > > - Nir > From kcr at openjdk.java.net Wed Jan 27 12:51:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Jan 2021 12:51:49 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v4] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 12:14:54 GMT, Robert Lichtenberger wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS > > Removed unnecessary imports. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From aghaisas at openjdk.java.net Wed Jan 27 13:12:49 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 27 Jan 2021 13:12:49 GMT Subject: RFR: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS [v4] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 12:14:54 GMT, Robert Lichtenberger wrote: >> By using the anchor location facility of PopupWindows we can avoid miscalculation of the >> menu's height entirely. >> This fix also cleans up some documentation issues. >> This fix introduces tests that check the correct positioning (test_position_) >> test_position_withCSS reproduces the problem that is fixed with this patch. >> The other test_position_ cases serve as "proof" that no regressions are introduces. >> They work before and after the fix is introduced. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS > > Removed unnecessary imports. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From kcr at openjdk.java.net Wed Jan 27 13:16:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Jan 2021 13:16:45 GMT Subject: RFR: 8260246: Ensemble: Update version of Lucene to 7.7.3 Message-ID: This updates to the latest bug fix version of Lucene 7, which is version 7.7.3. Since it is only an update to the micro version, there is no need to regenerate the index. See [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt). ------------- Commit messages: - 8260246: Ensemble: Update version of Lucene to 7.7.3 Changes: https://git.openjdk.java.net/jfx/pull/387/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=387&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260246 Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/387.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/387/head:pull/387 PR: https://git.openjdk.java.net/jfx/pull/387 From kcr at openjdk.java.net Wed Jan 27 13:35:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Jan 2021 13:35:49 GMT Subject: RFR: 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak Message-ID: Prism implements a dirty region optimization, where in many cases, only part of the scene graph is re-rendered when something changes. In support of this, the `ViewPainter` class in the Quantum Toolkit keeps an array of node paths, `ROOT_PATHS`, which is a list of sub-trees in the scene graph that need to be rendered based on a change to that node. The entries in the `ROOT_PATHS` array are intended to be transient during the rendering of a single pass of a single scene. They are recreated every time a scene is rendered. The leak occurs because the entries are not cleared after being used. The fix is to clear each entry after it is rendered. In addition to static analysis, which shows that the entries are never used again after a frame is rendered, I have done a full build and test, including manual tests, to be sure that there is no regression. I have added a test that will fail consistently on Mac and Windows (and intermittently on Linux) without the fix. It passes consistently on all platforms with the fix. Even though this is a simple change, it is in an area that has historically been fragile, so I would like two reviewers. ------------- Commit messages: - 8259046: ViewPainter.ROOT_PATHS holds reference to Scene causing memory leak Changes: https://git.openjdk.java.net/jfx/pull/388/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259046 Stats: 116 lines in 2 files changed: 116 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/388.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/388/head:pull/388 PR: https://git.openjdk.java.net/jfx/pull/388 From rlichten at openjdk.java.net Wed Jan 27 13:49:43 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 27 Jan 2021 13:49:43 GMT Subject: Integrated: 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 06:42:19 GMT, Robert Lichtenberger wrote: > By using the anchor location facility of PopupWindows we can avoid miscalculation of the > menu's height entirely. > This fix also cleans up some documentation issues. > This fix introduces tests that check the correct positioning (test_position_) > test_position_withCSS reproduces the problem that is fixed with this patch. > The other test_position_ cases serve as "proof" that no regressions are introduces. > They work before and after the fix is introduced. This pull request has now been integrated. Changeset: 6c1a0ca7 Author: Robert Lichtenberger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6c1a0ca7 Stats: 192 lines in 3 files changed: 164 ins; 14 del; 14 mod 8228363: ContextMenu.show with side=TOP does not work the first time in the presence of CSS Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/383 From johan.vos at gluonhq.com Wed Jan 27 15:01:06 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 27 Jan 2021 16:01:06 +0100 Subject: RFR: 8260519: Change JavaFX release version in 11-dev to 11.0.11 Message-ID: Hi Kevin, Please review http://cr.openjdk.java.net/~jvos/8260519/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8260519 (bumping the security version in 11-dev) Thanks, - Johan From kevin.rushforth at oracle.com Wed Jan 27 15:33:05 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Jan 2021 07:33:05 -0800 Subject: RFR: 8260519: Change JavaFX release version in 11-dev to 11.0.11 In-Reply-To: References: Message-ID: <31ec10b2-d9af-7f6e-a812-c274e35dfcbb@oracle.com> +1 On 1/27/2021 7:01 AM, Johan Vos wrote: > Hi Kevin, > > Please review http://cr.openjdk.java.net/~jvos/8260519/webrev.00/ which > fixes https://bugs.openjdk.java.net/browse/JDK-8260519 (bumping the > security version in 11-dev) > > Thanks, > > - Johan From tsayao at openjdk.java.net Wed Jan 27 16:22:45 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 27 Jan 2021 16:22:45 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.3223abb7-1a94-4053-ad6f-c236fc9e44b2@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.2a95b59f-e33b-452d-a8c0-197979f41e53@github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.c078948c-8d04-4e3a-86ea-89406f7ffdc4@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.9f745afb-87f7-4854-b64b-8949c694cb6a@github.com> <8Wn8DBDp_UqK56hh7U7Xcqt8c1iJpFLwD3fZCUdsgH8=.b9d83da6-0278-47c9-b752-b814ac0c1e43@github.com> Message-ID: <81KDjzggqJ_WCMwd8AY2r565MCCHejmjZpoVsDLWIxY=.05740386-9bc9-4d69-9ef7-9f7a4487cda9@github.com> On Mon, 25 Jan 2021 23:49:38 GMT, Kevin Rushforth wrote: >> I would prefer this approach: >> https://github.com/openjdk/jfx/pull/367 > > Given the alternate approach that you propose to pursue (which I agree is a better option), this PR should either be closed or moved to Draft. Closing it in favor of #367 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 27 16:22:46 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 27 Jan 2021 16:22:46 GMT Subject: Withdrawn: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.81d1f7b6-9f99-4fb4-aa31-477d04b7943a@github.com> Message-ID: <4VfZ0GgjySNuyiBRVIGM5D44chlaNeEjK7Q1YNgAF6Y=.da028c1c-bc74-48bd-943c-db4cc0cbe22e@github.com> On Mon, 6 Jan 2020 00:28:14 GMT, Thiago Milczarek Sayao wrote: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jan 27 16:42:45 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 27 Jan 2021 16:42:45 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> Message-ID: <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> On Tue, 26 Jan 2021 00:01:44 GMT, Kevin Rushforth wrote: >> This is a new approach to rewrite parts of gtk glass backend to be more clean. >> >> I will provide small "manageable" PR to incrementally make the backend better. >> >> This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. >> >> Current status (Ubuntu 20.04): >> ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) >> >> (*) Some of the iconify tests are also failing on the main branch. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. > > This does look like a much more manageable approach. > > One thing to be aware of from a bookkeeping point of view is that a JBS issues is resolved by a single PR. Once a PR has been integrated for a given JBS bug ID, that bug ID cannot be reused. > > This means that each separate PR will need it's own JBS issue to be filed, even if those enhancements taken together are part of a larger set of improvements. Incremental improvements are fine (and in this case a good way to proceed), but you might give some thought to the title of each such improvement. I wouldn't want to see 5 fixes go in each with the same title of `Simplify and update glass gtk backend`. It's been pointed out about this https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events My tests point out that this PR causes less sizing events that the current master branch, but I also think this could be improved further. But, by the nature of X and window managers, window sizes does not account decoration frames, but javafx does (probably mimicking windows behavior). Given this information I probably could reduce further the sizing events, but not make it equivalent to windows. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From arapte at openjdk.java.net Thu Jan 28 11:48:02 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Jan 2021 11:48:02 GMT Subject: RFR: 8256283: IndexOutOfBoundsException when sorting a TreeTableView [v2] In-Reply-To: References: Message-ID: > This particular issue JDK-8256283, is a specific case of IOOBE when, rootItem is not shown, some children including first child are selected, then all children are removed and sort() is invoked. The sort() fails with an IOOBE. > This PR only addresses this specific IOOBE. > Root cause of this issue is that the selection is not cleared after rootItems children are removed. In addition to this, there are few other scenarios when selection is not updated correctly, which are collected under an umbrella task [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Fix for [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217) would require good amount refactoring of selection model. > > The fix for this issue is to avoid sort() when rootItem.getChildren().isEmpty(). > Added a unit test with the fix, which fails without fix and passes with fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Review correction ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/384/files - new: https://git.openjdk.java.net/jfx/pull/384/files/f1e6c63a..89da162b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=384&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=384&range=00-01 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/384.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/384/head:pull/384 PR: https://git.openjdk.java.net/jfx/pull/384 From arapte at openjdk.java.net Thu Jan 28 11:52:43 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Jan 2021 11:52:43 GMT Subject: RFR: 8256283: IndexOutOfBoundsException when sorting a TreeTableView [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 17:48:15 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Review correction > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 582: > >> 580: try { >> 581: TreeItem rootItem = table.getRoot(); >> 582: if (rootItem == null | rootItem.getChildren().isEmpty()) return false; > > That should be `||` (boolean OR). In addition to being less clear, this will get an NPE if `rootItem` is ever null, since the bit-wise `|` operator doesn't short-curcuit the rest of the `if` test if the first term is true. > > Given that this would have caused a regression, and that we don't have a test that would catch it, can you add a test that sets the root to null and calls sort? It will fail with this version of the fix, but would pass without the fix and should pass once you update your fix. Sorry about that, It was a typo. But it did reveal the missing test. Corrected the operator to `||` and added a test as you suggested which fails only with the commit 1 of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/384 From kcr at openjdk.java.net Thu Jan 28 13:40:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 28 Jan 2021 13:40:47 GMT Subject: RFR: 8252935: Add treeShowing listener only when needed [v3] In-Reply-To: References: <3L5ZsgUcuNPS6MQIoJwz5daTJl9nhJ-qxlsluOOXHdw=.9345a53f-f529-4853-acc2-372e593921da@github.com> Message-ID: On Sun, 24 Jan 2021 15:25:06 GMT, John Hendrikx wrote: >> This is a PoC for performance testing. >> >> It contains commented out code in PopupWindow and ProgressIndicatorSkin and two tests are failing because of that. >> >> This code avoids registering two listeners (on Scene and on Window) for each and every Node to support the aforementioned classes. The complete change should update these two classes to add their own listeners instead. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add performance test > - Use registerChangeListener in ProgressIndicatorSkin The updated fix using `registerChangeListener` and the test look good. I left a few mostly-minor comments. tests/system/src/test/java/test/javafx/scene/NodeTreeShowingTest.java line 2: > 1: /* > 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. 2021 tests/system/src/test/java/test/javafx/scene/NodeTreeShowingTest.java line 125: > 123: }); > 124: > 125: for(int j = 0; j < 5; j++) { MInor: add space after `for` tests/system/src/test/java/test/javafx/scene/NodeTreeShowingTest.java line 49: > 47: /** > 48: * TODO fix > 49: * This test is based on the test case reported in JDK-8209830 Comment block needs to be updated to describe this bug. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/TreeShowingExpression.java line 2: > 1: /* > 2: * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved. change 2020 to 2021 ------------- PR: https://git.openjdk.java.net/jfx/pull/185 From kevin.rushforth at oracle.com Thu Jan 28 16:15:16 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 28 Jan 2021 08:15:16 -0800 Subject: JavaFX 16 is in Rampdown Phase Two (RDP2) Message-ID: <62307772-5693-ef01-5789-b811c1c42b6e@oracle.com> To: OpenJFX Developers As a reminder, JavaFX 16 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bugs, and test or doc bugs of any priority, can be fixed during RDP2. Explicit approval is needed for bug fixes (except for doc and test fixes), and all enhancements to go in to the jfx16 branch. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. We will use the same rules for RDP2 that the JDK uses [2], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 16 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx16-fix-request", "openjfx16-fix-yes", "openjfx16-fix-no" and "openjfx16-fix-nmi", "openjfx16-enhancement-request", "openjfx16-enhancement-yes", "openjfx16-enhancement-no" and "openjfx16-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into jfx16 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx16 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx16 --> master for the duration of the openjfx16 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in openjfx16. We need to be extremely careful about including anything that introduces risk. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 17 as of today). This is usually what we want. A PR should be targeted to `jfx16` if, and only if, it is intended for OpenJFX 16 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx16`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 17. Reviewers also need to be extra careful when reviewing PRs targeted to jfx16 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027837.html [2] http://openjdk.java.net/jeps/3 From kcr at openjdk.java.net Fri Jan 29 00:10:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 00:10:49 GMT Subject: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice Message-ID: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> As indicated in the JBS bug, using a `PixelReader` to read a scaled image in HiDPI mode, for example an `@2x` image, to read more than one pixel will read data from the wrong location in the image, usually leading to an IOOBE. The bug is in the `getPixelAccessor` method of Prism Image. The method correctly creates a new `Accessor` if one hasn't already been created, but then it unconditionally wraps the current `Accessor` in a `ScaledPixelAccessor` if the scale is > 1. So the second time this method is called, it created another `ScaledPixelAccessor` that wraps the first `ScaledPixelAccessor`, meaning that the indexes into the pixel array are multiplied by 4. This continues for each new call to this method. The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first time, when it is created. I added a test, which is run for both scaled and unscaled images, to ensure that we get the right value when reading a pixel, and that reading it a second time returns the same result. Without the fix, the new test will fail with IOOBE when the scale factor is two. Related to this, I initially commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see what would happen, and none of the existing tests caught it. The new test will catch this. ------------- Commit messages: - 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice Changes: https://git.openjdk.java.net/jfx/pull/389/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=389&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258986 Stats: 160 lines in 4 files changed: 157 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/389.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/389/head:pull/389 PR: https://git.openjdk.java.net/jfx/pull/389 From tschindl at openjdk.java.net Fri Jan 29 12:22:43 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 29 Jan 2021 12:22:43 GMT Subject: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice In-Reply-To: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> References: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> Message-ID: <19VAiNIfJFn3hh9Syin11sEQIrVo6Jyl42oWrNeAIFg=.2b17787d-e2c1-49a8-b6db-3ac6d277fdaa@github.com> On Fri, 29 Jan 2021 00:05:57 GMT, Kevin Rushforth wrote: > As indicated in the JBS bug, using a `PixelReader` to read a scaled image in HiDPI mode, for example an `@2x` image, to read more than one pixel will read data from the wrong location in the image, usually leading to an IOOBE. > > The bug is in the `getPixelAccessor` method of Prism Image. The method correctly creates a new `Accessor` if one hasn't already been created, but then it unconditionally wraps the current `Accessor` in a `ScaledPixelAccessor` if the scale is > 1. So the second time this method is called, it created another `ScaledPixelAccessor` that wraps the first `ScaledPixelAccessor`, meaning that the indexes into the pixel array are multiplied by 4. This continues for each new call to this method. > > The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first time, when it is created. > > I added a test, which is run for both scaled and unscaled images, to ensure that we get the right value when reading a pixel, and that reading it a second time returns the same result. Without the fix, the new test will fail with IOOBE when the scale factor is two. Related to this, I initially commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see what would happen, and none of the existing tests caught it. The new test will catch this. modules/javafx.graphics/src/main/java/com/sun/prism/Image.java line 654: > 652: } > 653: if (pixelScale != 1.0f) { > 654: pixelaccessor = new ScaledAccessor<>(pixelaccessor, pixelScale); is that really correct? I think you should not overwrite save the scaled pixelAccessor in the instance variable - if I read that correct with this change the following happens: if I call getPixelAccessor() 3 times I get a ScaledAccessor wrapping a ScaleAccessor wrapping a ScaledAccessor, wrapping one of ByteAccess, ByteRgbAccess, IntAccess ------------- PR: https://git.openjdk.java.net/jfx/pull/389 From kcr at openjdk.java.net Fri Jan 29 12:28:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 12:28:44 GMT Subject: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice In-Reply-To: <19VAiNIfJFn3hh9Syin11sEQIrVo6Jyl42oWrNeAIFg=.2b17787d-e2c1-49a8-b6db-3ac6d277fdaa@github.com> References: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> <19VAiNIfJFn3hh9Syin11sEQIrVo6Jyl42oWrNeAIFg=.2b17787d-e2c1-49a8-b6db-3ac6d277fdaa@github.com> Message-ID: On Fri, 29 Jan 2021 12:19:51 GMT, Tom Schindl wrote: >> As indicated in the JBS bug, using a `PixelReader` to read a scaled image in HiDPI mode, for example an `@2x` image, to read more than one pixel will read data from the wrong location in the image, usually leading to an IOOBE. >> >> The bug is in the `getPixelAccessor` method of Prism Image. The method correctly creates a new `Accessor` if one hasn't already been created, but then it unconditionally wraps the current `Accessor` in a `ScaledPixelAccessor` if the scale is > 1. So the second time this method is called, it created another `ScaledPixelAccessor` that wraps the first `ScaledPixelAccessor`, meaning that the indexes into the pixel array are multiplied by 4. This continues for each new call to this method. >> >> The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first time, when it is created. >> >> I added a test, which is run for both scaled and unscaled images, to ensure that we get the right value when reading a pixel, and that reading it a second time returns the same result. Without the fix, the new test will fail with IOOBE when the scale factor is two. Related to this, I initially commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see what would happen, and none of the existing tests caught it. The new test will catch this. > > modules/javafx.graphics/src/main/java/com/sun/prism/Image.java line 654: > >> 652: } >> 653: if (pixelScale != 1.0f) { >> 654: pixelaccessor = new ScaledAccessor<>(pixelaccessor, pixelScale); > > is that really correct? I think you should not overwrite/save the scaled pixelAccessor in the instance variable - if I read that correct with this change the following happens: if I call getPixelAccessor() 3 times I get a ScaledAccessor wrapping a ScaleAccessor wrapping a ScaledAccessor, wrapping one of ByteAccess, ByteRgbAccess, IntAccess No, that?s what used to happen before this fix. The fix moves the wrapping of the pixelAccessor with a ScaledPixelAxcessor inside the null check so it?s now only done once. ------------- PR: https://git.openjdk.java.net/jfx/pull/389 From tschindl at openjdk.java.net Fri Jan 29 12:35:44 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 29 Jan 2021 12:35:44 GMT Subject: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice In-Reply-To: References: <3Me5cX_YlxPrVfipsRImdTVRke-cnIk9TKy4EUwkrLI=.22f03557-9375-455d-82b0-56ffcc43701f@github.com> <19VAiNIfJFn3hh9Syin11sEQIrVo6Jyl42oWrNeAIFg=.2b17787d-e2c1-49a8-b6db-3ac6d277fdaa@github.com> Message-ID: On Fri, 29 Jan 2021 12:25:53 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/Image.java line 654: >> >>> 652: } >>> 653: if (pixelScale != 1.0f) { >>> 654: pixelaccessor = new ScaledAccessor<>(pixelaccessor, pixelScale); >> >> is that really correct? I think you should not overwrite/save the scaled pixelAccessor in the instance variable - if I read that correct with this change the following happens: if I call getPixelAccessor() 3 times I get a ScaledAccessor wrapping a ScaleAccessor wrapping a ScaledAccessor, wrapping one of ByteAccess, ByteRgbAccess, IntAccess > > No, that?s what used to happen before this fix. > > The fix moves the wrapping of the pixelAccessor with a ScaledPixelAxcessor inside the null check so it?s now only done once. ah I missed that the lines moved up inside the first if-check ------------- PR: https://git.openjdk.java.net/jfx/pull/389 From arapte at openjdk.java.net Fri Jan 29 12:46:46 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Jan 2021 12:46:46 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 23:08:58 GMT, Kevin Rushforth wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Use XkbGetNamedIndicator on Linux instead of relying on the (unreliable) GDK method. Looks good to me, verified tests on all three platforms. Left minor comments. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 878: > 876: > 877: /** > 878: * Return the lock state for the given keyCode. Minor typo: Return -> Returns modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m line 407: > 405: (JNIEnv * env, jobject obj, jint keyCode) > 406: { > 407: NSUInteger modifierFlags = [NSEvent modifierFlags]; If this line is moved just before return statement(Line#418), then we can avoid executing this call in case of invalid keyCode. modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 381: > 379: } > 380: > 381: Atom atom = None; The documentation of [XInternAtom()](https://www.x.org/releases/X11R7.5/doc/man/man3/XInternAtom.3.html) does mention that this function returns an atom identifier associated with the provided atom name. So the variable name 'atom' does sound good enough. But would it be good to rename this variable to something like 'keyCodeAtom'. I am Ok either way. ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Fri Jan 29 13:19:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 13:19:00 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v4] In-Reply-To: References: Message-ID: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Updates based on review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/385/files - new: https://git.openjdk.java.net/jfx/pull/385/files/c4961b16..0ae116f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=385&range=02-03 Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/385/head:pull/385 PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Fri Jan 29 13:19:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 13:19:02 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v3] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 07:08:47 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use XkbGetNamedIndicator on Linux instead of relying on the (unreliable) GDK method. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 878: > >> 876: >> 877: /** >> 878: * Return the lock state for the given keyCode. > > Minor typo: Return -> Returns fixed > modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m line 407: > >> 405: (JNIEnv * env, jobject obj, jint keyCode) >> 406: { >> 407: NSUInteger modifierFlags = [NSEvent modifierFlags]; > > If this line is moved just before return statement(Line#418), then we can avoid executing this call in case of invalid keyCode. fixed > modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp line 381: > >> 379: } >> 380: >> 381: Atom atom = None; > > The documentation of [XInternAtom()](https://www.x.org/releases/X11R7.5/doc/man/man3/XInternAtom.3.html) does mention that this function returns an atom identifier associated with the provided atom name. So the variable name 'atom' does sound good enough. But would it be good to rename this variable to something like 'keyCodeAtom'. I am Ok either way. fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Fri Jan 29 13:23:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 13:23:42 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <6CTqu61aDbuJF_x8iIoCaGu24jtaBQGyBqkvVktxxEk=.bd6d4b7b-ac98-4559-8be9-1f4e0e6c0f58@github.com> On Mon, 18 Jan 2021 15:07:34 GMT, Nir Lisker wrote: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. @nlisker I'll wait to review this until after you add the fix noted in [JDK-8260430](https://bugs.openjdk.java.net/browse/JDK-8260430). ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From kcr at openjdk.java.net Fri Jan 29 13:38:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 29 Jan 2021 13:38:44 GMT Subject: RFR: 8256283: IndexOutOfBoundsException when sorting a TreeTableView [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 11:48:02 GMT, Ambarish Rapte wrote: >> This particular issue JDK-8256283, is a specific case of IOOBE when, rootItem is not shown, some children including first child are selected, then all children are removed and sort() is invoked. The sort() fails with an IOOBE. >> This PR only addresses this specific IOOBE. >> Root cause of this issue is that the selection is not cleared after rootItems children are removed. In addition to this, there are few other scenarios when selection is not updated correctly, which are collected under an umbrella task [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Fix for [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217) would require good amount refactoring of selection model. >> >> The fix for this issue is to avoid sort() when rootItem.getChildren().isEmpty(). >> Added a unit test with the fix, which fails without fix and passes with fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Review correction Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/384 From jvos at openjdk.java.net Fri Jan 29 13:41:50 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 29 Jan 2021 13:41:50 GMT Subject: RFR: 8259635: Update to 610.2 version of WebKit [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 15:57:04 GMT, Arun Joseph wrote: >> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Fix color in DefaultPlugin Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From ajoseph at openjdk.java.net Fri Jan 29 13:54:47 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 29 Jan 2021 13:54:47 GMT Subject: Integrated: 8259635: Update to 610.2 version of WebKit In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 04:14:28 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.30 (610.2) This pull request has now been integrated. Changeset: b0a404de Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/b0a404de Stats: 257339 lines in 5451 files changed: 125161 ins; 93742 del; 38436 mod 8259635: Update to 610.2 version of WebKit Reviewed-by: kcr, ghb, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/382 From arapte at openjdk.java.net Fri Jan 29 14:31:46 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Jan 2021 14:31:46 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 13:19:00 GMT, Kevin Rushforth wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on review comments Looks good. +1 ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/385 From David.Grieve at microsoft.com Fri Jan 29 15:02:28 2021 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 29 Jan 2021 15:02:28 +0000 Subject: JDK-8177635: Optimise CSS lookup resolution Message-ID: Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution? From kevin.rushforth at oracle.com Fri Jan 29 15:08:39 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 29 Jan 2021 07:08:39 -0800 Subject: JDK-8177635: Optimise CSS lookup resolution In-Reply-To: References: Message-ID: Hi David, That would be great, if a safe fix can be found (I don't need to tell you how fragile the CSS code is when it comes to these sorts of optimizations). Thanks! -- Kevin On 1/29/2021 7:02 AM, David Grieve wrote: > Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution? From nlisker at openjdk.java.net Fri Jan 29 16:17:02 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 29 Jan 2021 16:17:02 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fix for 8260430 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/380/files - new: https://git.openjdk.java.net/jfx/pull/380/files/148ce0f6..ba164e55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=380&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=380&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/380.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/380/head:pull/380 PR: https://git.openjdk.java.net/jfx/pull/380 From nlisker at openjdk.java.net Fri Jan 29 16:23:41 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 29 Jan 2021 16:23:41 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs In-Reply-To: <6CTqu61aDbuJF_x8iIoCaGu24jtaBQGyBqkvVktxxEk=.bd6d4b7b-ac98-4559-8be9-1f4e0e6c0f58@github.com> References: <6CTqu61aDbuJF_x8iIoCaGu24jtaBQGyBqkvVktxxEk=.bd6d4b7b-ac98-4559-8be9-1f4e0e6c0f58@github.com> Message-ID: <3GcexZ5mgICXr54gZ2u7518RNR1oHUU-uvEdMwzu6NE=.f4f84bbb-adcb-4eb7-82aa-ddf002799d70@github.com> On Fri, 29 Jan 2021 13:20:38 GMT, Kevin Rushforth wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > @nlisker I'll wait to review this until after you add the fix noted in [JDK-8260430](https://bugs.openjdk.java.net/browse/JDK-8260430). I added a fix for JDK-8260430. Note that the underlying behavior in this class is different than that of `Node`. While both have a map of properties, `Node` uses a special key to add/get the user data to/from the map while `MenuItem` has a separate field for it. In `Node` these methods are convenience methods, but here they have a separate functionality. ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From arapte at openjdk.java.net Fri Jan 29 17:15:44 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Jan 2021 17:15:44 GMT Subject: Integrated: 8256283: IndexOutOfBoundsException when sorting a TreeTableView In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 10:08:51 GMT, Ambarish Rapte wrote: > This particular issue JDK-8256283, is a specific case of IOOBE when, rootItem is not shown, some children including first child are selected, then all children are removed and sort() is invoked. The sort() fails with an IOOBE. > This PR only addresses this specific IOOBE. > Root cause of this issue is that the selection is not cleared after rootItems children are removed. In addition to this, there are few other scenarios when selection is not updated correctly, which are collected under an umbrella task [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Fix for [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217) would require good amount refactoring of selection model. > > The fix for this issue is to avoid sort() when rootItem.getChildren().isEmpty(). > Added a unit test with the fix, which fails without fix and passes with fix. This pull request has now been integrated. Changeset: db6941de Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/db6941de Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod 8256283: IndexOutOfBoundsException when sorting a TreeTableView Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/384 From wookey.dean at gmail.com Fri Jan 29 18:26:22 2021 From: wookey.dean at gmail.com (Dean Wookey) Date: Fri, 29 Jan 2021 20:26:22 +0200 Subject: JDK-8177635: Optimise CSS lookup resolution In-Reply-To: References: Message-ID: Hi David, We experimented with some changes last year which we've been running. We haven't noticed any problems and we do get some good memory and speed enhancements.. I've been meaning to clean it up before considering a pull request, but since this is a delicate area, I've procrastinated a bit in doing that. Here are the changes https://github.com/openjdk/jfx/compare/master...DeanWookey:CleanerPseudoClassEnhancements . I could look at redoing the changes cleaner if you think we've taken the right approach, else if not, feel free to incorporate any of the ideas in there in what you're doing. Dean On Fri, Jan 29, 2021 at 5:11 PM Kevin Rushforth wrote: > Hi David, > > That would be great, if a safe fix can be found (I don't need to tell > you how fragile the CSS code is when it comes to these sorts of > optimizations). > > Thanks! > > -- Kevin > > > On 1/29/2021 7:02 AM, David Grieve wrote: > > Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution? > > From David.Grieve at microsoft.com Fri Jan 29 20:24:25 2021 From: David.Grieve at microsoft.com (David Grieve) Date: Fri, 29 Jan 2021 20:24:25 +0000 Subject: [EXTERNAL] Re: JDK-8177635: Optimise CSS lookup resolution In-Reply-To: References: Message-ID: I'm looking at a broader issue which is the amount of time spent looking up the parent chain to resolve a style. My thought is to push parent state down to children as CSS is applied. The state would include pseudoclass, font, and styles that might need looking up. But I like your change. It looks like a good optimization for the style cache. I would let it stand alone. -----Original Message----- From: openjfx-dev On Behalf Of Dean Wookey Sent: Friday, January 29, 2021 1:26 PM To: openjfx-dev at openjdk.java.net Mailing Subject: [EXTERNAL] Re: JDK-8177635: Optimise CSS lookup resolution Hi David, We experimented with some changes last year which we've been running. We haven't noticed any problems and we do get some good memory and speed enhancements.. I've been meaning to clean it up before considering a pull request, but since this is a delicate area, I've procrastinated a bit in doing that. Here are the changes https://github.com/openjdk/jfx/compare/master...DeanWookey:CleanerPseudoClassEnhancements I could look at redoing the changes cleaner if you think we've taken the right approach, else if not, feel free to incorporate any of the ideas in there in what you're doing. Dean On Fri, Jan 29, 2021 at 5:11 PM Kevin Rushforth wrote: > Hi David, > > That would be great, if a safe fix can be found (I don't need to tell > you how fragile the CSS code is when it comes to these sorts of > optimizations). > > Thanks! > > -- Kevin > > > On 1/29/2021 7:02 AM, David Grieve wrote: > > Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution? > > From pbansal at openjdk.java.net Sat Jan 30 11:37:45 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 30 Jan 2021 11:37:45 GMT Subject: RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 13:19:00 GMT, Kevin Rushforth wrote: >> The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM LOCK on the keyboard. Being able to read the lock state would allow an application to inform the user that caps lock was enabled for passwords or other usages where the keyboard input might not be echoed. It would also allow an application to do spell checking / auto-correction that might ordinarily be skipped when typing all upper-case letters. >> >> We need an equivalent JavaFX API to the existing AWT `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in JavaFX is in the `javafx.application.Platform` class, so we propose to create a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether or not that key is in the locked or "on" state. If we can't read the key state on a particular platform, we will return `Optional.empty()`, rather than throwing a runtime exception as AWT does. >> >> I have provided both an automated Robot test and a manual test. The latter is needed primarily because we can't set the CAPS lock on Mac using Robot, but also because we want way to test the case where the user has enabled CAPS lock before the program starts. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on review comments looks good to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/385 From kcr at openjdk.java.net Sat Jan 30 15:40:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Jan 2021 15:40:45 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 16:17:02 GMT, Nir Lisker wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fix for 8260430 I left two additional comments. Otherwise good. modules/javafx.base/src/main/java/javafx/collections/ListChangeListener.java line 195: > 193: * Note that using set will also produce a change with {@code wasRemoved()} returning > 194: * true. See {@link #wasReplaced()}. > 195: * @return {@code true} if something was removed from the list This same change could be applied to `wasAdded`. modules/javafx.controls/src/main/java/javafx/scene/control/MenuItem.java line 509: > 507: * set. > 508: * > 509: * @return the user object that was stored (including {@code null}), or {@code null} if no object has been set. Trailing `.` can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/380 From nlisker at openjdk.java.net Sat Jan 30 20:21:59 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 30 Jan 2021 20:21:59 GMT Subject: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3] In-Reply-To: References: Message-ID: > The usual doc fixes (for OpenJFX 16). > > Can wait until RDP2 to see if something else comes up. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/380/files - new: https://git.openjdk.java.net/jfx/pull/380/files/ba164e55..5ba0799d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=380&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=380&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/380.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/380/head:pull/380 PR: https://git.openjdk.java.net/jfx/pull/380 From nlisker at openjdk.java.net Sat Jan 30 21:38:48 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 30 Jan 2021 21:38:48 GMT Subject: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter Message-ID: Deprecating protected members in DateTimeStringConverter. Internal implementation should not be exposed (similar to `NumberStringConverter` and others). ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/390/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=390&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260475 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/390.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/390/head:pull/390 PR: https://git.openjdk.java.net/jfx/pull/390