From mp at jugs.org Sat Aug 1 07:41:04 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 1 Aug 2020 09:41:04 +0200 Subject: Tray Icon? In-Reply-To: <91261036-D07C-4034-96E3-AAF77BD44930@gmail.com> References: <91261036-D07C-4034-96E3-AAF77BD44930@gmail.com> Message-ID: <8efce7f8-c116-1949-46cb-7b6fcf9b94a2@jugs.org> My mistake. Sorry. I read the question a bit too fast :-). Anyway, here is an example of how to use the AWT system tray from within JavaFX. Maybe it helps: https://gist.github.com/jewelsea/e231e89e8d36ef4e5d8a I just verified that this still works with Java 11+. Otherwise I fully support the idea of getting this shortcoming fixed? in JavaFX itself. Michael Am 01.08.20 um 01:45 schrieb Scott Palmer: > I should also point out that this shortcoming was identified nearly 9 years ago. > > https://bugs.openjdk.java.net/browse/JDK-8092115 > > I would love to make some progress on this, but I think doing it right is a bigger job than ?outsiders? can tackle. Ideally most of the desktop APIs should be supported by JavaFX without AWT/Swing. I think that requires some careful thought. Some of the code should be independent of the UI toolkit and it could be shared between the AWT and JavaFX implementations. In a modular JRE we shouldn?t need the Swing modules to have a system tray icon in a JavaFX app. > > Scott > >> On Jul 31, 2020, at 7:34 PM, Scott Palmer wrote: >> >> ? No you can?t. System tray support is something else, not an application icon in the start bar or doc. >> >> Scott >> >>> On Jul 31, 2020, at 6:02 PM, Michael Paus wrote: >>> >>> ?You can add such an icon to your JavaFX app if you bundle it with the jpackage tool distributed with JDK 14+ >>> >>>>> Am 31.07.20 um 23:07 schrieb Davide Perini: >>>> Hi all guys, >>>> love JavaFX, it's so productive, so easy to use, can't understand why the world don't use it "for some tasks". >>>> >>>> I know that tray icon can be easily done with AWT but is there something for JavaFX? >>>> Is it possible to create a tray icon with JavaFX? >>>> >>>> Thanks >>>> Davide >>> >>> From github.com+5037600+tobiasdiez at openjdk.java.net Sun Aug 2 10:27:17 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Sun, 2 Aug 2020 10:27:17 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v3] In-Reply-To: References: Message-ID: <0jolnM-kTVjKbwU7wBu45V9co51Lek95lKAurb0q0qk=.db82b6e5-8598-4879-8773-6b69c194a816@github.com> > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/22/files - new: https://git.openjdk.java.net/jfx/pull/22/files/f58ddfca..717dd939 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/22/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/22/webrev.01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx/pull/22 From nlisker at openjdk.java.net Sun Aug 2 23:25:10 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 2 Aug 2020 23:25:10 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jul 2020 17:38:27 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected javadoc generation errors > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 3401: > >> 3400: *
  • {@link #layoutXProperty layoutX}, {@link #layoutYProperty layoutY} and >> 3401: * {@link #translateXProperty translateX}, {@link #translateYProperty translateY}, {@link #translateZProperty >> translateZ}
  • 3402: * > > I think the translate properties should still remain in a separate `
  • `. > layout and translate, they together determine the final translation but are different properties. I don't want to imply that they are performed separately in the order previously written. I think that the difference in properties is evident by the links. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kevin.rushforth at oracle.com Tue Aug 4 11:49:20 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Aug 2020 04:49:20 -0700 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: References: <98f62a62-3b62-418b-8075-411bdde43073@iPad> Message-ID: <0187a1c2-b356-00ab-e58a-5b2dc43f15cc@oracle.com> Hi Steven, Thanks for filing the bug. It will be transferred to the JDK project and become publicly visible soon. -- Kevin On 7/31/2020 8:48 AM, Steven Yi wrote: > I haven't seen a bug posted to the system so I suppose it is still under > review. When I submitted it, I got an automated response that there was an > internal review ID of 9066237 if that is of use to anyone. > > On Fri, Jul 31, 2020 at 8:16 AM Eric Bresie wrote: > >> What was the ticket? >> >> Eric Bresie >> Ebresie at gmail.com >>> On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >>> Thanks, I'll take a look at it and let you know if we need anything else. >>> >>> -- Kevin >>> >>> >>> On 7/30/2020 8:45 AM, Steven Yi wrote: >>>> Hi Kevin, >>>> >>>> I pasted in the minimal reproducible example with the issue I filed as >>>> well as a link to the github repo; I hope the everything is in order. >>>> >>>> Thanks, >>>> Steven >>>> >>>> >>>> On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth >>>> > >> wrote: >>>> If you can provide a small, standalone test case as part of the bug >>>> report, that would be ideal. >>>> >>>> Thanks. >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/30/2020 6:46 AM, Steven Yi wrote: >>>>> Hi Michael, >>>>> >>>>> Thanks for the link, I missed that when I went to explore JBS. >>>> I'll report >>>>> the issue there. >>>>> >>>>> All best, >>>>> Steven >>>>> >>>>> >>>>> On Thu, Jul 30, 2020 at 3:25 AM Michael Paus >>> > wrote: >>>>>> Hi Steven, >>>>>> the right place for bug reports like this is here: >>>>>> >>>>>> Michael >>>>>> >>>>>> Am 30.07.20 um 01:28 schrieb Steven Yi: >>>>>>> Hi All, >>>>>>> >>>>>>> I'm not sure if this is the place to report this, but >>>> hopefully so. (I >>>>>> did >>>>>>> not see a way to create an account or report issues on JBS.) >>>>>>> >>>>>>> I am using JavaFX embedded within a Swing application and had >>>> found >>>>>>> intermittent deadlocks on macOS that I wasn't sure why it was >>>> happening. >>>>>> I >>>>>>> was finally able to create a minimal working example and have >>>> published >>>>>> it >>>>>>> here: >>>>>>> >>>>>>> https://github.com/kunstmusik/ContextMenuHangingTest >>>>>>> >>>>>>> The switching applications seems to be a key to getting the >>>> deadlock to >>>>>>> happen. Testing with debugger in Netbeans, when the app >>>> freezes, I paused >>>>>>> the app and saw this in the Java FX Application Thread stack: >>>>>>> >>>>>>> "JavaFX Application Thread" >>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) >>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) >>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) >>>>>>> at >>>> sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) >>>>>>> at >>>> sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) >>>>>>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) >>>>>>> at com.sun.glass.ui.Window.setView(Window.java:416) >>>>>>> at >>>>>>> >> com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) >>>>>>> at >> com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get >>>>>>> at >>>>>>> >> com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) >>>>>>> at >>>> com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) >>>>>>> at javafx.stage.Window$12.invalidated(Window.java:1085) >>>>>>> at >>>>>>> >> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>>>>>> at >>>>>>> >> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>>>>>> at javafx.stage.Window.setShowing(Window.java:1174) >>>>>>> at javafx.stage.Window.show(Window.java:1189) >>>>>>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) >>>>>>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) >>>>>>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) >>>>>>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) >>>>>>> at >>>>>>> >> com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) >>>>>>> at >>>>>>> >> com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle >>>>>>> at >>>>>>> >> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>>>>>> at >>>>>>> >> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) >>>>>>> at javafx.event.Event.fireEvent(Event.java:198) >>>>>>> at javafx.scene.Node.fireEvent(Node.java:8885) >>>>>>> at javafx.scene.control.Button.fire(Button.java:203) >>>>>>> at >>>>>>> >> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) >>>>>>> at >>>>>>> >> com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle >>>>>>> at >> com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) >>>>>>> at >>>>>>> >> com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle >>>>>>> at >>>>>>> >> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) >>>>>>> at >>>>>>> >> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>>>>>> at >>>>>>> >> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >>>>>>> >> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>>>>>> at >>>>>>> >> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>>>>>> at >> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) >>>>>>> at javafx.event.Event.fireEvent(Event.java:198) >>>>>>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) >>>>>>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) >>>>>>> at >>>> javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) >>>>>>> at >>>>>>> >> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) >>>>>>> at >>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run >>>>>>> at >>>> java.security.AccessController.doPrivileged(AccessController.java) >>>>>>> at >>>>>>> >> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) >>>>>>> at >>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run >>>>>>> at >>>>>>> >> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) >>>>>>> at >>>> com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run >>>>>>> at >>>> java.security.AccessController.doPrivileged(AccessController.java) >>>>>>> at >>>>>>> >> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) >>>>>>> at >>>> com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run >>>>>>> at >>>>>>> >> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>>>>>> Any help would be very much appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> Steven >>>>>> From kevin.rushforth at oracle.com Tue Aug 4 12:19:33 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 Aug 2020 05:19:33 -0700 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: <0187a1c2-b356-00ab-e58a-5b2dc43f15cc@oracle.com> References: <98f62a62-3b62-418b-8075-411bdde43073@iPad> <0187a1c2-b356-00ab-e58a-5b2dc43f15cc@oracle.com> Message-ID: <11971d13-1248-62af-4d6a-dc29d81549cb@oracle.com> And here it is: https://bugs.openjdk.java.net/browse/JDK-8251038 On 8/4/2020 4:49 AM, Kevin Rushforth wrote: > Hi Steven, > > Thanks for filing the bug. It will be transferred to the JDK project > and become publicly visible soon. > > -- Kevin > > > On 7/31/2020 8:48 AM, Steven Yi wrote: >> I haven't seen a bug posted to the system so I suppose it is still under >> review. When I submitted it, I got an automated response that there >> was an >> internal review ID of 9066237 if that is of use to anyone. >> >> On Fri, Jul 31, 2020 at 8:16 AM Eric Bresie wrote: >> >>> What was the ticket? >>> >>> Eric Bresie >>> Ebresie at gmail.com >>>> On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>>> Thanks, I'll take a look at it and let you know if we need anything >>>> else. >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/30/2020 8:45 AM, Steven Yi wrote: >>>>> Hi Kevin, >>>>> >>>>> I pasted in the minimal reproducible example with the issue I >>>>> filed as >>>>> well as a link to the github repo; I hope the everything is in order. >>>>> >>>>> Thanks, >>>>> Steven >>>>> >>>>> >>>>> On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth >>>>> > >>> wrote: >>>>> If you can provide a small, standalone test case as part of the bug >>>>> report, that would be ideal. >>>>> >>>>> Thanks. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 7/30/2020 6:46 AM, Steven Yi wrote: >>>>>> Hi Michael, >>>>>> >>>>>> Thanks for the link, I missed that when I went to explore JBS. >>>>> I'll report >>>>>> the issue there. >>>>>> >>>>>> All best, >>>>>> Steven >>>>>> >>>>>> >>>>>> On Thu, Jul 30, 2020 at 3:25 AM Michael Paus >>>> > wrote: >>>>>>> Hi Steven, >>>>>>> the right place for bug reports like this is here: >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> Am 30.07.20 um 01:28 schrieb Steven Yi: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I'm not sure if this is the place to report this, but >>>>> hopefully so. (I >>>>>>> did >>>>>>>> not see a way to create an account or report issues on JBS.) >>>>>>>> >>>>>>>> I am using JavaFX embedded within a Swing application and had >>>>> found >>>>>>>> intermittent deadlocks on macOS that I wasn't sure why it was >>>>> happening. >>>>>>> I >>>>>>>> was finally able to create a minimal working example and have >>>>> published >>>>>>> it >>>>>>>> here: >>>>>>>> >>>>>>>> https://github.com/kunstmusik/ContextMenuHangingTest >>>>>>>> >>>>>>>> The switching applications seems to be a key to getting the >>>>> deadlock to >>>>>>>> happen. Testing with debugger in Netbeans, when the app >>>>> freezes, I paused >>>>>>>> the app and saw this in the Java FX Application Thread stack: >>>>>>>> >>>>>>>> "JavaFX Application Thread" >>>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) >>>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) >>>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) >>>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) >>>>>>>> at >>>>> sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) >>>>>>>> at >>>>> sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) >>>>> >>>>>>>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) >>>>>>>> at com.sun.glass.ui.Window.setView(Window.java:416) >>>>>>>> at >>>>>>>> >>> com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) >>> >>>>>>>> at >>> com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get >>>>>>>> at >>>>>>>> >>> com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) >>> >>>>>>>> at >>>>> com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) >>>>>>>> at javafx.stage.Window$12.invalidated(Window.java:1085) >>>>>>>> at >>>>>>>> >>> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>> >>>>>>>> at >>>>>>>> >>> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> >>>>>>>> at javafx.stage.Window.setShowing(Window.java:1174) >>>>>>>> at javafx.stage.Window.show(Window.java:1189) >>>>>>>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) >>>>>>>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) >>>>>>>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) >>>>>>>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) >>>>>>>> at >>>>>>>> >>> com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) >>> >>>>>>>> at >>>>>>>> >>> com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) >>>>>>>> at javafx.event.Event.fireEvent(Event.java:198) >>>>>>>> at javafx.scene.Node.fireEvent(Node.java:8885) >>>>>>>> at javafx.scene.control.Button.fire(Button.java:203) >>>>>>>> at >>>>>>>> >>> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle >>> >>>>>>>> at >>> com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) >>> >>>>>>>> at >>>>>>>> >>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) >>> >>>>>>>> at >>> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) >>>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) >>>>>>>> at javafx.event.Event.fireEvent(Event.java:198) >>>>>>>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) >>>>>>>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) >>>>>>>> at >>>>> javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) >>>>>>>> at >>>>>>>> >>> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) >>> >>>>>>>> at >>>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run >>>>>>>> at >>>>> java.security.AccessController.doPrivileged(AccessController.java) >>>>>>>> at >>>>>>>> >>> com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) >>> >>>>>>>> at >>>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run >>>>>>>> at >>>>>>>> >>> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) >>> >>>>>>>> at >>>>> com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run >>>>>>>> at >>>>> java.security.AccessController.doPrivileged(AccessController.java) >>>>>>>> at >>>>>>>> >>> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) >>> >>>>>>>> at >>>>> com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run >>>>>>>> at >>>>>>>> >>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>> >>>>>>>> Any help would be very much appreciated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Steven >>>>>>> > From stevenyi at gmail.com Tue Aug 4 16:19:14 2020 From: stevenyi at gmail.com (Steven Yi) Date: Tue, 4 Aug 2020 12:19:14 -0400 Subject: Deadlock: JFXPanel, ContextMenu, macOS In-Reply-To: <11971d13-1248-62af-4d6a-dc29d81549cb@oracle.com> References: <98f62a62-3b62-418b-8075-411bdde43073@iPad> <0187a1c2-b356-00ab-e58a-5b2dc43f15cc@oracle.com> <11971d13-1248-62af-4d6a-dc29d81549cb@oracle.com> Message-ID: Thank you! If there's something else I can do to help assist please let me know. All best, Steven On Tue, Aug 4, 2020 at 8:20 AM Kevin Rushforth wrote: > And here it is: > > https://bugs.openjdk.java.net/browse/JDK-8251038 > > On 8/4/2020 4:49 AM, Kevin Rushforth wrote: > > Hi Steven, > > > > Thanks for filing the bug. It will be transferred to the JDK project > > and become publicly visible soon. > > > > -- Kevin > > > > > > On 7/31/2020 8:48 AM, Steven Yi wrote: > >> I haven't seen a bug posted to the system so I suppose it is still under > >> review. When I submitted it, I got an automated response that there > >> was an > >> internal review ID of 9066237 if that is of use to anyone. > >> > >> On Fri, Jul 31, 2020 at 8:16 AM Eric Bresie wrote: > >> > >>> What was the ticket? > >>> > >>> Eric Bresie > >>> Ebresie at gmail.com > >>>> On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth < > >>> kevin.rushforth at oracle.com> wrote: > >>>> Thanks, I'll take a look at it and let you know if we need anything > >>>> else. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> On 7/30/2020 8:45 AM, Steven Yi wrote: > >>>>> Hi Kevin, > >>>>> > >>>>> I pasted in the minimal reproducible example with the issue I > >>>>> filed as > >>>>> well as a link to the github repo; I hope the everything is in order. > >>>>> > >>>>> Thanks, > >>>>> Steven > >>>>> > >>>>> > >>>>> On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth > >>>>> > > >>> wrote: > >>>>> If you can provide a small, standalone test case as part of the bug > >>>>> report, that would be ideal. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> On 7/30/2020 6:46 AM, Steven Yi wrote: > >>>>>> Hi Michael, > >>>>>> > >>>>>> Thanks for the link, I missed that when I went to explore JBS. > >>>>> I'll report > >>>>>> the issue there. > >>>>>> > >>>>>> All best, > >>>>>> Steven > >>>>>> > >>>>>> > >>>>>> On Thu, Jul 30, 2020 at 3:25 AM Michael Paus >>>>> > wrote: > >>>>>>> Hi Steven, > >>>>>>> the right place for bug reports like this is here: > >>>>>>> > >>>>>>> Michael > >>>>>>> > >>>>>>> Am 30.07.20 um 01:28 schrieb Steven Yi: > >>>>>>>> Hi All, > >>>>>>>> > >>>>>>>> I'm not sure if this is the place to report this, but > >>>>> hopefully so. (I > >>>>>>> did > >>>>>>>> not see a way to create an account or report issues on JBS.) > >>>>>>>> > >>>>>>>> I am using JavaFX embedded within a Swing application and had > >>>>> found > >>>>>>>> intermittent deadlocks on macOS that I wasn't sure why it was > >>>>> happening. > >>>>>>> I > >>>>>>>> was finally able to create a minimal working example and have > >>>>> published > >>>>>>> it > >>>>>>>> here: > >>>>>>>> > >>>>>>>> https://github.com/kunstmusik/ContextMenuHangingTest > >>>>>>>> > >>>>>>>> The switching applications seems to be a key to getting the > >>>>> deadlock to > >>>>>>>> happen. Testing with debugger in Netbeans, when the app > >>>>> freezes, I paused > >>>>>>>> the app and saw this in the Java FX Application Thread stack: > >>>>>>>> > >>>>>>>> "JavaFX Application Thread" > >>>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > >>>>>>>> at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > >>>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > >>>>>>>> at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > >>>>>>>> at > >>>>> sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > >>>>>>>> at > >>>>> > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > >>>>> > >>>>>>>> at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > >>>>>>>> at com.sun.glass.ui.Window.setView(Window.java:416) > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > > >>> > >>>>>>>> at > >>> com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > > >>> > >>>>>>>> at > >>>>> com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > >>>>>>>> at javafx.stage.Window$12.invalidated(Window.java:1085) > >>>>>>>> at > >>>>>>>> > >>> > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > >>> > >>>>>>>> at javafx.stage.Window.setShowing(Window.java:1174) > >>>>>>>> at javafx.stage.Window.show(Window.java:1189) > >>>>>>>> at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > >>>>>>>> at javafx.stage.PopupWindow.show(PopupWindow.java:417) > >>>>>>>> at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > >>>>>>>> at javafx.scene.control.ContextMenu.show(ContextMenu.java:265) > >>>>>>>> at > >>>>>>>> > >>> > com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) > >>>>>>>> at javafx.event.Event.fireEvent(Event.java:198) > >>>>>>>> at javafx.scene.Node.fireEvent(Node.java:8885) > >>>>>>>> at javafx.scene.control.Button.fire(Button.java:203) > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle > > >>> > >>>>>>>> at > >>> > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) > > >>> > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) > > >>> > >>>>>>>> at > >>> com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) > >>>>>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) > >>>>>>>> at javafx.event.Event.fireEvent(Event.java:198) > >>>>>>>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3890) > >>>>>>>> at javafx.scene.Scene.processMouseEvent(Scene.java:1885) > >>>>>>>> at > >>>>> javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2618) > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$4(EmbeddedScene.java:287) > > >>> > >>>>>>>> at > >>>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$322.1002466434.run > >>>>>>>> at > >>>>> java.security.AccessController.doPrivileged(AccessController.java) > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.tk.quantum.EmbeddedScene.lambda$mouseEvent$5(EmbeddedScene.java:280) > > >>> > >>>>>>>> at > >>>>> com.sun.javafx.tk.quantum.EmbeddedScene$$Lambda$321.1000105301.run > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) > > >>> > >>>>>>>> at > >>>>> com.sun.javafx.application.PlatformImpl$$Lambda$163.1646337711.run > >>>>>>>> at > >>>>> java.security.AccessController.doPrivileged(AccessController.java) > >>>>>>>> at > >>>>>>>> > >>> > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) > > >>> > >>>>>>>> at > >>>>> com.sun.javafx.application.PlatformImpl$$Lambda$162.158199555.run > >>>>>>>> at > >>>>>>>> > >>> > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > >>> > >>>>>>>> Any help would be very much appreciated. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Steven > >>>>>>> > > > > From Rony.Flatscher at wu.ac.at Wed Aug 5 14:39:57 2020 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 5 Aug 2020 16:39:57 +0200 Subject: Seeking FXML examples with the "onChange" attribute defined for ObservableList, ObservableMap, ObservableSet ... In-Reply-To: <54712f71-7eeb-f37c-b4bf-1d5aee7b8025@wu.ac.at> References: <54712f71-7eeb-f37c-b4bf-1d5aee7b8025@wu.ac.at> Message-ID: Maybe asking the same with a different question: what JavaFX classes can have an "onChange" attribute in a FXML file defined, such that one can look into it and explore that particular feature? As there are three change listener types (ListChangeListener.Change, MapChaneListener.Change, SetChangeListener.Change) for that purpose, it would be helpful to be pointed at three respective JavaFX classes. ---rony On 28.07.2020 13:18, Rony G. Flatscher wrote: > Hi Nir, > > On 27.07.2020 22:39, Nir Lisker wrote: > > Hi Rony, > > > > I think that this PR is not the place for this question since it only fixes a typo there. > > sorry, my bad, not realizing that the reply will be taken as part of the PR! This time with a proper > new e-mail. > > --- > > In there are corrections for the text relating to > documenting the "onChange" attribute for "ObservableList" supplying a "ListChangeListener.Change" > [1], "ObservableMap" supplying a "MapChangeListener.Change" [2] or "ObservableSet" supplying a > "SetChangeListener.Change" [3]. > > Does anyone have FXML examples for defining the "onChange" attribute for any of the three > Observable{List|Map|Set}? > > ---rony > > [1] "ListChangeListener.Change": > > [2] "MapChangeListener.Change":? > > [3] "SetChangeListener.Change": > From arapte at openjdk.java.net Thu Aug 6 06:50:05 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 6 Aug 2020 06:50:05 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v5] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <0zRbspBREPaEC2WSAa1c9X6tgag1faIrXjqgYrWw2Qc=.a3e48c8a-127f-4456-8c88-9b2a52f93e4b@github.com> > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: change property existence check ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/f81ed026..03538148 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.03-04 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Thu Aug 6 09:42:05 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 6 Aug 2020 09:42:05 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v3] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <-V5jdNa2cn3k7wb6n9saJeYrmA6PIExi-BMlJROuBcw=.2784bd82-e661-45b2-a719-3886913833d5@github.com> On Tue, 4 Aug 2020 10:07:14 GMT, Jeanette Winzenburg wrote: >> good that we agree on where to put it :) >> >> Will have to think about about the remove installed mappings vs. change existing code to not installing. Right now, >> feels a bit smelly .. but I see the constraints (and might agree :) Will come back! > > btw, using a key-value pair in properties is just fine with me (might have been unclear, sry) - nothing else to do > short of changing api (which feels too heavy weight) > One nit-pit for checking for its existence, an alternative slightly simplified pattern might be > > if (Boolean.TRUE.equals(control.getProperties().get(....)) { > removeMappings(...); > } okay, I still favor the not-adding-if-not-needed approach - and it's not _that_ much of a change to existing code. Basically, in the constructor of ListViewBehavior - in a first block, do not add the mappings that (currently) are removed again if the combo flag is set -in a second block, add the mappings for a stand-alone listView to all inputMaps as needed code snippets: // not needed if in combo popup // addDefaultMapping(listViewInputMap, FocusTraversalInputMap.getFocusTraversalMappings()); addDefaultMapping(listViewInputMap, // not needed if in combo popup // new KeyMapping(HOME, e -> selectFirstRow()), ... // add those that are always needed } // same for child input maps addDefaultMappings(verticalInputMap, ... // add those for stand-alone listView // handle mappings that are needed only in a stand-alone listView if (!Boolean.TRUE.equals(control.getProperties().get("removeKeyMappingsForComboBoxEditor"))) { addDefaultMapping(listViewInputMap, FocusTraversalInputMap.getFocusTraversalMappings()); addDefaultMapping(listViewInputMap, new KeyMapping(HOME, e -> selectFirstRow()), new KeyMapping(END, e -> selectLastRow()), new KeyMapping(new KeyBinding(HOME).shift(), e -> selectAllToFirstRow()), new KeyMapping(new KeyBinding(END).shift(), e -> selectAllToLastRow()), new KeyMapping(new KeyBinding(A).shortcut(), e -> selectAll()), new KeyMapping(new KeyBinding(HOME).shortcut(), e -> focusFirstRow()), new KeyMapping(new KeyBinding(END).shortcut(), e -> focusLastRow()) ); addDefaultMapping(verticalListInputMap, new KeyMapping(new KeyBinding(HOME).shortcut().shift(), e -> discontinuousSelectAllToFirstRow()), new KeyMapping(new KeyBinding(END).shortcut().shift(), e -> discontinuousSelectAllToLastRow()) ); } Tests are passing as expected, and the [open issue JDK-8250807](https://bugs.openjdk.java.net/browse/JDK-8250807) doesn't stand in the way :) As to testing, independent of which approach is chosen at the end: I would suggest to not only test the macroscopic behavior (look if key events on combo/listView have the expected effect) but also test the base layer, that is whether or not the mappings are not/added to the inputMaps. One open (maybe not-an) issue might be the handling of the horizontal map which currently is not touched (but probably will, once the deep removal of [JDK-8250807](https://bugs.openjdk.java.net/browse/JDK-8250807) is fixed) : while not very probable, client code might change the listView in the popup to be horizontal. What would be the expected UI in that case? Anyway, could be left open for the scope of this issue, IMO. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From michaelstrau2 at gmail.com Thu Aug 6 16:16:28 2020 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 6 Aug 2020 18:16:28 +0200 Subject: Logical scene graph traversal API Message-ID: Every now and then I have encountered the need to traverse and inspect the JavaFX scene graph. In one recent example, my task was to selectively adorn UI controls with other controls for enhanced accessibility. Other people have also tried to do similar things, as indicated by some StackOverflow questions and blog posts [0]. The JavaFX scene graph consists of user-created nodes, as well as nodes that are created by control skins. While APIs like `Parent.getChildrenUnmodifiable` can be used to traverse the scene graph, this only works once it is connected to a scene and skins have been applied. The scene graph can also change quite dramatically depending on particular control skins, and generally does not correspond to the "logical graph" that was defined in FXML or in code. Adding an API like `Parent.getLogicalChildrenUnmodifiable` would solve that issue quite easily, and it would also enable the inspection of subgraphs that are not connected to a scene. The logical graph could be used to inspect the document structure of the code, independent of the applied control skins. For example, `Button.getLogicalChildrenUnmodifiable` would return a single node, namely the value of the ?graphic` property (or no node, if there is no graphic). `ScrollPane.getLogicalChildrenUnmodifiable` would return the value of the `content` property, and so on. The downside is, of course, that the responsibility of defining logical nodes would need to be imposed on third-party controls. It stands to reason that such a feature might need to be an opt-in feature in order to prevent breaking changes. However, even if only implemented in the core controls that ship with JavaFX, it might still be a useful addition for many applications. [0] http://www.kware.net/?p=8 From kcr at openjdk.java.net Fri Aug 7 13:02:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 13:02:04 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: References: Message-ID: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> On Thu, 30 Jul 2020 16:42:00 GMT, Nir Lisker wrote: >> This was missed the in Javadoc fixes for 15. >> >> Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected NumberFormat constructor text modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 35: > 34: /** > 35: * A {@link StringConverter} implementation for {@link Number} values that represent currency. Instances of this > class are immutable. 36: * Given that there are no setters or other mutator methods, the immutability seems obvious. I don't see a problem with stating it explicitly, though. It's up to you. modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 52: > 51: /** > 52: * Constructs a {@code CurrencyStringConverter} with the given locale and the default format. > 53: */ Can you also add the `@param locale` tag? This applies to all of the newly documented constructors that have arguments. ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From nlisker at openjdk.java.net Fri Aug 7 13:09:12 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 7 Aug 2020 13:09:12 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> References: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> Message-ID: On Fri, 7 Aug 2020 12:48:34 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected NumberFormat constructor text > > modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 35: > >> 34: /** >> 35: * A {@link StringConverter} implementation for {@link Number} values that represent currency. Instances of this >> class are immutable. 36: * > > Given that there are no setters or other mutator methods, the immutability seems obvious. I don't see a problem with > stating it explicitly, though. It's up to you. True, but I just looked at [Border](https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/layout/Border.html) which states immutability, so I did the same. I don't mind changing it. ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From kcr at openjdk.java.net Fri Aug 7 13:35:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 13:35:41 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: References: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> Message-ID: On Fri, 7 Aug 2020 13:06:51 GMT, Nir Lisker wrote: >> modules/javafx.base/src/main/java/javafx/util/converter/CurrencyStringConverter.java line 35: >> >>> 34: /** >>> 35: * A {@link StringConverter} implementation for {@link Number} values that represent currency. Instances of this >>> class are immutable. 36: * >> >> Given that there are no setters or other mutator methods, the immutability seems obvious. I don't see a problem with >> stating it explicitly, though. It's up to you. > > True, but I just looked at [Border](https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/layout/Border.html) > which states immutability, so I did the same. I don't mind changing it. I don't mind either way. ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From kcr at openjdk.java.net Fri Aug 7 14:40:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 14:40:14 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 18:42:46 GMT, Nir Lisker wrote: >> Adds clarifications to the documentation in various places. Some notes: >> >> * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were >> updated to Java 8 only. >> * Point 8 has been deferred until all the animation bugs have been resolevd. >> * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback >> extractor)` method. Later I found that `observableList(List list, Callback extractor)` already >> talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. >> * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that >> this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and >> there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality >> instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. >> I think that in the future we will want to let the user define what a change is (for example, by creating an >> overridable method with the current behavior as the default, or using object equality and letting the user override >> that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation >> `IndentityHashMap` to deal with this ambiguity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected javadoc generation errors I left a few formatting comments and a substantive one on the clarification of the transform order, which I recommend to defer to 16. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 48: > 47: * Current implementing classes in JavaFX check for a change using reference > 48: * equality (and not object equality, {@code Object#equals(Object)}) of the value. An > 49: * invalidation event is generated if the current value is not valid anymore. I think this is fine given the way it is stated. It might be good to move it to an `@implSpec` section, along with the previous paragraph regarding lazy evaluation, but that would require a CSR and can be considered for a future release. modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 114: > 113: * Observable objects returned by the extractor (applied to each list element) are listened for changes > 114: * and transformed into {@link ListChangeListener.Change#wasUpdated() "update"} changes of a {@code > ListChangeListener}. 115: * I recommend `@linkplain` here since "update" is not the name of a method or property. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 804: > 803: * > 804: * @defaultValue {@code false}; {@code true} for some Controls. > 805: */ Either `controls` (lower case) or `{@code Control}s` seems better. modules/javafx.graphics/src/main/java/javafx/animation/Timeline.java line 146: > 145: /** > 146: * Creates a {@code Timeline} with no key frames and a {@link Animation#getTargetFramerate() target framerate}. > 147: * `@linkplain` modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 868: > 867: * clearing the map or overriding its values. These entries are not removed automatically if the node is > removed from the layout 868: * manager, so unused entries can exist throughout the life of the node. > 869: * If we were in the habit of using `@apiNote` then that's probably where the note about layout managers using the node properties would go. Since we aren't, this seems fine. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 328: > 327: * {@link #translateXProperty translateX}, {@link #translateYProperty translateY} and {@link #translateZProperty > translateZ} 328: * properties. > 329: * See my comment on the transform property. This section seems like the right place to expand the documentation to specify the order of matrix multiplication and the order in which they affect the node's geometry. modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 269: > 268: * @since JavaFX 2.2 > 269: * @defaultValue {@code "..."} > 270: */ This should go before the `@since` (which is usually the last tag) modules/javafx.controls/src/main/java/javafx/scene/control/Labeled.java line 613: > 612: * @since JavaFX 8.0 > 613: * @defaultValue 0 > 614: */ Before `@since` ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Fri Aug 7 14:40:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 14:40:15 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jul 2020 19:02:16 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected javadoc generation errors > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 5523: > >> 5522: * Defines the {@code ObservableList} of {@link Transform} objects to be applied to this {@code Node}. The >> transforms in this list 5523: * are applied in the reverse order of which they are specified as per matrix >> multiplication rules. This list of transforms 5524: * is applied before scaling ({@link #scaleXProperty scaleX}, >> {@link #scaleYProperty scaleY} and {@link #scaleZProperty scaleZ}), > > `The transforms in this list are applied in the reverse order of which they are specified as per matrix > multiplication rules` > To apply transformations in a specific order their respective matrices should be multiplied in reverse order. So just > the order of multiplication is reverse but the transformation are applied in same order as they are added into the > `getTransforms()`. I think phrasing it as 'the transforms are applied in reverse order...' would not be accurate and > confusing to reader. In reading the existing doc carefully, it is both wrong and confusing. It has the wrong ordering of transform, scale and rotate. It is also confusing given that no distinction is made between matrix multiplication order and the observed effect on the geometry of the node. You have fixed the part about it being wrong, but the confusion remains, especially since you made a point of saying that the transforms list is applied in the reverse order. The matrices are multiplied in the following order: 1. layoutX/Y + translateX/Y/Z 2. rotate 3. scale 4. transforms[0] 5. transforms[1] ... We need to both list the actual matrix multiplication order, and then describe that the object is transformed from object coordinates to local coordinates of the node, to parent coordinated, etc., by first applying the transforms in the list in reverse order, then scale, rotate, translate+layout. I don't think that the `transforms` list is the place to do that (it belongs in the Transformations section). This doesn't seem like something we can sort out for JavaFX 15, so I would split this out and defer it. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Fri Aug 7 17:19:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 17:19:40 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v7] In-Reply-To: References: Message-ID: On Tue, 28 Jul 2020 17:52:50 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Removed RenderSVGResourceMasker changes and added fix for HIDPI mask rendering While reviewing the most recent fix, I noticed that the call to `setCTM` in `GraphicsContextJava.cpp` was only done in the `fillRect` case. I then took a closer look at the change in `WCGraphicsPrismContext.java` and I see that the application of the mask is also only done for `fillRect`. A mask will still not be applied for filled rounded rectangles, filled paths, and all stroked primitives. So this is an incomplete fix. I will add a couple additional test cases to the bug report. modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp line 235: > 234: if (m_state.fillGradient) { > 235: setCTM(m_state.transform); > 236: setGradient( Why is this needed here, but not in the other places `setGradient` is called? Won't there be a similar problem with `strokeRect`, `fillPath`, etc? ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From kcr at openjdk.java.net Fri Aug 7 19:04:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 19:04:02 GMT Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4] In-Reply-To: References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: <6IOfhu7edU1v3rcLaWF16oF4B8GRF9vauTVCLhuKXn8=.676ab0d7-b36b-44d0-b1e2-a862551d5a35@github.com> On Thu, 23 Jul 2020 09:43:36 GMT, Bhawesh Choudhary wrote: >> root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four >> corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while >> rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it >> otherwise construct a path from given rounded rect and draw it. > > Bhawesh Choudhary has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge branch 'master' into 8181775 > - Removed wildcard import statement > - Formatting (File Mode Attribute change) > - 8181775: JavaFX WebView does not calculate border-radius properly Looks good. I confirm that the test passes with the fix and fails without the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/218 From dubaut at gmail.com Fri Aug 7 20:09:58 2020 From: dubaut at gmail.com (Hannes H.) Date: Fri, 7 Aug 2020 22:09:58 +0200 Subject: JDK-8154847 : Windows content is blank when using StageStyle.UNIFIED Message-ID: Good evening, Weeks ago I reported a duplicate to JDK-8154847 because I did not realize that this has been reported years ago. As far as I understand most of the contributors to this ticket believe that the problem is related to specific video cards. Since I can reproduce this issue on my developer notebook on Windows 10, I decided to install Linux (not on a VM but actually on the hardware) to check if I can reproduce the issue there as well. First tests show that this issue cannot be reproduced on Linux Mint while it can on the very same hardware when using Windows 10. I am not sure if this information helps anyone. I decided to send it to this mailing list since I find it very cumbersome to create - another - duplicate of an issue just to add information. If you have any further questions or I can be of assistance with reproducing the issue please let me know. Kind regards, Hannes From kevin.rushforth at oracle.com Fri Aug 7 20:25:09 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 7 Aug 2020 13:25:09 -0700 Subject: JDK-8154847 : Windows content is blank when using StageStyle.UNIFIED In-Reply-To: References: Message-ID: <95fd6dbd-6545-e3c5-79a9-c1aca95238cd@oracle.com> Thanks for the additional information. I added it to the bug report. It is interesting to note that it doesn't happen on Linux when running on the same HW, although it isn't surprising. This is likely a graphics driver bug, as opposed to a fundamental HW issue, so it isn't surprising that the results would be different on Linux. -- Kevin On 8/7/2020 1:09 PM, Hannes H. wrote: > Good evening, > > Weeks ago I reported a duplicate to JDK-8154847 because I did not realize > that this has been reported years ago. > > As far as I understand most of the contributors to this ticket believe that > the problem is related to specific video cards. Since I can reproduce this > issue on my developer notebook on Windows 10, I decided to install Linux > (not on a VM but actually on the hardware) to check if I can reproduce > the issue there as well. > > First tests show that this issue cannot be reproduced on Linux Mint while > it can on the very same hardware when using Windows 10. > > I am not sure if this information helps anyone. I decided to send it to > this mailing list since I find it very cumbersome to create - another - > duplicate of an issue just to add information. > > If you have any further questions or I can be of assistance with > reproducing the issue please let me know. > > Kind regards, > Hannes From kcr at openjdk.java.net Fri Aug 7 21:45:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 21:45:11 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 12:03:34 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > The tests are now reused for native and monocle tests. The fix to Monocle looks good. So does the test (I left some minor comments). I can confirm that the test catches the leak (it passes with your fix and fails without it). My only question is regarding the change to `Window.java`. tests/system/src/test/java/test/javafx/stage/FocusedWindowMonocleTest.java line 56: > 55: } > 56: } Minor: Add missing newline tests/system/src/test/java/test/javafx/stage/FocusedWindowNativeTest.java line 52: > 51: } > 52: } Minor: Add missing newline tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 45: > 44: @Ignore > 45: abstract public class FocusedWindowTestBase { > 46: The preferred order is `public abstract`. Also, there is no need for an `@Ignore` here. tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 50: > 49: > 50: > 51: public static void initFXBase() throws Exception { Minor: remove extra blank line. tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 60: > 59: static WeakReference closedFocusedStageWeak = null; > 60: static Stage closedFocusedStage = null; > 61: These two can be instance fields (which is usually preferred for test variables). tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 106: > 105: } > 106: } Minor: Add missing newline ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Fri Aug 7 21:45:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 21:45:12 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Tue, 28 Apr 2020 14:32:37 GMT, Florian Kirmaier wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 1325: >> >>> 1324: this.isFocused = focused; >>> 1325: if (this.isFocused && this.isVisible) { >>> 1326: setFocusedWindow(this); >> >> On my Window10 machine, with this change, `Window.focusedWindow` remains `null` even after the first window (I have not >> verified with multiple windows though) is shown onto the screen and is focused. And It continues to remain `null` until >> some mouse or key action is performed on the window. I am not sure if this causes any side effects. It looks like the >> `Window.focusedWindow` is mostly(only) used for Monocle. Can you please confirm the behavior that >> `Window.focusedWindow` remain `null` and check for any side effects. > > As mentioned - I don't have a good setup to test this code on Windows. > > But I've checked where focusedWindow/getFocusedWindow is used, and I can verify your assumption. I've searched through > the whole project and the variable is only used in the MonocleCode. > The fact that focusedWindow get's sometimes set is probably the cause of the irregular happening memoryleak on Window. In reading the comments, I thought you were going to revert the changes to `Window.java`? Or did I misinterpret what you said earlier? I can confirm that `focusedWindow` is no longer correctly set to the focused window when that Window is first shown (I tried this on Windows). This is true for apps with multiple windows as well as single Stage apps. I can also confirm that `focusedWindow` isn't used on any platform other than Monocle. Even so, since this change isn't needed it seems best to revert it. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Fri Aug 7 21:57:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 21:57:35 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Wed, 29 Jul 2020 23:11:20 GMT, Nir Lisker wrote: >> High-level comments: >> >> 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to >> the "Submitted" state. 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe >> in `tests/performance` (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. 3. We >> need some functional tests, ideally automated ones in `tests/system` >> I also left a few inline comments. I haven't reviewed the shaders yet, so I do that, in addition to further testing, >> next week. > >> 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to >> the "Submitted" state. > > I moved it to the PROPOSED state. > >> 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe in `tests/performance` >> (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. > > I added it under `tests/performance`. > >> 3. We need some functional tests, ideally automated ones in `tests/system` > > What should this test do? Which example should I follow? > > By the way, The `tests` project is broken in Eclipse because several source folders, like `tests\system\src\testapp6`, > define their own `module-info.java`, and it's illegal in Eclipse to have several of these in a project. To have the > tests there compile, the Eclipse files will need to be updated. Given that we don't have any automated tests for lighting (we have a couple that verify that we can take a snapshot and get the same result, but that isn't testing the lighting itself), probably the most we can expect is a simple test of a large quad with a light fairly close to the object, such that the difference with / without attenuation is noticeable. Then you could sample the center and near the corners of the object for both the attenuated and unattenuated cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Aug 7 22:33:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 22:33:02 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Wed, 29 Jul 2020 09:17:10 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 187: >> >>> 186: 0, 0, 0, 0, // r g b w >>> 187: 1, 0, 0, 0); // ca la qa maxRange >>> 188: } >> >> Minor: maybe use the getDefaultXxxx methods of NGPointLight? > > The only impact this has is that the range will be maximal instead of 0. When these reach the shader, they will run the > lighting computation as opposed to skipping it. I'm not sure if this will have any performance impact though. In that case, it seems like a generally useful optimization (not just at initialization) to send down `maxRange` as 0 whenever `ca`, `la`, and `qa` are all at their default values. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Fri Aug 7 22:39:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Aug 2020 22:39:27 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 21:55:25 GMT, Kevin Rushforth wrote: >>> 1. The API docs look good. If you change the public API to `@since 16` then you can also update the CSR and move it to >>> the "Submitted" state. >> >> I moved it to the PROPOSED state. >> >>> 2. I think it would be good to cleanup the performance test and make it part of this PR, maybe in `tests/performance` >>> (which currently only has the not-very-useful `VMPerformance` subdir) or `tests/manual`. >> >> I added it under `tests/performance`. >> >>> 3. We need some functional tests, ideally automated ones in `tests/system` >> >> What should this test do? Which example should I follow? >> >> By the way, The `tests` project is broken in Eclipse because several source folders, like `tests\system\src\testapp6`, >> define their own `module-info.java`, and it's illegal in Eclipse to have several of these in a project. To have the >> tests there compile, the Eclipse files will need to be updated. > > Given that we don't have any automated tests for lighting (we have a couple that verify that we can take a snapshot and > get the same result, but that isn't testing the lighting itself), probably the most we can expect is a simple test of a > large quad with a light fairly close to the object, such that the difference with / without attenuation is noticeable. > Then you could sample the center and near the corners of the object for both the attenuated and unattenuated cases. The performance tests need a standard GPLv2+classpath copyright header. I haven't tested them yet, but will do that next week. ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From lbourges at openjdk.java.net Sat Aug 8 09:22:57 2020 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 8 Aug 2020 09:22:57 GMT Subject: RFR: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: On Sat, 18 Jul 2020 14:57:08 GMT, Kevin Rushforth wrote: > This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin > rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. > There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based > renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this > proposed fix. I have tested this on Mac, Windows, and Linux. Loiks good to me. ------------- Marked as reviewed by lbourges (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/268 From kcr at openjdk.java.net Sat Aug 8 15:46:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 Aug 2020 15:46:38 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jul 2020 09:16:38 GMT, Ambarish Rapte wrote: > ``` > float attenuatedColor = gLightColor[i].xyz / (ca + la * dist + qa * dist * dist); > ``` Typo: that should be: float3 attenuatedColor = gLightColor[i].xyz / (ca + la * dist + qa * dist * dist); ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From kcr at openjdk.java.net Sat Aug 8 16:06:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 Aug 2020 16:06:40 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v9] In-Reply-To: References: Message-ID: On Wed, 29 Jul 2020 23:09:52 GMT, Nir Lisker wrote: >> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag line 91: > 90: > 91: float attenuatedColor = (lights[0].color).rgb / (lights[0].attn.x + lights[0].attn.y * dist + > lights[0].attn.z * dist * dist); 92: d = clamp(dot(n, l), 0.0, 1.0) * attenuatedColor; This fails (on macOS) at shader compilation time with: Shader compile log: ERROR: 0:325: Incompatible types in initialization (and no available implicit conversion) ERROR: 0:326: Use of undeclared identifier 'attenuatedColor' ... That should be `vec3` (same for the other two shader files) ------------- PR: https://git.openjdk.java.net/jfx/pull/43 From fkirmaier at openjdk.java.net Sun Aug 9 17:15:36 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 9 Aug 2020 17:15:36 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v6] In-Reply-To: References: Message-ID: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: - JDK-8241840 fixed tests - JDK-8241840 Removed unnecessary change. - JDK-8241840 Minor cleanups ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/3f618c11..a7c9d83c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.04-05 Stats: 9 lines in 4 files changed: 3 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From ajoseph at openjdk.java.net Mon Aug 10 05:00:39 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 10 Aug 2020 05:00:39 GMT Subject: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4] In-Reply-To: References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: On Thu, 23 Jul 2020 09:43:36 GMT, Bhawesh Choudhary wrote: >> root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four >> corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while >> rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it >> otherwise construct a path from given rounded rect and draw it. > > Bhawesh Choudhary has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge branch 'master' into 8181775 > - Removed wildcard import statement > - Formatting (File Mode Attribute change) > - 8181775: JavaFX WebView does not calculate border-radius properly The fix and test looks good. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/218 From nlisker at openjdk.java.net Mon Aug 10 05:39:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 05:39:05 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v4] In-Reply-To: References: Message-ID: <8Wu1g_mqpGYIEbFgWyIuwKd0AxbBZqa0m_zJEVxV4eY=.74267bbf-8d76-4939-875f-b2712004831e@github.com> > This was missed the in Javadoc fixes for 15. > > Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added @param tags ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/277/files - new: https://git.openjdk.java.net/jfx/pull/277/files/8f19315b..84cdd62e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/277/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/277/webrev.02-03 Stats: 22 lines in 3 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/277.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/277/head:pull/277 PR: https://git.openjdk.java.net/jfx/pull/277 From nlisker at openjdk.java.net Mon Aug 10 06:37:18 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 06:37:18 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 13:37:28 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected javadoc generation errors > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 868: > >> 867: * clearing the map or overriding its values. These entries are not removed automatically if the node is >> removed from the layout 868: * manager, so unused entries can exist throughout the life of the node. >> 869: * > > If we were in the habit of using `@apiNote` then that's probably where the note about layout managers using the node > properties would go. Since we aren't, this seems fine. I think that `@aipNote` is indeed better. Does it require a CSR? ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Mon Aug 10 06:47:22 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 06:47:22 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v3] In-Reply-To: References: Message-ID: > Adds clarifications to the documentation in various places. Some notes: > > * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were > updated to Java 8 only. > * Point 8 has been deferred until all the animation bugs have been resolevd. > * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback > extractor)` method. Later I found that `observableList(List list, Callback extractor)` already > talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. > * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that > this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and > there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality > instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. > I think that in the future we will want to let the user define what a change is (for example, by creating an > overridable method with the current behavior as the default, or using object equality and letting the user override > that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation > `IndentityHashMap` to deal with this ambiguity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed parts of the review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/276/files - new: https://git.openjdk.java.net/jfx/pull/276/files/a44bfb18..6c0a3eb9 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/276/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/276/webrev.01-02 Stats: 24 lines in 3 files changed: 7 ins; 7 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/276/head:pull/276 PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Mon Aug 10 10:29:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 10:29:05 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 14:18:31 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 5523: >> >>> 5522: * Defines the {@code ObservableList} of {@link Transform} objects to be applied to this {@code Node}. The >>> transforms in this list 5523: * are applied in the reverse order of which they are specified as per matrix >>> multiplication rules. This list of transforms 5524: * is applied before scaling ({@link #scaleXProperty scaleX}, >>> {@link #scaleYProperty scaleY} and {@link #scaleZProperty scaleZ}), >> >> `The transforms in this list are applied in the reverse order of which they are specified as per matrix >> multiplication rules` >> To apply transformations in a specific order their respective matrices should be multiplied in reverse order. So just >> the order of multiplication is reverse but the transformation are applied in same order as they are added into the >> `getTransforms()`. I think phrasing it as 'the transforms are applied in reverse order...' would not be accurate and >> confusing to reader. > > In reading the existing doc carefully, it is both wrong and confusing. It has the wrong ordering of transform, scale > and rotate. It is also confusing given that no distinction is made between matrix multiplication order and the observed > effect on the geometry of the node. You have fixed the part about it being wrong, but the confusion remains, especially > since you made a point of saying that the transforms list is applied in the reverse order. The matrices are multiplied > in the following order: 1. layoutX/Y + translateX/Y/Z > 2. rotate > 3. scale > 4. transforms[0] > 5. transforms[1] > ... > > We need to both list the actual matrix multiplication order, and then describe that the object is transformed from > object coordinates to local coordinates of the node, to parent coordinated, etc., by first applying the transforms in > the list in reverse order, then scale, rotate, translate+layout. I don't think that the `transforms` list is the place > to do that (it belongs in the Transformations section). This doesn't seem like something we can sort out for JavaFX > 15, so I would split this out and defer it. So should I revert all the changes about the transforms and leave it for 16, or do part of it now and part later? The changes are in the docs for the `Node` class, the `getTransforms()` method and the `boundsInParentProperty()` method. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Mon Aug 10 10:45:03 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 10:45:03 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 14:37:48 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected javadoc generation errors > > I left a few formatting comments and a substantive one on the clarification of the transform order, which I recommend > to defer to 16. @kevinrushforth @arapte Can you give your input on the changes to the methods with an extractor in `FXCollections` that I mentioned in the 3rd bullet point of this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Mon Aug 10 12:23:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 12:23:07 GMT Subject: Integrated: 8196079: Remove obsolete Pisces rasterizer In-Reply-To: References: Message-ID: On Sat, 18 Jul 2020 14:57:08 GMT, Kevin Rushforth wrote: > This removes the obsolete OpenPiscesRasterizer (Java-based) and NativePiscesRasterizer implementations. The Marlin > rasterizer was added in FX 9 and was made the default in FX 10. Marlin both outperforms Pisces and is more robust. > There is no reason to keep the Pisces rasterizer(s) any more. Note that the SW pipeline still has a Pisces-based > renderer for the actual rendering of primitives. This is separate from the rasterizer and is not affected by this > proposed fix. I have tested this on Mac, Windows, and Linux. This pull request has now been integrated. Changeset: 5c596b14 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5c596b14 Stats: 10224 lines in 30 files changed: 10217 ins; 1 del; 6 mod 8196079: Remove obsolete Pisces rasterizer Reviewed-by: prr, lbourges ------------- PR: https://git.openjdk.java.net/jfx/pull/268 From bchoudhary at openjdk.java.net Mon Aug 10 12:23:34 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 10 Aug 2020 12:23:34 GMT Subject: Integrated: 8181775: JavaFX WebView does not calculate border-radius properly In-Reply-To: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> References: <5QH7_-ZuKLxdG7xunZ5D8Unu9xKIxi_upbhSZlO0Tn8=.37a43402-2a90-4058-ae3b-f0b7f8e3d769@github.com> Message-ID: On Thu, 14 May 2020 08:15:19 GMT, Bhawesh Choudhary wrote: > root cause of issue is prism's fillRoundedRect() API doesn't allow rendering of rounded corner rectangle if four > corners have different radii. but same can be achieved via Path. to fix the issue, in GraphicsContextJava.cpp while > rendering fillRoundedRect, check if all four corners have same radii. if yes, use FILL_ROUNDED_RECT to draw it > otherwise construct a path from given rounded rect and draw it. This pull request has now been integrated. Changeset: f216c5fe Author: Bhawesh Choudhary Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f216c5fe Stats: 104 lines in 2 files changed: 0 ins; 95 del; 9 mod 8181775: JavaFX WebView does not calculate border-radius properly Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/218 From jvos at openjdk.java.net Mon Aug 10 12:23:37 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 Aug 2020 12:23:37 GMT Subject: RFR: 8249777: build.gradle: project.version should not contain time stamps [v2] In-Reply-To: <9RmAkJXr0lOHwc6IwZIlEXpEnyGonm34_lyUmhsPLH0=.12f1660f-eac7-4475-ab9a-873a7bc137a9@github.com> References: <9RmAkJXr0lOHwc6IwZIlEXpEnyGonm34_lyUmhsPLH0=.12f1660f-eac7-4475-ab9a-873a7bc137a9@github.com> Message-ID: On Thu, 23 Jul 2020 13:45:33 GMT, Kevin Rushforth wrote: >> The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, >> controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing >> problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). >> We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we >> were creating them, we would have the problem that each time we ran gradle, it would generate a new >> `project-$version.jar` file with a different time stamp each time the build was run. The setting of >> `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor >> for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to >> `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven >> publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the >> maven publishing tasks. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unised mavenPublish property from graphics project Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/270 From kcr at openjdk.java.net Mon Aug 10 12:37:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 12:37:39 GMT Subject: Integrated: 8249777: build.gradle: project.version should not contain time stamps In-Reply-To: References: Message-ID: On Wed, 22 Jul 2020 17:22:25 GMT, Kevin Rushforth wrote: > The addMavenPublication method sets the `project.version` to `$MAVEN_VERSION`, where project is base, graphics, > controls, etc. When doing an ordinary "developer" build, this property contains the time stamp . This is causing > problems with the NetBeans gradle plugin not being able to determine the dependencies between the projects (modules). > We haven't noticed this bug before now, because we suppress the creation of the individual project jar files, but if we > were creating them, we would have the problem that each time we ran gradle, it would generate a new > `project-$version.jar` file with a different time stamp each time the build was run. The setting of > `project.version=$MAVEN_VERSION` is only used by the maven "publish" tasks, which isn't done for developer builds nor > for most productions builds. The proposed solution is to add a new boolean `MAVEN_PUBLISH` flag, which will default to > `false`. This flag will qualify the setting of the `MAVEN_VERSION` property and the configuration of the maven > publishing tasks. After this change, it will be necessary to run gradle with `-PMAVEN_PUBLISH=true` in order to run the > maven publishing tasks. This pull request has now been integrated. Changeset: aefed810 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/aefed810 Stats: 11 lines in 1 file changed: 1 ins; 9 del; 1 mod 8249777: build.gradle: project.version should not contain time stamps Reviewed-by: sykora, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/270 From kcr at openjdk.java.net Mon Aug 10 12:48:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 12:48:08 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: References: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> Message-ID: <9B4KVPdppxdxhFfAJzPRwqrGRrQUsS0QmSqO4ZvRK0g=.60c77ec5-c8ec-4d10-9639-3c5c309381b5@github.com> On Mon, 10 Aug 2020 12:45:07 GMT, Johan Vos wrote: >> I don't mind either way. > > I don't think it's bad to stating this explicitly here. Agreed. ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From jvos at openjdk.java.net Mon Aug 10 12:48:08 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 Aug 2020 12:48:08 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v3] In-Reply-To: References: <6iWllOo1VaefwKV5310VMbtgrYv1AJIEH_vbwRQzmCI=.846fa99d-2e64-4314-92c7-7ee99c12a4aa@github.com> Message-ID: On Fri, 7 Aug 2020 13:33:22 GMT, Kevin Rushforth wrote: >> True, but I just looked at [Border](https://openjfx.io/javadoc/14/javafx.graphics/javafx/scene/layout/Border.html) >> which states immutability, so I did the same. I don't mind changing it. > > I don't mind either way. I don't think it's bad to stating this explicitly here. ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From jvos at openjdk.java.net Mon Aug 10 12:53:31 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 Aug 2020 12:53:31 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v4] In-Reply-To: <8Wu1g_mqpGYIEbFgWyIuwKd0AxbBZqa0m_zJEVxV4eY=.74267bbf-8d76-4939-875f-b2712004831e@github.com> References: <8Wu1g_mqpGYIEbFgWyIuwKd0AxbBZqa0m_zJEVxV4eY=.74267bbf-8d76-4939-875f-b2712004831e@github.com> Message-ID: On Mon, 10 Aug 2020 05:39:05 GMT, Nir Lisker wrote: >> This was missed the in Javadoc fixes for 15. >> >> Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added @param tags Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From kcr at openjdk.java.net Mon Aug 10 13:00:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 13:00:51 GMT Subject: [jfx15] RFR: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors [v4] In-Reply-To: <8Wu1g_mqpGYIEbFgWyIuwKd0AxbBZqa0m_zJEVxV4eY=.74267bbf-8d76-4939-875f-b2712004831e@github.com> References: <8Wu1g_mqpGYIEbFgWyIuwKd0AxbBZqa0m_zJEVxV4eY=.74267bbf-8d76-4939-875f-b2712004831e@github.com> Message-ID: <4y2I0ZyLjEwh5qoINo9zdnNQ13NYBpEoX1Cy6eaJFZ4=.2ce981de-52f3-440b-a7e2-a12a7a10c906@github.com> On Mon, 10 Aug 2020 05:39:05 GMT, Nir Lisker wrote: >> This was missed the in Javadoc fixes for 15. >> >> Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added @param tags Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From nlisker at openjdk.java.net Mon Aug 10 13:04:35 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 13:04:35 GMT Subject: [jfx15] Integrated: 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors In-Reply-To: References: Message-ID: <1mtXLqipjgpPaNF5MyfviHUA0e2MkbBo6Pe9gIqf8ik=.e3b9855a-366d-47f0-b6e3-84b4f83df55d@github.com> On Thu, 30 Jul 2020 00:27:18 GMT, Nir Lisker wrote: > This was missed the in Javadoc fixes for 15. > > Added documentation for all the constructors, did a bit of formatting, and removed redundant comments. This pull request has now been integrated. Changeset: 7a8708b0 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/7a8708b0 Stats: 87 lines in 3 files changed: 10 ins; 66 del; 11 mod 8250799: NumberStringConverter and its subclasses are missing documentation for all their constructors Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/277 From kcr at openjdk.java.net Mon Aug 10 13:10:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 13:10:08 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Mon, 10 Aug 2020 10:26:50 GMT, Nir Lisker wrote: >> In reading the existing doc carefully, it is both wrong and confusing. It has the wrong ordering of transform, scale >> and rotate. It is also confusing given that no distinction is made between matrix multiplication order and the observed >> effect on the geometry of the node. You have fixed the part about it being wrong, but the confusion remains, especially >> since you made a point of saying that the transforms list is applied in the reverse order. The matrices are multiplied >> in the following order: 1. layoutX/Y + translateX/Y/Z >> 2. rotate >> 3. scale >> 4. transforms[0] >> 5. transforms[1] >> ... >> >> We need to both list the actual matrix multiplication order, and then describe that the object is transformed from >> object coordinates to local coordinates of the node, to parent coordinated, etc., by first applying the transforms in >> the list in reverse order, then scale, rotate, translate+layout. I don't think that the `transforms` list is the place >> to do that (it belongs in the Transformations section). This doesn't seem like something we can sort out for JavaFX >> 15, so I would split this out and defer it. > > So should I revert all the changes about the transforms and leave it for 16, or do part of it now and part later? > The changes are in the docs for the `Node` class, the `getTransforms()` method and the `boundsInParentProperty()` > method. It seems best to revert all of the transform changes in this PR and deal with it in 16. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Mon Aug 10 13:10:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 Aug 2020 13:10:07 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v2] In-Reply-To: References: Message-ID: On Mon, 10 Aug 2020 06:34:57 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 868: >> >>> 867: * clearing the map or overriding its values. These entries are not removed automatically if the node is >>> removed from the layout 868: * manager, so unused entries can exist throughout the life of the node. >>> 869: * >> >> If we were in the habit of using `@apiNote` then that's probably where the note about layout managers using the node >> properties would go. Since we aren't, this seems fine. > > I think that `@aipNote` is indeed better. Does it require a CSR? In this case, I think it would be fine without a CSR, since it is just a clarifying note for developers. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Mon Aug 10 16:08:31 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 16:08:31 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v4] In-Reply-To: References: Message-ID: <57L1gVUnCEhIJ6GfUN5LMc_jEsGji84LpAeN-dRIaJQ=.7a8cd7ac-d28e-4aca-bd15-7e8b3e6e2709@github.com> > Adds clarifications to the documentation in various places. Some notes: > > * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were > updated to Java 8 only. > * Point 8 has been deferred until all the animation bugs have been resolevd. > * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback > extractor)` method. Later I found that `observableList(List list, Callback extractor)` already > talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. > * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that > this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and > there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality > instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. > I think that in the future we will want to let the user define what a change is (for example, by creating an > overridable method with the current behavior as the default, or using object equality and letting the user override > that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation > `IndentityHashMap` to deal with this ambiguity. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Reverted transforms-related changes and added API note for getProperties ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/276/files - new: https://git.openjdk.java.net/jfx/pull/276/files/6c0a3eb9..3bb17c7e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/276/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/276/webrev.02-03 Stats: 26 lines in 1 file changed: 5 ins; 7 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/276/head:pull/276 PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Mon Aug 10 16:37:11 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 10 Aug 2020 16:37:11 GMT Subject: RFR: 8217472: Add attenuation for PointLight [v11] In-Reply-To: References: Message-ID: > CSR: https://bugs.openjdk.java.net/browse/JDK-8218264 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/43/files - new: https://git.openjdk.java.net/jfx/pull/43/files/3ab051d2..2c9af767 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/43/webrev.10 - incr: https://webrevs.openjdk.java.net/jfx/43/webrev.09-10 Stats: 134 lines in 10 files changed: 125 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx/pull/43 From bchoudhary at openjdk.java.net Tue Aug 11 16:55:13 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 11 Aug 2020 16:55:13 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling Message-ID: ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. ------------- Commit messages: - Formatting - Formatting - added Unit Test - 8202990: javafx webview css filter property with display scaling Changes: https://git.openjdk.java.net/jfx/pull/279/files Webrev: https://webrevs.openjdk.java.net/jfx/279/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202990 Stats: 46 lines in 4 files changed: 45 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/279/head:pull/279 PR: https://git.openjdk.java.net/jfx/pull/279 From kcr at openjdk.java.net Tue Aug 11 20:53:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 Aug 2020 20:53:30 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v4] In-Reply-To: <57L1gVUnCEhIJ6GfUN5LMc_jEsGji84LpAeN-dRIaJQ=.7a8cd7ac-d28e-4aca-bd15-7e8b3e6e2709@github.com> References: <57L1gVUnCEhIJ6GfUN5LMc_jEsGji84LpAeN-dRIaJQ=.7a8cd7ac-d28e-4aca-bd15-7e8b3e6e2709@github.com> Message-ID: On Mon, 10 Aug 2020 16:08:31 GMT, Nir Lisker wrote: >> Adds clarifications to the documentation in various places. Some notes: >> >> * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were >> updated to Java 8 only. >> * Point 8 has been deferred until all the animation bugs have been resolevd. >> * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback >> extractor)` method. Later I found that `observableList(List list, Callback extractor)` already >> talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. >> * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that >> this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and >> there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality >> instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. >> I think that in the future we will want to let the user define what a change is (for example, by creating an >> overridable method with the current behavior as the default, or using object equality and letting the user override >> that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation >> `IndentityHashMap` to deal with this ambiguity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Reverted transforms-related changes and added API note for getProperties I left a couple inline comments. I think the changes to the two `FXCollections` methods that take an extractor parameter are fine, other than the one comment I made which would help unify the docs between the two methods. modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 324: > 323: * a change in one of those observables, the user is notified of it through an > 324: * {@link ListChangeListener.Change#wasUpdated() update} change of an attached {@code ListChangeListener}. > These changes 325: * are unrelated to the changes made to the observable list itself using methods such as {@code > add} and {@code remove}. I suggest to change this to `@linkplain`. modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 330: > 329: * @param The type of List to be wrapped > 330: * @param extractor element to Observable[] converter. Observable objects are listened for changes on the > element. 331: * @return a newly created ObservableList You can probably drop the second sentence (and thus the period after the first) if you copy the following from `observableList` to the description of this method: Observable objects returned by the extractor (applied to each list element) are listened for changes... modules/javafx.controls/src/main/java/javafx/scene/control/Pagination.java line 90: > 89: * public Node call(Integer pageIndex) { > 90: * return new Label(pageIndex + 1 + ". Lorem ipsum dolor sit amet,\n" > 91: * + "consectetur adipiscing elit,\n" Do you think we need keep the non-lambda version of the example? It's up to you. modules/javafx.graphics/src/main/java/javafx/animation/Timeline.java line 49: > 48: *

    > 49: * {@code Timeline} processes individual a {@code KeyFrame} at or after the specified > 50: * time interval elapsed, it does not guarantee the exact time when a {@code KeyFrame} The `a` and `KeyFrame` are switched in this sentence; it should be `processes an individual @{KeyFrame}` instead. Also, the previous paragraph should say either `processes individual {@code KeyFrame}s sequentially` or `processes individual {@code KeyFrame} objects sequentially` or similar. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From florian.kirmaier at gmail.com Wed Aug 12 08:25:52 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Wed, 12 Aug 2020 10:25:52 +0200 Subject: Enter, Non-Push-Button, Mac - popposing change Message-ID: Hi everyone, related ticket from the past: https://bugs.openjdk.java.net/browse/JDK-8139509 Examples for ButtonTypes: non-push-buttons: RadioButton, CheckBox pushButtons: Button, ToggleButton CurrentStatus: Consumes EnterEvent Windows Mac PushButton true false NotPushButton true false I propose changing this behavior to the following: Consumes EnterEvent Windows Mac PushButton true true NotPushButton false false Why? On Windows, the non-push-buttons usually don't work on enter. They only consume enter by accident because of the changes made, in JDK-8139509. So this should be changed, we should probably add a way to distinguish between push and pushable buttons. On Mac, I think normal buttons should also consume enter. The OS-Dialogs don't have the concept focus, so they can't be used as a reference. On Safari, only TextFields can be focused but buttons can't be focused, which isn't a real option for JavaFX. On the other Browsers, they behave the same as Windows (Chrome Firefox). Proposed Solution: - Remove the not-mac-condition whether to decide we want to consume the Enter-Event. - Make push button distinguishable from other buttons, use it to decide whether enter consumes the event Advantages: - Focused RadioButtons/Checkboxes etc. no longer block the DefaultButton - Behavior would be the same on all Systems - Enter on a mac would work again, which is the default on mac on browsers. I've created a ticket for it: https://bugs.openjdk.java.net/browse/JDK-8251472 Any opinions on the topic? Greetings Florian Kirmaier From nlisker at openjdk.java.net Wed Aug 12 10:26:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 12 Aug 2020 10:26:06 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v5] In-Reply-To: References: Message-ID: > Adds clarifications to the documentation in various places. Some notes: > > * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were > updated to Java 8 only. > * Point 8 has been deferred until all the animation bugs have been resolevd. > * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback > extractor)` method. Later I found that `observableList(List list, Callback extractor)` already > talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. > * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that > this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and > there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality > instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. > I think that in the future we will want to let the user define what a change is (for example, by creating an > overridable method with the current behavior as the default, or using object equality and letting the user override > that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation > `IndentityHashMap` to deal with this ambiguity. 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/276/files - new: https://git.openjdk.java.net/jfx/pull/276/files/3bb17c7e..93ad171e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/276/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/276/webrev.03-04 Stats: 25 lines in 2 files changed: 5 ins; 2 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/276/head:pull/276 PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Wed Aug 12 10:26:07 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 12 Aug 2020 10:26:07 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v4] In-Reply-To: References: <57L1gVUnCEhIJ6GfUN5LMc_jEsGji84LpAeN-dRIaJQ=.7a8cd7ac-d28e-4aca-bd15-7e8b3e6e2709@github.com> Message-ID: On Tue, 11 Aug 2020 20:37:54 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted transforms-related changes and added API note for getProperties > > modules/javafx.controls/src/main/java/javafx/scene/control/Pagination.java line 90: > >> 89: * public Node call(Integer pageIndex) { >> 90: * return new Label(pageIndex + 1 + ". Lorem ipsum dolor sit amet,\n" >> 91: * + "consectetur adipiscing elit,\n" > > Do you think we need keep the non-lambda version of the example? It's up to you. Other controls have them, so I kept it. ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Wed Aug 12 13:31:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Aug 2020 13:31:04 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v5] In-Reply-To: References: Message-ID: On Wed, 12 Aug 2020 10:26:06 GMT, Nir Lisker wrote: >> Adds clarifications to the documentation in various places. Some notes: >> >> * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were >> updated to Java 8 only. >> * Point 8 has been deferred until all the animation bugs have been resolevd. >> * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback >> extractor)` method. Later I found that `observableList(List list, Callback extractor)` already >> talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. >> * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that >> this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and >> there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality >> instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. >> I think that in the future we will want to let the user define what a change is (for example, by creating an >> overridable method with the current behavior as the default, or using object equality and letting the user override >> that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation >> `IndentityHashMap` to deal with this ambiguity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From kcr at openjdk.java.net Wed Aug 12 16:01:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Aug 2020 16:01:32 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Tue, 11 Aug 2020 16:18:37 GMT, Bhawesh Choudhary wrote: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. With your patch installed, I see a race condition that manifests in one of two ways: * If I load the new .html file with HelloWebView, I see the shadow most of the time, but it is messing some of the time. * The new unit test crashes intermittently I suspect this might be related to the `gc.setCompositeOperation` call. Are you certain this is being done on the right thread? ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/279 From arapte at openjdk.java.net Thu Aug 13 05:04:12 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 13 Aug 2020 05:04:12 GMT Subject: [jfx15] RFR: 8228570: Add various documentation clarifications [v5] In-Reply-To: References: Message-ID: On Wed, 12 Aug 2020 10:26:06 GMT, Nir Lisker wrote: >> Adds clarifications to the documentation in various places. Some notes: >> >> * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were >> updated to Java 8 only. >> * Point 8 has been deferred until all the animation bugs have been resolevd. >> * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback >> extractor)` method. Later I found that `observableList(List list, Callback extractor)` already >> talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. >> * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that >> this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and >> there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality >> instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. >> I think that in the future we will want to let the user define what a change is (for example, by creating an >> overridable method with the current behavior as the default, or using object equality and letting the user override >> that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation >> `IndentityHashMap` to deal with this ambiguity. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From nlisker at openjdk.java.net Thu Aug 13 06:45:43 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 13 Aug 2020 06:45:43 GMT Subject: [jfx15] Integrated: 8228570: Add various documentation clarifications In-Reply-To: References: Message-ID: On Mon, 27 Jul 2020 20:32:46 GMT, Nir Lisker wrote: > Adds clarifications to the documentation in various places. Some notes: > > * Point 6 should probably be deferred until it is verified that the tutorials are correct enough, seeing as they were > updated to Java 8 only. > * Point 8 has been deferred until all the animation bugs have been resolevd. > * Point 5: I wrote new documentation about the `extractor` for the `observableArrayList(Callback > extractor)` method. Later I found that `observableList(List list, Callback extractor)` already > talks about it (I updated it too). I'm not sure which of them we want to keep, or maybe merge them. > * Point 1: I think that it's necessary to mention the internal implementation behavior even if it requires a caveat that > this is only the current behavior and may change in the future. What constitutes a "change" is extremely important and > there is no way for the user to know it. I've tripped on this hard when using ReactFX which uses object equality > instead, so when the JavaFX observables are wrapped by ReactFX observables, the behavior changes silently. > I think that in the future we will want to let the user define what a change is (for example, by creating an > overridable method with the current behavior as the default, or using object equality and letting the user override > that, although that's more risky). Even a `HashMap` that uses object equality has the sister implementation > `IndentityHashMap` to deal with this ambiguity. This pull request has now been integrated. Changeset: 208d8282 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/208d8282 Stats: 126 lines in 9 files changed: 16 ins; 63 del; 47 mod 8228570: Add various documentation clarifications Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/276 From florian.kirmaier at gmail.com Thu Aug 13 12:39:08 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Thu, 13 Aug 2020 14:39:08 +0200 Subject: RFR: JDK-8251241 - mac minimize Message-ID: Hi everyone, Can someone look into my small fix for mac minimize? https://github.com/openjdk/jfx/pull/280 Greetings Florian Kirmaier From kevin.rushforth at oracle.com Thu Aug 13 12:42:47 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Aug 2020 05:42:47 -0700 Subject: RFR: JDK-8251241 - mac minimize In-Reply-To: References: Message-ID: <1996dced-8eab-7e7b-6d40-ba9ecd7b3f3f@oracle.com> Can you change the PR title to be properly formatted? That will allow Skara to initiate the RFR, and is needed for a formal review (and eventual integration). -- Kevin On 8/13/2020 5:39 AM, Florian Kirmaier wrote: > Hi everyone, > > Can someone look into my small fix for mac minimize? > https://github.com/openjdk/jfx/pull/280 > > Greetings Florian Kirmaier From fkirmaier at openjdk.java.net Thu Aug 13 12:44:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 12:44:13 GMT Subject: RFR: JDK-8251241 fixing mac minimize Message-ID: ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 This small change fixing the minimize for mac. Changes are property registered. Calling setIconize(true) no longer resets to false. ------------- Commit messages: - JDK-8251241 Changes: https://git.openjdk.java.net/jfx/pull/280/files Webrev: https://webrevs.openjdk.java.net/jfx/280/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251241 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/280.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/280/head:pull/280 PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 12:49:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 12:49:54 GMT Subject: RFR: 8251241: fixing mac minimize In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 12:37:11 GMT, Florian Kirmaier wrote: > ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 > > This small change fixing the minimize for mac. > Changes are property registered. > Calling setIconize(true) no longer resets to false. > JDK-8251241: macOS: iconify property doesn't change after minimize when resizable is false ?? Title mismatch between PR > and JBS. Can you change the title to match the JBS title? ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 12:54:51 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 12:54:51 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 12:47:32 GMT, Kevin Rushforth wrote: >> ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 >> >> This small change fixing the minimize for mac. >> Changes are property registered. >> Calling setIconize(true) no longer resets to false. > >> JDK-8251241: macOS: iconify property doesn't change after minimize when resizable is false ?? Title mismatch between PR >> and JBS. > > Can you change the title to match the JBS title? Done! I've changed the title. ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 16:40:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 16:40:07 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false In-Reply-To: References: Message-ID: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> On Thu, 13 Aug 2020 12:37:11 GMT, Florian Kirmaier wrote: > ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 > > This small change fixing the minimize for mac. > Changes are property registered. > Calling setIconize(true) no longer resets to false. This looks good based on my initial testing, including a modified version of the test program that doesn't temporarily set resizable to true. Nice. I want to do some additional testing. I left one minor comment on the code formatting inline. modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Java.m line 100: > 99: type = com_sun_glass_events_WindowEvent_MINIMIZE; > 100: } else if([self->nsWindow isZoomed]) { > 101: type = com_sun_glass_events_WindowEvent_MAXIMIZE; Minor: can you add a space between `if` and `(` to match our coding style? ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 17:11:59 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 17:11:59 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v2] In-Reply-To: References: Message-ID: > ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 > > This small change fixing the minimize for mac. > Changes are property registered. > Calling setIconize(true) no longer resets to false. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8251241 Added missing spaces to match the coding style. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/280/files - new: https://git.openjdk.java.net/jfx/pull/280/files/f89e43f2..1f42cebe Webrevs: - full: https://webrevs.openjdk.java.net/jfx/280/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/280/webrev.00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/280.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/280/head:pull/280 PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 17:12:01 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 17:12:01 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v2] In-Reply-To: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> References: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> Message-ID: On Thu, 13 Aug 2020 16:35:51 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8251241 >> Added missing spaces to match the coding style. > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Java.m line 100: > >> 99: type = com_sun_glass_events_WindowEvent_MINIMIZE; >> 100: } else if([self->nsWindow isZoomed]) { >> 101: type = com_sun_glass_events_WindowEvent_MAXIMIZE; > > Minor: can you add a space between `if` and `(` to match our coding style? Done! ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 17:12:22 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 17:12:22 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v2] In-Reply-To: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> References: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> Message-ID: <2Hy7phxu_1aUmZvVzy4ooO8ls8guHRLzM7GFFBv8Hik=.3f2d7c27-4e72-4a4c-8c75-c6a1fb9caf65@github.com> On Thu, 13 Aug 2020 16:37:44 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8251241 >> Added missing spaces to match the coding style. > > This looks good based on my initial testing, including a modified version of the test program that doesn't temporarily > set resizable to true. Nice. > I want to do some additional testing. > > I left one minor comment on the code formatting inline. Thank you for the very quick feedback! In the application, the fix was developed for, it also seems to fix all issues related to iconified. ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 18:13:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 18:13:45 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v2] In-Reply-To: <2Hy7phxu_1aUmZvVzy4ooO8ls8guHRLzM7GFFBv8Hik=.3f2d7c27-4e72-4a4c-8c75-c6a1fb9caf65@github.com> References: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> <2Hy7phxu_1aUmZvVzy4ooO8ls8guHRLzM7GFFBv8Hik=.3f2d7c27-4e72-4a4c-8c75-c6a1fb9caf65@github.com> Message-ID: On Thu, 13 Aug 2020 17:09:43 GMT, Florian Kirmaier wrote: >> This looks good based on my initial testing, including a modified version of the test program that doesn't temporarily >> set resizable to true. Nice. >> I want to do some additional testing. >> >> I left one minor comment on the code formatting inline. > > Thank you for the very quick feedback! > In the application, the fix was developed for, it also seems to fix all issues related to iconified. You may have seen my comment in JBS: This PR also fixes [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202), which I discovered while testing [JDK-8248490](https://bugs.openjdk.java.net/browse/JDK-8248490). This means that I already have an automated test that can be modified to test this. I just need to add a couple things to it (an assertion check for the iconified property, a check to ensure that we can deiconify the stage, and then add a mode to run it with a non-resizable stage). Once I verify it, I can send you the patch for the test, if that's OK with you? ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 19:24:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 19:24:14 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v2] In-Reply-To: References: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> <2Hy7phxu_1aUmZvVzy4ooO8ls8guHRLzM7GFFBv8Hik=.3f2d7c27-4e72-4a4c-8c75-c6a1fb9caf65@github.com> Message-ID: On Thu, 13 Aug 2020 18:11:25 GMT, Kevin Rushforth wrote: >> Thank you for the very quick feedback! >> In the application, the fix was developed for, it also seems to fix all issues related to iconified. > > You may have seen my comment in JBS: This PR also fixes > [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202), which I discovered while testing > [JDK-8248490](https://bugs.openjdk.java.net/browse/JDK-8248490). This means that I already have an automated test that > can be modified to test this. I just need to add a couple things to it (an assertion check for the iconified property, > a check to ensure that we can deiconify the stage, and then add a mode to run it with a non-resizable stage). Once I > verify it, I can send you the patch for the test, if that's OK with you? Here is [the patch](https://github.com/openjdk/jfx/files/5071008/icontest.patch.txt) for [IconifyTest.java](https://github.com/openjdk/jfx/blob/1f42cebed04d88998d1a66ce99ba3c51995a18a8/tests/system/src/test/java/test/robot/javafx/stage/IconifyTest.java) : [icontest.patch.txt](https://github.com/openjdk/jfx/files/5071008/icontest.patch.txt) I verified that it catches the bugs, in that the modified test fails without the fix and passes with the fix. Can you apply the patch to your repo and push a new commit with the updated test? ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 19:27:26 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 19:27:26 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 20:39:56 GMT, Kevin Rushforth wrote: >> As mentioned - I don't have a good setup to test this code on Windows. >> >> But I've checked where focusedWindow/getFocusedWindow is used, and I can verify your assumption. I've searched through >> the whole project and the variable is only used in the MonocleCode. >> The fact that focusedWindow get's sometimes set is probably the cause of the irregular happening memoryleak on Window. > > In reading the comments, I thought you were going to revert the changes to `Window.java`? Or did I misinterpret what > you said earlier? > I can confirm that `focusedWindow` is no longer correctly set to the focused window when that Window is first shown (I > tried this on Windows). This is true for apps with multiple windows as well as single Stage apps. I can also confirm > that `focusedWindow` isn't used on any platform other than Monocle. Even so, since this change isn't needed it seems > best to revert it. The motivation for this change was, that I've seen a similar bug on native-windows without monocle. In this case a leak happened related to the focusedWindow variable. Sadly I don't have a test for this bug, because it is undeterministic. For that reason, I thought it would make sense to keep this change, because I think it fixes it. If I remember correctly, it was related to Stages which were focused but closed at the same time, which only weren't collected because of the focusedWindow variable. Because the variable also isn't used on NativeWindows it doesn't seem to do much harm. I've now removed it, but it might be considered to be readded. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Thu Aug 13 19:27:28 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 19:27:28 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 21:38:27 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> The tests are now reused for native and monocle tests. > > tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 60: > >> 59: static WeakReference closedFocusedStageWeak = null; >> 60: static Stage closedFocusedStage = null; >> 61: > > These two can be instance fields (which is usually preferred for test variables). They are called from the following static method: @BeforeClass public static void initFX() throws Exception { initFXBase(); } ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Thu Aug 13 19:42:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 19:42:14 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Wed, 22 Apr 2020 12:03:34 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > The tests are now reused for native and monocle tests. The fix looks good now. I'll file a follow-up issue for the potential leak on the other platforms. My thinking is that if `focusedWindow` is only used in Monocle, we should push the tracking down to the platform rather than tracking it in the base class. Alternatively, we could have a platform-specific attribute that indicates whether to track (and leave it null otherwise). ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Thu Aug 13 19:42:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 19:42:15 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Fri, 7 Aug 2020 21:34:49 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> The tests are now reused for native and monocle tests. > > tests/system/src/test/java/test/javafx/stage/FocusedWindowMonocleTest.java line 56: > >> 55: } >> 56: } > > Minor: Add missing newline I meant that the file should end with a newline (it doesn't matter whether or not there is a newline before the final closing brace). The red circle with a `-` in it is GitHub's way of showing you that the file doesn't end with a newline. > tests/system/src/test/java/test/javafx/stage/FocusedWindowNativeTest.java line 52: > >> 51: } >> 52: } > > Minor: Add missing newline Same as in previous file. > tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 106: > >> 105: } >> 106: } > > Minor: Add missing newline Same as in previous file. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Thu Aug 13 19:42:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 19:42:15 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: <5y9rNlz24ZzGDIeh5mUh79-hPeNG9Sp1B-HxklD5-E0=.98a26bd5-da2e-4514-bd4a-0ecf5771e62f@github.com> On Sun, 9 Aug 2020 17:11:27 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 60: >> >>> 59: static WeakReference closedFocusedStageWeak = null; >>> 60: static Stage closedFocusedStage = null; >>> 61: >> >> These two can be instance fields (which is usually preferred for test variables). > > They are called from the following static method: > @BeforeClass > public static void initFX() throws Exception { > initFXBase(); > } No, these two are only used from `testClosedFocusedStageLeakBase`, which is an instance method. I removed `static` while testing it and it compiles and runs fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Thu Aug 13 19:45:49 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 19:45:49 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v3] In-Reply-To: References: <2fzBU2X_8PlLaSTaY7CDFrfy-92zmVo6cIHuemxAwrA=.8c2c4a66-72e8-4749-85b8-041052368668@github.com> <2Hy7phxu_1aUmZvVzy4ooO8ls8guHRLzM7GFFBv8Hik=.3f2d7c27-4e72-4a4c-8c75-c6a1fb9caf65@github.com> Message-ID: On Thu, 13 Aug 2020 19:21:56 GMT, Kevin Rushforth wrote: >> You may have seen my comment in JBS: This PR also fixes >> [JDK-8249202](https://bugs.openjdk.java.net/browse/JDK-8249202), which I discovered while testing >> [JDK-8248490](https://bugs.openjdk.java.net/browse/JDK-8248490). This means that I already have an automated test that >> can be modified to test this. I just need to add a couple things to it (an assertion check for the iconified property, >> a check to ensure that we can deiconify the stage, and then add a mode to run it with a non-resizable stage). Once I >> verify it, I can send you the patch for the test, if that's OK with you? > > Here is [the patch](https://github.com/openjdk/jfx/files/5071008/icontest.patch.txt) for > [IconifyTest.java](https://github.com/openjdk/jfx/blob/1f42cebed04d88998d1a66ce99ba3c51995a18a8/tests/system/src/test/java/test/robot/javafx/stage/IconifyTest.java) > : [icontest.patch.txt](https://github.com/openjdk/jfx/files/5071008/icontest.patch.txt) > > I verified that it catches the bugs, in that the modified test fails without the fix and passes with the fix. > > Can you apply the patch to your repo and push a new commit with the updated test? I've added your patch for the unit-test! Nice to see it fixes more bugs. : ) Don't want to know how many hours were spent working around this bug by all the people around the world. Compared to this, the fix was developed really quickly. ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Thu Aug 13 19:45:49 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 13 Aug 2020 19:45:49 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v3] In-Reply-To: References: Message-ID: > ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 > > This small change fixing the minimize for mac. > Changes are property registered. > Calling setIconize(true) no longer resets to false. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8251241 applied tests from kevinrushforth ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/280/files - new: https://git.openjdk.java.net/jfx/pull/280/files/1f42cebe..7c9584f3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/280/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/280/webrev.01-02 Stats: 28 lines in 1 file changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/280.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/280/head:pull/280 PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 19:52:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 19:52:18 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 19:40:02 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8241840 >> The tests are now reused for native and monocle tests. > > The fix looks good now. I'll file a follow-up issue for the potential leak on the other platforms. > > My thinking is that if `focusedWindow` is only used in Monocle, we should push the tracking down to the platform rather > than tracking it in the base class. Alternatively, we could have a platform-specific attribute that indicates whether > to track (and leave it null otherwise). I filed [JDK-8251555](https://bugs.openjdk.java.net/browse/JDK-8251555) to track the follow-on issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Thu Aug 13 20:32:07 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 20:32:07 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v3] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 19:45:49 GMT, Florian Kirmaier wrote: >> ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 >> >> This small change fixing the minimize for mac. >> Changes are property registered. >> Calling setIconize(true) no longer resets to false. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8251241 > applied tests from kevinrushforth Looks good. Thanks for fixing this long-standing bug. I ran a full set of unit test, including the newly modified one. All looks good. Can we get one more reviewer on this? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/280 From kcr at openjdk.java.net Thu Aug 13 21:39:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Aug 2020 21:39:18 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v3] In-Reply-To: <0jolnM-kTVjKbwU7wBu45V9co51Lek95lKAurb0q0qk=.db82b6e5-8598-4879-8773-6b69c194a816@github.com> References: <0jolnM-kTVjKbwU7wBu45V9co51Lek95lKAurb0q0qk=.db82b6e5-8598-4879-8773-6b69c194a816@github.com> Message-ID: On Sun, 2 Aug 2020 10:27:17 GMT, Tobias Diez wrote: >> Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url >> start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. > > Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace Changes requested by kcr (Lead). modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 478: > 477: @Test public void loadJrtCssFileSuccessfully() { > 478: getEngine().setUserStyleSheetLocation("jrt:/javafx.web/html/imported-styles.css"); > 479: } This won't run as is for a couple reasons. First it's on the wrong thread, but more importantly, you will not be able to load anything from the unit test using a `jrt` URL, so I don't think a unit test in the `javafx.web` module itself will work. You will either need to provide a system test in `tests/system/` that creates a modular jar file (which is probably overkill for this fix), or else a manual test in `tests/manual`. The latter seems sufficient for this bug and will be easier. ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Aug 14 06:13:45 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 14 Aug 2020 06:13:45 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v3] In-Reply-To: References: <0jolnM-kTVjKbwU7wBu45V9co51Lek95lKAurb0q0qk=.db82b6e5-8598-4879-8773-6b69c194a816@github.com> Message-ID: On Thu, 13 Aug 2020 21:36:52 GMT, Kevin Rushforth wrote: >> Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove whitespace > > modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 478: > >> 477: @Test public void loadJrtCssFileSuccessfully() { >> 478: getEngine().setUserStyleSheetLocation("jrt:/javafx.web/html/imported-styles.css"); >> 479: } > > This won't run as is for a couple reasons. First it's on the wrong thread, but more importantly, you will not be able > to load anything from the unit test using a `jrt` URL, so I don't think a unit test in the `javafx.web` module itself > will work. You will either need to provide a system test in `tests/system/` that creates a modular jar file (which is > probably overkill for this fix), or else a manual test in `tests/manual`. The latter seems sufficient for this bug and > will be easier. Thanks for the feedback. How is `tests/manual` invoked? I don't see how it would make it possible to load the jrt url successful (as you need to have a modularized app for this, or not?). Moreover, the test here was supposed to only check that jrt url's are no longer rejected. Not that the css is successfully applied (since there is no bug in this part of the code, and I couldn't find such a test for the loading of a normal "file://" or "jar://" either). ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Aug 14 06:23:18 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 14 Aug 2020 06:23:18 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4] In-Reply-To: References: Message-ID: > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: Update MiscellaneousTest.java ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/22/files - new: https://git.openjdk.java.net/jfx/pull/22/files/717dd939..ad72fd63 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/22/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/22/webrev.02-03 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx/pull/22 From fkirmaier at openjdk.java.net Fri Aug 14 10:09:22 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 Aug 2020 10:09:22 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v7] In-Reply-To: References: Message-ID: <9CFk-h4Lu_0-FtBa8zIB2x7JZeN79Yq2-tFej7J1RFA=.59f21627-0685-40d1-aeef-8f1684a614b3@github.com> > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8241840 small formatting changes based on codereview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/153/files - new: https://git.openjdk.java.net/jfx/pull/153/files/a7c9d83c..2971a112 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/153/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/153/webrev.05-06 Stats: 8 lines in 3 files changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/153.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/153/head:pull/153 PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Fri Aug 14 10:09:28 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 Aug 2020 10:09:28 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: <5y9rNlz24ZzGDIeh5mUh79-hPeNG9Sp1B-HxklD5-E0=.98a26bd5-da2e-4514-bd4a-0ecf5771e62f@github.com> References: <5y9rNlz24ZzGDIeh5mUh79-hPeNG9Sp1B-HxklD5-E0=.98a26bd5-da2e-4514-bd4a-0ecf5771e62f@github.com> Message-ID: On Thu, 13 Aug 2020 19:31:57 GMT, Kevin Rushforth wrote: >> They are called from the following static method: >> @BeforeClass >> public static void initFX() throws Exception { >> initFXBase(); >> } > > No, these two are only used from `testClosedFocusedStageLeakBase`, which is an instance method. I removed `static` > while testing it and it compiles and runs fine. You are right, I've probably picked up the other 2 static variables. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Fri Aug 14 10:09:30 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 Aug 2020 10:09:30 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 19:26:47 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/javafx/stage/FocusedWindowMonocleTest.java line 56: >> >>> 55: } >>> 56: } >> >> Minor: Add missing newline > > I meant that the file should end with a newline (it doesn't matter whether or not there is a newline before the final > closing brace). The red circle with a `-` in it is GitHub's way of showing you that the file doesn't end with a newline. done >> tests/system/src/test/java/test/javafx/stage/FocusedWindowTestBase.java line 106: >> >>> 105: } >>> 106: } >> >> Minor: Add missing newline > > Same as in previous file. done >> tests/system/src/test/java/test/javafx/stage/FocusedWindowNativeTest.java line 52: >> >>> 51: } >>> 52: } >> >> Minor: Add missing newline > > Same as in previous file. done ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Fri Aug 14 10:10:01 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 Aug 2020 10:10:01 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v5] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 19:49:45 GMT, Kevin Rushforth wrote: >> The fix looks good now. I'll file a follow-up issue for the potential leak on the other platforms. >> >> My thinking is that if `focusedWindow` is only used in Monocle, we should push the tracking down to the platform rather >> than tracking it in the base class. Alternatively, we could have a platform-specific attribute that indicates whether >> to track (and leave it null otherwise). > > I filed [JDK-8251555](https://bugs.openjdk.java.net/browse/JDK-8251555) to track the follow-on issue. Great, I've added the changes and commented on the now ticket. ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Fri Aug 14 12:25:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Aug 2020 12:25:05 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v7] In-Reply-To: <9CFk-h4Lu_0-FtBa8zIB2x7JZeN79Yq2-tFej7J1RFA=.59f21627-0685-40d1-aeef-8f1684a614b3@github.com> References: <9CFk-h4Lu_0-FtBa8zIB2x7JZeN79Yq2-tFej7J1RFA=.59f21627-0685-40d1-aeef-8f1684a614b3@github.com> Message-ID: On Fri, 14 Aug 2020 10:09:22 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > small formatting changes based on codereview Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From kcr at openjdk.java.net Fri Aug 14 12:38:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Aug 2020 12:38:24 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4] In-Reply-To: <_aGb-tBcmjYvlTOWjsbXHENp8lYsVOCUycRaingzq6Q=.01b6b235-34ee-4cc5-91c8-9b8671a8ac47@github.com> References: <_aGb-tBcmjYvlTOWjsbXHENp8lYsVOCUycRaingzq6Q=.01b6b235-34ee-4cc5-91c8-9b8671a8ac47@github.com> Message-ID: On Fri, 14 Aug 2020 12:35:00 GMT, Kevin Rushforth wrote: >> Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: >> >> Update MiscellaneousTest.java > > Given the simplicity of the fix, I think the minimal test is enough. @arun-Joseph can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From kcr at openjdk.java.net Fri Aug 14 12:38:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 Aug 2020 12:38:24 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4] In-Reply-To: References: Message-ID: <_aGb-tBcmjYvlTOWjsbXHENp8lYsVOCUycRaingzq6Q=.01b6b235-34ee-4cc5-91c8-9b8671a8ac47@github.com> On Fri, 14 Aug 2020 06:23:18 GMT, Tobias Diez wrote: >> Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url >> start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. > > Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: > > Update MiscellaneousTest.java Given the simplicity of the fix, I think the minimal test is enough. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/22 From arapte at openjdk.java.net Fri Aug 14 13:03:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 14 Aug 2020 13:03:06 GMT Subject: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. [v7] In-Reply-To: <9CFk-h4Lu_0-FtBa8zIB2x7JZeN79Yq2-tFej7J1RFA=.59f21627-0685-40d1-aeef-8f1684a614b3@github.com> References: <9CFk-h4Lu_0-FtBa8zIB2x7JZeN79Yq2-tFej7J1RFA=.59f21627-0685-40d1-aeef-8f1684a614b3@github.com> Message-ID: On Fri, 14 Aug 2020 10:09:22 GMT, Florian Kirmaier wrote: >> Closed focused Stages are not collected with Monocle >> >> This commit adds a unit-test and a fix for collecting focused closed stages. >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8241840 > small formatting changes based on codereview Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From fkirmaier at openjdk.java.net Fri Aug 14 17:46:12 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 Aug 2020 17:46:12 GMT Subject: Integrated: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. In-Reply-To: References: Message-ID: On Mon, 30 Mar 2020 13:37:51 GMT, Florian Kirmaier wrote: > Closed focused Stages are not collected with Monocle > > This commit adds a unit-test and a fix for collecting focused closed stages. > > ticket: https://bugs.openjdk.java.net/browse/JDK-8241840 This pull request has now been integrated. Changeset: 1c54e612 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1c54e612 Stats: 211 lines in 4 files changed: 0 ins; 210 del; 1 mod 8241840: Memoryleak: Closed focused Stages are not collected with Monocle. Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/153 From ajoseph at openjdk.java.net Fri Aug 14 17:47:54 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 14 Aug 2020 17:47:54 GMT Subject: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4] In-Reply-To: References: Message-ID: On Fri, 14 Aug 2020 06:23:18 GMT, Tobias Diez wrote: >> Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url >> start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. > > Tobias Diez has updated the pull request incrementally with one additional commit since the last revision: > > Update MiscellaneousTest.java The fix and test looks good. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/22 From github.com+5037600+tobiasdiez at openjdk.java.net Fri Aug 14 20:24:41 2020 From: github.com+5037600+tobiasdiez at openjdk.java.net (Tobias Diez) Date: Fri, 14 Aug 2020 20:24:41 GMT Subject: Integrated: 8240969: WebView does not allow to load style sheet in modularized applications In-Reply-To: References: Message-ID: On Thu, 24 Oct 2019 16:42:14 GMT, Tobias Diez wrote: > Currently, loading a style sheet file using `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url > start's with `jrt`, i.e. if the file is packaged in an application image using jlink. This is fixed with this PR. This pull request has now been integrated. Changeset: 2aed5ad3 Author: Tobias Diez Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2aed5ad3 Stats: 16 lines in 2 files changed: 0 ins; 15 del; 1 mod 8240969: WebView does not allow to load style sheet in modularized applications Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/22 From gb91757 at gmail.com Sat Aug 15 10:55:09 2020 From: gb91757 at gmail.com (Andrew Waters) Date: Sat, 15 Aug 2020 11:55:09 +0100 Subject: Unable to import OpenJFX Build into Eclipse Message-ID: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> Hi All, I'm trying to diagnose a bug in OpenJFX that I've been struggling with on and off for almost a year(!) and I decided to build OpenJFX from source and use Eclipse to help.? I've built a brand new Ubuntu 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX 14.? I've run the Gradle build and run the tests and all looks 100%. When importing the root directory (home/jdkdev/dev/jfx) into Eclipse using the gradle import tool (using the wrapper option as recommended) I get this build path error: Cannot nest 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' inside library 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' It seems to be trying to set up a looped import to itself somehow.? I've tried to edit the build path in eclipse but the fields appear to be all non-editable.? Has anyone any idea as to what the problem is and how to fix it?? Has anyone recently done a successful import with these latest levels? As this is the base module none of the other modules compile of course so they too may have other problems once the base module is fixed. I tried the "existing projects" import too but that just appears to have even more problems. Thanks, Andrew Waters UK. From TobiasDiez at gmx.de Sun Aug 16 13:28:25 2020 From: TobiasDiez at gmx.de (Tobias Diez) Date: Sun, 16 Aug 2020 15:28:25 +0200 Subject: Make TransformationList (Filtered and Sorted) extendable Message-ID: <000601d673d1$1ef218f0$5cd64ad0$@gmx.de> Hello everybody, Right now it is hard to extend the FilteredList and the SortedList as these classes are marked final. This makes it practically impossible to add convenient helper methods, or change or extend the behavior of these classes. I agree that normally you don't need to extend them, but I also don't see any reason why you shouldn't be allowed to do so. Usually, you could use composition over inheritance if a class is marked final but you still want to extend it. However, some of the controls expect really a SortedList , e.g. https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/ java/javafx/scene/control/TableView.java#L442 So this approach does not work either. The motivation for me comes from some limitations that we encountered while developing EasyBind, a small library to make bindings easier. We provide a few convenient methods that extend the ObservableList, and we want to provide a fluent interface similar to streams, e.g. EasyBind.wrap(standard observable list).filter(predicate).map(mapper). For this to work, the filter method needs to return a FilteredList with the additional map method. The easiest solution would be to derive from FilteredList, and implement the "EasyObservableList" interface that we have. Removing the final keyword is done in the following PR: https://github.com/openjdk/jfx/pull/278 Looking forward to your feedback. Best regards Tobias From nlisker at gmail.com Sun Aug 16 19:49:47 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 16 Aug 2020 22:49:47 +0300 Subject: Unable to import OpenJFX Build into Eclipse In-Reply-To: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> References: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> Message-ID: Hi Andrew, I did the same setup only with Ubuntu 18, which shouldn't matter, and I don't remember having this issue. I can try redoing it next time I boot the Ubuntu partition. What looks odd is that the error references the build directory. What happens if you clean the project first? - Nir On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: > Hi All, > > > I'm trying to diagnose a bug in OpenJFX that I've been struggling with > on and off for almost a year(!) and I decided to build OpenJFX from > source and use Eclipse to help. I've built a brand new Ubuntu > 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX > 14. I've run the Gradle build and run the tests and all looks 100%. > > > When importing the root directory (home/jdkdev/dev/jfx) into Eclipse > using the gradle import tool (using the wrapper option as recommended) I > get this build path error: > > > Cannot nest > 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' > > inside library > 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' > > > It seems to be trying to set up a looped import to itself somehow. I've > tried to edit the build path in eclipse but the fields appear to be all > non-editable. Has anyone any idea as to what the problem is and how to > fix it? Has anyone recently done a successful import with these latest > levels? > > > As this is the base module none of the other modules compile of course > so they too may have other problems once the base module is fixed. > > > I tried the "existing projects" import too but that just appears to have > even more problems. > > > Thanks, > > Andrew Waters > > UK. > > From arapte at openjdk.java.net Mon Aug 17 06:45:26 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 Aug 2020 06:45:26 GMT Subject: [jfx15] RFR: 8249537: Update copyright header for files modified in 2020 Message-ID: Update last modified year of copyright headers for files modified in 2020. ------------- Commit messages: - 8249537: Update copyright header for files modified in 2020 Changes: https://git.openjdk.java.net/jfx/pull/281/files Webrev: https://webrevs.openjdk.java.net/jfx/281/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249537 Stats: 92 lines in 91 files changed: 0 ins; 0 del; 92 mod Patch: https://git.openjdk.java.net/jfx/pull/281.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/281/head:pull/281 PR: https://git.openjdk.java.net/jfx/pull/281 From tom.schindl at bestsolution.at Mon Aug 17 07:42:24 2020 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 17 Aug 2020 09:42:24 +0200 Subject: Unable to import OpenJFX Build into Eclipse In-Reply-To: References: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> Message-ID: <0ba0cda3-600f-fa39-45ad-1f7f05565648@bestsolution.at> Hi, Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we checked in all .product/.classpath files is that this did not work in the past. At least my Eclipse install I use for OpenJFX-Development does not have the gradle-tooling installed and things work there just fine. Tom Am 16.08.20 um 21:49 schrieb Nir Lisker: > Hi Andrew, > > I did the same setup only with Ubuntu 18, which shouldn't matter, and I > don't remember having this issue. I can try redoing it next time I boot the > Ubuntu partition. > > What looks odd is that the error references the build directory. What > happens if you clean the project first? > > - Nir > > On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: > >> Hi All, >> >> >> I'm trying to diagnose a bug in OpenJFX that I've been struggling with >> on and off for almost a year(!) and I decided to build OpenJFX from >> source and use Eclipse to help. I've built a brand new Ubuntu >> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX >> 14. I've run the Gradle build and run the tests and all looks 100%. >> >> >> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse >> using the gradle import tool (using the wrapper option as recommended) I >> get this build path error: >> >> >> Cannot nest >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' >> >> inside library >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' >> >> >> It seems to be trying to set up a looped import to itself somehow. I've >> tried to edit the build path in eclipse but the fields appear to be all >> non-editable. Has anyone any idea as to what the problem is and how to >> fix it? Has anyone recently done a successful import with these latest >> levels? >> >> >> As this is the base module none of the other modules compile of course >> so they too may have other problems once the base module is fixed. >> >> >> I tried the "existing projects" import too but that just appears to have >> even more problems. >> >> >> Thanks, >> >> Andrew Waters >> >> UK. >> >> From bchoudhary at openjdk.java.net Mon Aug 17 09:30:48 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 17 Aug 2020 09:30:48 GMT Subject: RFR: 8251352: Many javafx.base classes have implicit no-arg constructors Message-ID: Added missing explicit no-arg constructors to classes in package javafx.beans.property, javafx.collections, javafx.util and javafx.util.converter in module javafx.base. ------------- Commit messages: - 8251352: Many javafx.base classes have implicit no-arg constructors Changes: https://git.openjdk.java.net/jfx/pull/282/files Webrev: https://webrevs.openjdk.java.net/jfx/282/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251352 Stats: 224 lines in 35 files changed: 224 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/282.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/282/head:pull/282 PR: https://git.openjdk.java.net/jfx/pull/282 From bchoudhary at openjdk.java.net Mon Aug 17 11:25:01 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 17 Aug 2020 11:25:01 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors Message-ID: Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. ------------- Commit messages: - 8251353: Many javafx scenegraph classes have implicit no-arg constructors Changes: https://git.openjdk.java.net/jfx/pull/283/files Webrev: https://webrevs.openjdk.java.net/jfx/283/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251353 Stats: 92 lines in 14 files changed: 92 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283 PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at gmail.com Mon Aug 17 11:48:18 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 17 Aug 2020 14:48:18 +0300 Subject: Unable to import OpenJFX Build into Eclipse In-Reply-To: <0ba0cda3-600f-fa39-45ad-1f7f05565648@bestsolution.at> References: <635de104-69d2-687d-e100-436502bfe92b@gmail.com> <0ba0cda3-600f-fa39-45ad-1f7f05565648@bestsolution.at> Message-ID: They are not required if you use the command line interface, but I find that they do make things easier since I can run the gradle command from Eclipse directly. The instructions mention that if you import through gradle, you will need to replace the Eclipse files with the ones in the repo because at this point gradle still messes them up. On Mon, Aug 17, 2020 at 10:43 AM Tom Schindl wrote: > Hi, > > Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we > checked in all .product/.classpath files is that this did not work in > the past. > > At least my Eclipse install I use for OpenJFX-Development does not have > the gradle-tooling installed and things work there just fine. > > Tom > > Am 16.08.20 um 21:49 schrieb Nir Lisker: > > Hi Andrew, > > > > I did the same setup only with Ubuntu 18, which shouldn't matter, and I > > don't remember having this issue. I can try redoing it next time I boot > the > > Ubuntu partition. > > > > What looks odd is that the error references the build directory. What > > happens if you clean the project first? > > > > - Nir > > > > On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: > > > >> Hi All, > >> > >> > >> I'm trying to diagnose a bug in OpenJFX that I've been struggling with > >> on and off for almost a year(!) and I decided to build OpenJFX from > >> source and use Eclipse to help. I've built a brand new Ubuntu > >> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX > >> 14. I've run the Gradle build and run the tests and all looks 100%. > >> > >> > >> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse > >> using the gradle import tool (using the wrapper option as recommended) I > >> get this build path error: > >> > >> > >> Cannot nest > >> > 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' > >> > >> inside library > >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' > >> > >> > >> It seems to be trying to set up a looped import to itself somehow. I've > >> tried to edit the build path in eclipse but the fields appear to be all > >> non-editable. Has anyone any idea as to what the problem is and how to > >> fix it? Has anyone recently done a successful import with these latest > >> levels? > >> > >> > >> As this is the base module none of the other modules compile of course > >> so they too may have other problems once the base module is fixed. > >> > >> > >> I tried the "existing projects" import too but that just appears to have > >> even more problems. > >> > >> > >> Thanks, > >> > >> Andrew Waters > >> > >> UK. > >> > >> > From nlisker at openjdk.java.net Mon Aug 17 12:24:08 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 17 Aug 2020 12:24:08 GMT Subject: RFR: 8251352: Many javafx.base classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 09:23:34 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.beans.property, javafx.collections, javafx.util > and javafx.util.converter in module javafx.base. Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/282 From powers.anirvan at gmail.com Mon Aug 17 12:41:52 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Mon, 17 Aug 2020 21:41:52 +0900 Subject: JDK-8154847 : Windows content is blank when using StageStyle.UNIFIED In-Reply-To: <95fd6dbd-6545-e3c5-79a9-c1aca95238cd@oracle.com> References: <95fd6dbd-6545-e3c5-79a9-c1aca95238cd@oracle.com> Message-ID: Hi, I can see in the implementation that Platform.isSupported(ConditionalFeature.UNIFIED_WINDOW) is always false on Linux [1]. So it seems that the issue does not occur in Linux because StageStyle.UNIFIED is not supported there and so as per the specification [2] the StageStyle is downgraded to StageStyle.DECORATED. The workaround of using SW pipeline does not resolve the issue for me when the below option is selected and accent color is changed. Settings (Win + I) -> Personalization -> Colors -> Show accent color on the following surfaces -> Title bars and window borders I was expecting the background color of the window content to be the same as the title bar color / accent color but it is not. Since this issue is in the SW pipeline I don't think the issue is due to a graphics driver bug, or maybe this is a different bug. I have attached my observations in the JBS issue. [1] : https://github.com/openjdk/jfx/blob/2aed5ad3e57cd8aa9875965d17eeb76e09dae13c/modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java#L474 [2] : https://openjfx.io/javadoc/14/javafx.graphics/javafx/stage/StageStyle.html#UNIFIED On Sat, 8 Aug 2020 at 05:25, Kevin Rushforth wrote: > Thanks for the additional information. I added it to the bug report. > > It is interesting to note that it doesn't happen on Linux when running > on the same HW, although it isn't surprising. This is likely a graphics > driver bug, as opposed to a fundamental HW issue, so it isn't surprising > that the results would be different on Linux. > > -- Kevin > > > On 8/7/2020 1:09 PM, Hannes H. wrote: > > Good evening, > > > > Weeks ago I reported a duplicate to JDK-8154847 because I did not realize > > that this has been reported years ago. > > > > As far as I understand most of the contributors to this ticket believe > that > > the problem is related to specific video cards. Since I can reproduce > this > > issue on my developer notebook on Windows 10, I decided to install Linux > > (not on a VM but actually on the hardware) to check if I can reproduce > > the issue there as well. > > > > First tests show that this issue cannot be reproduced on Linux Mint while > > it can on the very same hardware when using Windows 10. > > > > I am not sure if this information helps anyone. I decided to send it to > > this mailing list since I find it very cumbersome to create - another - > > duplicate of an issue just to add information. > > > > If you have any further questions or I can be of assistance with > > reproducing the issue please let me know. > > > > Kind regards, > > Hannes > > -- Anirvan From johntheisen9 at icloud.com Mon Aug 17 13:27:22 2020 From: johntheisen9 at icloud.com (John Theisen) Date: Mon, 17 Aug 2020 08:27:22 -0500 Subject: openjfx-dev Digest, Vol 105, Issue 26 In-Reply-To: References: Message-ID: Remove > On Aug 17, 2020, at 4:35 AM, openjfx-dev-request at openjdk.java.net wrote: > > ?Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Make TransformationList (Filtered and Sorted) extendable > (Tobias Diez) > 2. Re: Unable to import OpenJFX Build into Eclipse (Nir Lisker) > 3. [jfx15] RFR: 8249537: Update copyright header for files > modified in 2020 (Ambarish Rapte) > 4. Re: Unable to import OpenJFX Build into Eclipse (Tom Schindl) > 5. RFR: 8251352: Many javafx.base classes have implicit no-arg > constructors (Bhawesh Choudhary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Aug 2020 15:28:25 +0200 > From: "Tobias Diez" > To: > Subject: Make TransformationList (Filtered and Sorted) extendable > Message-ID: <000601d673d1$1ef218f0$5cd64ad0$@gmx.de> > Content-Type: text/plain; charset="us-ascii" > > Hello everybody, > > Right now it is hard to extend the FilteredList and the SortedList as these > classes are marked final. This makes it practically impossible to add > convenient helper methods, or change or extend the behavior of these > classes. > I agree that normally you don't need to extend them, but I also don't see > any reason why you shouldn't be allowed to do so. > > Usually, you could use composition over inheritance if a class is marked > final but you still want to extend it. However, some of the controls expect > really a SortedList , e.g. > https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/ > java/javafx/scene/control/TableView.java#L442 > So this approach does not work either. > > The motivation for me comes from some limitations that we encountered while > developing EasyBind, a small library to make bindings easier. We provide a > few convenient methods that extend the ObservableList, and we want to > provide a fluent interface similar to streams, e.g. > EasyBind.wrap(standard observable list).filter(predicate).map(mapper). > For this to work, the filter method needs to return a FilteredList with the > additional map method. The easiest solution would be to derive from > FilteredList, and implement the "EasyObservableList" interface that we have. > > Removing the final keyword is done in the following PR: > https://github.com/openjdk/jfx/pull/278 > > Looking forward to your feedback. > Best regards > Tobias > > > > ------------------------------ > > Message: 2 > Date: Sun, 16 Aug 2020 22:49:47 +0300 > From: Nir Lisker > To: Andrew Waters > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Subject: Re: Unable to import OpenJFX Build into Eclipse > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Hi Andrew, > > I did the same setup only with Ubuntu 18, which shouldn't matter, and I > don't remember having this issue. I can try redoing it next time I boot the > Ubuntu partition. > > What looks odd is that the error references the build directory. What > happens if you clean the project first? > > - Nir > >> On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: >> >> Hi All, >> >> >> I'm trying to diagnose a bug in OpenJFX that I've been struggling with >> on and off for almost a year(!) and I decided to build OpenJFX from >> source and use Eclipse to help. I've built a brand new Ubuntu >> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX >> 14. I've run the Gradle build and run the tests and all looks 100%. >> >> >> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse >> using the gradle import tool (using the wrapper option as recommended) I >> get this build path error: >> >> >> Cannot nest >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' >> >> inside library >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' >> >> >> It seems to be trying to set up a looped import to itself somehow. I've >> tried to edit the build path in eclipse but the fields appear to be all >> non-editable. Has anyone any idea as to what the problem is and how to >> fix it? Has anyone recently done a successful import with these latest >> levels? >> >> >> As this is the base module none of the other modules compile of course >> so they too may have other problems once the base module is fixed. >> >> >> I tried the "existing projects" import too but that just appears to have >> even more problems. >> >> >> Thanks, >> >> Andrew Waters >> >> UK. >> >> > > > ------------------------------ > > Message: 3 > Date: Mon, 17 Aug 2020 06:45:26 GMT > From: Ambarish Rapte > To: > Subject: [jfx15] RFR: 8249537: Update copyright header for files > modified in 2020 > Message-ID: > > > Content-Type: text/plain; charset=utf-8 > > Update last modified year of copyright headers for files modified in 2020. > > ------------- > > Commit messages: > - 8249537: Update copyright header for files modified in 2020 > > Changes: https://git.openjdk.java.net/jfx/pull/281/files > Webrev: https://webrevs.openjdk.java.net/jfx/281/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8249537 > Stats: 92 lines in 91 files changed: 0 ins; 0 del; 92 mod > Patch: https://git.openjdk.java.net/jfx/pull/281.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/281/head:pull/281 > > PR: https://git.openjdk.java.net/jfx/pull/281 > > > ------------------------------ > > Message: 4 > Date: Mon, 17 Aug 2020 09:42:24 +0200 > From: Tom Schindl > To: openjfx-dev at openjdk.java.net > Subject: Re: Unable to import OpenJFX Build into Eclipse > Message-ID: <0ba0cda3-600f-fa39-45ad-1f7f05565648 at bestsolution.at> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > > Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we > checked in all .product/.classpath files is that this did not work in > the past. > > At least my Eclipse install I use for OpenJFX-Development does not have > the gradle-tooling installed and things work there just fine. > > Tom > >> Am 16.08.20 um 21:49 schrieb Nir Lisker: >> Hi Andrew, >> >> I did the same setup only with Ubuntu 18, which shouldn't matter, and I >> don't remember having this issue. I can try redoing it next time I boot the >> Ubuntu partition. >> >> What looks odd is that the error references the build directory. What >> happens if you clean the project first? >> >> - Nir >> >>> On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: >>> >>> Hi All, >>> >>> >>> I'm trying to diagnose a bug in OpenJFX that I've been struggling with >>> on and off for almost a year(!) and I decided to build OpenJFX from >>> source and use Eclipse to help. I've built a brand new Ubuntu >>> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX >>> 14. I've run the Gradle build and run the tests and all looks 100%. >>> >>> >>> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse >>> using the gradle import tool (using the wrapper option as recommended) I >>> get this build path error: >>> >>> >>> Cannot nest >>> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' >>> >>> inside library >>> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' >>> >>> >>> It seems to be trying to set up a looped import to itself somehow. I've >>> tried to edit the build path in eclipse but the fields appear to be all >>> non-editable. Has anyone any idea as to what the problem is and how to >>> fix it? Has anyone recently done a successful import with these latest >>> levels? >>> >>> >>> As this is the base module none of the other modules compile of course >>> so they too may have other problems once the base module is fixed. >>> >>> >>> I tried the "existing projects" import too but that just appears to have >>> even more problems. >>> >>> >>> Thanks, >>> >>> Andrew Waters >>> >>> UK. >>> >>> > > > ------------------------------ > > Message: 5 > Date: Mon, 17 Aug 2020 09:30:48 GMT > From: Bhawesh Choudhary > To: > Subject: RFR: 8251352: Many javafx.base classes have implicit no-arg > constructors > Message-ID: > > > Content-Type: text/plain; charset=utf-8 > > Added missing explicit no-arg constructors to classes in package javafx.beans.property, javafx.collections, javafx.util > and javafx.util.converter in module javafx.base. > > ------------- > > Commit messages: > - 8251352: Many javafx.base classes have implicit no-arg constructors > > Changes: https://git.openjdk.java.net/jfx/pull/282/files > Webrev: https://webrevs.openjdk.java.net/jfx/282/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8251352 > Stats: 224 lines in 35 files changed: 224 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jfx/pull/282.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/282/head:pull/282 > > PR: https://git.openjdk.java.net/jfx/pull/282 > > > End of openjfx-dev Digest, Vol 105, Issue 26 > ******************************************** From kcr at openjdk.java.net Mon Aug 17 20:54:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 Aug 2020 20:54:54 GMT Subject: RFR: 8251352: Many javafx.base classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 09:23:34 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.beans.property, javafx.collections, javafx.util > and javafx.util.converter in module javafx.base. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/282 From kcr at openjdk.java.net Mon Aug 17 20:56:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 Aug 2020 20:56:47 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From tobias.oelgarte at gmail.com Tue Aug 18 04:01:17 2020 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Tue, 18 Aug 2020 06:01:17 +0200 Subject: PageOrientation partially ignored? Message-ID: <2c8a2cb9-5c67-9c1a-fa68-fc3575cfc267@gmail.com> I just experimented with the JavaFX printing API and I'm confused about the results. If I request to print in landscape format the resulting page is still in portrait mode, but rotated by 90 degrees and with mirrored borders/margins. Is this intentional or should I file a bug report? Simplified Example: Printer printer = Printer.getDefaultPrinter(); PageLayout layout = printer.createPageLayout(Paper.A4, PageOrientation.LANDSCAPE, 80, 20, 10, 40); PrinterJob job = PrinterJob.createPrinterJob(printer); job.getJobSettings().setPageLayout(layout); boolean success = job.printPage(someNode); if (success) { ??? job.endJob(); } What i would expect would be an A4 page in landscape orientation, with a top border (long side) of 10, a bottom border of 40, a left border of 80 and a right border of 20. The content/node will not be rotated. But what i get is the following. The paper size is A4 as requested. The orientation is portrait (not as requested). The top border (long side) is 40, the bottom border is 10, the left border is 20, the right border is 80. The content/node is rotated by 90 degrees to the left. My guess is that the orientation is partially ignored, resulting in the confusing margins. -- Tobias Oelgarte Mail: tobias.oelgarte at gmail.com From philip.race at oracle.com Tue Aug 18 04:42:40 2020 From: philip.race at oracle.com (Phil Race) Date: Mon, 17 Aug 2020 21:42:40 -0700 Subject: PageOrientation partially ignored? In-Reply-To: <2c8a2cb9-5c67-9c1a-fa68-fc3575cfc267@gmail.com> References: <2c8a2cb9-5c67-9c1a-fa68-fc3575cfc267@gmail.com> Message-ID: <38B4673B-7D4D-4A53-8BBD-AF5A485A177F@oracle.com> what printer, driver, and os? did you call any methods to verify the values being passed are supported ? -Phil. > On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte wrote: > > ?I just experimented with the JavaFX printing API and I'm confused about the results. > > If I request to print in landscape format the resulting page is still in portrait mode, but rotated by 90 degrees and with mirrored borders/margins. Is this intentional or should I file a bug report? > > Simplified Example: > > Printer printer = Printer.getDefaultPrinter(); > PageLayout layout = printer.createPageLayout(Paper.A4, PageOrientation.LANDSCAPE, 80, 20, 10, 40); > PrinterJob job = PrinterJob.createPrinterJob(printer); > job.getJobSettings().setPageLayout(layout); > boolean success = job.printPage(someNode); > if (success) { > job.endJob(); > } > > What i would expect would be an A4 page in landscape orientation, with a top border (long side) of 10, a bottom border of 40, a left border of 80 and a right border of 20. The content/node will not be rotated. > > But what i get is the following. The paper size is A4 as requested. The orientation is portrait (not as requested). The top border (long side) is 40, the bottom border is 10, the left border is 20, the right border is 80. The content/node is rotated by 90 degrees to the left. > > My guess is that the orientation is partially ignored, resulting in the confusing margins. > > -- > Tobias Oelgarte > Mail: tobias.oelgarte at gmail.com From tobias.oelgarte at gmail.com Tue Aug 18 05:08:46 2020 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Tue, 18 Aug 2020 07:08:46 +0200 Subject: PageOrientation partially ignored? In-Reply-To: <38B4673B-7D4D-4A53-8BBD-AF5A485A177F@oracle.com> References: <2c8a2cb9-5c67-9c1a-fa68-fc3575cfc267@gmail.com> <38B4673B-7D4D-4A53-8BBD-AF5A485A177F@oracle.com> Message-ID: <273f6d13-592d-d878-9d2e-12a6d397bc6a@gmail.com> I used the following printers together with JavaFX (versions 14.0.2.1 and 16-ea+1): - cups-pdf under Ubuntu 18.04 (supports A4, all orientations, down to 0 margins) - PDF24 under Windows 7 (supports A4, all orientations, down to 0 margins) - Kyocera FS 2020DN under Windows 7 (supports A4, all orientations, margins adjusted to match printer) All show exactly the same (wrong) result. Tobias Oelgarte Mail: tobias.oelgarte at gmail.com On 18.08.20 06:42, Phil Race wrote: > what printer, driver, and os? > did you call any methods to verify the values being passed are supported ? > > -Phil. > >> On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte wrote: >> >> ?I just experimented with the JavaFX printing API and I'm confused about the results. >> >> If I request to print in landscape format the resulting page is still in portrait mode, but rotated by 90 degrees and with mirrored borders/margins. Is this intentional or should I file a bug report? >> >> Simplified Example: >> >> Printer printer = Printer.getDefaultPrinter(); >> PageLayout layout = printer.createPageLayout(Paper.A4, PageOrientation.LANDSCAPE, 80, 20, 10, 40); >> PrinterJob job = PrinterJob.createPrinterJob(printer); >> job.getJobSettings().setPageLayout(layout); >> boolean success = job.printPage(someNode); >> if (success) { >> job.endJob(); >> } >> >> What i would expect would be an A4 page in landscape orientation, with a top border (long side) of 10, a bottom border of 40, a left border of 80 and a right border of 20. The content/node will not be rotated. >> >> But what i get is the following. The paper size is A4 as requested. The orientation is portrait (not as requested). The top border (long side) is 40, the bottom border is 10, the left border is 20, the right border is 80. The content/node is rotated by 90 degrees to the left. >> >> My guess is that the orientation is partially ignored, resulting in the confusing margins. >> >> -- >> Tobias Oelgarte >> Mail: tobias.oelgarte at gmail.com From tobias.oelgarte at gmail.com Tue Aug 18 08:39:31 2020 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Tue, 18 Aug 2020 10:39:31 +0200 Subject: PageOrientation partially ignored? In-Reply-To: <38B4673B-7D4D-4A53-8BBD-AF5A485A177F@oracle.com> References: <2c8a2cb9-5c67-9c1a-fa68-fc3575cfc267@gmail.com> <38B4673B-7D4D-4A53-8BBD-AF5A485A177F@oracle.com> Message-ID: <24ae0f1e-92ff-800e-8bf7-33b1e61aff6c@gmail.com> I created a minimal example to illustrate the issue. If I print with 'orientation' set to PORTRAIT i get the expected result [1]. But if i print with 'orientation' set to LANDSCAPE, then i still get a page in portrait orientation and with mixed up margins [2]. Picture [3] illustrates what i would expect. ========= [1] https://pasteboard.co/JmUr91w.png (Portrait) [2] https://pasteboard.co/JmUryc2.png (Landscape actual result) [3] https://pasteboard.co/JmUsc04.png (Landscape expected result) ========= public class TestApp extends Application { ??? private final PageOrientation orientation = PageOrientation.LANDSCAPE; ??? @Override ??? public void start(Stage stage) throws Exception { ??? ??? Button printButton = new Button("Print Example Page"); ??? ??? Scene scene = new Scene(printButton); ??? ??? stage.setScene(scene); ??? ??? Rectangle rect = new Rectangle(0,0,null); ??? ??? rect.setStrokeType(StrokeType.INSIDE); ??? ??? rect.setStrokeWidth(4); ??? ??? rect.setStroke(Color.RED); ??? ??? Circle circle = new Circle(0, 0, 40, null); ??? ??? circle.setStrokeWidth(4); ??? ??? circle.setStroke(Color.BLUE); ??? ??? Group group = new Group(rect, circle); ??? ??? printButton.setOnAction(e -> { ??? ??? ??? Printer printer = Printer.getDefaultPrinter(); ??? ??? ??? PrinterJob job = PrinterJob.createPrinterJob(printer); ??? ??? ??? System.out.println(printer); ??? ??? ??? System.out.println("Supports A4 paper: " + printer.getPrinterAttributes().getSupportedPapers().contains(Paper.A4)); ??? ??? ??? System.out.println("Supports Portrait: " + printer.getPrinterAttributes().getSupportedPageOrientations().contains(PageOrientation.PORTRAIT)); ??? ??? ??? System.out.println("Supports Landscape: " + printer.getPrinterAttributes().getSupportedPageOrientations().contains(PageOrientation.LANDSCAPE)); ??? ??? ??? PageLayout layout = printer.createPageLayout(Paper.A4, orientation, 160, 40, 20, 80); ??? ??? ??? job.getJobSettings().setPageLayout(layout); ??? ??? ??? layout = job.getJobSettings().getPageLayout(); ??? ??? ??? System.out.println(layout); ??? ??? ??? rect.setWidth(layout.getPrintableWidth()); ??? ??? ??? rect.setHeight(layout.getPrintableHeight()); ??? ??? ??? boolean success = job.printPage(group); ??? ??? ??? if (success) { ??? ??? ??? ??? job.endJob(); ??? ??? ??? } ??? ??? }); ??? ??? stage.show(); ??? } ??? public static void main(String[] args) { ??? ??? Application.launch(TestApp.class, args); ??? } } On 18.08.2020 06:42, Phil Race wrote: > what printer, driver, and os? > did you call any methods to verify the values being passed are supported ? > > -Phil. > >> On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte wrote: >> >> ?I just experimented with the JavaFX printing API and I'm confused about the results. >> >> If I request to print in landscape format the resulting page is still in portrait mode, but rotated by 90 degrees and with mirrored borders/margins. Is this intentional or should I file a bug report? >> >> Simplified Example: >> >> Printer printer = Printer.getDefaultPrinter(); >> PageLayout layout = printer.createPageLayout(Paper.A4, PageOrientation.LANDSCAPE, 80, 20, 10, 40); >> PrinterJob job = PrinterJob.createPrinterJob(printer); >> job.getJobSettings().setPageLayout(layout); >> boolean success = job.printPage(someNode); >> if (success) { >> job.endJob(); >> } >> >> What i would expect would be an A4 page in landscape orientation, with a top border (long side) of 10, a bottom border of 40, a left border of 80 and a right border of 20. The content/node will not be rotated. >> >> But what i get is the following. The paper size is A4 as requested. The orientation is portrait (not as requested). The top border (long side) is 40, the bottom border is 10, the left border is 20, the right border is 80. The content/node is rotated by 90 degrees to the left. >> >> My guess is that the orientation is partially ignored, resulting in the confusing margins. >> >> -- >> Tobias Oelgarte >> Mail: tobias.oelgarte at gmail.com From bchoudhary at openjdk.java.net Tue Aug 18 12:38:25 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 18 Aug 2020 12:38:25 GMT Subject: Integrated: 8251352: Many javafx.base classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 09:23:34 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.beans.property, javafx.collections, javafx.util > and javafx.util.converter in module javafx.base. This pull request has now been integrated. Changeset: b25ffc7a Author: Bhawesh Choudhary Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/b25ffc7a Stats: 224 lines in 35 files changed: 0 ins; 224 del; 0 mod 8251352: Many javafx.base classes have implicit no-arg constructors Reviewed-by: nlisker, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/282 From nlisker at openjdk.java.net Tue Aug 18 17:51:21 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 18 Aug 2020 17:51:21 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. I've completed a partial review. I think that just mechanically adding a constructor with the same doc everywhere is not a good approach. The classes should be inspected to see if one is needed and if its doc is suitable. See my comments on some of the classes I've looked at. modules/javafx.controls/src/main/java/javafx/scene/control/TableFocusModel.java line 51: > 50: > 51: /** > 52: * Causes the item at the given index to receive the focus. Please add a missing `)` for the class docs on line 30. modules/javafx.controls/src/main/java/javafx/scene/control/TableSelectionModel.java line 46: > 45: > 46: /** > 47: * Convenience function which tests whether the given row and column index Same missing `)` modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 83: > 82: > 83: /** > 84: * There is only one PseudoClass instance for a given pseudoClass. 1. Is having a public constructor for this class a good idea? Instances are created by a factory method. 2. Both methods in this class need documentation update. `getPseudoClass` has a poor method description and the formatting of the `@return` tag is wrong (lowercase and no period). `getPseudoClassName` is missing a description. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 51: > 50: > 51: private static class UniversalSelector { > 52: private static final Selector INSTANCE = Is a public constructor suitable in this class? `createSelector(String)` is the factory. There are public abstract methods here, on the other hand, so I don't know what the design idea is. The class docs should be updated too to say how to use this class. modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 95: > 94: > 95: /** > 96: * Convert from the parsed CSS value to the target property type. Looks like a constructor is fine here if the predefined factories are not suitable, but I'm not familiar with this. modules/javafx.graphics/src/main/java/javafx/css/converter/ShapeConverter.java line 51: > 50: } > 51: > 52: @Override public Shape convert(ParsedValue value, Font font) { Looks like a singleton class. modules/javafx.graphics/src/main/java/javafx/scene/input/ClipboardContent.java line 45: > 44: */ > 45: public ClipboardContent() { > 46: } Not sure that "default" means anything here. I don't see any configuration. modules/javafx.graphics/src/main/java/javafx/application/Preloader.java line 121: > 120: public Preloader() { > 121: } > 122: Not sure that "default" means anything here. I don't see any configuration. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Tue Aug 18 18:43:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Aug 2020 18:43:56 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. @nlisker raises some good issues, so they should be addressed ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Tue Aug 18 18:49:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Aug 2020 18:49:58 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Tue, 18 Aug 2020 17:49:06 GMT, Nir Lisker wrote: > The classes should be inspected to see if one is needed and if its doc is suitable. This is an excellent point. One of the main reasons for not relying on implicit, no-arg constructors is that you might get a public constructor where one isn't intended. See [JDK-8229472](https://bugs.openjdk.java.net/browse/JDK-8229472) and [JDK-8240688](https://bugs.openjdk.java.net/browse/JDK-8240688) for what is needed if we determine that there should not be a public constructor. To that end, I'll go through it more carefully and comment on this specific question. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Tue Aug 18 22:29:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Aug 2020 22:29:11 GMT Subject: [jfx15] RFR: 8249537: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 06:39:08 GMT, Ambarish Rapte wrote: > Update last modified year of copyright headers for files modified in 2020. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/281 From kcr at openjdk.java.net Wed Aug 19 00:14:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Aug 2020 00:14:17 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. I think that two of the classes have implicit constructors that are there by accident. Once we get agreement, I'll file a follow-on bug for those, and those changes should be reverted. As for the other comments, I would prefer a follow-up bug for any doc cleanup that isn't part of adding in an explicit constructor. Tempting as it might be to fix it, it seems out of scope. That leaves the question about the wording. The more I think about it the more I like what the JDK did as opposed to what we did. The question then becomes: if we agree that it's a better pattern, do we adopt it here and then clean it up for the other two batches or just leave it as is for now, and file one cleanup bug for later. I'd like to hear from @aghaisas and @nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Wed Aug 19 00:14:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Aug 2020 00:14:21 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> On Mon, 17 Aug 2020 12:31:14 GMT, Nir Lisker wrote: >> Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. > > modules/javafx.controls/src/main/java/javafx/scene/control/TableFocusModel.java line 51: > >> 50: >> 51: /** >> 52: * Causes the item at the given index to receive the focus. > > Please add a missing `)` for the class docs on line 30. The change to the class header seems unrelated. It would be a good thing to fix, but could be done as part of a follow-on doc cleanup issue. > modules/javafx.graphics/src/main/java/javafx/application/Preloader.java line 121: > >> 120: public Preloader() { >> 121: } >> 122: > > Not sure that "default" means anything here. I don't see any configuration. Right, but isn't that true of most of the classes, including those in the two related bugs that were fixed? Worth noting is that the JDK chose different language for abstract classes than concrete ones. For abstract classes, they just use the following language: * Constructor for subclasses to call. And for concrete ones: Constructs a {@code Foo}. This gets around the problem of whether or not `default` adds any useful information since it is the only constructor. Not saying we should adopt this now, but just adding another data point. > modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 83: > >> 82: >> 83: /** >> 84: * There is only one PseudoClass instance for a given pseudoClass. > > 1. Is having a public constructor for this class a good idea? Instances are created by a factory method. > 2. Both methods in this class need documentation update. `getPseudoClass` has a poor method description and the > formatting of the `@return` tag is wrong (lowercase and no period). `getPseudoClassName` is missing a description. Yes, this constructor is needed. `PseudoClass` is abstract, so it's constructor is just there for subclasses to call (note that for a constructor of an abstract class, `public` and `protected` mean the same thing). As for the other methods in the class, I agree that they should be changed...but in a follow-up issue. > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 51: > >> 50: >> 51: private static class UniversalSelector { >> 52: private static final Selector INSTANCE = > > Is a public constructor suitable in this class? `createSelector(String)` is the factory. There are public abstract > methods here, on the other hand, so I don't know what the design idea is. The class docs should be updated too to say > how to use this class. This one does not look like it should be public. It seems quite by accident, since the only two classes that subclass `Selector` are in the same package and are constructed by factory methods (their constructors are package-scope). This seems like a good candidate for removal (via the deprecate-for-removal, remove route). > modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 95: > >> 94: >> 95: /** >> 96: * Convert from the parsed CSS value to the target property type. > > Looks like a constructor is fine here if the predefined factories are not suitable, but I'm not familiar with this. This one needs to be public since it is subclassed in many other classes. > modules/javafx.graphics/src/main/java/javafx/css/converter/ShapeConverter.java line 51: > >> 50: } >> 51: >> 52: @Override public Shape convert(ParsedValue value, Font font) { > > Looks like a singleton class. Agreed. This is another candidate for removal. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From arapte at openjdk.java.net Wed Aug 19 02:46:57 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 19 Aug 2020 02:46:57 GMT Subject: [jfx15] Integrated: 8249537: Update copyright header for files modified in 2020 In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 06:39:08 GMT, Ambarish Rapte wrote: > Update last modified year of copyright headers for files modified in 2020. This pull request has now been integrated. Changeset: 41ff3fa8 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/41ff3fa8 Stats: 92 lines in 91 files changed: 0 ins; 0 del; 92 mod 8249537: Update copyright header for files modified in 2020 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/281 From arapte at openjdk.java.net Wed Aug 19 13:06:34 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 19 Aug 2020 13:06:34 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: change approach from removing to excluding ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/03538148..f58ee4a2 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.04-05 Stats: 154 lines in 4 files changed: 114 ins; 38 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Wed Aug 19 13:22:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Aug 2020 13:22:58 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v3] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 20:29:47 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8251241 >> applied tests from kevinrushforth > > Looks good. Thanks for fixing this long-standing bug. > > I ran a full set of unit test, including the newly modified one. All looks good. > > Can we get one more reviewer on this? @arapte can you be a second reviewer? ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From github.com+9534301+dlemmermann at openjdk.java.net Wed Aug 19 13:26:50 2020 From: github.com+9534301+dlemmermann at openjdk.java.net (Dirk Lemmermann) Date: Wed, 19 Aug 2020 13:26:50 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 12:52:37 GMT, Florian Kirmaier wrote: >>> JDK-8251241: macOS: iconify property doesn't change after minimize when resizable is false ?? Title mismatch between PR >>> and JBS. >> >> Can you change the title to match the JBS title? > > Done! I've changed the title. Thank you Florian!!! :-) ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From arapte at openjdk.java.net Wed Aug 19 14:06:18 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 19 Aug 2020 14:06:18 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v3] In-Reply-To: <-V5jdNa2cn3k7wb6n9saJeYrmA6PIExi-BMlJROuBcw=.2784bd82-e661-45b2-a719-3886913833d5@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <-V5jdNa2cn3k7wb6n9saJeYrmA6PIExi-BMlJROuBcw=.2784bd82-e661-45b2-a719-3886913833d5@github.com> Message-ID: <6lrK2MLzMtjjopuF-2f0xY9DhtFr8G44IMohlW8nhyI=.e25537ed-eb65-43b2-9b18-4b4dd9a52803@github.com> On Thu, 6 Aug 2020 09:39:35 GMT, Jeanette Winzenburg wrote: > okay, I still favor the not-adding-if-not-needed approach I have updated the PR to use this approach. I did not think that all of `FocusTraversalInputMap.getFocusTraversalMappings()` can be removed. But looks like they can be removed without any side effect. This approach looks good. Additionally, changed name of the property as `excludeKeyMappingsForComboBoxEditor` to reflect the action. > whether or not the mappings are not/added to the inputMaps. Added this test for both ComboBox and ListView. > Anyway, could be left open for the scope of this issue, IMO. I also think the same that it can be kept out of scope for now. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From daniel.peintner at gmail.com Wed Aug 19 15:17:17 2020 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 19 Aug 2020 17:17:17 +0200 Subject: TabPane - initial select tab not working properly? Message-ID: All, I just stumbled over a problem which I think is a bug in JavaFX. In a program I create several tabs and initialize a selected tab upfront. The 'select' command works fine for the tab pane content but unfortunately not for the header that shows the current active tab (somehow the tab header does not move to the set index). Note1: Only happens for indices outside the visible range Note2: wrapping the 'select' command in Platform.runLater() works as expected Please find below a simple example to reproduce the issue. Do you consider this behavior being a bug? I see the problem for JavaFX 8 but also for 15-ea. Thanks for any insight, -- Daniel =========== import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.control.Tab; import javafx.scene.control.TabPane; import javafx.stage.Stage; public class TestManyTabs extends Application { @Override public void start(Stage stage) { TabPane tabPane = new TabPane(); for (int i = 0; i < 30; i++) { Tab tab = new Tab("Tab " + i); tab.setContent(new Label("Content for " + i)); tabPane.getTabs().add(tab); } // set initial tab *outside* the visible range // Issue: tab header does *not* switch properly // Note: wrapping the following select statement in Platform.runLater() works as expected // Platform.runLater(() -> { tabPane.getSelectionModel().select(25); // }); Scene scene = new Scene(tabPane, 600, 400); stage.setScene(scene); stage.show(); } public static void main(String[] args) { Application.launch(TestManyTabs.class, args); } } From arapte at openjdk.java.net Wed Aug 19 16:44:01 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 19 Aug 2020 16:44:01 GMT Subject: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false [v3] In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 19:45:49 GMT, Florian Kirmaier wrote: >> ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 >> >> This small change fixing the minimize for mac. >> Changes are property registered. >> Calling setIconize(true) no longer resets to false. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8251241 > applied tests from kevinrushforth Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From fkirmaier at openjdk.java.net Wed Aug 19 17:37:36 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 19 Aug 2020 17:37:36 GMT Subject: Integrated: 8251241: macOS: iconify property doesn't change after minimize when resizable is false In-Reply-To: References: Message-ID: On Thu, 13 Aug 2020 12:37:11 GMT, Florian Kirmaier wrote: > ticket: https://bugs.openjdk.java.net/browse/JDK-8251241 > > This small change fixing the minimize for mac. > Changes are property registered. > Calling setIconize(true) no longer resets to false. This pull request has now been integrated. Changeset: 85821ca1 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/85821ca1 Stats: 36 lines in 2 files changed: 0 ins; 29 del; 7 mod 8251241: macOS: iconify property doesn't change after minimize when resizable is false Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/280 From ambarish.rapte at oracle.com Wed Aug 19 18:45:31 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 19 Aug 2020 11:45:31 -0700 (PDT) Subject: TabPane - initial select tab not working properly? In-Reply-To: References: Message-ID: Hello Daniel, The behavior seems like a bug to me. Looks like the first layout of TabHeader fails to bring the selected tab header into view. You can report it here https://bugs.java.com/bugdatabase/ Reason why it works with Platform.runLater(): Wrapping the select() call inside a Platfrom.runLater() causes it to run after the stage is shown i.e. after the first layout is performed. It can be confirmed, by wrapping a call to System.out.println(stage.isShowing()); along with select() call OR by wrapping the select() call inside stage.setOnShown(); instead of Platform.runLater(). Regards, Ambarish -----Original Message----- From: Daniel Peintner Sent: Wednesday, August 19, 2020 8:47 PM To: openjfx-dev at openjdk.java.net Subject: TabPane - initial select tab not working properly? All, I just stumbled over a problem which I think is a bug in JavaFX. In a program I create several tabs and initialize a selected tab upfront. The 'select' command works fine for the tab pane content but unfortunately not for the header that shows the current active tab (somehow the tab header does not move to the set index). Note1: Only happens for indices outside the visible range Note2: wrapping the 'select' command in Platform.runLater() works as expected Please find below a simple example to reproduce the issue. Do you consider this behavior being a bug? I see the problem for JavaFX 8 but also for 15-ea. Thanks for any insight, -- Daniel =========== import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.control.Tab; import javafx.scene.control.TabPane; import javafx.stage.Stage; public class TestManyTabs extends Application { @Override public void start(Stage stage) { TabPane tabPane = new TabPane(); for (int i = 0; i < 30; i++) { Tab tab = new Tab("Tab " + i); tab.setContent(new Label("Content for " + i)); tabPane.getTabs().add(tab); } // set initial tab *outside* the visible range // Issue: tab header does *not* switch properly // Note: wrapping the following select statement in Platform.runLater() works as expected // Platform.runLater(() -> { tabPane.getSelectionModel().select(25); // }); Scene scene = new Scene(tabPane, 600, 400); stage.setScene(scene); stage.show(); } public static void main(String[] args) { Application.launch(TestManyTabs.class, args); } } From perini.davide at dpsoftware.org Thu Aug 20 00:52:41 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Thu, 20 Aug 2020 02:52:41 +0200 Subject: JPackage and JavaFX Message-ID: Hi all, is there someone able to use JPackage with JavaFX under ubuntu with JDK14? When I try to use jpackage on ubuntu I get this error: jpackage -n TestFX -i target --main-jar tmyjar-jar-with-dependencies.jar -d output --module-path /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib WARNING: Using incubator modules: jdk.incubator.jpackage java.lang.module.FindException: Hash of jdk.management.jfr (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) differs to expected hash (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) recorded in java.base Any idea? Thanks From kevin.rushforth at oracle.com Thu Aug 20 01:07:45 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Aug 2020 18:07:45 -0700 Subject: JPackage and JavaFX In-Reply-To: References: Message-ID: I've not seen the module FindException with jfr before, but one thing I do see is that you will need to use the JavaFX jmods rather than the sdk. Otherwise, jlink (which is invoked by jpackage) won't produce a runnable application. -- Kevin On 8/19/2020 5:52 PM, Davide Perini wrote: > Hi all, > is there someone able to use JPackage with JavaFX under ubuntu with > JDK14? > > When I try to use jpackage on ubuntu I get this error: > > jpackage -n TestFX -i target --main-jar > tmyjar-jar-with-dependencies.jar -d output --module-path > /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib > WARNING: Using incubator modules: jdk.incubator.jpackage > > java.lang.module.FindException: Hash of jdk.management.jfr > (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) > differs to expected hash > (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) > recorded in java.base > > Any idea? > > Thanks From jfxuser2 at gmail.com Thu Aug 20 03:09:54 2020 From: jfxuser2 at gmail.com (jfx user2) Date: Wed, 19 Aug 2020 23:09:54 -0400 Subject: HID multitouch display support in JavaFX In-Reply-To: <10df58dd-f163-9749-5e99-c3afa13b3855@jugs.org> References: <10df58dd-f163-9749-5e99-c3afa13b3855@jugs.org> Message-ID: HID support specifically would be good b/c there seem to be lots of cases where the OS's are properly recognizing HID compatible displays with touch events working through the HID APIs but do not work in JavaFX since it relies on the OS's (native?) support. For example, I have multiple HID displays that work as HID devices on MacOS, Windows, Linux (Mint and Ubuntu at least), and Raspberry Pi. But they fail to work in JavaFX except on Windows and sometimes on the Raspberry PI (except you have to run as root). Direct HID support in JavaFX seems like a viable solution to cover more displays on more OSes and bypass the overhead of installing a separate driver that pipes HID events into the OSes touch interfaces. If someone who understands the touch support in JavaFX today could comment that would be great. Touch is critical for the majority of targeted devices (Android, iOS, Pi, and hopefully... Apple Silicon). HID support would expand the ability to test rapidly on existing desktops apart from Windows only. Also, is there a specific GTK issue on Linux b/c I could have sworn HID displays were working fine awhile ago (doesn't work on latest Mint for sure). On Wed, May 13, 2020 at 5:17 AM Michael Paus wrote: > Having proper and consistent Multitouch support on all platforms is > certainly > an interesting goal, especially if your development is targeting a > mobile platform. If one > could test the input behavior already on the desktop, this would be an > enormous time saver because the turn-around times > (edit-compile-build-deploy-debug-curse) > for mobile are currently still extremely high and thus not very > development-friendly. > I learned from your mail that the situation on Windows seems to be better > than on macOS, which is my current development environment. That gives > me an idea :-) > > Am 13.05.20 um 10:15 schrieb jfx user2: > > Nobody is biting... so is anyone else out there interested in using HID > > touchscreens with JavaFX on OSX (or any other plaform) without using a > > third party driver? > > > > On Fri, May 8, 2020 at 4:18 AM jfx user2 wrote: > > > >> Multitouch display support JavaFX on Windows, iOS, and Android seems > >> straightforward. If the OS recognizes the display as multitouch, then > the > >> chances are that JavaFX will also work with it since it relies on the > >> native multitouch support of the OS. > >> > >> When it comes to Linux and OSX, it's not always as easy. Linux > sometimes > >> requires device mapping. I'm not sure if it works at all in OSX unless > you > >> have specific drivers for the display. > >> > >> All of the platforms seem to support HID so maybe JavaFX could have > direct > >> support for HID devices (optionally) if they are present instead of just > >> the current method. It may also improve performance in cases where the > OS > >> is just piping HID events through their own API's to support multitouch. > >> Why not just go straight to the HID source and bypass that conduit. > >> > >> This would vastly improve multitouch app development on OSX. It would > be > >> possible to connect a HID display and use it for testing apps that are > >> destined for platforms that formally support multitouch. > >> > >> Is there any work being done in this area? Is there a bigger picture > >> (e.g. better multi-display and connect/disconnect support in JavaFX)? > >> > >> ... coming from a frustrated OSX user with lots of HID displays and no > >> easy JavaFX support. > >> > >> https://www.usb.org/hid > >> > > From tobias.oelgarte at gmail.com Thu Aug 20 05:15:31 2020 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Thu, 20 Aug 2020 07:15:31 +0200 Subject: JPackage and JavaFX In-Reply-To: References: Message-ID: I have no problem using jpackage together with JDK 14 and JavaFX 14/16 under Ubuntu 18.04. My guess is that you run the jpackage command from a different JDK version, which loads it's own module "java.base" and references it's own module "jdk.management.jfr". This is different from the one found inside the ".. javafx-sdk-14.0.2.1/lib" directory, resulting in the hash conflict. Tobias Oelgarte Mail: tobias.oelgarte at gmail.com On 20.08.20 02:52, Davide Perini wrote: > Hi all, > is there someone able to use JPackage with JavaFX under ubuntu with > JDK14? > > When I try to use jpackage on ubuntu I get this error: > > jpackage -n TestFX -i target --main-jar > tmyjar-jar-with-dependencies.jar -d output --module-path > /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib > WARNING: Using incubator modules: jdk.incubator.jpackage > > java.lang.module.FindException: Hash of jdk.management.jfr > (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) > differs to expected hash > (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) > recorded in java.base > > Any idea? > > Thanks From ajoseph at openjdk.java.net Thu Aug 20 06:10:10 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 20 Aug 2020 06:10:10 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v4] In-Reply-To: References: Message-ID: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Incorect axis of rotational ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/2e2b5cd1..9b841f4b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From bardot.jerome at gmail.com Thu Aug 20 14:12:56 2020 From: bardot.jerome at gmail.com (=?UTF-8?B?QmFyZG90IErDqXLDtG1l?=) Date: Thu, 20 Aug 2020 16:12:56 +0200 Subject: JPackage and JavaFX In-Reply-To: References: Message-ID: <42eb14ff-73a4-b248-0708-63c2c2545465@gmail.com> i personaly try to use javapackager https://github.com/fvarrui/JavaPackager for me this tool need to be hightlight and it need feedback On 20/08/2020 02:52, Davide Perini wrote: > Hi all, > is there someone able to use JPackage with JavaFX under ubuntu with JDK14? > > When I try to use jpackage on ubuntu I get this error: > > jpackage -n TestFX -i target --main-jar tmyjar-jar-with-dependencies.jar > -d output --module-path /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib > WARNING: Using incubator modules: jdk.incubator.jpackage > > java.lang.module.FindException: Hash of jdk.management.jfr > (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) > differs to expected hash > (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) > recorded in java.base > > Any idea? > > Thanks From pnem at cmail.cz Thu Aug 20 14:16:41 2020 From: pnem at cmail.cz (Petr Nemecek) Date: Thu, 20 Aug 2020 16:16:41 +0200 Subject: JavaFX14/Listener not called Message-ID: <004201d676fc$868de290$93a9a7b0$@cmail.cz> Dear all, could somebody explain me, please, why the output differs for CODE-1 and CODE-2 see below? I would expect the listener to be called four times in both cases. I believe there's trivial answer for that, but I'm not able to find it by myself, probably due to the hot weather here in Prague, CZ. Many thanks, Petr *** CODE-1 IntegerProperty property = new SimpleIntegerProperty(); property.addListener((o) -> { System.out.println("value changed to " + property.get() + " ... " + System.currentTimeMillis()); }); for (int i = 0; i < 5; i++) { property.set(i); } OUTPUT-1 value changed to 1 ... 1597932211288 value changed to 2 ... 1597932211293 value changed to 3 ... 1597932211293 value changed to 4 ... 1597932211294 *** CODE-2 IntegerProperty property = new SimpleIntegerProperty(); property.addListener((o) -> { System.out.println("value changed" + " . " + System.currentTimeMillis()); }); for (int i = 0; i < 5; i++) { property.set(i); } OUTPUT-2 value changed ... 1597932237151 *** From nlisker at gmail.com Thu Aug 20 14:57:19 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 20 Aug 2020 17:57:19 +0300 Subject: JavaFX14/Listener not called In-Reply-To: <004201d676fc$868de290$93a9a7b0$@cmail.cz> References: <004201d676fc$868de290$93a9a7b0$@cmail.cz> Message-ID: Hi Peter, This is a development mailing list, not a help list. I suggest you ask questions on a help site. The reason you see this difference is that you're using an invalidation listener which uses lazy evaluation, so in your second example it is not updated because it is not used in the printing method. Read the documentations/tutorial of listeners and observables. - Nir On Thu, Aug 20, 2020 at 5:19 PM Petr Nemecek wrote: > Dear all, > > > > could somebody explain me, please, why the output differs for CODE-1 and > CODE-2 see below? I would expect the listener to be called four times in > both cases. > > > > I believe there's trivial answer for that, but I'm not able to find it by > myself, probably due to the hot weather here in Prague, CZ. > > > > Many thanks, > > Petr > > > > *** > > CODE-1 > > IntegerProperty property = new SimpleIntegerProperty(); > > > > property.addListener((o) -> { > > System.out.println("value changed to " + property.get() + " ... " + > System.currentTimeMillis()); > > }); > > > > for (int i = 0; i < 5; i++) { > > property.set(i); > > } > > > > OUTPUT-1 > > value changed to 1 ... 1597932211288 > > value changed to 2 ... 1597932211293 > > value changed to 3 ... 1597932211293 > > value changed to 4 ... 1597932211294 > > > > *** > > CODE-2 > > IntegerProperty property = new SimpleIntegerProperty(); > > > > property.addListener((o) -> { > > System.out.println("value changed" + " . " + > System.currentTimeMillis()); > > }); > > > > for (int i = 0; i < 5; i++) { > > property.set(i); > > } > > > > OUTPUT-2 > > value changed ... 1597932237151 > > *** > > From kevin.rushforth at oracle.com Thu Aug 20 15:06:50 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Aug 2020 08:06:50 -0700 Subject: JPackage and JavaFX In-Reply-To: <42eb14ff-73a4-b248-0708-63c2c2545465@gmail.com> References: <42eb14ff-73a4-b248-0708-63c2c2545465@gmail.com> Message-ID: <611782f4-2b6a-23e6-e0fc-ff228c74dca7@oracle.com> This list is be the right place to discuss the javapackager tool (regardless of whether or not it is a fork of the old java(fx)packager tool that used to be part of openjfx). -- Kevin On 8/20/2020 7:12 AM, Bardot J?r?me wrote: > i personaly try to use javapackager > https://github.com/fvarrui/JavaPackager > > for me this tool need to be hightlight and it need feedback > > On 20/08/2020 02:52, Davide Perini wrote: >> Hi all, >> is there someone able to use JPackage with JavaFX under ubuntu with JDK14? >> >> When I try to use jpackage on ubuntu I get this error: >> >> jpackage -n TestFX -i target --main-jar tmyjar-jar-with-dependencies.jar >> -d output --module-path /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib >> WARNING: Using incubator modules: jdk.incubator.jpackage >> >> java.lang.module.FindException: Hash of jdk.management.jfr >> (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) >> differs to expected hash >> (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) >> recorded in java.base >> >> Any idea? >> >> Thanks From kevin.rushforth at oracle.com Thu Aug 20 15:07:27 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Aug 2020 08:07:27 -0700 Subject: JPackage and JavaFX In-Reply-To: <611782f4-2b6a-23e6-e0fc-ff228c74dca7@oracle.com> References: <42eb14ff-73a4-b248-0708-63c2c2545465@gmail.com> <611782f4-2b6a-23e6-e0fc-ff228c74dca7@oracle.com> Message-ID: That should be "This list is *not* the right place..." On 8/20/2020 8:06 AM, Kevin Rushforth wrote: > This list is be the right place to discuss the javapackager tool > (regardless of whether or not it is a fork of the old java(fx)packager > tool that used to be part of openjfx). > > -- Kevin > > > On 8/20/2020 7:12 AM, Bardot J?r?me wrote: >> i personaly try to use javapackager >> https://github.com/fvarrui/JavaPackager >> >> for me this tool need to be hightlight and it need feedback >> >> On 20/08/2020 02:52, Davide Perini wrote: >>> Hi all, >>> is there someone able to use JPackage with JavaFX under ubuntu with >>> JDK14? >>> >>> When I try to use jpackage on ubuntu I get this error: >>> >>> jpackage -n TestFX -i target --main-jar >>> tmyjar-jar-with-dependencies.jar >>> -d output --module-path >>> /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib >>> WARNING: Using incubator modules: jdk.incubator.jpackage >>> >>> java.lang.module.FindException: Hash of jdk.management.jfr >>> (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) >>> differs to expected hash >>> (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) >>> recorded in java.base >>> >>> Any idea? >>> >>> Thanks > From daniel.peintner at gmail.com Thu Aug 20 15:43:16 2020 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 20 Aug 2020 17:43:16 +0200 Subject: TabPane - initial select tab not working properly? In-Reply-To: References: Message-ID: Hi Ambarish, all, Thank you for the feedback. I did report the bug and got the internal review ID : 9066543 Thanks, -- Daniel On Wed, Aug 19, 2020 at 8:45 PM Ambarish Rapte wrote: > Hello Daniel, > > The behavior seems like a bug to me. > Looks like the first layout of TabHeader fails to bring the selected tab > header into view. > You can report it here https://bugs.java.com/bugdatabase/ > > Reason why it works with Platform.runLater(): > Wrapping the select() call inside a Platfrom.runLater() causes it to run > after the stage is shown i.e. after the first layout is performed. > It can be confirmed, by wrapping a call to > System.out.println(stage.isShowing()); along with select() call OR by > wrapping the select() call inside stage.setOnShown(); instead of > Platform.runLater(). > > Regards, > Ambarish > > -----Original Message----- > From: Daniel Peintner > Sent: Wednesday, August 19, 2020 8:47 PM > To: openjfx-dev at openjdk.java.net > Subject: TabPane - initial select tab not working properly? > > All, > > I just stumbled over a problem which I think is a bug in JavaFX. > > In a program I create several tabs and initialize a selected tab upfront. > The 'select' command works fine for the tab pane content but unfortunately > not for the header that shows the current active tab (somehow the tab > header does not move to the set index). > > Note1: Only happens for indices outside the visible range > Note2: wrapping the 'select' command in Platform.runLater() works as > expected > > Please find below a simple example to reproduce the issue. > Do you consider this behavior being a bug? > > I see the problem for JavaFX 8 but also for 15-ea. > > Thanks for any insight, > > -- Daniel > > > =========== > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.control.Tab; > import javafx.scene.control.TabPane; > import javafx.stage.Stage; > > public class TestManyTabs extends Application { > > @Override > public void start(Stage stage) { > TabPane tabPane = new TabPane(); > > for (int i = 0; i < 30; i++) { > Tab tab = new Tab("Tab " + i); > tab.setContent(new Label("Content for " + i)); > tabPane.getTabs().add(tab); > } > > // set initial tab *outside* the visible range > // Issue: tab header does *not* switch properly > // Note: wrapping the following select statement in > Platform.runLater() works as expected > // Platform.runLater(() -> { > tabPane.getSelectionModel().select(25); > // }); > > Scene scene = new Scene(tabPane, 600, 400); > stage.setScene(scene); > > stage.show(); > } > > public static void main(String[] args) { > Application.launch(TestManyTabs.class, args); > } > > } > From almatvee at openjdk.java.net Thu Aug 20 23:38:42 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 20 Aug 2020 23:38:42 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video =?UTF-8?B?Ymlu4oCm?= Message-ID: https://bugs.openjdk.java.net/browse/JDK-8252107 - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. ------------- Commit messages: - 8252107: Media pipeline initializtion can crash if audio or video bin state change fails Changes: https://git.openjdk.java.net/jfx/pull/285/files Webrev: https://webrevs.openjdk.java.net/jfx/285/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252107 Stats: 27 lines in 1 file changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/285.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/285/head:pull/285 PR: https://git.openjdk.java.net/jfx/pull/285 From kcr at openjdk.java.net Fri Aug 21 00:01:48 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Aug 2020 00:01:48 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video =?UTF-8?B?Ymlu4oCm?= In-Reply-To: References: Message-ID: <2n-mUHcBLa4tabG9rg_BMSWlDtt3pPegi4W6IzxvXdY=.9336318d-d75f-4cdc-ad60-fd16991065fb@github.com> On Thu, 20 Aug 2020 23:57:12 GMT, Kevin Rushforth wrote: >> https://bugs.openjdk.java.net/browse/JDK-8252107 >> >> - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. > > I built and tested it on Linux and it looks good. Have you done a build / test on Mac and Windows as well? The PR title doesn't match the JBS title. Can you fix it? ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From kcr at openjdk.java.net Fri Aug 21 00:01:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Aug 2020 00:01:47 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video =?UTF-8?B?Ymlu4oCm?= In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020 23:32:24 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8252107 > > - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. I built and tested it on Linux and it looks good. Have you done a build / test on Mac and Windows as well? ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From almatvee at openjdk.java.net Fri Aug 21 00:17:32 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 21 Aug 2020 00:17:32 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails In-Reply-To: References: Message-ID: <2r9jAlugHMQqDdkaYTwQLvY7KapgUec0J5SsTsrxb48=.e2d828c5-3254-41b3-8201-75e76217747f@github.com> On Thu, 20 Aug 2020 23:57:12 GMT, Kevin Rushforth wrote: > I built and tested it on Linux and it looks good. Have you done a build / test on Mac and Windows as well? Yes, Mac and Windows was tested with all formats. ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From almatvee at openjdk.java.net Fri Aug 21 00:17:32 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 21 Aug 2020 00:17:32 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails In-Reply-To: <2n-mUHcBLa4tabG9rg_BMSWlDtt3pPegi4W6IzxvXdY=.9336318d-d75f-4cdc-ad60-fd16991065fb@github.com> References: <2n-mUHcBLa4tabG9rg_BMSWlDtt3pPegi4W6IzxvXdY=.9336318d-d75f-4cdc-ad60-fd16991065fb@github.com> Message-ID: On Thu, 20 Aug 2020 23:59:24 GMT, Kevin Rushforth wrote: > The PR title doesn't match the JBS title. Can you fix it? Fixed. It looks like github auto truncate long titles. ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From kcr at openjdk.java.net Fri Aug 21 13:18:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Aug 2020 13:18:20 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020 23:32:24 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8252107 > > - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From kcr at openjdk.java.net Fri Aug 21 13:18:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Aug 2020 13:18:20 GMT Subject: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails In-Reply-To: References: <2n-mUHcBLa4tabG9rg_BMSWlDtt3pPegi4W6IzxvXdY=.9336318d-d75f-4cdc-ad60-fd16991065fb@github.com> Message-ID: On Fri, 21 Aug 2020 00:15:11 GMT, Alexander Matveev wrote: > Fixed. It looks like github auto truncate long titles. Thanks. Yes, GitHub does do that. ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From perini.davide at dpsoftware.org Fri Aug 21 15:57:57 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 21 Aug 2020 17:57:57 +0200 Subject: JPackage and JavaFX In-Reply-To: References: Message-ID: <5c513f46-7caf-9c96-b872-429dd68dd1f6@dpsoftware.org> But I haven't installed JavaFX manually, I'm getting it with maven, like this: this is the pom.xml https://github.com/sblantipodi/firefly_luciferin/blob/master/pom.xml as you can see I get JavaFX from maven repos. It works on Windows. Any idea? Thanks Davide Il 20/08/2020 07.15, Tobias Oelgarte ha scritto: > I have no problem using jpackage together with JDK 14 and JavaFX 14/16 > under Ubuntu 18.04. > > My guess is that you run the jpackage command from a different JDK > version, which loads it's own module "java.base" and references it's > own module "jdk.management.jfr". This is different from the one found > inside the ".. javafx-sdk-14.0.2.1/lib" directory, resulting in the > hash conflict. > > Tobias Oelgarte > Mail: tobias.oelgarte at gmail.com > > On 20.08.20 02:52, Davide Perini wrote: >> Hi all, >> is there someone able to use JPackage with JavaFX under ubuntu with >> JDK14? >> >> When I try to use jpackage on ubuntu I get this error: >> >> jpackage -n TestFX -i target --main-jar >> tmyjar-jar-with-dependencies.jar -d output --module-path >> /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib >> WARNING: Using incubator modules: jdk.incubator.jpackage >> >> java.lang.module.FindException: Hash of jdk.management.jfr >> (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) >> differs to expected hash >> (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) >> recorded in java.base >> >> Any idea? >> >> Thanks From perini.davide at dpsoftware.org Sat Aug 22 11:32:36 2020 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sat, 22 Aug 2020 13:32:36 +0200 Subject: JPackage and JavaFX In-Reply-To: References: <42eb14ff-73a4-b248-0708-63c2c2545465@gmail.com> <611782f4-2b6a-23e6-e0fc-ff228c74dca7@oracle.com> Message-ID: Just for reference, I was using maven to bundle JavaFX, using OpenJDK I had that error, using AdoptOpenJDK solved the problem. Regards, Davide Il 20/08/2020 17.07, Kevin Rushforth ha scritto: > That should be "This list is *not* the right place..." > > On 8/20/2020 8:06 AM, Kevin Rushforth wrote: >> This list is be the right place to discuss the javapackager tool >> (regardless of whether or not it is a fork of the old >> java(fx)packager tool that used to be part of openjfx). >> >> -- Kevin >> >> >> On 8/20/2020 7:12 AM, Bardot J?r?me wrote: >>> i personaly try to use javapackager >>> https://github.com/fvarrui/JavaPackager >>> >>> for me this tool need to be hightlight and it need feedback >>> >>> On 20/08/2020 02:52, Davide Perini wrote: >>>> Hi all, >>>> is there someone able to use JPackage with JavaFX under ubuntu with >>>> JDK14? >>>> >>>> When I try to use jpackage on ubuntu I get this error: >>>> >>>> jpackage -n TestFX -i target --main-jar >>>> tmyjar-jar-with-dependencies.jar >>>> -d output --module-path >>>> /home/sblantipodi/dev/jdk/javafx-sdk-14.0.2.1/lib >>>> WARNING: Using incubator modules: jdk.incubator.jpackage >>>> >>>> java.lang.module.FindException: Hash of jdk.management.jfr >>>> (a405f735790e653ae6ad1ef35615c78a555389cc5076c74c52f3790a13351666) >>>> differs to expected hash >>>> (06d891a3ae65eb002ec7c3adeac782a67e5c76c5f1569cbb4e9bdace4e220f23) >>>> recorded in java.base >>>> >>>> Any idea? >>>> >>>> Thanks >> > From thangalin at gmail.com Sat Aug 22 17:57:27 2020 From: thangalin at gmail.com (Thangalin) Date: Sat, 22 Aug 2020 10:57:27 -0700 Subject: Blurry render of SwingNode Message-ID: Ahoy list, Running OpenJDK 14.0.1 on Windows 7, adding a SwingNode to a SplitPane causes the contents of the SwingNode to appear blurry. There's a full write-up with screen-shots at: https://stackoverflow.com/q/63444771/59087 Here's an SSCCE that demonstrates the problem: import javafx.application.Application; import javafx.embed.swing.SwingNode; import javafx.scene.Scene; import javafx.scene.control.SplitPane; import javafx.scene.layout.StackPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; import javax.swing.*; import java.awt.*; import static javafx.application.Platform.runLater; import static javax.swing.SwingUtilities.invokeLater; public class FlyingSourceTest extends Application { public static void main( String[] args ) { Application.launch( args ); } @Override public void start( Stage stage ) { invokeLater( () -> { stage.setTitle( "SSCCE" ); final var size = 120f; final var font = new javafx.scene.text.Font( "Arial", size ); final var bgStyle = "-fx-background-color: white"; // FX label, StackPane final var fxLabelTop = new javafx.scene.text.Text( "FX/FX" ); fxLabelTop.setFont( font ); final var fxStackPaneTop = new StackPane( fxLabelTop ); // FX label, StackPane final var fxLabelSplit = new javafx.scene.text.Text( "FX LABEL" ); fxLabelSplit.setFont( font ); final var fxLabelPane = new StackPane(); fxLabelPane.getChildren().addAll( fxLabelSplit ); fxLabelPane.setStyle( bgStyle ); // Swing label, StackPane final var swingLabel = new JLabel( "SW LABEL" ); swingLabel.setBackground( Color.WHITE ); swingLabel.setOpaque( true ); swingLabel.setFont( swingLabel.getFont().deriveFont( Font.PLAIN, size ) ); final var swingLabelNode = new SwingNode(); swingLabelNode.setContent( swingLabel ); final var swingLabelPane = new StackPane( swingLabelNode ); swingLabelPane.setStyle( bgStyle ); final var fxSplitPane = new SplitPane( fxLabelPane, swingLabelPane ); fxSplitPane.setPrefSize( 1280, 300 ); final var root = new VBox(); root.getChildren().addAll( fxStackPaneTop, fxSplitPane ); root.setStyle( bgStyle ); runLater( () -> { final var scene = new Scene( root ); stage.setScene( scene ); stage.show(); } ); } ); } } Closely compare the "L" from "SW LABEL" to the "L" from "FX LABEL". You'll see that the "SW LABEL" ell has what looks like stronger antialiasing applied. Changing the Graphics2D rendering hints on the JLabel has no effect. Changing the JLabel's AffineTransform to shift by 0.5px worsens the blurriness. Moving the SwingNode out of the SplitPane renders crisply, as expected. The font colours and background do not affect the outcome, but are there to make consistent output, which makes comparing easier. This problem affects neither X11 (Linux) nor OSX, only Windows. Been trying to fix this for several days without success. Any ideas why embedding a SwingNode within a SplitPane causes a blurry effect? And how can the problem be resolved? Thank you! From mp at jugs.org Sat Aug 22 18:40:35 2020 From: mp at jugs.org (Michael Paus) Date: Sat, 22 Aug 2020 20:40:35 +0200 Subject: Blurry render of SwingNode In-Reply-To: References: Message-ID: <9d629aec-5a3a-7732-2230-613278198f99@jugs.org> Hi, this is not a bug reporting list. Please file your bug report here https://bugs.java.com/bugdatabase/ instead. Best regards Michael Am 22.08.20 um 19:57 schrieb Thangalin: > Ahoy list, > > Running OpenJDK 14.0.1 on Windows 7, adding a SwingNode to a SplitPane > causes the contents of the SwingNode to appear blurry. There's a full > write-up with screen-shots at: > https://stackoverflow.com/q/63444771/59087 > > Here's an SSCCE that demonstrates the problem: > > import javafx.application.Application; > import javafx.embed.swing.SwingNode; > import javafx.scene.Scene; > import javafx.scene.control.SplitPane; > import javafx.scene.layout.StackPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > import javax.swing.*; > import java.awt.*; > > import static javafx.application.Platform.runLater; > import static javax.swing.SwingUtilities.invokeLater; > > public class FlyingSourceTest extends Application { > public static void main( String[] args ) { > Application.launch( args ); > } > > @Override > public void start( Stage stage ) { > invokeLater( () -> { > stage.setTitle( "SSCCE" ); > > final var size = 120f; > final var font = new javafx.scene.text.Font( "Arial", size ); > final var bgStyle = "-fx-background-color: white"; > > // FX label, StackPane > final var fxLabelTop = new javafx.scene.text.Text( "FX/FX" ); > fxLabelTop.setFont( font ); > final var fxStackPaneTop = new StackPane( fxLabelTop ); > > // FX label, StackPane > final var fxLabelSplit = new javafx.scene.text.Text( "FX LABEL" ); > fxLabelSplit.setFont( font ); > final var fxLabelPane = new StackPane(); > fxLabelPane.getChildren().addAll( fxLabelSplit ); > fxLabelPane.setStyle( bgStyle ); > > // Swing label, StackPane > final var swingLabel = new JLabel( "SW LABEL" ); > swingLabel.setBackground( Color.WHITE ); > swingLabel.setOpaque( true ); > swingLabel.setFont( swingLabel.getFont().deriveFont( Font.PLAIN, size ) ); > final var swingLabelNode = new SwingNode(); > swingLabelNode.setContent( swingLabel ); > final var swingLabelPane = new StackPane( swingLabelNode ); > swingLabelPane.setStyle( bgStyle ); > > final var fxSplitPane = new SplitPane( > fxLabelPane, swingLabelPane ); > fxSplitPane.setPrefSize( 1280, 300 ); > > final var root = new VBox(); > root.getChildren().addAll( fxStackPaneTop, fxSplitPane ); > root.setStyle( bgStyle ); > > runLater( () -> { > final var scene = new Scene( root ); > stage.setScene( scene ); > stage.show(); > } ); > } ); > } > } > > Closely compare the "L" from "SW LABEL" to the "L" from "FX LABEL". > You'll see that the "SW LABEL" ell has what looks like stronger > antialiasing applied. > > Changing the Graphics2D rendering hints on the JLabel has no effect. > Changing the JLabel's AffineTransform to shift by 0.5px worsens the > blurriness. Moving the SwingNode out of the SplitPane renders crisply, > as expected. The font colours and background do not affect the > outcome, but are there to make consistent output, which makes > comparing easier. > > This problem affects neither X11 (Linux) nor OSX, only Windows. > > Been trying to fix this for several days without success. > > Any ideas why embedding a SwingNode within a SplitPane causes a blurry > effect? And how can the problem be resolved? > > Thank you! From kevin.rushforth at oracle.com Sat Aug 22 19:28:38 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Aug 2020 12:28:38 -0700 Subject: Blurry render of SwingNode In-Reply-To: <9d629aec-5a3a-7732-2230-613278198f99@jugs.org> References: <9d629aec-5a3a-7732-2230-613278198f99@jugs.org> Message-ID: <69bb957f-3818-67e6-f0f0-0f4e05b4c173@oracle.com> Actually, someone already did file a bug report a couple days ago (I see it in our internal incident tracker). Once it is transferred to the JDK project, I'll add the standalone test program from this email thread to the bug report, which should help in narrowing it down. Thanks. -- Kevin On 8/22/2020 11:40 AM, Michael Paus wrote: > Hi, > this is not a bug reporting list. Please file your bug report here > https://bugs.java.com/bugdatabase/ instead. > Best regards > Michael > > Am 22.08.20 um 19:57 schrieb Thangalin: >> Ahoy list, >> >> Running OpenJDK 14.0.1 on Windows 7, adding a SwingNode to a SplitPane >> causes the contents of the SwingNode to appear blurry. There's a full >> write-up with screen-shots at: >> https://stackoverflow.com/q/63444771/59087 >> >> Here's an SSCCE that demonstrates the problem: >> >> import javafx.application.Application; >> import javafx.embed.swing.SwingNode; >> import javafx.scene.Scene; >> import javafx.scene.control.SplitPane; >> import javafx.scene.layout.StackPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> import javax.swing.*; >> import java.awt.*; >> >> import static javafx.application.Platform.runLater; >> import static javax.swing.SwingUtilities.invokeLater; >> >> public class FlyingSourceTest extends Application { >> ?? public static void main( String[] args ) { >> ???? Application.launch( args ); >> ?? } >> >> ?? @Override >> ?? public void start( Stage stage ) { >> ???? invokeLater( () -> { >> ?????? stage.setTitle( "SSCCE" ); >> >> ?????? final var size = 120f; >> ?????? final var font = new javafx.scene.text.Font( "Arial", size ); >> ?????? final var bgStyle = "-fx-background-color: white"; >> >> ?????? // FX label, StackPane >> ?????? final var fxLabelTop = new javafx.scene.text.Text( "FX/FX" ); >> ?????? fxLabelTop.setFont( font ); >> ?????? final var fxStackPaneTop = new StackPane( fxLabelTop ); >> >> ?????? // FX label, StackPane >> ?????? final var fxLabelSplit = new javafx.scene.text.Text( "FX >> LABEL" ); >> ?????? fxLabelSplit.setFont( font ); >> ?????? final var fxLabelPane = new StackPane(); >> ?????? fxLabelPane.getChildren().addAll( fxLabelSplit ); >> ?????? fxLabelPane.setStyle( bgStyle ); >> >> ?????? // Swing label, StackPane >> ?????? final var swingLabel = new JLabel( "SW LABEL" ); >> ?????? swingLabel.setBackground( Color.WHITE ); >> ?????? swingLabel.setOpaque( true ); >> ?????? swingLabel.setFont( swingLabel.getFont().deriveFont( >> Font.PLAIN, size ) ); >> ?????? final var swingLabelNode = new SwingNode(); >> ?????? swingLabelNode.setContent( swingLabel ); >> ?????? final var swingLabelPane = new StackPane( swingLabelNode ); >> ?????? swingLabelPane.setStyle( bgStyle ); >> >> ?????? final var fxSplitPane = new SplitPane( >> ?????????? fxLabelPane, swingLabelPane ); >> ?????? fxSplitPane.setPrefSize( 1280, 300 ); >> >> ?????? final var root = new VBox(); >> ?????? root.getChildren().addAll( fxStackPaneTop, fxSplitPane ); >> ?????? root.setStyle( bgStyle ); >> >> ?????? runLater( () -> { >> ???????? final var scene = new Scene( root ); >> ???????? stage.setScene( scene ); >> ???????? stage.show(); >> ?????? } ); >> ???? } ); >> ?? } >> } >> >> Closely compare the "L" from "SW LABEL" to the "L" from "FX LABEL". >> You'll see that the "SW LABEL" ell has what looks like stronger >> antialiasing applied. >> >> Changing the Graphics2D rendering hints on the JLabel has no effect. >> Changing the JLabel's AffineTransform to shift by 0.5px worsens the >> blurriness. Moving the SwingNode out of the SplitPane renders crisply, >> as expected. The font colours and background do not affect the >> outcome, but are there to make consistent output, which makes >> comparing easier. >> >> This problem affects neither X11 (Linux) nor OSX, only Windows. >> >> Been trying to fix this for several days without success. >> >> Any ideas why embedding a SwingNode within a SplitPane causes a blurry >> effect? And how can the problem be resolved? >> >> Thank you! > > From kcr at openjdk.java.net Sat Aug 22 19:45:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 22 Aug 2020 19:45:51 GMT Subject: RFR: 8251555: Remove unused focusedWindow field in glass Window to avoid leak Message-ID: This is a follow-up to [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840) that removes an unused static `focusedWindow` field and its associated getter and setter from the platform-independent glass Window class. This is entirely unused by any of the glass platforms. The Monocle platform keeps track of the `focusedWindow` attribute itself. The existing `test.javafx.stage.FocusedWindowNativeTest` automated test, which was added as part of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840), was failing fairly consistently on one of our test machines before this fix, and now passes. ------------- Commit messages: - Remove unused focusedWindow field in glass Window to avoid leak Changes: https://git.openjdk.java.net/jfx/pull/286/files Webrev: https://webrevs.openjdk.java.net/jfx/286/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251555 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/286.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/286/head:pull/286 PR: https://git.openjdk.java.net/jfx/pull/286 From ajoseph at openjdk.java.net Mon Aug 24 05:56:57 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 24 Aug 2020 05:56:57 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v5] In-Reply-To: References: Message-ID: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with three additional commits since the last revision: - Exclude TYPE_IDENTITY case - Another fix for printing - Minimal fix for printing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/9b841f4b..d808d27a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.03-04 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From ajoseph at openjdk.java.net Mon Aug 24 07:48:27 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 24 Aug 2020 07:48:27 GMT Subject: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6] In-Reply-To: References: Message-ID: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be transformed. Arun Joseph has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year - Minor refactoring ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/d808d27a..4241c502 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.04-05 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190 From kevin.rushforth at oracle.com Mon Aug 24 18:34:54 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Aug 2020 11:34:54 -0700 Subject: Blurry render of SwingNode In-Reply-To: <69bb957f-3818-67e6-f0f0-0f4e05b4c173@oracle.com> References: <9d629aec-5a3a-7732-2230-613278198f99@jugs.org> <69bb957f-3818-67e6-f0f0-0f4e05b4c173@oracle.com> Message-ID: It's now in the JDK project in JBS: https://bugs.openjdk.java.net/browse/JDK-8252255 I was able to reproduce it with the test program you sent. -- Kevin On 8/22/2020 12:28 PM, Kevin Rushforth wrote: > Actually, someone already did file a bug report a couple days ago (I > see it in our internal incident tracker). Once it is transferred to > the JDK project, I'll add the standalone test program from this email > thread to the bug report, which should help in narrowing it down. > > Thanks. > > -- Kevin > > > On 8/22/2020 11:40 AM, Michael Paus wrote: >> Hi, >> this is not a bug reporting list. Please file your bug report here >> https://bugs.java.com/bugdatabase/ instead. >> Best regards >> Michael >> >> Am 22.08.20 um 19:57 schrieb Thangalin: >>> Ahoy list, >>> >>> Running OpenJDK 14.0.1 on Windows 7, adding a SwingNode to a SplitPane >>> causes the contents of the SwingNode to appear blurry. There's a full >>> write-up with screen-shots at: >>> https://stackoverflow.com/q/63444771/59087 >>> >>> Here's an SSCCE that demonstrates the problem: >>> >>> import javafx.application.Application; >>> import javafx.embed.swing.SwingNode; >>> import javafx.scene.Scene; >>> import javafx.scene.control.SplitPane; >>> import javafx.scene.layout.StackPane; >>> import javafx.scene.layout.VBox; >>> import javafx.stage.Stage; >>> >>> import javax.swing.*; >>> import java.awt.*; >>> >>> import static javafx.application.Platform.runLater; >>> import static javax.swing.SwingUtilities.invokeLater; >>> >>> public class FlyingSourceTest extends Application { >>> ?? public static void main( String[] args ) { >>> ???? Application.launch( args ); >>> ?? } >>> >>> ?? @Override >>> ?? public void start( Stage stage ) { >>> ???? invokeLater( () -> { >>> ?????? stage.setTitle( "SSCCE" ); >>> >>> ?????? final var size = 120f; >>> ?????? final var font = new javafx.scene.text.Font( "Arial", size ); >>> ?????? final var bgStyle = "-fx-background-color: white"; >>> >>> ?????? // FX label, StackPane >>> ?????? final var fxLabelTop = new javafx.scene.text.Text( "FX/FX" ); >>> ?????? fxLabelTop.setFont( font ); >>> ?????? final var fxStackPaneTop = new StackPane( fxLabelTop ); >>> >>> ?????? // FX label, StackPane >>> ?????? final var fxLabelSplit = new javafx.scene.text.Text( "FX >>> LABEL" ); >>> ?????? fxLabelSplit.setFont( font ); >>> ?????? final var fxLabelPane = new StackPane(); >>> ?????? fxLabelPane.getChildren().addAll( fxLabelSplit ); >>> ?????? fxLabelPane.setStyle( bgStyle ); >>> >>> ?????? // Swing label, StackPane >>> ?????? final var swingLabel = new JLabel( "SW LABEL" ); >>> ?????? swingLabel.setBackground( Color.WHITE ); >>> ?????? swingLabel.setOpaque( true ); >>> ?????? swingLabel.setFont( swingLabel.getFont().deriveFont( >>> Font.PLAIN, size ) ); >>> ?????? final var swingLabelNode = new SwingNode(); >>> ?????? swingLabelNode.setContent( swingLabel ); >>> ?????? final var swingLabelPane = new StackPane( swingLabelNode ); >>> ?????? swingLabelPane.setStyle( bgStyle ); >>> >>> ?????? final var fxSplitPane = new SplitPane( >>> ?????????? fxLabelPane, swingLabelPane ); >>> ?????? fxSplitPane.setPrefSize( 1280, 300 ); >>> >>> ?????? final var root = new VBox(); >>> ?????? root.getChildren().addAll( fxStackPaneTop, fxSplitPane ); >>> ?????? root.setStyle( bgStyle ); >>> >>> ?????? runLater( () -> { >>> ???????? final var scene = new Scene( root ); >>> ???????? stage.setScene( scene ); >>> ???????? stage.show(); >>> ?????? } ); >>> ???? } ); >>> ?? } >>> } >>> >>> Closely compare the "L" from "SW LABEL" to the "L" from "FX LABEL". >>> You'll see that the "SW LABEL" ell has what looks like stronger >>> antialiasing applied. >>> >>> Changing the Graphics2D rendering hints on the JLabel has no effect. >>> Changing the JLabel's AffineTransform to shift by 0.5px worsens the >>> blurriness. Moving the SwingNode out of the SplitPane renders crisply, >>> as expected. The font colours and background do not affect the >>> outcome, but are there to make consistent output, which makes >>> comparing easier. >>> >>> This problem affects neither X11 (Linux) nor OSX, only Windows. >>> >>> Been trying to fix this for several days without success. >>> >>> Any ideas why embedding a SwingNode within a SplitPane causes a blurry >>> effect? And how can the problem be resolved? >>> >>> Thank you! >> >> > From arapte at openjdk.java.net Mon Aug 24 18:36:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 Aug 2020 18:36:15 GMT Subject: RFR: 8252107: Media pipeline initialization can crash if audio or video bin state change fails In-Reply-To: References: Message-ID: <25hu5a5SH8xsz9y_UjXzjQ1NZfNyOqZ4LbyNhh-JIYU=.a9124cf0-ca6a-4435-832c-dc050136881a@github.com> On Thu, 20 Aug 2020 23:32:24 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8252107 > > - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. Built and tested on Linux. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/285 From almatvee at openjdk.java.net Mon Aug 24 19:21:07 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 24 Aug 2020 19:21:07 GMT Subject: Integrated: 8252107: Media pipeline initialization can crash if audio or video bin state change fails In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020 23:32:24 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8252107 > > - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. This pull request has now been integrated. Changeset: c3fb3210 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c3fb3210 Stats: 27 lines in 1 file changed: 0 ins; 24 del; 3 mod 8252107: Media pipeline initialization can crash if audio or video bin state change fails Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/285 From almatvee at openjdk.java.net Tue Aug 25 01:06:26 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 25 Aug 2020 01:06:26 GMT Subject: RFR: 8252060: gstreamer fails to build with gcc 10 Message-ID: Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin proposed solution. On Windows we do not need to define GST_API, since we using .def file to export symbols. ------------- Commit messages: - 8252060: gstreamer fails to build with gcc 10 Changes: https://git.openjdk.java.net/jfx/pull/287/files Webrev: https://webrevs.openjdk.java.net/jfx/287/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252060 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/287.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/287/head:pull/287 PR: https://git.openjdk.java.net/jfx/pull/287 From bchoudhary at openjdk.java.net Tue Aug 25 05:41:22 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 25 Aug 2020 05:41:22 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: References: Message-ID: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Marked few class constructor as deprecated as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/283/files - new: https://git.openjdk.java.net/jfx/pull/283/files/25c7b37c..16d8b9ad Webrevs: - full: https://webrevs.openjdk.java.net/jfx/283/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/283/webrev.00-01 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283 PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at openjdk.java.net Tue Aug 25 09:14:07 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 Aug 2020 09:14:07 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 00:12:01 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Marked few class constructor as deprecated as per review > > I think that two of the classes have implicit constructors that are there by accident. Once we get agreement, I'll file > a follow-on bug for those, and those changes should be reverted. > As for the other comments, I would prefer a follow-up bug for any doc cleanup that isn't part of adding in an explicit > constructor. Tempting as it might be to fix it, it seems out of scope. > That leaves the question about the wording. The more I think about it the more I like what the JDK did as opposed to > what we did. The question then becomes: if we agree that it's a better pattern, do we adopt it here and then clean it > up for the other two batches or just leave it as is for now, and file one cleanup bug for later. I'd like to hear from > @aghaisas and @nlisker @bhaweshkc You can't deprecate the constructors in this PR since it will need a separate CSR. You should revert the changes on these classes completely and file a new bug (and CSR) dealing with deprecations. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at openjdk.java.net Tue Aug 25 09:14:08 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 Aug 2020 09:14:08 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> References: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> Message-ID: <3CMju_kcA-IRRuHw3lW2rYrKA6gD5JN2qc_UHI1msCA=.bb07bdd0-ae90-43b5-9e89-31012d4d507d@github.com> On Tue, 18 Aug 2020 23:31:42 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TableFocusModel.java line 51: >> >>> 50: >>> 51: /** >>> 52: * Causes the item at the given index to receive the focus. >> >> Please add a missing `)` for the class docs on line 30. > > The change to the class header seems unrelated. It would be a good thing to fix, but could be done as part of a > follow-on doc cleanup issue. Alright, we could add them to this version's doc fixes issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at openjdk.java.net Tue Aug 25 09:18:56 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 Aug 2020 09:18:56 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> References: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> Message-ID: On Tue, 18 Aug 2020 23:47:07 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 83: >> >>> 82: >>> 83: /** >>> 84: * There is only one PseudoClass instance for a given pseudoClass. >> >> 1. Is having a public constructor for this class a good idea? Instances are created by a factory method. >> 2. Both methods in this class need documentation update. `getPseudoClass` has a poor method description and the >> formatting of the `@return` tag is wrong (lowercase and no period). `getPseudoClassName` is missing a description. > > Yes, this constructor is needed. `PseudoClass` is abstract, so it's constructor is just there for subclasses to call > (note that for a constructor of an abstract class, `public` and `protected` mean the same thing). > As for the other methods in the class, I agree that they should be changed...but in a follow-up issue. Maybe we can add the method docs fixes to [JDK-8250590](https://bugs.openjdk.java.net/browse/JDK-8250590)? ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at openjdk.java.net Tue Aug 25 09:38:12 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 Aug 2020 09:38:12 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> References: <8ihHjH9X_aAyaWU4gYCoRlrrCn_UyZQnZ2x_xfnjtks=.9300a075-4f14-4b3b-8947-5911155f59a3@github.com> Message-ID: <6VEvuxuqFYQobYeI92LtH2TZgTqRUchmTx9LTKn1rZg=.58207050-f36e-4689-b682-1269b68ea47c@github.com> On Tue, 18 Aug 2020 23:41:23 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Preloader.java line 121: >> >>> 120: public Preloader() { >>> 121: } >>> 122: >> >> Not sure that "default" means anything here. I don't see any configuration. > > Right, but isn't that true of most of the classes, including those in the two related bugs that were fixed? > > Worth noting is that the JDK chose different language for abstract classes than concrete ones. For abstract classes, > they just use the following language: > * Constructor for subclasses to call. > > And for concrete ones: > > Constructs a {@code Foo}. > > This gets around the problem of whether or not `default` adds any useful information since it is the only constructor. > Not saying we should adopt this now, but just adding another data point. I didn't look closely at whether "default" was suitable in the previous cases. I like the JDK's wording, but in cases where there are constructors that allow configuration, the empty constructor could use "default", though specifying what the default values are is more beneficial anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From nlisker at openjdk.java.net Tue Aug 25 09:44:33 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 Aug 2020 09:44:33 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v2] In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 00:12:01 GMT, Kevin Rushforth wrote: > I think that two of the classes have implicit constructors that are there by accident. Once we get agreement, I'll file > a follow-on bug for those, and those changes should be reverted. I finished reviewing the rest of the classes and I had no additional comments about them, so I agree about deprecating for removal those 2 classes' constructors. > As for the other comments, I would prefer a follow-up bug for any doc cleanup that isn't part of adding in an explicit > constructor. Tempting as it might be to fix it, it seems out of scope. That's fine. I left inline comments about those. > That leaves the question about the wording. The more I think about it the more I like what the JDK did as opposed to > what we did. The question then becomes: if we agree that it's a better pattern, do we adopt it here and then clean it > up for the other two batches or just leave it as is for now, and file one cleanup bug for later. I'd like to hear from > @aghaisas and @nlisker Since it will require an additional cleanup issue anyway, I don't think it matters when we do it, but since we're here I see no reason not to start already. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From bchoudhary at openjdk.java.net Tue Aug 25 10:27:03 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 25 Aug 2020 10:27:03 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v3] In-Reply-To: References: Message-ID: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Reverted changes for class Selector and ShapeConverter as per review comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/283/files - new: https://git.openjdk.java.net/jfx/pull/283/files/16d8b9ad..38a7551d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/283/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/283/webrev.01-02 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283 PR: https://git.openjdk.java.net/jfx/pull/283 From arapte at openjdk.java.net Tue Aug 25 10:57:24 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 Aug 2020 10:57:24 GMT Subject: RFR: 8251555: Remove unused focusedWindow field in glass Window to avoid leak In-Reply-To: References: Message-ID: On Sat, 22 Aug 2020 19:39:33 GMT, Kevin Rushforth wrote: > This is a follow-up to [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840) that removes an unused static > `focusedWindow` field and its associated getter and setter from the platform-independent glass Window class. This is > entirely unused by any of the glass platforms. The Monocle platform keeps track of the `focusedWindow` attribute > itself. The existing `test.javafx.stage.FocusedWindowNativeTest` automated test, which was added as part of > [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840), was failing fairly consistently on one of our test > machines before this fix, and now passes. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/286 From fastegal at openjdk.java.net Tue Aug 25 11:46:17 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 25 Aug 2020 11:46:17 GMT Subject: RFR: 8251941: ListCell: visual artifact when items contain null values Message-ID: The issue describes the makroscopic effect/s, namely content showing in cells that are off range. The base reason is missing cleanup of the cell on transition from not-empty to empty when the old item is a null contained in the items. Fixed by changing the logic to cope with that special case. Added tests that fail before and pass after the fix. ------------- Commit messages: - 8251941: ListCell: visual artifact when items contain null values Changes: https://git.openjdk.java.net/jfx/pull/288/files Webrev: https://webrevs.openjdk.java.net/jfx/288/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251941 Stats: 90 lines in 2 files changed: 87 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/288.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/288/head:pull/288 PR: https://git.openjdk.java.net/jfx/pull/288 From kcr at openjdk.java.net Tue Aug 25 11:59:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Aug 2020 11:59:24 GMT Subject: Integrated: 8251555: Remove unused focusedWindow field in glass Window to avoid leak In-Reply-To: References: Message-ID: On Sat, 22 Aug 2020 19:39:33 GMT, Kevin Rushforth wrote: > This is a follow-up to [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840) that removes an unused static > `focusedWindow` field and its associated getter and setter from the platform-independent glass Window class. This is > entirely unused by any of the glass platforms. The Monocle platform keeps track of the `focusedWindow` attribute > itself. The existing `test.javafx.stage.FocusedWindowNativeTest` automated test, which was added as part of > [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840), was failing fairly consistently on one of our test > machines before this fix, and now passes. This pull request has now been integrated. Changeset: ddf8814e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ddf8814e Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod 8251555: Remove unused focusedWindow field in glass Window to avoid leak Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/286 From kcr at openjdk.java.net Tue Aug 25 13:01:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 Aug 2020 13:01:51 GMT Subject: RFR: 8252060: gstreamer fails to build with gcc 10 In-Reply-To: References: Message-ID: On Tue, 25 Aug 2020 01:00:31 GMT, Alexander Matveev wrote: > Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin proposed solution. On Windows we do not need to > define GST_API, since we using .def file to export symbols. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/287 From tsayao at openjdk.java.net Tue Aug 25 14:14:37 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 25 Aug 2020 14:14:37 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> Message-ID: <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.f0d13854-5f71-4d32-98a1-d8d4add15c1c@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 fastegal at openjdk.java.net Tue Aug 25 14:19:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 25 Aug 2020 14:19:33 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> Message-ID: On Wed, 19 Aug 2020 13:06:34 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > change approach from removing to excluding fix and tests look okay (added minor inline comments), verified that the tests for the fix are failing before and passing after, those added for completeness are fine also. As noted in one of my comments (again? :), I don't like underscores .. not even in test methods - but as they are wide spread nothing to really complain about: just be consistent with yourself :) modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 181: > 180: > 181: @Test public void test_SwitchingSelectionModel() { > 182: ListView listView = new ListView<>(); maybe the name could be improved by adding _what_ it's testing: something like testCtrlAWhenSwitchingSelectionModel? modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1509: > 1508: > 1509: @Test public void test_switchingSelectionMode() { > 1510: ListView listView = new ListView<>(); same as naming suggestion to the other Switching test above modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1536: > 1535: assertEquals(4, sm.getSelectedItems().size()); > 1536: > 1537: sl.dispose(); wondering about these repeated blocks? The flow is single: (default on start) -> multiple -> single -> multiple. Looks like the last two are repeating the first two .. what do I overlook? modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2055: > 2054: .observableArrayList("Item1", "Item2")); > 2055: listView.setCellFactory(TextFieldListCell.forListView()); > 2056: StageLoader sl = new StageLoader(listView); hmm .. why the textFieldListCell? It's just a plain listCell if not in editing state .. or not? modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1344: > 1343: > 1344: @Test public void test_EditorKeyInputsWhenPopupIsShowing() { > 1345: final ComboBox cb = new ComboBox<>(FXCollections.observableArrayList("a", "b", "c")); minor nit: naming is inconsistent to the other added test below (testExcludeKeyMappingsForComboBoxEditor) - either use an underscore or not (my personal preference is to not use them at all, following general java naming conventions also in tests .. but definitely not overly important :) ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Tue Aug 25 14:19:33 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 25 Aug 2020 14:19:33 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> Message-ID: On Tue, 25 Aug 2020 13:54:14 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> change approach from removing to excluding > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1509: > >> 1508: >> 1509: @Test public void test_switchingSelectionMode() { >> 1510: ListView listView = new ListView<>(); > > same as naming suggestion to the other Switching test above if you prefer not to, the capitalizing should be consistent - here it's test_switch, above it's test_Switch :) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kevin.rushforth at oracle.com Tue Aug 25 20:01:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Aug 2020 13:01:51 -0700 Subject: Bulk request to backport 14 fixes to 11-dev for 11.0.9 Message-ID: Hi Johan, I request approval to backport the following 14 fixes to openjfx11: JDK-8247963: Update SQLite to version 3.32.3 JDK-8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars JDK-8247947: Build DirectShow Samples (Base Classes) from source checked into repo JDK-8245284: Update to 610.1 version of WebKit JDK-8249839: Cherry pick GTK WebKit 2.28.3 changes JDK-8242507: Add support for Visual Studio 2019 JDK-8244487: One Windows 10 SDK file missing from FX build JDK-8191758: Match WebKit's font weight rendering with JavaFX? (to keep native WebKit in sync) JDK-8239095: Upgrade libFFI to the latest 3.3 version JDK-8193800: TreeTableView selection changes on sorting JDK-8246204: No 3D support for newer Intel graphics drivers on Linux JDK-8248490: [macOS] Undecorated stage does not minimize JDK-8250238: Media fails to load libav 58 library when using modules from maven central JDK-8252326: Update to Visual Studio 2017 version 15.9.24 -- Kevin From johan.vos at gluonhq.com Tue Aug 25 20:30:04 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 25 Aug 2020 22:30:04 +0200 Subject: Bulk request to backport 14 fixes to 11-dev for 11.0.9 In-Reply-To: References: Message-ID: Approved. - Johan On Tue, Aug 25, 2020 at 10:03 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following 14 fixes to openjfx11: > > JDK-8247963: Update SQLite to version 3.32.3 > JDK-8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars > JDK-8247947: Build DirectShow Samples (Base Classes) from source checked > into repo > JDK-8245284: Update to 610.1 version of WebKit > JDK-8249839: Cherry pick GTK WebKit 2.28.3 changes > JDK-8242507: Add support for Visual Studio 2019 > JDK-8244487: One Windows 10 SDK file missing from FX build > JDK-8191758: Match WebKit's font weight rendering with JavaFX (to keep > native WebKit in sync) > JDK-8239095: Upgrade libFFI to the latest 3.3 version > JDK-8193800: TreeTableView selection changes on sorting > JDK-8246204: No 3D support for newer Intel graphics drivers on Linux > JDK-8248490: [macOS] Undecorated stage does not minimize > JDK-8250238: Media fails to load libav 58 library when using modules > from maven central > JDK-8252326: Update to Visual Studio 2017 version 15.9.24 > > -- Kevin > > From almatvee at openjdk.java.net Tue Aug 25 22:04:33 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 25 Aug 2020 22:04:33 GMT Subject: Integrated: 8252060: gstreamer fails to build with gcc 10 In-Reply-To: References: Message-ID: On Tue, 25 Aug 2020 01:00:31 GMT, Alexander Matveev wrote: > Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin proposed solution. On Windows we do not need to > define GST_API, since we using .def file to export symbols. This pull request has now been integrated. Changeset: 7a4bd9b2 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/7a4bd9b2 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8252060: gstreamer fails to build with gcc 10 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/287 From nlisker at gmail.com Wed Aug 26 08:42:08 2020 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 26 Aug 2020 11:42:08 +0300 Subject: Make TransformationList (Filtered and Sorted) extendable In-Reply-To: <000601d673d1$1ef218f0$5cd64ad0$@gmx.de> References: <000601d673d1$1ef218f0$5cd64ad0$@gmx.de> Message-ID: Hi Tobias, I thought that ReactFX superseded EasyBind and InhiBeans. What is the current relation between these? In any case, while removing the final modifier could work (I didn't look into it much), I suggest to take a broader approach. These libraries have many features that I think are desirable to add to JavaFX, and they could be added cleanly considering that we don't need to jump through the hoops that a 3rd party library needs to. For example, the Val and Var extensions could be integrated seamlessly (more or less) into the current classes, solving problems such as the current "select" mechanism and wrong recursive behavior. I suggest to look at an approach where we adapt these libraries for javaFX rather than adapting JavaFX for these libraries. If you are familiar with these libraries, can we try to form a broader plan and see what meets the bar? - Nir On Sun, Aug 16, 2020 at 4:29 PM Tobias Diez wrote: > Hello everybody, > > Right now it is hard to extend the FilteredList and the SortedList as these > classes are marked final. This makes it practically impossible to add > convenient helper methods, or change or extend the behavior of these > classes. > I agree that normally you don't need to extend them, but I also don't see > any reason why you shouldn't be allowed to do so. > > Usually, you could use composition over inheritance if a class is marked > final but you still want to extend it. However, some of the controls expect > really a SortedList , e.g. > > https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/ > java/javafx/scene/control/TableView.java#L442 > > So this approach does not work either. > > The motivation for me comes from some limitations that we encountered while > developing EasyBind, a small library to make bindings easier. We provide a > few convenient methods that extend the ObservableList, and we want to > provide a fluent interface similar to streams, e.g. > EasyBind.wrap(standard observable list).filter(predicate).map(mapper). > For this to work, the filter method needs to return a FilteredList with the > additional map method. The easiest solution would be to derive from > FilteredList, and implement the "EasyObservableList" interface that we > have. > > Removing the final keyword is done in the following PR: > https://github.com/openjdk/jfx/pull/278 > > Looking forward to your feedback. > Best regards > Tobias > > From thomas.manz+JFX at gmail.com Wed Aug 26 10:07:25 2020 From: thomas.manz+JFX at gmail.com (thomas.manz+JFX at gmail.com) Date: Wed, 26 Aug 2020 12:07:25 +0200 Subject: ComboBox not working with touch screen Message-ID: <00ac01d67b90$b3756290$1a6027b0$@gmail.com> Hello, first of all I?m really sorry for this long email, esp. because it?s not as constructive as I would wish - nevertheless I hope you are interested enough to read it. Just a get a coffee before... ;) I?m still working on a JavaFX project for a RaspberryPi and a 7" touch screen. For selecting an option from a list of about 5 - 20 items I decided to use a ComboBox. Now while this was working rather well on one hardware (i. e. in about 8 out 10 tries) it is absolutely unusable on a second one! When tapping the ComboBox the dropdown list opens fine, but when you tap on one of the items then the dropdown list closes without any item being selected (or changed if another was already selected before). Only in one of about 10 tries it works and the item will be selected. I think the root cause of the issue consists of actually two issues, this is what I found out so far: There would be two options to use the ComboBox: setting "-Djavafx.scene.control.skin.ListViewSkin.pannable" to TRUE or FALSE. Setting it to FALSE does not allow to scroll the dropdown list at all using a touch screen because no ScrollBar is shown (even with setting "-Dcom.sun.javafx.isEmbedded" to FALSE) - so this is not an option. (I don?t know if this could be an intended usage.) Now setting it to TRUE allows scrolling by "finger down" anywhere on the dropdown list - move finger - "finger up". Great, but here?s the first issue: with "finger up" the dropdown list closes immediately, no chance to select anything! The only good thing here is that when opening the ComboBox again we are still at the new scrolling position and could scroll further or select an item. I would rate this as super annoying (and actually a bug) but it?s somehow usable. On Windows the behavior with "pannable=true" is a little bit different: similarly there is no ScrollBar but you still can scroll the list with "mouse button down" on the list - move the mouse - "mouse button up" and also here the dropdown list closes immediately after "mouse button up" but here already with "mouse button down" the item on that position is selected. So a little bit weird behavior but maybe it also was never intended to use pannable=TRUE with a mouse. Now the second issue that makes the ComboBox completely unusable is Monocle in combination with the hardware - it seems that my second touch screen is a little bit more sensitive. The consequence is that on that touch screen it?s barely possible to do a simple "tap" = "click" - nearly always Monocle will recognize it as a "finger down" - "move finger by 1 or 3 pixel" - "finger up". I guess you see it coming already: on the sensitive touch screen whenever you just want to do a "click" to select an item then the ComboBox is recognizing it as a scroll and because of the first issue the dropdown closes and nothing is selected. For your convenience I copied the relevant code from CellBehaviorBase.java, lines 170 - 192 at the bottom: if you know that MouseEvent.isSynthesized() will only be TRUE with Monocle and a touch screen you?ll understand the above described behavior and the different behavior in Windows or when using a mouse. Solutions: I guess the intended solution for this is setting "-Dmonocle.input.touchRadius" to an appropriate value and as soon as I actually set it to 4 or 5 it?s working. But there is still the first issue with "immediate close after scrolling" what is a bug in my opinion, I?m not sure if you agree. Additionally I?m not a big fan of increasing the touchRadius: even with setting it to 1 on the very sensitive touch screen all the other controls work perfectly fine and setting it to 5 would waste resolution for Controls like ScrollBar or Slider, they are becoming "jumpy" and so it really would be a pity to do that. Unfortunately here I cannot think of a good solution: the only that came to my mind was to ignore the MouseEvent.isSynthesized(), put a (configurable) threshold directly in CellBehaviorBase and decide there when it?s a scroll or just a "slippy tap". But to be honest even I don?t think that this is a good solution from architectural point of view. Here I really miss lots of your experience to come up with a better solution, I?m still a newbie in JavaFX development so I hope you guys can provide better ideas and approaches to fix it in a way that preserves the user experience with all Controls on a touch screen! Thanks a lot for reading and keep continuing your great work, I really appreciate it! Best regards, Thomas CellBehaviorBase.java, lines 170 - 192: -------------------------------- public void mousePressed(MouseEvent e) { if (e.isSynthesized()) { latePress = true; } else { latePress = isSelected(); if (!latePress) { doSelect(e.getX(), e.getY(), e.getButton(), e.getClickCount(), e.isShiftDown(), e.isShortcutDown()); } } } public void mouseReleased(MouseEvent e) { if (latePress) { latePress = false; doSelect(e.getX(), e.getY(), e.getButton(), e.getClickCount(), e.isShiftDown(), e.isShortcutDown()); } } public void mouseDragged(MouseEvent e) { latePress = false; } From arapte at openjdk.java.net Wed Aug 26 10:14:14 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 26 Aug 2020 10:14:14 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Corrections in test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/f58ee4a2..22f79d63 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.05-06 Stats: 10 lines in 2 files changed: 1 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Wed Aug 26 10:18:29 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 26 Aug 2020 10:18:29 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> Message-ID: <4qskeUVJ6w6ies-RYwKkxUtSUKcaliT7VstTtgcRuDM=.fd0f6a04-ae4e-4c8c-83f3-0823a4d63419@github.com> On Tue, 25 Aug 2020 14:07:08 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> change approach from removing to excluding > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 1344: > >> 1343: >> 1344: @Test public void test_EditorKeyInputsWhenPopupIsShowing() { >> 1345: final ComboBox cb = new ComboBox<>(FXCollections.observableArrayList("a", "b", "c")); > > minor nit: naming is inconsistent to the other added test below (testExcludeKeyMappingsForComboBoxEditor) - either use > an underscore or not (my personal preference is to not use them at all, following general java naming conventions also > in tests .. but definitely not overly important :) Removed _, changed to `testEditorKeyInputsWhenPopupIsShowing` > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2055: > >> 2054: .observableArrayList("Item1", "Item2")); >> 2055: listView.setCellFactory(TextFieldListCell.forListView()); >> 2056: StageLoader sl = new StageLoader(listView); > > hmm .. why the textFieldListCell? It's just a plain listCell if not in editing state .. or not? It is effect of copy paste ;), Test behaves as expected even without it, so removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Wed Aug 26 10:23:36 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 26 Aug 2020 10:23:36 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> Message-ID: <75zQExJVL9TJ727X6Kf-IpI7nomgd1Bhmi92HmqKJKA=.c085b1d7-308a-4e7d-aaef-6b5f9ce168d5@github.com> On Tue, 25 Aug 2020 13:58:43 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> change approach from removing to excluding > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1536: > >> 1535: assertEquals(4, sm.getSelectedItems().size()); >> 1536: >> 1537: sl.dispose(); > > wondering about these repeated blocks? The flow is single: (default on start) -> multiple -> single -> multiple. Looks > like the last two are repeating the first two .. what do I overlook? I had kept it with initial version of patch to test the listeners, But the patch has evolved to be very different now. But still have removed only one block. Now there are three blocks and `sm.getSelectedItems().size()` varies in each block. > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 181: > >> 180: >> 181: @Test public void test_SwitchingSelectionModel() { >> 182: ListView listView = new ListView<>(); > > maybe the name could be improved by adding _what_ it's testing: something like testCtrlAWhenSwitchingSelectionModel? Done, removed _ from all the test names. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Wed Aug 26 10:23:36 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 26 Aug 2020 10:23:36 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> Message-ID: <1GH3oZCZIRNcIAkzcggA6l0wVJC49lZE55L1vNTkatE=.e9f61c83-b030-4715-bc9a-d0983816a598@github.com> On Tue, 25 Aug 2020 14:09:08 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1509: >> >>> 1508: >>> 1509: @Test public void test_switchingSelectionMode() { >>> 1510: ListView listView = new ListView<>(); >> >> same as naming suggestion to the other Switching test above > > if you prefer not to, the capitalizing should be consistent - here it's test_switch, above it's test_Switch :) Changed name to `testCtrlAWhenSwitchingSelectionMode`, It sounds much better. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Wed Aug 26 12:05:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 26 Aug 2020 12:05:36 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <8aCyFZHr6bh2Gr3tQ6NWEtBJVFRGuvXgeYOumg5HZsk=.9ef1fc24-bd83-48dd-b786-3f139dea3420@github.com> On Wed, 26 Aug 2020 10:14:14 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Corrections in test looks good :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Wed Aug 26 12:05:36 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 26 Aug 2020 12:05:36 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v6] In-Reply-To: <75zQExJVL9TJ727X6Kf-IpI7nomgd1Bhmi92HmqKJKA=.c085b1d7-308a-4e7d-aaef-6b5f9ce168d5@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <7L8zZjvBLU9Hv5hJeM-jEidjhrSybzI1zmuPmbpkalI=.054ddeef-487c-4db4-a781-c7576d79bd46@github.com> <75zQExJVL9TJ727X6Kf-IpI7nomgd1Bhmi92HmqKJKA=.c085b1d7-308a-4e7d-aaef-6b5f9ce168d5@github.com> Message-ID: On Wed, 26 Aug 2020 10:19:28 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1536: >> >>> 1535: assertEquals(4, sm.getSelectedItems().size()); >>> 1536: >>> 1537: sl.dispose(); >> >> wondering about these repeated blocks? The flow is single: (default on start) -> multiple -> single -> multiple. Looks >> like the last two are repeating the first two .. what do I overlook? > > I had kept it with initial version of patch to test the listeners, But the patch has evolved to be very different now. > But still have removed only one block. Now there are three blocks and `sm.getSelectedItems().size()` varies in each > block. ahh .. that's what I overlooked - thanks for opening my eyes :) ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From github.com+6702882+dannygonzalez at openjdk.java.net Wed Aug 26 14:10:58 2020 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Wed, 26 Aug 2020 14:10:58 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Fri, 17 Apr 2020 10:46:51 GMT, dannygonzalez wrote: >> The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for >> each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change >> would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very >> limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that >> specifically checks add/remove performance of nodes may prevent such future regressions. > > @hjohn, agreed regards the issues of adding a listener to each node. > > Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own > listeners to make this a pull request that can be reviewed officially? > I await any further comments from @kevinrushforth et al. I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From bchoudhary at openjdk.java.net Wed Aug 26 15:21:48 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 26 Aug 2020 15:21:48 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v4] In-Reply-To: References: Message-ID: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Updated comments as per JDK convention ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/283/files - new: https://git.openjdk.java.net/jfx/pull/283/files/38a7551d..69b75d69 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/283/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/283/webrev.02-03 Stats: 12 lines in 12 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283 PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Wed Aug 26 15:24:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Aug 2020 15:24:46 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v4] In-Reply-To: References: Message-ID: On Tue, 25 Aug 2020 09:42:16 GMT, Nir Lisker wrote: > Since it will require an additional cleanup issue anyway, I don't think it matters when we do it, but since we're here > I see no reason not to start already. Agreed. Let's adopt the same language as the JDK. If there are configurable parameters, we can indicate the default by adding an `@defaultValue` tag (I don't think we need the word `default` in the description). ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Wed Aug 26 15:31:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Aug 2020 15:31:01 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v4] In-Reply-To: References: Message-ID: On Wed, 26 Aug 2020 15:21:48 GMT, Bhawesh Choudhary wrote: >> Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments as per JDK convention Looks good except for the one you missed to update, `StringStore`. modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 544: > 543: */ > 544: public StringStore() { > 545: } You missed updating the wording for this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From jpereda at openjdk.java.net Wed Aug 26 15:43:17 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 26 Aug 2020 15:43:17 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Wed, 26 Aug 2020 14:08:37 GMT, dannygonzalez wrote: >> @hjohn, agreed regards the issues of adding a listener to each node. >> >> Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own >> listeners to make this a pull request that can be reviewed officially? >> I await any further comments from @kevinrushforth et al. > > I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX > thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. > Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". > > [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: - this one #108, that tries to improve the performance of excessive number of `removeListener` calls - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. For the case presented, where new items are constantly added to the TableView, the trace of calls that reach `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) As can be seen, all those calls are triggered by the change of the number of cells in [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). Whenever the cell count changes there is this [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): sheetChildren.clear(); This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes used is given by `sheetChildren.size()`. This means that all the actual cells (nodes) that are used by the `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those calls to unregister those nodes from the scene that ultimately lead to remove the listeners with `ExpressionHelper.removeListener`. However, this seems unnecessary, as the number of actual cells/nodes doesn't change that much, and causes this very bad performance. On a quick test over the sample posted, just removing that line gives a noticeable improvement in performance.. There is a concern though due to the [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): // Fix for RT-13965: Without this line of code, the number of items in // the sheet would constantly grow, leaking memory for the life of the // application. This was especially apparent when the total number of // cells changes - regardless of whether it became bigger or smaller. sheetChildren.clear(); There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't constantly grow and there is no memory leak. Running the attached sample for a long time, and profiling with VisualVM, shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners wouldn't be modified). Thoughts and feedback are welcome. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From bchoudhary at openjdk.java.net Wed Aug 26 15:46:46 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 26 Aug 2020 15:46:46 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v5] In-Reply-To: References: Message-ID: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Updated comments as per JDK Convention ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/283/files - new: https://git.openjdk.java.net/jfx/pull/283/files/69b75d69..5bb07901 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/283/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/283/webrev.03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283 PR: https://git.openjdk.java.net/jfx/pull/283 From ajoseph at openjdk.java.net Wed Aug 26 17:08:45 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 26 Aug 2020 17:08:45 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Wed, 12 Aug 2020 15:59:20 GMT, Kevin Rushforth wrote: > With your patch installed, I see a race condition that manifests in one of two ways: I couldn't reproduce the race condition or crash with the fix. > I suspect this might be related to the gc.setCompositeOperation call. This may not be the cause as the compositeOperator is pushed to a RenderQueue which is decoded from the java side. ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From kcr at openjdk.java.net Wed Aug 26 17:24:45 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Aug 2020 17:24:45 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v5] In-Reply-To: References: Message-ID: On Wed, 26 Aug 2020 15:46:46 GMT, Bhawesh Choudhary wrote: >> Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments as per JDK Convention Looks good. I also verified that the only two class without an explicit constructor are the two we identified as needing to be deprecated for removal in a follow-up issue: `Selector` and `SshapeConverter` ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/283 From github.com+7517141+yososs at openjdk.java.net Wed Aug 26 17:46:38 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 26 Aug 2020 17:46:38 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote: >> I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX >> thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. >> Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". >> >> [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) > > So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: > > - this one #108, that tries to improve the performance of excessive number of `removeListener` calls > - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. > > For the case presented, where new items are constantly added to the TableView, the trace of calls that reach > `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: > ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) > > As can be seen, all those calls are triggered by the change of the number of cells in > [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). > Whenever the cell count changes there is this > [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): > sheetChildren.clear(); > > This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number > of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes > used is given by `sheetChildren.size()`. This means that all the actual cells (nodes) that are used by the > `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those > calls to unregister those nodes from the scene that ultimately lead to remove the listeners with > `ExpressionHelper.removeListener`. However, this seems unnecessary, as the number of actual cells/nodes doesn't change > that much, and causes this very bad performance. On a quick test over the sample posted, just removing that line gives > a noticeable improvement in performance.. > There is a concern though due to the > [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): > // Fix for RT-13965: Without this line of code, the number of items in > // the sheet would constantly grow, leaking memory for the life of the > // application. This was especially apparent when the total number of > // cells changes - regardless of whether it became bigger or smaller. > sheetChildren.clear(); > > There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add > cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't > constantly grow and there is no memory leak. Running the attached sample for a long time, and profiling with VisualVM, > shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. > So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but > wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners > wouldn't be modified). Thoughts and feedback are welcome. I confirmed the sample code (JavaFX Sluggish), This is not scroll performance It seems to reproduce the additional performance issue. Therefore, it is not considered appropriate as a fix for JDK-8185886. I know you are reproducing another performance issue, but I'm proposing to fix scrolling performance issues in #125. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Wed Aug 26 17:53:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Aug 2020 17:53:25 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v5] In-Reply-To: References: Message-ID: On Wed, 26 Aug 2020 17:22:36 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comments as per JDK Convention > > Looks good. I also verified that the only two class without an explicit constructor are the two we identified as > needing to be deprecated for removal in a follow-up issue: `Selector` and `SshapeConverter` I filed the following two follow-up issues: 1. [JDK-8252387](https://bugs.openjdk.java.net/browse/JDK-8252387): Deprecate for removal css Selector and ShapeConverter constructors 2. [JDK-8252389](https://bugs.openjdk.java.net/browse/JDK-8252389): Fix mistakes in FX API docs I also added the note about the PseudoClass docs to: 3. [JDK-8250590](https://bugs.openjdk.java.net/browse/JDK-8250590): Classes and methods in the javafx.css package are missing documentation ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From kcr at openjdk.java.net Wed Aug 26 18:44:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 26 Aug 2020 18:44:24 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <7sL4c0N1eXdL_mTZjT4voOgYZdhqgoqee-9_kX2uLTE=.3a5cbfae-0672-49c7-8742-4b2a1b5efbc8@github.com> References: <7sL4c0N1eXdL_mTZjT4voOgYZdhqgoqee-9_kX2uLTE=.3a5cbfae-0672-49c7-8742-4b2a1b5efbc8@github.com> Message-ID: <-NS8l8gfFyd3JtBiOrmjMlSjpzR1ee_UrwBG7QuJk4E=.8c9663b6-5d78-404b-a197-9eef44d3cedc@github.com> On Fri, 8 May 2020 19:03:26 GMT, Kevin Rushforth wrote: >> Long term, yes. >> >> I am currently low on time and my Java-foo is not that great, so I was hoping that someone would pick it up. > > I note that the JDK build recently implemented this feature in JDK 15 with > [JDK-8244592](https://bugs.openjdk.java.net/browse/JDK-8244592). Converted to a Draft PR, so that it will not show up as `rfr`. Go ahead and resubmit it when you are ready to proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/99 From bchoudhary at openjdk.java.net Wed Aug 26 18:46:41 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 26 Aug 2020 18:46:41 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v8] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into clip_mask_support - Removed RenderSVGResourceMasker changes and added fix for HIDPI mask rendering - HiDPI printing and Rendering fix - Removed unnecessery Ceil Functions - Refactoring, Utilize getFilterContext() function - Moved Printing drawing path to non MaskTextureGraphics interface - added dispose of resources - Formatting correction (Line Endings) - removed executable file mode - Added unit test + SW Graphics rendering part - ... and 2 more: https://git.openjdk.java.net/jfx/compare/31912a00...b1299ba1 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/ef47709f..b1299ba1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/213/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/213/webrev.06-07 Stats: 404841 lines in 5801 files changed: 202048 ins; 139986 del; 62807 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From jhendrikx at openjdk.java.net Wed Aug 26 22:59:23 2020 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 26 Aug 2020 22:59:23 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Wed, 26 Aug 2020 17:44:20 GMT, yosbits wrote: >> So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: >> >> - this one #108, that tries to improve the performance of excessive number of `removeListener` calls >> - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. >> >> For the case presented, where new items are constantly added to the TableView, the trace of calls that reach >> `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: >> ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) >> >> As can be seen, all those calls are triggered by the change of the number of cells in >> [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). >> Whenever the cell count changes there is this >> [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): >> sheetChildren.clear(); >> >> This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number >> of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes >> used is given by `sheetChildren.size()`. This means that all the actual cells (nodes) that are used by the >> `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those >> calls to unregister those nodes from the scene that ultimately lead to remove the listeners with >> `ExpressionHelper.removeListener`. However, this seems unnecessary, as the number of actual cells/nodes doesn't change >> that much, and causes this very bad performance. On a quick test over the sample posted, just removing that line gives >> a noticeable improvement in performance.. >> There is a concern though due to the >> [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): >> // Fix for RT-13965: Without this line of code, the number of items in >> // the sheet would constantly grow, leaking memory for the life of the >> // application. This was especially apparent when the total number of >> // cells changes - regardless of whether it became bigger or smaller. >> sheetChildren.clear(); >> >> There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add >> cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't >> constantly grow and there is no memory leak. Running the attached sample for a long time, and profiling with VisualVM, >> shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. >> So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but >> wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners >> wouldn't be modified). Thoughts and feedback are welcome. > > I confirmed the sample code (JavaFX Sluggish), > This is not scroll performance > It seems to reproduce the additional performance issue. > Therefore, it is not considered appropriate as a fix for JDK-8185886. > I know you are reproducing another performance issue, but > I'm proposing to fix scrolling performance issues in #125. The https://github.com/openjdk/jfx/pull/185 is a full fix, not a WIP. It avoids registering the listeners on Scene and Window and moves the only uses of those listeners to their respective controls, PopupWindow and ProgressIndicatorSkin (the property involved is internal, so there is no risk of affecting 3rd parties). Please have a closer look. I updated the title to make it more clear it is no longer a WIP, unless someone has review comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Thu Aug 27 00:09:50 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Aug 2020 00:09:50 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.02f3475f-dafe-459f-95cb-6debe5167d80@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.f265bd65-5b73-4d1f-aa5d-548fce87af16@github.com> <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.d4494f84-d2ec-4956-a963-4d21c45faf5b@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.013f8faf-8ef9-4a56-81ce-f5a6d94ab8ba@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.428ac098-5c16-4eee-acac-0b8d764e1120@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.6ab45011-7b65-4a9f-a6e6-190bcef75bb5@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.72ff63f9-8aed-4d1a-901d-c691b4012cd8@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.a65cb77b-0e17-440e-8509-1b1ee829d824@github.com> Message-ID: On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote: > So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but > wouldn't have any impact in the rest of controls as the other two options (as ExpressionHelper or Node listeners > wouldn't be modified). Given PR #185, which was mentioned above, (it isn't out for review yet, but I want to evaluate it), this would be a 4th approach. As long as this really doesn't introduce a leak, it seems promising. I note that these are not mutually exclusive. We should discuss this on the list and not just in one or more of of the 3 (soon to be 4) open pull requests. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kevin.rushforth at oracle.com Thu Aug 27 00:11:02 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Aug 2020 17:11:02 -0700 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView Message-ID: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> I see some progress being made on the {Tree}TableView performance issue. To summarize where I think we are: There are currently 2 different approaches under review: 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base to make removing listeners faster 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView to reduce the number of add / removes In addition, the following is a WIP PR that the author thinks could be a 3rd approach: 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph to avoid install treeShowing listeners on Window and Scene for all nodes Jose has proposed a 4th approach as a comment to PR #108, and as I understand it, he will propose a PR shortly. 4. Don't clear the list of children in a VirtualFlow when the number of items changes. So the first thing that is needed is to evaluate the approaches and decide which one to pursue. Options 1 and 3 are more broad in their scope, option #2 is more targeted (to TableView), but within that area is a larger change. Option #3 would remove the (internal) treeShowing property as a generally available concept and only use it for controls like ProgressIndicator that really need it. Option #4 affects only controls that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a large change (presuming we can verify that no leak is introduced). I note that these fixes are not mutually exclusive, but I do think we need to settle on a primary approach and use that to fix this issue. If there are still performance problems after that fix, we can consider one (or more) of the others. Comments? -- Kevin From kevin.rushforth at oracle.com Thu Aug 27 00:17:49 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 26 Aug 2020 17:17:49 -0700 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> Message-ID: <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> Sorry for the badly formatted html. Here it is again. I see some progress being made on the {Tree}TableView performance issue. To summarize where I think we are: There are currently 2 different approaches under review: 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base to make removing listeners faster 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView to reduce the number of add / removes In addition, the following is a WIP PR that the author thinks could be a 3rd approach: 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph to avoid install treeShowing listeners on Window and Scene for all nodes Jose has proposed a 4th approach as a comment to PR #108, and as I understand it, he will propose a PR shortly. 4. Don't clear the list of children in a VirtualFlow when the number of items changes. So the first thing that is needed is to evaluate the approaches and decide which one to pursue. Options 1 and 3 are more broad in their scope, option #2 is more targeted (to TableView), but within that area is a larger change. Option #3 would remove the (internal) treeShowing property as a generally available concept and only use it for controls like ProgressIndicator that really need it. Option #4 affects only controls that use VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a large change (presuming we can verify that no leak is introduced). I note that these fixes are not mutually exclusive, but I do think we need to settle on a primary approach and use that to fix this issue. If there are still performance problems after that fix, we can consider one (or more) of the others. Comments? -- Kevin From github.com+7517141+yososs at openjdk.java.net Thu Aug 27 06:40:12 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Thu, 27 Aug 2020 06:40:12 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v2] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Sat, 18 Apr 2020 17:40:30 GMT, yosbits wrote: >> My name is "Naohiro Yoshimoto" >> I have received an approved email on 2019-8-3. > > 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 > > * Constructor creates multiple cell nodes, but the > Fixed a wasteful problem of creating all cells and deleting out-of-display cells because the fixedCellSize attribute > was not initialized in the constructor.. > * Reduce the load on ExpressionHelper.removeListener by removing cells outside of the display range from the back of the > scrolling operation. When setting the cell height to a fixed value with setFixedCellSize(), column virtualization can improve performance. As the next step, I think it is possible to try to enable column virtualization regardless of whether setFixedCellSize() is set or not. Before doing this step, the direct access validation of the internal structure of the test code needs to be changed via the public API. ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From hjohn at xs4all.nl Thu Aug 27 12:58:57 2020 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 27 Aug 2020 14:58:57 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> Message-ID: <6299aea1-d2dd-832f-75e3-3003cf5266c5@xs4all.nl> I just want to quickly mention that option 3 (https://github.com/openjdk/jfx/pull/185) is no longer a WIP -- all functionality is working all tests pass. The PR creates a TreeShowingExpression class which encapsulates the tree showing logic that was in Node class. This class is then only used by ProgressIndicatorSkin and PopupWindow. This effectively means that instead of registering a listener on Window and Scene for all nodes they're only registered for those classes that need to know the showing status of a Scene. --John On 27/08/2020 02:17, Kevin Rushforth wrote: > Sorry for the badly formatted html. Here it is again. > > I see some progress being made on the {Tree}TableView performance issue. > To summarize where I think we are: > > There are currently 2 different approaches under review: > > 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base > to make removing listeners faster > 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView > to reduce the number of add / removes > > In addition, the following is a WIP PR that the author thinks could be a > 3rd approach: > > 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph > to avoid install treeShowing listeners on Window and Scene for all nodes > > Jose has proposed a 4th approach as a comment to PR #108, and as I > understand it, he will propose a PR shortly. > > 4. Don't clear the list of children in a VirtualFlow when the number of > items changes. > > So the first thing that is needed is to evaluate the approaches and > decide which one to pursue. > > Options 1 and 3 are more broad in their scope, option #2 is more > targeted (to TableView), but within that area is a larger change. Option > #3 would remove the (internal) treeShowing property as a generally > available concept and only use it for controls like ProgressIndicator > that really need it. Option #4 affects only controls that use > VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a > large change (presuming we can verify that no leak is introduced). > > I note that these fixes are not mutually exclusive, but I do think we > need to settle on a primary approach and use that to fix this issue. If > there are still performance problems after that fix, we can consider one > (or more) of the others. > > Comments? > > -- Kevin > From ajoseph at openjdk.java.net Thu Aug 27 15:06:01 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 27 Aug 2020 15:06:01 GMT Subject: RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes Message-ID: Update to GTK WebKit 2.28.4 https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html ------------- Commit messages: - 8252381: Cherry pick GTK WebKit 2.28.4 changes Changes: https://git.openjdk.java.net/jfx/pull/289/files Webrev: https://webrevs.openjdk.java.net/jfx/289/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252381 Stats: 174 lines in 21 files changed: 123 ins; 16 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/289/head:pull/289 PR: https://git.openjdk.java.net/jfx/pull/289 From github.com+17347324+Torbuntu at openjdk.java.net Thu Aug 27 21:23:51 2020 From: github.com+17347324+Torbuntu at openjdk.java.net (Tor (torbuntu)) Date: Thu, 27 Aug 2020 21:23:51 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.f0d13854-5f71-4d32-98a1-d8d4add15c1c@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> <1tmjd7JiVjZcfYETfxsMFmjUe8eiVaI7zP6bGvkCzUs=.b4b2b8ca-3f26-4e74-8c61-024b82a9d1f5@github.com> <3ybQJCH8SW7KUnraQ590POUBC60Bc5ARHo8lk9jmA9Y=.f0d13854-5f71-4d32-98a1-d8d4add15c1c@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 kcr at openjdk.java.net Thu Aug 27 21:29:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Aug 2020 21:29:39 GMT Subject: RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes In-Reply-To: References: Message-ID: On Thu, 27 Aug 2020 14:59:56 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.4 > https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html Looks good. Also, I tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/289 From kcr at openjdk.java.net Thu Aug 27 23:23:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 Aug 2020 23:23:49 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7] In-Reply-To: <8aCyFZHr6bh2Gr3tQ6NWEtBJVFRGuvXgeYOumg5HZsk=.9ef1fc24-bd83-48dd-b786-3f139dea3420@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <8aCyFZHr6bh2Gr3tQ6NWEtBJVFRGuvXgeYOumg5HZsk=.9ef1fc24-bd83-48dd-b786-3f139dea3420@github.com> Message-ID: On Wed, 26 Aug 2020 12:03:26 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrections in test > > looks good :) The fix looks good for an editable ComboBox. If the ComboBox is not editable, it will have the effect of making the HOME and END keys no-ops, which is a (possibly unwanted) change in behavior. I checked a couple native Windows apps and they have the behavior I would expect: the arrow keys, and the HOME / END keys navigate the text field for editable combo boxes. HOME and END go to the beginning or end of the list for non-editable combo boxes. While we could treat that as a follow-up issue, it would be worth thinking about whether we could limit the change to editable combo boxes. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From nlisker at openjdk.java.net Fri Aug 28 02:03:46 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 28 Aug 2020 02:03:46 GMT Subject: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v5] In-Reply-To: References: Message-ID: On Wed, 26 Aug 2020 15:46:46 GMT, Bhawesh Choudhary wrote: >> Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments as per JDK Convention Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From ajoseph at openjdk.java.net Fri Aug 28 05:26:45 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 28 Aug 2020 05:26:45 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Tue, 11 Aug 2020 16:18:37 GMT, Bhawesh Choudhary wrote: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. The fix and test looks good. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/279 From aghaisas at openjdk.java.net Fri Aug 28 07:17:37 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 28 Aug 2020 07:17:37 GMT Subject: RFR: 8251941: ListCell: visual artifact when items contain null values In-Reply-To: References: Message-ID: On Tue, 25 Aug 2020 11:40:56 GMT, Jeanette Winzenburg wrote: > The issue describes the makroscopic effect/s, namely content showing in cells that are off range. > > The base reason is missing cleanup of the cell on transition from not-empty to empty when the old item is a null > contained in the items. Fixed by changing the logic to cope with that special case. Added tests that fail before and > pass after the fix. Marked as reviewed by aghaisas (Reviewer). Looks OK. ------------- PR: https://git.openjdk.java.net/jfx/pull/288 From bchoudhary at openjdk.java.net Fri Aug 28 07:27:21 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 28 Aug 2020 07:27:21 GMT Subject: Integrated: 8251353: Many javafx scenegraph classes have implicit no-arg constructors In-Reply-To: References: Message-ID: <9exee9EMkPO5MYIMk_TpyilS4vvg3ef9IlWUv5of1Ig=.05b7f831-140f-4f72-8299-b30c0f7ecd78@github.com> On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary wrote: > Added missing explicit no-arg constructors to classes in package javafx.scene, javafx.css and javafx.stage. This pull request has now been integrated. Changeset: 23ad8f40 Author: Bhawesh Choudhary Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/23ad8f40 Stats: 80 lines in 12 files changed: 0 ins; 80 del; 0 mod 8251353: Many javafx scenegraph classes have implicit no-arg constructors Reviewed-by: kcr, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/283 From fastegal at openjdk.java.net Fri Aug 28 10:08:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 Aug 2020 10:08:53 GMT Subject: Integrated: 8251941: ListCell: visual artifact when items contain null values In-Reply-To: References: Message-ID: On Tue, 25 Aug 2020 11:40:56 GMT, Jeanette Winzenburg wrote: > The issue describes the makroscopic effect/s, namely content showing in cells that are off range. > > The base reason is missing cleanup of the cell on transition from not-empty to empty when the old item is a null > contained in the items. Fixed by changing the logic to cope with that special case. Added tests that fail before and > pass after the fix. This pull request has now been integrated. Changeset: c86bd353 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/c86bd353 Stats: 90 lines in 2 files changed: 0 ins; 87 del; 3 mod 8251941: ListCell: visual artifact when items contain null values Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/288 From fastegal at openjdk.java.net Fri Aug 28 10:24:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 Aug 2020 10:24:10 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <8aCyFZHr6bh2Gr3tQ6NWEtBJVFRGuvXgeYOumg5HZsk=.9ef1fc24-bd83-48dd-b786-3f139dea3420@github.com> Message-ID: On Thu, 27 Aug 2020 23:21:28 GMT, Kevin Rushforth wrote: > > > If the ComboBox is not editable, it will have the effect of making the HOME and END keys no-ops, which is a (possibly > unwanted) change in behavior. I checked a couple native Windows apps and they have the behavior I would expect: the > arrow keys, and the HOME / END keys navigate the text field for editable combo boxes. HOME and END go to the beginning > or end of the list for non-editable combo boxes. While we could treat that as a follow-up issue, it would be worth > thinking about whether we could limit the change to editable combo boxes. outch .. how did I overlook that .. (seems reviewing doesn't belong to my strengths ;) This fix should not break (correct) existing behavior, so back to thinking .. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From bchoudhary at openjdk.java.net Fri Aug 28 12:29:51 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 28 Aug 2020 12:29:51 GMT Subject: RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes In-Reply-To: References: Message-ID: On Thu, 27 Aug 2020 14:59:56 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.4 > https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html Marked as reviewed by bchoudhary (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/289 From bchoudhary at openjdk.java.net Fri Aug 28 12:29:51 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 28 Aug 2020 12:29:51 GMT Subject: RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes In-Reply-To: References: Message-ID: On Thu, 27 Aug 2020 21:27:18 GMT, Kevin Rushforth wrote: >> Update to GTK WebKit 2.28.4 >> https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html > > Looks good. Also, I tested on all three platforms. Verified with all three platform. Looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/289 From ajoseph at openjdk.java.net Fri Aug 28 12:34:13 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 28 Aug 2020 12:34:13 GMT Subject: Integrated: 8252381: Cherry pick GTK WebKit 2.28.4 changes In-Reply-To: References: Message-ID: On Thu, 27 Aug 2020 14:59:56 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.4 > https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html This pull request has now been integrated. Changeset: 88c0f978 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/88c0f978 Stats: 174 lines in 21 files changed: 16 ins; 123 del; 35 mod 8252381: Cherry pick GTK WebKit 2.28.4 changes Reviewed-by: kcr, bchoudhary ------------- PR: https://git.openjdk.java.net/jfx/pull/289 From kevin.rushforth at oracle.com Fri Aug 28 13:20:14 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Aug 2020 06:20:14 -0700 Subject: 11-dev backport request for 11.0.9: JDK-8252381: Cherry pick GTK WebKit 2.28.4 changes Message-ID: <48d81ffd-7341-66bb-d482-84b2aeec5f26@oracle.com> Hi Johan, I request approval to backport the following to 11-dev for 11.0.9: JDK-8252381 [1] : Cherry pick GTK WebKit 2.28.4 changes -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8252381 From johan.vos at gluonhq.com Fri Aug 28 13:35:04 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 28 Aug 2020 15:35:04 +0200 Subject: 11-dev backport request for 11.0.9: JDK-8252381: Cherry pick GTK WebKit 2.28.4 changes In-Reply-To: <48d81ffd-7341-66bb-d482-84b2aeec5f26@oracle.com> References: <48d81ffd-7341-66bb-d482-84b2aeec5f26@oracle.com> Message-ID: approved On Fri, Aug 28, 2020 at 3:20 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following to 11-dev for 11.0.9: > > JDK-8252381 [1] : Cherry pick GTK WebKit 2.28.4 changes > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8252381 > > From bchoudhary at openjdk.java.net Fri Aug 28 15:01:23 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 28 Aug 2020 15:01:23 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors Message-ID: Deprecate the public constructor of javafx.css.Selector and javafx.css.converter.ShapeConverter Constrcutor for class javafx.css.Selector should not be public as it is only extended by classes in same package. it should be changed to package-private Constrcutor for class javafx.css.converter.ShapeConverter should be private rather than public as its a singleton class. ------------- Commit messages: - 8252387: Deprecate for removal css Selector and ShapeConverter constructors Changes: https://git.openjdk.java.net/jfx/pull/290/files Webrev: https://webrevs.openjdk.java.net/jfx/290/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252387 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/290/head:pull/290 PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Fri Aug 28 15:07:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Aug 2020 15:07:29 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020 14:55:55 GMT, Bhawesh Choudhary wrote: > Constrcutor for class javafx.css.Selector should not be public as it is only extended by classes in same package. it > should be changed to package-private Constrcutor for class javafx.css.converter.ShapeConverter should be private rather > than public as its a singleton class. This is the eventual goal (for JavaFX 17), but it isn't what this bug is addressing for JavaFX 16. Can you reword this to indicate that this bug is just deprecating the constructors for removal, and that we will file a follow-up bug to later change the access? ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From nlisker at openjdk.java.net Fri Aug 28 16:27:46 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 28 Aug 2020 16:27:46 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: <2IWSfAtmB5adK4IlgM4SDAJO8ldALDzmOAZpNDGw6-c=.3e5bb800-dac4-4075-a8e1-2370048e1fcd@github.com> On Fri, 28 Aug 2020 14:55:55 GMT, Bhawesh Choudhary wrote: > Deprecate the public constructor of javafx.css.Selector as it should not be public due to only being extended by > classes in same package. Deprecate the public constructor of javafx.css.converter.ShapeConverter as its a singleton > class. Looks good. Added a single comment. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 47: > 46: * @deprecated This constructor was exposed erroneously and will be removed in the next version. > 47: */ > 48: @Deprecated(since="16", forRemoval=true) Please direct the reader to the way of obtaining an instance of this class like you did for `ShapeConverter`. ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From arapte at openjdk.java.net Fri Aug 28 16:45:38 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 28 Aug 2020 16:45:38 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Fix for non editable ComboBox ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/22f79d63..2539a5a2 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.06-07 Stats: 40 lines in 2 files changed: 38 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Fri Aug 28 16:55:00 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 28 Aug 2020 16:55:00 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> <8aCyFZHr6bh2Gr3tQ6NWEtBJVFRGuvXgeYOumg5HZsk=.9ef1fc24-bd83-48dd-b786-3f139dea3420@github.com> Message-ID: <1rGBp6tCen3Am_wD5-rDkj3v8Bj-6XIo9rLb8gchF7I=.c96b33a6-af50-4645-9de3-ec86f029e1e3@github.com> On Fri, 28 Aug 2020 10:21:50 GMT, Jeanette Winzenburg wrote: > If the ComboBox is not editable, it will have the effect of making the HOME and END keys no-ops, which is a (possibly > unwanted) change in behavior. I have updated PR with changes for non editable ComboBox. I could think of adding another property to propagate the editable property of ComboBox to ListViewBehavior. So now this fix adds another property `editableComboBoxEditor`, not sure if there is other way to handle it. The change adds HOME and END KeyMappings when ComboBox is non editable and removes them when ComboBox is editable. If the change sounds Ok, I shall include test in next commit. Also, there is one change in the if condition that was suggested by Jeanette before, `if (!Boolean.TRUE.equals(control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor")))` is changed to, `if (Boolean.FALSE.equals(control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor")))` It seems safe as `control.getProperties().containsKey()` returns either true or false. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From bchoudhary at openjdk.java.net Fri Aug 28 17:26:41 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Fri, 28 Aug 2020 17:26:41 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: > Deprecate the public constructor of javafx.css.Selector as it should not be public due to only being extended by > classes in same package. Deprecate the public constructor of javafx.css.converter.ShapeConverter as its a singleton > class. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Updated Selector class comments as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/290/files - new: https://git.openjdk.java.net/jfx/pull/290/files/4719ef18..eb2f71b8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/290/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/290/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/290/head:pull/290 PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Fri Aug 28 17:26:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Aug 2020 17:26:46 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: <2IWSfAtmB5adK4IlgM4SDAJO8ldALDzmOAZpNDGw6-c=.3e5bb800-dac4-4075-a8e1-2370048e1fcd@github.com> References: <2IWSfAtmB5adK4IlgM4SDAJO8ldALDzmOAZpNDGw6-c=.3e5bb800-dac4-4075-a8e1-2370048e1fcd@github.com> Message-ID: On Fri, 28 Aug 2020 16:24:54 GMT, Nir Lisker wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated Selector class comments as per review > > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 47: > >> 46: * @deprecated This constructor was exposed erroneously and will be removed in the next version. >> 47: */ >> 48: @Deprecated(since="16", forRemoval=true) > > Please direct the reader to the way of obtaining an instance of this class like you did for `ShapeConverter`. Probably you can refer to the `createSelector` method. ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Fri Aug 28 17:52:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Aug 2020 17:52:15 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 28 Aug 2020 16:45:38 GMT, Ambarish Rapte wrote: >> The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. >> This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several >> `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. >> Fix: >> 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. >> 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to >> `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. >> Change unrelated to fix: >> `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup >> is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code >> from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed >> for the fix. But this seems to be dead code. Verification: >> Added new unit tests to verify the change. >> Also verified that the behavior ListView behaves same before and after this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Fix for non editable ComboBox I haven't tested it, but it looks like it should work. I left a couple of minor suggestions below. Would it be possible to add some tests to verify the behavior of HOME and END for editable and non-editable ComboBox controls? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 143: > 142: > 143: if (Boolean.FALSE.equals(control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor"))) { > 144: // This is not ComboBox's ListView Unless I'm missing something, you don't need to compare with a `Boolean` at all since containsKey returns a `boolean` primitive type, so I think this can be simplified to: if (!control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor")) { If instead you do want to check the value of the property, and not just its existence, you would need the following, and it would be important to check `!TRUE.equals` rather than `FALSE.equals` so that an unset property would be treated as `false`. if (!Boolean.TRUE.equals(control.getProperties().get("excludeKeyMappingsForComboBoxEditor"))) { modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 359: > 358: Boolean isComboBoxEditable = (Boolean)getNode().getProperties().get("editableComboBoxEditor"); > 359: if (isComboBoxEditable != null) { > 360: // This is ComboBox's ListView Maybe simplify this as follows, to match the earlier logic? if (Boolean.FALSE.equals(getNode().getProperties().get("editableComboBoxEditor"))) { ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From kcr at openjdk.java.net Fri Aug 28 18:45:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 Aug 2020 18:45:37 GMT Subject: RFR: 8251858: Update to Xcode 11.3.1 Message-ID: This updates the compiler used to build JavaFX on macOS to Xcode 11.3.1 + MacOSX10.15 sdk, which matches the compiler used to build JDK 16. As noted in the bug report, Xcode 11.3.1 needs macOS 10.14.4 (Mojave) or later to build, but the produced artifacts will be able to run on earlier versions of macOS. ------------- Commit messages: - 8251858: Update to Xcode 11.3.1 Changes: https://git.openjdk.java.net/jfx/pull/291/files Webrev: https://webrevs.openjdk.java.net/jfx/291/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251858 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/291/head:pull/291 PR: https://git.openjdk.java.net/jfx/pull/291 From jvos at openjdk.java.net Fri Aug 28 19:53:42 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 28 Aug 2020 19:53:42 GMT Subject: RFR: 8251858: Update to Xcode 11.3.1 In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020 18:39:16 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 11.3.1 + MacOSX10.15 sdk, which matches the compiler > used to build JDK 16. > As noted in the bug report, Xcode 11.3.1 needs macOS 10.14.4 (Mojave) or later to build, but the produced artifacts > will be able to run on earlier versions of macOS. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/291 From kcr at openjdk.java.net Sat Aug 29 00:34:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 29 Aug 2020 00:34:21 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020 05:24:24 GMT, Arun Joseph wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply state to fix the issue. > > The fix and test looks good. I spent some time this afternoon going over the fix in more detail and doing extensive testing on both Windows and Mac. I believe the fix is good. Both by inspection and by instrumenting the code, there are no race conditions or other problems that I can see. The problem appears to be in the test, or else somewhere in the test harness or the SW pipeline exposed by the test. If I run the new CSSTest in a loop on either Mac or Windows, it will crash intermittently. I then reverted your fix, running the new test (which will throw an expected assertion error), and it still crashes intermittently. My recommendation is to use a system test, similar to what [SVGTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/SVGTest.java) does, rather than a unit test in the javafx.web module, which uses `WebPage::paint`. ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From arapte at openjdk.java.net Sat Aug 29 08:49:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 29 Aug 2020 08:49:19 GMT Subject: RFR: 8251858: Update to Xcode 11.3.1 In-Reply-To: References: Message-ID: <9S5ftUd-Wo9UoHzls9nlVD1I_VXAVCjYJOPoPDYid1Q=.4a338f52-d904-4912-88ca-390e00787620@github.com> On Fri, 28 Aug 2020 18:39:16 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 11.3.1 + MacOSX10.15 sdk, which matches the compiler > used to build JDK 16. > As noted in the bug report, Xcode 11.3.1 needs macOS 10.14.4 (Mojave) or later to build, but the produced artifacts > will be able to run on earlier versions of macOS. Build verified on Mojave 10.14.6 ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/291 From arapte at openjdk.java.net Sat Aug 29 09:13:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 29 Aug 2020 09:13:55 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v9] In-Reply-To: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: <4_Cu9cTjlqGXSf6hZhV2bUXeTKzzfRgzkY8-yWUmw6A=.5a9133d6-8dcd-415c-8348-01d8a955072f@github.com> > The issue occurs because the key events are consumed by the `ListView` in `Popup`, which displays the items. > This is a regression of [JDK-8077916](https://bugs.openjdk.java.net/browse/JDK-8077916). This change aadded several > `KeyMapping`s for focus traversals to `ListView`, which consume the `Left`, `Right` and `Ctrl+A` key events. > Fix: > 1. Remove the four focus traversal arrow `KeyMapping`s from `ListViewBehavior`. > 2. Add the `Ctrl + A` `KeyMapping` to `ListViewBehavior` only if the `ListView`'s selection mode is set to > `SelectionMode.MULTIPLE`. `ComboBox` uses the `ListView` with `SelectionMode.SINGLE` mode. > Change unrelated to fix: > `ComboBoxListViewBehavior` adds `KeyMapping` for `Up` and `Down` keys, which are not invoked when the `ComboBox` popup > is showing. When the popup is shown, the Up and Down key events are handled by the `ListView` and the `KeyMapping` code > from `ComboBoxListViewBehavior` does not get executed. These KeyMapping are removed. However this change is not needed > for the fix. But this seems to be dead code. Verification: > Added new unit tests to verify the change. > Also verified that the behavior ListView behaves same before and after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: add test, modify ifs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/172/files - new: https://git.openjdk.java.net/jfx/pull/172/files/2539a5a2..b948ef18 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/172/webrev.08 - incr: https://webrevs.openjdk.java.net/jfx/172/webrev.07-08 Stats: 70 lines in 3 files changed: 31 ins; 10 del; 29 mod Patch: https://git.openjdk.java.net/jfx/pull/172.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172 PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Sat Aug 29 09:13:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 29 Aug 2020 09:13:56 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 28 Aug 2020 17:30:11 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix for non editable ComboBox > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 143: > >> 142: >> 143: if (Boolean.FALSE.equals(control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor"))) { >> 144: // This is not ComboBox's ListView > > Unless I'm missing something, you don't need to compare with a `Boolean` at all since containsKey returns a `boolean` > primitive type, so I think this can be simplified to: > if (!control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor")) { > > If instead you do want to check the value of the property, and not just its existence, you would need the following, > and it would be important to check `!TRUE.equals` rather than `FALSE.equals` so that an unset property would be treated > as `false`. if (!Boolean.TRUE.equals(control.getProperties().get("excludeKeyMappingsForComboBoxEditor"))) { Changed to use `if (!control.getProperties().containsKey("excludeKeyMappingsForComboBoxEditor")) {` > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 359: > >> 358: Boolean isComboBoxEditable = (Boolean)getNode().getProperties().get("editableComboBoxEditor"); >> 359: if (isComboBoxEditable != null) { >> 360: // This is ComboBox's ListView > > Maybe simplify this as follows, to match the earlier logic? > > if (Boolean.FALSE.equals(getNode().getProperties().get("editableComboBoxEditor"))) { With this change, we need to check both FALSE and TRUE. For a Non ComboBox ListView `getNode().getProperties().get("editableComboBoxEditor")` would be `null`. if (Boolean.FALSE.equals(getNode().getProperties().get("editableComboBoxEditor"))) { add KeyMappings } else if (Boolean.TRUE.equals(getNode().getProperties().get("editableComboBoxEditor"))) { remove KeyMappings } else { ListView is not contained by ComboBox } ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From arapte at openjdk.java.net Sat Aug 29 09:14:12 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 29 Aug 2020 09:14:12 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Fri, 28 Aug 2020 17:49:57 GMT, Kevin Rushforth wrote: > Would it be possible to add some tests to verify the behavior of HOME and END for editable and non-editable ComboBox > controls? @kevinrushforth @kleopatra Please check the updated changes. _ComboBoxTest_ and _ListViewTest_ both have minor modifications in how they access _KeyMappings_. and added test for verifying **HOME** and **END** key with both editable and non editable ComboBox. ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From fastegal at openjdk.java.net Sat Aug 29 10:42:54 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 29 Aug 2020 10:42:54 GMT Subject: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v8] In-Reply-To: References: <27_Na3SYCciAYSxhFNWMb-CCBfXXAyySSAz-5bv4uZg=.b89064f3-70df-44ef-a371-1325af47d9d1@github.com> Message-ID: On Sat, 29 Aug 2020 09:11:26 GMT, Ambarish Rapte wrote: >> I haven't tested it, but it looks like it should work. I left a couple of minor suggestions below. >> >> Would it be possible to add some tests to verify the behavior of HOME and END for editable and non-editable ComboBox >> controls? > >> Would it be possible to add some tests to verify the behavior of HOME and END for editable and non-editable ComboBox >> controls? > > @kevinrushforth @kleopatra > Please check the updated changes. _ComboBoxTest_ and _ListViewTest_ both have minor modifications in how they access > _KeyMappings_. and added test for verifying **HOME** and **END** key with both editable and non editable ComboBox. hmm .. this is getting unwieldy, isn't it ;) The pain points: - cascade of listeners (editable -> comboSkin -> properties -> behavior) - dynamic change (add/remove) of mappings - multiple key/value pairs for basically the same - though variant - state My suggestion would be to take a step back (in solution path): near the beginning was the evaluation of using different inputMaps for different state contexts. Which was not further evaluated because it looked like we could get away with simply configuring the mappings - based on certain condition - once at instantiation time. Which has the advantage of not touching too much code but unfortunely turned out to be not enough. Meanwhile, I'm convinced that in the long run there is no way around different inputMaps based on context: the differences in behavior (stand-alone vs. editable combo-popup vs. not-editable combo-popup) are many - f.i. focus-only navigation doesn't make sense in the popup (should be selection navigation always), left/right in a not-editable should trigger selection navigation .. and certainly more. So we not only have to enable/disable certain mappings, but also re-map the triggered behavior. That's too broad for this issue, but we could take a step into that direction: use the InputMap/Mapping API to help - it was designed for exactly such a differentiation :) The step would be to use interceptors (instead of dynamic modification of the mappings list), they are available on both inputMap and mapping level. As a first step, we could use the latter: keep the addition of mappings as-is (before the fix) and add interceptors to mappings for inclusion/exclusion based on context. No listeners, no dynamic modification, just one marker in the properties .. hopefully :) Raw code snippets: // let combo skin put a Supplier for editable as value getProperties().put("comboContext", (Supplier) () -> getSkinnable().isEditable()); // let listView behavior use the supplier to build interceptors Supplier comboEditable = (Supplier) control.getProperties().get("comboContext"); Predicate interceptIfInCombo = e -> comboEditable != null; Predicate interceptIfInEditableCombo = e -> comboEditable != null && comboEditable.get(); if (comboEditable == null) { // add focus traversal mappings if not in combo popup addDefaultMapping(listViewInputMap, FocusTraversalInputMap.getFocusTraversalMappings()); } // add mappings with appropriate interceptors addDefaultMapping(listViewInputMap, // missing api in KeyMapping: no constructor taking KeyCode and interceptor new KeyMapping(new KeyBinding(HOME), e -> selectFirstRow(), interceptIfInEditableCombo), new KeyMapping(new KeyBinding(END), e -> selectLastRow(), interceptIfInEditableCombo), new KeyMapping(new KeyBinding(HOME).shift(), e -> selectAllToFirstRow(), interceptIfInCombo), new KeyMapping(new KeyBinding(END).shift(), e -> selectAllToLastRow(), interceptIfInCombo), ... With this, the tests for key navigation are passing, the low-level mapping tests will have to be re-formulated to test for not/intercepted vs. existence. What do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/172 From nlisker at openjdk.java.net Sat Aug 29 10:55:24 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 29 Aug 2020 10:55:24 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: <5hK_FjBkMRKW8YDUSkMzIQhOK01FiSVGfnrYtYMX0aU=.102ee2df-6cfd-4d58-ad55-48f656ca5b8f@github.com> On Fri, 28 Aug 2020 17:26:41 GMT, Bhawesh Choudhary wrote: >> Deprecate the public constructor of javafx.css.Selector as it should not be public due to only being extended by >> classes in same package. Deprecate the public constructor of javafx.css.converter.ShapeConverter as its a singleton >> class. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated Selector class comments as per review Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Sat Aug 29 12:08:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 29 Aug 2020 12:08:12 GMT Subject: Integrated: 8251858: Update to Xcode 11.3.1 In-Reply-To: References: Message-ID: <414TJIxfvOa-5JTjx4SDheyuJX2zF-wsJ4Bus0AYGdQ=.6959f212-3463-4016-99cb-d399284d7f8d@github.com> On Fri, 28 Aug 2020 18:39:16 GMT, Kevin Rushforth wrote: > This updates the compiler used to build JavaFX on macOS to Xcode 11.3.1 + MacOSX10.15 sdk, which matches the compiler > used to build JDK 16. > As noted in the bug report, Xcode 11.3.1 needs macOS 10.14.4 (Mojave) or later to build, but the produced artifacts > will be able to run on earlier versions of macOS. This pull request has now been integrated. Changeset: 87ad57f1 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/87ad57f1 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8251858: Update to Xcode 11.3.1 Reviewed-by: jvos, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/291 From nlisker at gmail.com Sat Aug 29 14:30:51 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 29 Aug 2020 17:30:51 +0300 Subject: Release notes presentation In-Reply-To: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> References: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> Message-ID: Reviving this, the JDK has a page for release notes [1] that makes it easier for the developer to be updated on the changes. I think that we can do something similar. [1] https://www.oracle.com/java/technologies/javase/14-relnote-issues.html On Mon, Mar 9, 2020 at 2:56 PM Jeanette Winzenburg wrote: > > agree with better highlighting of the important changes/issues > disagree with leaving out the not so important - that's in the eye of > the reader, anyway - changes/issues: after all, the target readership > are technicians, not suits :) > > -- Jeanette > > Zitat von Nir Lisker : > > > Hi, > > > > I posted the release notes for OpenJFX 14 on Reddit. The top comment [1] > > complained about the presentation. Maybe on openjfx.io the Release Notes > > link could show a more "friendly" summary with a link to the detailed > > table. I suggest: > > > > 1. Including only changes that matter to the users of the library with > > separate sections for new API and for (non-internal) bug fixes. > > 2. Highlighting significant changes. > > > > Some example bug fixes to include: > > - TableView, ListView: unexpected scrolling behaviour on up/down keys > > - DragAndDrop no longer works with GTK3 > > - Window order is not correct when Modality.WINDOW_MODAL > > > > Don't include: > > - [WebView] Sub-resource integrity check fails on Windows and Linux > > - javafx.web build fails on XCode 10.2 > > - Cherry pick GTK WebKit ___ changes > > > > Enhancements to include: > > - Add support for e-paper displays > > - Add exclusion scope for LightBase > > - Point2D and Point3D should implement Interpolatable > > > > Don't include: > > - Color, Point2D and Point3D's fields should be made final > > > > Thoughts? > > > > - Nir > > > > [1] > > > https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x > > > > From kcr at openjdk.java.net Sat Aug 29 14:33:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 29 Aug 2020 14:33:04 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020 17:26:41 GMT, Bhawesh Choudhary wrote: >> Deprecate the public constructor of javafx.css.Selector as it should not be public due to only being extended by >> classes in same package. Deprecate the public constructor of javafx.css.converter.ShapeConverter as its a singleton >> class. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Updated Selector class comments as per review Looks good. Please update the CSR to reflect the change in the docs Selector. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Sat Aug 29 14:38:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 29 Aug 2020 14:38:40 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Aug 2020 14:30:45 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated Selector class comments as per review > > Looks good. Please update the CSR to reflect the change in the docs Selector. This should not have been marked as ready by the Skara bot. Looks like there is a bug in the processing of the `/csr` since the CSR is not yet approved. @bhaweshkc please wait until the CSR is approved before integrating. ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From nlisker at openjdk.java.net Sat Aug 29 14:38:40 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 29 Aug 2020 14:38:40 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Aug 2020 14:35:58 GMT, Kevin Rushforth wrote: >> Looks good. Please update the CSR to reflect the change in the docs Selector. > > This should not have been marked as ready by the Skara bot. Looks like there is a bug in the processing of the `/csr` > since the CSR is not yet approved. > @bhaweshkc please wait until the CSR is approved before integrating. @kevinrushforth Why is the Skara bot saying this PR can be integrated if the CSR is not approved yet? Also, in the main post under Reviewers, the links to the users lead to a 404. Should I submit bugs for these? ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From kcr at openjdk.java.net Sat Aug 29 14:55:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 29 Aug 2020 14:55:53 GMT Subject: RFR: 8252387: Deprecate for removal css Selector and ShapeConverter constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Aug 2020 14:36:25 GMT, Nir Lisker wrote: > Why is the Skara bot saying this PR can be integrated if the CSR is not approved yet? Looks like we both noticed this at the same time. > Also, in the main post under Reviewers, the links to the users lead to a 404. I hadn't noticed this before. > Should I submit bugs for these? Yes, please. ------------- PR: https://git.openjdk.java.net/jfx/pull/290 From johan.vos at gluonhq.com Sat Aug 29 15:02:44 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 29 Aug 2020 17:02:44 +0200 Subject: Release notes presentation In-Reply-To: References: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> Message-ID: Hi Nir, I am very ok with that. I think we somehow need both. Currently, the release notes that are also in the repository are a dry summary of the bug fixes/features that have been added in this release. They are a 1-1 translation of the issues in JBS that are fixed in the given release. I think that is good to have, as it allows for an easy lookup of what feature was in which release. Apart from that, I'm often asked what the "key features" are for a specific release. That is of course very subjective, but from a marketing point, or even for developers, it makes sense to have those release notes as well. I don't think those should go in the github repo, but they can definitely go on openjfx.io. Those "friendly" release notes will always be subjective, but I don't see big problems with that. In case of doubt, the "official" (dry) release notes are objective. - Johan On Sat, Aug 29, 2020 at 4:32 PM Nir Lisker wrote: > Reviving this, the JDK has a page for release notes [1] that makes it > easier for the developer to be updated on the changes. I think that we can > do something similar. > > [1] https://www.oracle.com/java/technologies/javase/14-relnote-issues.html > > On Mon, Mar 9, 2020 at 2:56 PM Jeanette Winzenburg < > fastegal at swingempire.de> > wrote: > > > > > agree with better highlighting of the important changes/issues > > disagree with leaving out the not so important - that's in the eye of > > the reader, anyway - changes/issues: after all, the target readership > > are technicians, not suits :) > > > > -- Jeanette > > > > Zitat von Nir Lisker : > > > > > Hi, > > > > > > I posted the release notes for OpenJFX 14 on Reddit. The top comment > [1] > > > complained about the presentation. Maybe on openjfx.io the Release > Notes > > > link could show a more "friendly" summary with a link to the detailed > > > table. I suggest: > > > > > > 1. Including only changes that matter to the users of the library with > > > separate sections for new API and for (non-internal) bug fixes. > > > 2. Highlighting significant changes. > > > > > > Some example bug fixes to include: > > > - TableView, ListView: unexpected scrolling behaviour on up/down keys > > > - DragAndDrop no longer works with GTK3 > > > - Window order is not correct when Modality.WINDOW_MODAL > > > > > > Don't include: > > > - [WebView] Sub-resource integrity check fails on Windows and Linux > > > - javafx.web build fails on XCode 10.2 > > > - Cherry pick GTK WebKit ___ changes > > > > > > Enhancements to include: > > > - Add support for e-paper displays > > > - Add exclusion scope for LightBase > > > - Point2D and Point3D should implement Interpolatable > > > > > > Don't include: > > > - Color, Point2D and Point3D's fields should be made final > > > > > > Thoughts? > > > > > > - Nir > > > > > > [1] > > > > > > https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x > > > > > > > > > From kevin.rushforth at oracle.com Sat Aug 29 15:24:38 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 29 Aug 2020 08:24:38 -0700 Subject: Release notes presentation In-Reply-To: References: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> Message-ID: <2e703d78-6633-e9a0-e336-0d3ef03ec11f@oracle.com> I also like having both. We did something like this for JavaFX 11: https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-11.md with sections for "Important Changes", "New Features", "Known Issues", etc., and the list of fixes and enhancements at the end. We haven't done this for subsequent releases, but it seems worth doing, either on openjfx.io or in the release notes in the repo. -- Kevin On 8/29/2020 8:02 AM, Johan Vos wrote: > Hi Nir, > > I am very ok with that. I think we somehow need both. Currently, the > release notes that are also in the repository are a dry summary of the bug > fixes/features that have been added in this release. They are a 1-1 > translation of the issues in JBS that are fixed in the given release. I > think that is good to have, as it allows for an easy lookup of what feature > was in which release. > > Apart from that, I'm often asked what the "key features" are for a specific > release. That is of course very subjective, but from a marketing point, or > even for developers, it makes sense to have those release notes as well. I > don't think those should go in the github repo, but they can definitely go > on openjfx.io. > > Those "friendly" release notes will always be subjective, but I don't see > big problems with that. In case of doubt, the "official" (dry) release > notes are objective. > > - Johan > > On Sat, Aug 29, 2020 at 4:32 PM Nir Lisker wrote: > >> Reviving this, the JDK has a page for release notes [1] that makes it >> easier for the developer to be updated on the changes. I think that we can >> do something similar. >> >> [1] https://www.oracle.com/java/technologies/javase/14-relnote-issues.html >> >> On Mon, Mar 9, 2020 at 2:56 PM Jeanette Winzenburg < >> fastegal at swingempire.de> >> wrote: >> >>> agree with better highlighting of the important changes/issues >>> disagree with leaving out the not so important - that's in the eye of >>> the reader, anyway - changes/issues: after all, the target readership >>> are technicians, not suits :) >>> >>> -- Jeanette >>> >>> Zitat von Nir Lisker : >>> >>>> Hi, >>>> >>>> I posted the release notes for OpenJFX 14 on Reddit. The top comment >> [1] >>>> complained about the presentation. Maybe on openjfx.io the Release >> Notes >>>> link could show a more "friendly" summary with a link to the detailed >>>> table. I suggest: >>>> >>>> 1. Including only changes that matter to the users of the library with >>>> separate sections for new API and for (non-internal) bug fixes. >>>> 2. Highlighting significant changes. >>>> >>>> Some example bug fixes to include: >>>> - TableView, ListView: unexpected scrolling behaviour on up/down keys >>>> - DragAndDrop no longer works with GTK3 >>>> - Window order is not correct when Modality.WINDOW_MODAL >>>> >>>> Don't include: >>>> - [WebView] Sub-resource integrity check fails on Windows and Linux >>>> - javafx.web build fails on XCode 10.2 >>>> - Cherry pick GTK WebKit ___ changes >>>> >>>> Enhancements to include: >>>> - Add support for e-paper displays >>>> - Add exclusion scope for LightBase >>>> - Point2D and Point3D should implement Interpolatable >>>> >>>> Don't include: >>>> - Color, Point2D and Point3D's fields should be made final >>>> >>>> Thoughts? >>>> >>>> - Nir >>>> >>>> [1] >>>> >> https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x >>> >>> >>> From nlisker at gmail.com Sat Aug 29 16:22:21 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 29 Aug 2020 19:22:21 +0300 Subject: Release notes presentation In-Reply-To: <2e703d78-6633-e9a0-e336-0d3ef03ec11f@oracle.com> References: <20200309135358.Horde.CKAp2hMc0Pf6S-M1_A0LYQ1@webmail.df.eu> <2e703d78-6633-e9a0-e336-0d3ef03ec11f@oracle.com> Message-ID: Any of those options seem fine to me. Just have the "marketable" summary link to the full table if they are not on the same page. On Sat, Aug 29, 2020 at 6:24 PM Kevin Rushforth wrote: > I also like having both. We did something like this for JavaFX 11: > > https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-11.md > > with sections for "Important Changes", "New Features", "Known Issues", > etc., and the list of fixes and enhancements at the end. > > We haven't done this for subsequent releases, but it seems worth doing, > either on openjfx.io or in the release notes in the repo. > > -- Kevin > > On 8/29/2020 8:02 AM, Johan Vos wrote: > > Hi Nir, > > > > I am very ok with that. I think we somehow need both. Currently, the > > release notes that are also in the repository are a dry summary of the > bug > > fixes/features that have been added in this release. They are a 1-1 > > translation of the issues in JBS that are fixed in the given release. I > > think that is good to have, as it allows for an easy lookup of what > feature > > was in which release. > > > > Apart from that, I'm often asked what the "key features" are for a > specific > > release. That is of course very subjective, but from a marketing point, > or > > even for developers, it makes sense to have those release notes as well. > I > > don't think those should go in the github repo, but they can definitely > go > > on openjfx.io. > > > > Those "friendly" release notes will always be subjective, but I don't see > > big problems with that. In case of doubt, the "official" (dry) release > > notes are objective. > > > > - Johan > > > > On Sat, Aug 29, 2020 at 4:32 PM Nir Lisker wrote: > > > >> Reviving this, the JDK has a page for release notes [1] that makes it > >> easier for the developer to be updated on the changes. I think that we > can > >> do something similar. > >> > >> [1] > https://www.oracle.com/java/technologies/javase/14-relnote-issues.html > >> > >> On Mon, Mar 9, 2020 at 2:56 PM Jeanette Winzenburg < > >> fastegal at swingempire.de> > >> wrote: > >> > >>> agree with better highlighting of the important changes/issues > >>> disagree with leaving out the not so important - that's in the eye of > >>> the reader, anyway - changes/issues: after all, the target readership > >>> are technicians, not suits :) > >>> > >>> -- Jeanette > >>> > >>> Zitat von Nir Lisker : > >>> > >>>> Hi, > >>>> > >>>> I posted the release notes for OpenJFX 14 on Reddit. The top comment > >> [1] > >>>> complained about the presentation. Maybe on openjfx.io the Release > >> Notes > >>>> link could show a more "friendly" summary with a link to the detailed > >>>> table. I suggest: > >>>> > >>>> 1. Including only changes that matter to the users of the library with > >>>> separate sections for new API and for (non-internal) bug fixes. > >>>> 2. Highlighting significant changes. > >>>> > >>>> Some example bug fixes to include: > >>>> - TableView, ListView: unexpected scrolling behaviour on up/down keys > >>>> - DragAndDrop no longer works with GTK3 > >>>> - Window order is not correct when Modality.WINDOW_MODAL > >>>> > >>>> Don't include: > >>>> - [WebView] Sub-resource integrity check fails on Windows and Linux > >>>> - javafx.web build fails on XCode 10.2 > >>>> - Cherry pick GTK WebKit ___ changes > >>>> > >>>> Enhancements to include: > >>>> - Add support for e-paper displays > >>>> - Add exclusion scope for LightBase > >>>> - Point2D and Point3D should implement Interpolatable > >>>> > >>>> Don't include: > >>>> - Color, Point2D and Point3D's fields should be made final > >>>> > >>>> Thoughts? > >>>> > >>>> - Nir > >>>> > >>>> [1] > >>>> > >> > https://www.reddit.com/r/java/comments/fegcv9/release_notes_for_javafx_14/fjphqfn?utm_source=share&utm_medium=web2x > >>> > >>> > >>> > > From fastegal at openjdk.java.net Sun Aug 30 13:23:05 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 30 Aug 2020 13:23:05 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v2] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: On Thu, 27 Aug 2020 06:37:53 GMT, yosbits wrote: >> 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 >> >> * Constructor creates multiple cell nodes, but the >> Fixed a wasteful problem of creating all cells and deleting out-of-display cells because the fixedCellSize attribute >> was not initialized in the constructor.. >> * Reduce the load on ExpressionHelper.removeListener by removing cells outside of the display range from the back of the >> scrolling operation. > > When setting the cell height to a fixed value with setFixedCellSize(), column virtualization can improve performance. > > As the next step, I think it is possible to try to enable column virtualization regardless of whether > setFixedCellSize() is set or not. Before doing this step, the direct access validation of the internal structure of the > test code needs to be changed via the public API. this indeed improves scrolling performance considerably (from extremely lagging to smooth following the mouse when dragging the thumb of the vertical scrollbar). As a side-effect, start-up time of TreeTableView seems to increase considerably (at least by a factor of 3 to 4, probably not linear in # of columns) - see f.i. the [example in JDK-8166956](https://bugs.openjdk.java.net/browse/JDK-8166956). Any idea why that might happen? ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Sun Aug 30 16:15:39 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 30 Aug 2020 16:15:39 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec Message-ID: Moving implementation details about lazy evaluation and equality checking to `@implSpec`. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/292/files Webrev: https://webrevs.openjdk.java.net/jfx/292/00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252546 Stats: 12 lines in 1 file changed: 6 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/292/head:pull/292 PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at openjdk.java.net Sun Aug 30 16:19:17 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 30 Aug 2020 16:19:17 GMT Subject: RFR: 8252546: Move ObservableValue's equality check and lazy evaluation descriptions to @implSpec In-Reply-To: References: Message-ID: On Sun, 30 Aug 2020 16:09:14 GMT, Nir Lisker wrote: > Moving implementation details about lazy evaluation and equality checking to `@implSpec`. Once we settle on the docs I'll create the CSR. ------------- PR: https://git.openjdk.java.net/jfx/pull/292 From nlisker at gmail.com Sun Aug 30 16:59:16 2020 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 30 Aug 2020 19:59:16 +0300 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> Message-ID: I didn't review these in detail, except for #1, which I think is worth it regardless, as it encompasses many more cases. If the authors of these can provide before and after benchmarks, we could also test what combinations of them are relevant. If we do #1, maybe others won't improve performance much. On Thu, Aug 27, 2020 at 3:18 AM Kevin Rushforth wrote: > Sorry for the badly formatted html. Here it is again. > > I see some progress being made on the {Tree}TableView performance issue. > To summarize where I think we are: > > There are currently 2 different approaches under review: > > 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base > to make removing listeners faster > 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView > to reduce the number of add / removes > > In addition, the following is a WIP PR that the author thinks could be a > 3rd approach: > > 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph > to avoid install treeShowing listeners on Window and Scene for all nodes > > Jose has proposed a 4th approach as a comment to PR #108, and as I > understand it, he will propose a PR shortly. > > 4. Don't clear the list of children in a VirtualFlow when the number of > items changes. > > So the first thing that is needed is to evaluate the approaches and > decide which one to pursue. > > Options 1 and 3 are more broad in their scope, option #2 is more > targeted (to TableView), but within that area is a larger change. Option > #3 would remove the (internal) treeShowing property as a generally > available concept and only use it for controls like ProgressIndicator > that really need it. Option #4 affects only controls that use > VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a > large change (presuming we can verify that no leak is introduced). > > I note that these fixes are not mutually exclusive, but I do think we > need to settle on a primary approach and use that to fix this issue. If > there are still performance problems after that fix, we can consider one > (or more) of the others. > > Comments? > > -- Kevin > > From andrea.vacondio at gmail.com Mon Aug 31 08:06:24 2020 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Mon, 31 Aug 2020 10:06:24 +0200 Subject: java.lang.UnsatisfiedLinkError Message-ID: Hi, we have a user reporting this: PDFsam does not start on my computer (Win10), and the problem was easy to detect: It uses my home directory but with no international characters. Here is an excerpt from running the bat script: Loading library api-ms-win-core-console-l1-1-0 from resource failed: java.lang.UnsatisfiedLinkError: C:\Users\HkanLyngsj\.openjfx\cache\14.0.2\api-ms-win-core-console-l1-1-0.dll: Can't find dependent libraries java.lang.UnsatisfiedLinkError: C:\Users\HkanLyngsj\.openjfx\cache\14.0.2\api-ms-win-core-console-l1-1-0.dll: Can't find dependent libraries Needless to say, my home directory is: C:\Users\H??kanLyngsj??> We have a gazillion installations and no one reported this so it seems unlikely the issue is related to username characters. The application runs with a bundled jdk 11.0.8. I couldn't find anything similar in the https://bugs.openjdk.java.net Any idea? Thanks Andrea From org.openjdk at io7m.com Mon Aug 31 11:46:48 2020 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 31 Aug 2020 11:46:48 +0000 Subject: MediaException with trivial javafx-media example Message-ID: <20200831114648.39f3be00@sunflower.int.arc7.info> Hello! I thought I'd give javafx-media a shot, as I'd never tried it before and was curious as to what it was capable of. Unfortunately, it seems that the most trivial possible example fails on Arch Linux. The symptom is that attempting to create a Media player yields the following exception(s): Caused by: javafx.fxml.LoadException: /home/rm/doc/misc/2020/08/media_example/target/classes/com/io7m/media_example/mediaExample.fxml at javafx.fxml/javafx.fxml.FXMLLoader.constructLoadException(FXMLLoader.java:2625) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2603) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2466) at javafx.fxml/javafx.fxml.FXMLLoader.load(FXMLLoader.java:2435) at com.io7m.jbox/com.io7m.media_example.MainApplication.start(MainApplication.java:43) at com.io7m.jbox/com.io7m.media_example.Main.lambda$main$0(Main.java:36) ... 8 more Caused by: MediaException: UNKNOWN : com.sun.media.jfxmedia.MediaException: Could not create player! : com.sun.media.jfxmedia.MediaException: Could not create player! at javafx.media/javafx.scene.media.MediaException.exceptionToMediaException(MediaException.java:146) at javafx.media/javafx.scene.media.MediaPlayer.init(MediaPlayer.java:518) at javafx.media/javafx.scene.media.MediaPlayer.(MediaPlayer.java:421) at com.io7m.jbox/com.io7m.media_example.MainController.initialize(MainController.java:57) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2573) ... 12 more Caused by: com.sun.media.jfxmedia.MediaException: Could not create player! at javafx.media/com.sun.media.jfxmediaimpl.NativeMediaManager.getPlayer(NativeMediaManager.java:295) at javafx.media/com.sun.media.jfxmedia.MediaManager.getPlayer(MediaManager.java:118) at javafx.media/javafx.scene.media.MediaPlayer.init(MediaPlayer.java:474) ... 15 more The example code is here, just run the com.io7m.media_example.Main program: https://github.com/io7m/media_example_20200831 All the program does is unpack an included royalty-free H.264 MP4 file into a temporary directory and attempts to play it in a 128x128 window. I've traced the execution to this line in GSTMediaPlayer.java: int rc = gstInitPlayer(gstMedia.getNativeMediaRef()); if (0 != rc) { dispose(); throwMediaErrorException(rc, null); } It appears that gstMedia.getNativeMediaRef() returns 0L, and rc == 257 after the call. This results in the given MediaException. I don't think I'm misusing the API, so I'm guessing that this is some kind of system incompatibility. I've seen similar reports online, but those appeared to be down to using a raw filesystem path as the media source rather than a URI, but that's not the case here. $ uname -a Linux sunflower.int.arc7.info 5.8.4-arch1-1 #1 SMP PREEMPT Wed, 26 Aug 2020 18:35:43 +0000 x86_64 GNU/Linux $ java -version openjdk version "14.0.2" 2020-07-14 OpenJDK Runtime Environment (build 14.0.2+12) OpenJDK 64-Bit Server VM (build 14.0.2+12, mixed mode) Any assistance would be appreciated! -- Mark Raynsford | https://www.io7m.com From bchoudhary at openjdk.java.net Mon Aug 31 12:15:38 2020 From: bchoudhary at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 31 Aug 2020 12:15:38 GMT Subject: RFR: 8218973: SVG with masking is not rendering image with mask effect [v9] In-Reply-To: References: Message-ID: > Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking > doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() > in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in > WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface > otherwise use usual way of rendering. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Added unit tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/213/files - new: https://git.openjdk.java.net/jfx/pull/213/files/b1299ba1..41f64c0e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=213&range=07-08 Stats: 72 lines in 1 file changed: 71 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/213.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/213/head:pull/213 PR: https://git.openjdk.java.net/jfx/pull/213 From johan.vos at gluonhq.com Mon Aug 31 12:21:24 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 31 Aug 2020 14:21:24 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> Message-ID: It looks like those PR's are fixing different issues, and are mainly complimentary. I think the challenge here is that issues like "bad performance" are very generic and related to very specific use cases. Hence, I think it would help to create more narrowed issues with a test that quantitatively indicates there is a difference before/after applying the PR. The difficulty of course is in the fact that a enhancement for a specific case may cause regression for other cases. - Johan On Sun, Aug 30, 2020 at 7:02 PM Nir Lisker wrote: > I didn't review these in detail, except for #1, which I think is worth it > regardless, as it encompasses many more cases. > > If the authors of these can provide before and after benchmarks, we could > also test what combinations of them are relevant. If we do #1, maybe others > won't improve performance much. > > On Thu, Aug 27, 2020 at 3:18 AM Kevin Rushforth < > kevin.rushforth at oracle.com> > wrote: > > > Sorry for the badly formatted html. Here it is again. > > > > I see some progress being made on the {Tree}TableView performance issue. > > To summarize where I think we are: > > > > There are currently 2 different approaches under review: > > > > 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base > > to make removing listeners faster > > 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView > > to reduce the number of add / removes > > > > In addition, the following is a WIP PR that the author thinks could be a > > 3rd approach: > > > > 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph > > to avoid install treeShowing listeners on Window and Scene for all nodes > > > > Jose has proposed a 4th approach as a comment to PR #108, and as I > > understand it, he will propose a PR shortly. > > > > 4. Don't clear the list of children in a VirtualFlow when the number of > > items changes. > > > > So the first thing that is needed is to evaluate the approaches and > > decide which one to pursue. > > > > Options 1 and 3 are more broad in their scope, option #2 is more > > targeted (to TableView), but within that area is a larger change. Option > > #3 would remove the (internal) treeShowing property as a generally > > available concept and only use it for controls like ProgressIndicator > > that really need it. Option #4 affects only controls that use > > VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a > > large change (presuming we can verify that no leak is introduced). > > > > I note that these fixes are not mutually exclusive, but I do think we > > need to settle on a primary approach and use that to fix this issue. If > > there are still performance problems after that fix, we can consider one > > (or more) of the others. > > > > Comments? > > > > -- Kevin > > > > > From fastegal at swingempire.de Mon Aug 31 14:54:49 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 31 Aug 2020 16:54:49 +0200 Subject: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView In-Reply-To: <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> References: <6b1c4cd9-5fa8-e33a-c127-234dfc589319@oracle.com> <971ad5ea-3083-b7f6-1932-c97eef0be1a2@oracle.com> Message-ID: <20200831165449.Horde.Fkl1SwnK8dgnw6hBJcgdvQ3@webmail.df.eu> Looking at the examples provided in 108/125: apart from both having many columns (> 300 makes them really nasty) they differ in Table content: 125 - static data 108 - items are frequently modified (added) Perceived performance: 125 - vertical scrolling: thumb/content lags behind mouse 108 - with enough columns, all interaction is sluggish (mouse, keys, ..), scrolling being just one of them Both have examples, running those against the suggested fixes (with 108a for Jose's approach) 125 - fixes its own example, does nothing for the other 108, 108a, 185 - improves its own example, does nothing for other So we seem to have multiple issues that are (mostly) orthogonal: one being the broken/missing horizontal virtualization (125), the other related to dynamic update of table content (108, 108a, 185). We need to solve both, the solution/s for one looks (mostly?) unrelated to the solution to the other. 125 is the only one PR for its use-case, and it seems to do its job. From those targeting the dynamic data update all except Jose's (not yet formalized into a PR) approach feel too broad: table's reaction to items modifications is .. suboptimal in more than one aspect. Changing overall notification implementation to improve that, sounds like covering it up. -- Jeanette Zitat von Kevin Rushforth : > Sorry for the badly formatted html. Here it is again. > > I see some progress being made on the {Tree}TableView performance > issue. To summarize where I think we are: > > There are currently 2 different approaches under review: > > 1. https://github.com/openjdk/jfx/pull/108 : optimization in > javafx.base to make removing listeners faster > 2. https://github.com/openjdk/jfx/pull/125 : optimization in > TableView to reduce the number of add / removes > > In addition, the following is a WIP PR that the author thinks could > be a 3rd approach: > > 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene > graph to avoid install treeShowing listeners on Window and Scene for > all nodes > > Jose has proposed a 4th approach as a comment to PR #108, and as I > understand it, he will propose a PR shortly. > > 4. Don't clear the list of children in a VirtualFlow when the number > of items changes. > > So the first thing that is needed is to evaluate the approaches and > decide which one to pursue. > > Options 1 and 3 are more broad in their scope, option #2 is more > targeted (to TableView), but within that area is a larger change. > Option #3 would remove the (internal) treeShowing property as a > generally available concept and only use it for controls like > ProgressIndicator that really need it. Option #4 affects only > controls that use VirtualFlow (ListView, TableVIew, TreeTableView), > and seems not to be a large change (presuming we can verify that no > leak is introduced). > > I note that these fixes are not mutually exclusive, but I do think > we need to settle on a primary approach and use that to fix this > issue. If there are still performance problems after that fix, we > can consider one (or more) of the others. > > Comments? > > -- Kevin From github.com+7517141+yososs at openjdk.java.net Mon Aug 31 18:45:26 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 31 Aug 2020 18:45:26 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v3] In-Reply-To: References: Message-ID: > If there are many columns, the current TableView will stall scrolling. Resolving this performance issue requires column > virtualization. Virtualization mode is enabled when the row height is fixed by the following method. > `tableView.setFixedCellSize(height)` > > This proposal includes a fix because the current code does not correctly implement column virtualization. > > The improvement of this proposal can be seen in the following test program. > > Java > import java.util.Arrays; > import java.util.Collections; > > import javafx.animation.AnimationTimer; > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.stage.Stage; > > public class BigTableViewTest2 extends Application { > private static final boolean USE_WIDTH_FIXED_SIZE = false; > private static final boolean USE_HEIGHT_FIXED_SIZE = true; > // private static final int COL_COUNT=30; > // private static final int COL_COUNT=300; > // private static final int COL_COUNT=600; > private static final int COL_COUNT = 1000; > private static final int ROW_COUNT = 1000; > > @Override > public void start(final Stage primaryStage) throws Exception { > final TableView tableView = new TableView<>(); > > // tableView.setTableMenuButtonVisible(true); //too heavy > if (USE_HEIGHT_FIXED_SIZE) { > tableView.setFixedCellSize(24); > } > > final ObservableList> columns = tableView.getColumns(); > for (int i = 0; i < COL_COUNT; i++) { > final TableColumn column = new TableColumn<>("Col" + i); > final int colIndex = i; > column.setCellValueFactory((cell) -> new SimpleStringProperty(cell.getValue()[colIndex])); > columns.add(column); > if (USE_WIDTH_FIXED_SIZE) { > column.setPrefWidth(60); > column.setMaxWidth(60); > column.setMinWidth(60); > } > } > > final Button load = new Button("load"); > load.setOnAction(e -> { > final ObservableList items = tableView.getItems(); > items.clear(); > for (int i = 0; i < ROW_COUNT; i++) { > final String[] rec = new String[COL_COUNT]; > for (int j = 0; j < rec.length; j++) { > rec[j] = i + ":" + j; > } > items.add(rec); > } > }); > > final Button reverse = new Button("reverse columns"); > reverse.setOnAction(e -> { > final TableColumn[] itemsArray = columns.toArray(new TableColumn[0]); > Collections.reverse(Arrays.asList(itemsArray)); > tableView.getColumns().clear(); > tableView.getColumns().addAll(Arrays.asList(itemsArray)); > }); > > final Button hide = new Button("hide % 10"); > hide.setOnAction(e -> { > for (int i = 0, n = columns.size(); i < n; i++) { > if (i % 10 == 0) { > columns.get(i).setVisible(false); > } > } > }); > > final BorderPane root = new BorderPane(tableView); > root.setTop(new HBox(8, load, reverse, hide)); > > final Scene scene = new Scene(root, 800, 800); > primaryStage.setScene(scene); > primaryStage.show(); > this.prepareTimeline(scene); > } > > public static void main(final String[] args) { > Application.launch(args); > } > > private void prepareTimeline(final Scene scene) { > new AnimationTimer() { > @Override > public void handle(final long now) { > final double fps = com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS(); > ((Stage) scene.getWindow()).setTitle("FPS:" + (int) fps); > } > }.start(); > } > } yosbits 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: - 8185886: Fix scroll performance of TableView with many columns - 8185886: Fix scroll performance of TableView with many columns ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/125/files - new: https://git.openjdk.java.net/jfx/pull/125/files/19fabf2e..dcbbfdcd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=125&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=125&range=01-02 Stats: 429339 lines in 6107 files changed: 215276 ins; 144670 del; 69393 mod Patch: https://git.openjdk.java.net/jfx/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/125/head:pull/125 PR: https://git.openjdk.java.net/jfx/pull/125 From kcr at openjdk.java.net Mon Aug 31 19:11:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 31 Aug 2020 19:11:40 GMT Subject: RFR: 8202990: javafx webview css filter property with display scaling In-Reply-To: References: Message-ID: On Sat, 29 Aug 2020 00:31:51 GMT, Kevin Rushforth wrote: >> The fix and test looks good. > > I spent some time this afternoon going over the fix in more detail and doing extensive testing on both Windows and Mac. > > I believe the fix is good. Both by inspection and by instrumenting the code, there are no race conditions or other > problems that I can see. > The problem appears to be in the test, or else somewhere in the test harness or the SW pipeline exposed by the test. If > I run the new CSSTest in a loop on either Mac or Windows, it will crash intermittently. I then reverted your fix, > running the new test (which will throw an expected assertion error), and it still crashes intermittently. My > recommendation is to use a system test, similar to what > [SVGTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/SVGTest.java) > does, rather than a unit test in the javafx.web module, which uses `WebPage::paint`. I believe that the problem noted above is with the test harness, specifically the `WebPageShim::paint` method. I filed [JDK-8252596](https://bugs.openjdk.java.net/browse/JDK-8252596) to track fixing the tests. So the fix for _this_ PR should avoid using it, as suggested above. ------------- PR: https://git.openjdk.java.net/jfx/pull/279 From github.com+7517141+yososs at openjdk.java.net Mon Aug 31 19:18:49 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Mon, 31 Aug 2020 19:18:49 GMT Subject: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v3] In-Reply-To: References: <0sKlpjJk315cxrXr1o1ALhT1nw40VfXofrU7ykmyi_k=.7a4495c5-e5be-470a-836f-20b33c50768b@github.com> Message-ID: <5-VqBYoaKyIjfWPt4PN7C2Z417j3gVvpFSDPFo18p-U=.f2b2ce0c-1c55-48ad-9330-aa2860702b48@github.com> On Sun, 30 Aug 2020 13:20:49 GMT, Jeanette Winzenburg wrote: >> When setting the cell height to a fixed value with setFixedCellSize(), column virtualization can improve performance. >> >> As the next step, I think it is possible to try to enable column virtualization regardless of whether >> setFixedCellSize() is set or not. Before doing this step, the direct access validation of the internal structure of the >> test code needs to be changed via the public API. > > this indeed improves scrolling performance considerably (from extremely lagging to smooth following the mouse when > dragging the thumb of the vertical scrollbar). > As a side-effect, start-up time of TreeTableView seems to increase considerably (at least by a factor of 3 to 4, > probably not linear in # of columns) - see f.i. the [example in > JDK-8166956](https://bugs.openjdk.java.net/browse/JDK-8166956). Any idea why that might happen? Since there was a problem that the cell was not updated when the window was maximized, I added a fix to TreeTableViewSkin.java. Added test code (BigTreeTableViewTest) for TreeTableView to the first post. @kleopatra Does the test code I added (BigTreeTableViewTest.java) also have side effects? ------------- PR: https://git.openjdk.java.net/jfx/pull/125 From nlisker at openjdk.java.net Mon Aug 31 23:37:31 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 31 Aug 2020 23:37:31 GMT Subject: RFR: 8252547: Correct transformations docs in Node Message-ID: Correction to the order of transforms specified in the docs of `Node`. ------------- Commit messages: - Remove whitespace - Remove whitespace - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/293/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=293&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252547 Stats: 37 lines in 1 file changed: 13 ins; 12 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/293/head:pull/293 PR: https://git.openjdk.java.net/jfx/pull/293