RFR: 8242548: Honor line spacing in Labeled reflow calculation
This is a solution for 8242548. There was zero test coverage, so I added a few tests for this as well. - Commit messages: - 8242548: Honor line spacing in Labeled reflow calculation Changes: https://git.openjdk.java.net/jfx/pull/173/files Webrev: https://webrevs.openjdk.java.net/jfx/173/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242548 Stats: 44 lines in 4 files changed: 40 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/173.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/173/head:pull/173 PR: https://git.openjdk.java.net/jfx/pull/173
RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
Extract keystate and add to the existing modifier mask, to support eg multi-select https://bugs.openjdk.java.net/browse/JDK-8202296 - Commit messages: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Changes: https://git.openjdk.java.net/jfx/pull/170/files Webrev: https://webrevs.openjdk.java.net/jfx/170/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202296 Stats: 20 lines in 1 file changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170
Re: Testing JavaFX with Java14 preview features
It contains: -source 14 -target 14 Looks like I'll have to do some digging. Thanks On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth wrote: > Not sure, but you might check here: > > modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt > > That's the list of args that gradle generates to pass to javac (using > @.../java-compiler-args.txt) > > -- Kevin > > On 4/13/2020 4:10 PM, Nir Lisker wrote: > > Thanks, yes, testing on JavaFX itself. > I made these changes. I'm getting "error: invalid source release: 14" when > trying to build. These are the settings that are output during the task: > > Gradle Distribution: Gradle wrapper from target build > Gradle Version: 6.3 > Java Home: C:\Program Files\Java\jdk-14 > JVM Arguments: None > Program Arguments: None > Build Scans Enabled: false > Offline Mode Enabled: false > Gradle Tasks: build > > This is the full error message: > > error: invalid source release: 14 > Usage: javac > use --help for a list of possible options > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':base:compileJava'. > > Compilation failed with exit code 2; see the compiler error output for > details. > > On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> I guess you mean modifying the FX build in your local repo so that you >> can test the use of JDK 14 preview features in FX itself? (if you were >> just trying to use it from your app you wouldn't need any build changes >> in FX). At a minimum you would need to add the "--enable-preview" flag >> to compile.options.compilerArgs, and change "sourceCompatibility" from >> "11" to "14". Not sure if anything more is needed. I've never tried it. >> >> -- Kevin >> >> >> On 4/13/2020 1:49 PM, Nir Lisker wrote: >> > Hi, >> > >> > I would like to test the preview features in Java 14 on JavaFX. What >> > changes should I make in the build files to get it working? >> > >> > - Nir >> >> >
Re: RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina
On Mon, 13 Apr 2020 23:07:12 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8241629 > > We used to link with system provided libffi (due to a bug in Makefile) and > for some reason GLib signals did not work > correctly and thus we did not able to build dynamic pipelines. We did not > switch to AVFoundation until timeout is > reached while waiting for GStreamer to start playing or report us an error. > Fixed by linking GLib with libffi which we > build, like we do for other platforms. Looks good. I tested it on both 10.15.x (Catalina) and 10.13.x (High Sierra). I confirm that there is no more dependency on the system libffi. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/179
RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina
https://bugs.openjdk.java.net/browse/JDK-8241629 We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we build, like we do for other platforms. - Commit messages: - 8241629: [macos10.15] Long startup delay playing media over https on Catalina Changes: https://git.openjdk.java.net/jfx/pull/179/files Webrev: https://webrevs.openjdk.java.net/jfx/179/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241629 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/179.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/179/head:pull/179 PR: https://git.openjdk.java.net/jfx/pull/179
Re: Testing JavaFX with Java14 preview features
Not sure, but you might check here: modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt That's the list of args that gradle generates to pass to javac (using @.../java-compiler-args.txt) -- Kevin On 4/13/2020 4:10 PM, Nir Lisker wrote: Thanks, yes, testing on JavaFX itself. I made these changes. I'm getting "error: invalid source release: 14" when trying to build. These are the settings that are output during the task: Gradle Distribution: Gradle wrapper from target build Gradle Version: 6.3 Java Home: C:\Program Files\Java\jdk-14 JVM Arguments: None Program Arguments: None Build Scans Enabled: false Offline Mode Enabled: false Gradle Tasks: build This is the full error message: error: invalid source release: 14 Usage: javac use --help for a list of possible options FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':base:compileJava'. > Compilation failed with exit code 2; see the compiler error output for details. On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth mailto:kevin.rushfo...@oracle.com>> wrote: I guess you mean modifying the FX build in your local repo so that you can test the use of JDK 14 preview features in FX itself? (if you were just trying to use it from your app you wouldn't need any build changes in FX). At a minimum you would need to add the "--enable-preview" flag to compile.options.compilerArgs, and change "sourceCompatibility" from "11" to "14". Not sure if anything more is needed. I've never tried it. -- Kevin On 4/13/2020 1:49 PM, Nir Lisker wrote: > Hi, > > I would like to test the preview features in Java 14 on JavaFX. What > changes should I make in the build files to get it working? > > - Nir
Re: Testing JavaFX with Java14 preview features
Thanks, yes, testing on JavaFX itself. I made these changes. I'm getting "error: invalid source release: 14" when trying to build. These are the settings that are output during the task: Gradle Distribution: Gradle wrapper from target build Gradle Version: 6.3 Java Home: C:\Program Files\Java\jdk-14 JVM Arguments: None Program Arguments: None Build Scans Enabled: false Offline Mode Enabled: false Gradle Tasks: build This is the full error message: error: invalid source release: 14 Usage: javac use --help for a list of possible options FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':base:compileJava'. > Compilation failed with exit code 2; see the compiler error output for details. On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth wrote: > I guess you mean modifying the FX build in your local repo so that you > can test the use of JDK 14 preview features in FX itself? (if you were > just trying to use it from your app you wouldn't need any build changes > in FX). At a minimum you would need to add the "--enable-preview" flag > to compile.options.compilerArgs, and change "sourceCompatibility" from > "11" to "14". Not sure if anything more is needed. I've never tried it. > > -- Kevin > > > On 4/13/2020 1:49 PM, Nir Lisker wrote: > > Hi, > > > > I would like to test the preview features in Java 14 on JavaFX. What > > changes should I make in the build files to get it working? > > > > - Nir > >
Re: Testing JavaFX with Java14 preview features
I guess you mean modifying the FX build in your local repo so that you can test the use of JDK 14 preview features in FX itself? (if you were just trying to use it from your app you wouldn't need any build changes in FX). At a minimum you would need to add the "--enable-preview" flag to compile.options.compilerArgs, and change "sourceCompatibility" from "11" to "14". Not sure if anything more is needed. I've never tried it. -- Kevin On 4/13/2020 1:49 PM, Nir Lisker wrote: Hi, I would like to test the preview features in Java 14 on JavaFX. What changes should I make in the build files to get it working? - Nir
Testing JavaFX with Java14 preview features
Hi, I would like to test the preview features in Java 14 on JavaFX. What changes should I make in the build files to get it working? - Nir
Re: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes
On Sat, 11 Apr 2020 08:19:16 GMT, Johan Vos wrote: >> Marked as reviewed by kcr (Lead). > > The root cause for this issue is not the unnecessary logging, but the fact > that the Quantum Renderer keeps running when > the app is not in the foreground (causing a long list of debug lines). I'll > create a separate issue for that. It would be nice to show this debug info when javafx.pulseLogger is true, and hide it when that property is false. It shows interesting information about the rendering phase, so when that info is requested (by enabling pulseLogger), it is useful. - PR: https://git.openjdk.java.net/jfx/pull/165
Re: RFR: 8242490: Upgrade to gcc 9.2 on Linux
On Mon, 13 Apr 2020 16:12:38 GMT, Kevin Rushforth wrote: > This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc > 9.2. This will match a recent upgrade done > for JDK 15 -- see > [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). > On a related note, using the gcc 9 compiler produces many (harmless) warnings > that will be addressed by > [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR > #150. > I have run a full build and test using this new compiler. /reviewers 2 - PR: https://git.openjdk.java.net/jfx/pull/178
Re: RFR: 8242490: Upgrade to gcc 9.2 on Linux
On Mon, 13 Apr 2020 16:13:42 GMT, Kevin Rushforth wrote: >> This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc >> 9.2. This will match a recent upgrade done >> for JDK 15 -- see >> [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). >> On a related note, using the gcc 9 compiler produces many (harmless) >> warnings that will be addressed by >> [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR >> #150. >> I have run a full build and test using this new compiler. > > /reviewers 2 @arapte can you also review this? - PR: https://git.openjdk.java.net/jfx/pull/178
RFR: 8242490: Upgrade to gcc 9.2 on Linux
This is a compiler upgrade on Linux from the current gcc 8.3 compiler to gcc 9.2. This will match a recent upgrade done for JDK 15 -- see [JDK-8241721](https://bugs.openjdk.java.net/browse/JDK-8241721). On a related note, using the gcc 9 compiler produces many (harmless) warnings that will be addressed by [JDK-8241476](https://bugs.openjdk.java.net/browse/JDK-8241476) -- see PR #150. I have run a full build and test using this new compiler. - Commit messages: - 8242490: Upgrade to gcc 9.2 on Linux Changes: https://git.openjdk.java.net/jfx/pull/178/files Webrev: https://webrevs.openjdk.java.net/jfx/178/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242490 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/178.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/178/head:pull/178 PR: https://git.openjdk.java.net/jfx/pull/178
Re: RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel
On Mon, 13 Apr 2020 08:03:09 GMT, Ambarish Rapte wrote: > `TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` > which holds the `SelectionModel` from being > GCed. Fix is to add and remove the listener when a `SelectionModel` is > changed. > If the fix looks good, We can change all the > `getSkinnable().getSelectionModel()` calls to use the new class member > `selectionModel`. > The fix seems safe to cause any regression. Enabled an ignored test that was > added as part of fix for > [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). Changes requested by fastegal (Author). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 270: > 269: } > 270: > 271: super.dispose(); wondering if the removal is really needed? The memory leak seems to be fixed without explicit removing. Did you experience any side-effects if not? If so, a unit test covering that would be cool. There are other (mostly) skins that have a weak "path listener" which is not removed on dispose, they need a re-visit to see if the side-effect applies to them as well. Or the other way round: without a detectable side-effect, not doing it might be okay. Whatever the outcome, this looks like a pattern to remember when skins are listening weakly :) - PR: https://git.openjdk.java.net/jfx/pull/175
Re: [Rev 03] RFR: 8241476: Linux build warnings issued on gcc 9
On Fri, 10 Apr 2020 21:57:43 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Gstreamer build > > Looks good. @johanvos or @arapte Can one of you be the second reviewer on this? - PR: https://git.openjdk.java.net/jfx/pull/150
Re: RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection
On Mon, 13 Apr 2020 10:36:51 GMT, Jeanette Winzenburg wrote: > Macroscopic issue is that initially, the toggle is not sync'ed to the > selection state. Root reason is an missing else > block when updating toggle selection state (see report for details). > Fixed by introducing the else block and removing all follow-up errors that > tried to amend the consequences of the > incorrect selection state > - removed listener to selected item > - removed toggle selection update in showing listener > > The former also fixed the memory leak when replacing the selectionModel plus > an unreported NPE when the selectionModel > is null initially. > Added tests that failed before the fix and passed after. As there had been no > tests around toggle state, so added some > to verify that the change doesn't break. Enhanced shim/skin to allow access > to popup for testing. Removed the > informally ignored test part for memory leak. @aghaisas can you review this? - PR: https://git.openjdk.java.net/jfx/pull/177
Re: Automate copyright year?
Not that I know of. FWIW, I'm not too bothered by this, since I run a script 2-3 times a year to update the copyright years for those files fixed in the current year. -- Kevin On 4/13/2020 3:48 AM, Jeanette Winzenburg wrote: Seeing that missing to update of copyright year in the header is rather common (in my own pull requests as well as in others :) is there any means to do so automatically or some source tool (for me that would be for Eclipse) that would do on request? -- Jeanette
RFR: 8242489: ChoiceBox: initially toggle not sync'ed to selection
Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else block when updating toggle selection state (see report for details). Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the incorrect selection state - removed listener to selected item - removed toggle selection update in showing listener The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel is null initially. Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the informally ignored test part for memory leak. - Commit messages: - 8242489: ChoiceBox: initially toggle not sync'ed to selection Changes: https://git.openjdk.java.net/jfx/pull/177/files Webrev: https://webrevs.openjdk.java.net/jfx/177/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242489 Stats: 375 lines in 5 files changed: 347 ins; 25 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177 PR: https://git.openjdk.java.net/jfx/pull/177
Automate copyright year?
Seeing that missing to update of copyright year in the header is rather common (in my own pull requests as well as in others :) is there any means to do so automatically or some source tool (for me that would be for Eclipse) that would do on request? -- Jeanette
RFR: 8241737: TabPaneSkin memory leak on replacing selectionModel
`TabPaneSkin` adds a listener to `SelectionModel.selectedItemProperty()` which holds the `SelectionModel` from being GCed. Fix is to add and remove the listener when a `SelectionModel` is changed. If the fix looks good, We can change all the `getSkinnable().getSelectionModel()` calls to use the new class member `selectionModel`. The fix seems safe to cause any regression. Enabled an ignored test that was added as part of fix for [JDK-8241455](https://bugs.openjdk.java.net/browse/JDK-8241455). - Commit messages: - 8241737: TabPaneSkin memory leak on replacing selectionModel Changes: https://git.openjdk.java.net/jfx/pull/175/files Webrev: https://webrevs.openjdk.java.net/jfx/175/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241737 Stats: 36 lines in 2 files changed: 26 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/175/head:pull/175 PR: https://git.openjdk.java.net/jfx/pull/175
RFR: 8193286: IntegerSpinnerFactory does not wrap value correctly
Issue : https://bugs.openjdk.java.net/browse/JDK-8193286 Root Cause : Incorrect implementation. Current implementation of int wrapValue(int,int,int) in Spinner.java works well if min is 0. Hence this implementation works with ListSpinnerValueFactory, but fails with IntegerSpinnerValueFactory. Fix : Added a method for IntegerSpinnerValueFactory with separate implementation. Testing : Added unit tests to test increment/decrement in multiple steps and with different amountToStepBy values. Also, identified a related behavioral issue https://bugs.openjdk.java.net/browse/JDK-8242553, which will be addressed separately. - Commit messages: - IntegerSpinner_wrapAround Changes: https://git.openjdk.java.net/jfx/pull/174/files Webrev: https://webrevs.openjdk.java.net/jfx/174/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193286 Stats: 202 lines in 3 files changed: 195 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/174/head:pull/174 PR: https://git.openjdk.java.net/jfx/pull/174
