RFR: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached
Not sure why, but our finish() handle was not implemented on OSXPlatform. This handle should pause media stream when called. Also, seek should restart playback when we finish playing video. With proposed fix OSXPlatform will behave same as GSTPlatform. Stop playback when stopTime is reached and resume playback if seek is performed after EndOfMedia or stopTime is reached. - Commit messages: - 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Changes: https://git.openjdk.java.net/jfx/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=559=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268718 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/559/head:pull/559 PR: https://git.openjdk.java.net/jfx/pull/559
Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v5]
On Wed, 30 Jun 2021 22:30:47 GMT, Kevin Rushforth wrote:
>> Phil Race has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - 8223717: javafx printing: Support Specifying Print to File in the API
>> - 8223717: javafx printing: Support Specifying Print to File in the API
>> - 8223717: javafx printing: Support Specifying Print to File in the API
>
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 481:
>
>> 479: * such as Postscript or PDF, and the application intends to
>> distribute
>> 480: * the result instead of printing it, or for some other reason the
>> 481: * application does not want physical media (paper) emitted by the
>> printer.
>
> Very minor: maybe consider combining the first three paragraphs into a single
> paragraph?
well .. I usually like a short paragraph that succinctly says what it does as
the first paragraph
Anyway I've re-read all this and I prefer it as it is.
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 486:
>
>> 484: * equivalent to null, which means output is sent to the printer.
>> 485: * So in order to reset to print to the printer, clear the value of
>> 486: * this property by setting it to null or an empty string.
>
> This doesn't flow as well as it could. I think you only need to mention once
> that `null` is the same as an empty string, and then you can just say "empty
> string". Maybe something like this?
>
>
> The default value is an empty string, which means output is sent to the
> printer. So in order to reset
> to print to the printer, clear the value of this property by setting it to an
> empty string. A value
> of {@code null} is treated as an empty string.
But I don't say it twice. I say
> The default value is an empty string, which is interpreted as unset,
> equivalent to null,
and
> clear the value of this property by setting it to null or an empty string.
which is somewhat different and makes i t very clear that either will work ..
So I think this is all fine and flows as intended.
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 489:
>
>> 487: *
>> 488: * Additionally if the application displays a printer dialog which
>> allows
>> 489: * the user to specify a file destination including altering an
>> application
>
> Minor: I think there should be a comma between `destination` and `including`.
yep
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 491:
>
>> 489: * the user to specify a file destination including altering an
>> application
>> 490: * specified file destination, the value of this property will
>> reflect that
>> 491: * user-specified choice, including clearing it to re-set to print
>> to
>
> `reset` is one word (no need to hyphenate).
it is reset elsewhere not sure why a hyphen is here.
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 500:
>
>> 498: * a user writable file, when printing the results are
>> platform-dependent, including
>> 499: * replacement with a default output file location, printing to the
>> printer instead,
>> 500: * or a platform printing error.
>
> This sentence is a bit awkward and hard to parse. Maybe break it into two
> sentences? Perhaps something like this:
>
>
> If the specified name specifies a non-existent path, or does not specify a
> user writable file, the
> results when printing are platform-dependent. Possible behavior might include
> replacement with
> a default output file location, printing to the printer instead, or a
> platform printing error.
ok split it
-
PR: https://git.openjdk.java.net/jfx/pull/543
Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v5]
On Thu, 1 Jul 2021 00:15:13 GMT, Phil Race wrote:
>> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 481:
>>
>>> 479: * such as Postscript or PDF, and the application intends to
>>> distribute
>>> 480: * the result instead of printing it, or for some other reason the
>>> 481: * application does not want physical media (paper) emitted by the
>>> printer.
>>
>> Very minor: maybe consider combining the first three paragraphs into a
>> single paragraph?
>
> well .. I usually like a short paragraph that succinctly says what it does as
> the first paragraph
>
> Anyway I've re-read all this and I prefer it as it is.
ok
>> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 486:
>>
>>> 484: * equivalent to null, which means output is sent to the printer.
>>> 485: * So in order to reset to print to the printer, clear the value of
>>> 486: * this property by setting it to null or an empty string.
>>
>> This doesn't flow as well as it could. I think you only need to mention once
>> that `null` is the same as an empty string, and then you can just say "empty
>> string". Maybe something like this?
>>
>>
>> The default value is an empty string, which means output is sent to the
>> printer. So in order to reset
>> to print to the printer, clear the value of this property by setting it to
>> an empty string. A value
>> of {@code null} is treated as an empty string.
>
> But I don't say it twice. I say
>> The default value is an empty string, which is interpreted as unset,
>> equivalent to null,
>
> and
>> clear the value of this property by setting it to null or an empty string.
>
> which is somewhat different and makes i t very clear that either will work ..
>
> So I think this is all fine and flows as intended.
ok
-
PR: https://git.openjdk.java.net/jfx/pull/543
Button label text garbled - OS/X Catalina
I was looking at some JavaFX introductions. HelloWorld type things. In this case literally… https://docs.oracle.com/javafx/2/get_started/hello_world.htm The button labels show garbled text. Googling shows a number of similar examples. I found one issue indicating something very similar showing as resolved. https://bugs.openjdk.java.net/browse/JDK-8234916 If you try to setFont you get about the same messages like… java -cp . --module-path ~/Documents/javafx-sdk-11.0-2.2/lib --add-modules javafx.base,javafx.controls helloworld.HelloWorld 2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. 2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug. 2021-06-30 17:52:22.792 java[4142:207281] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. 2021-06-30 17:52:22.896 java[4142:207311] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:]. Hello World! Should I open an issue on this someplace or is it still open somewhere? Or is there something I should do different to avoid it?
Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v6]
> This enhancement adds the String property outputFileProperty() to the > JobSettings class. > The value should be a string that references a local file encoded as a URL. > If this is non-null and set to a location that the user has permission to > write to, > then the printer output will be spooled there instead of the printer, so long > as the platform printing system supports this. > The user can of course also set a print-to-file destination in the platform > printer dialogs which may over-ride what the application set. But now the > application can also see what it was set to, and cancel or alter it if > necessary. > > A simple manual test is provided, manual mainly because the few real printing > functional tests are all manual as they are only useful if run with a printer > configured. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8223717: javafx printing: Support Specifying Print to File in the API - Changes: - all: https://git.openjdk.java.net/jfx/pull/543/files - new: https://git.openjdk.java.net/jfx/pull/543/files/baab574d..1d86a803 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=543=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=543=04-05 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/543/head:pull/543 PR: https://git.openjdk.java.net/jfx/pull/543
Integrated: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc
On Tue, 29 Jun 2021 03:07:11 GMT, Alexander Matveev wrote: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of > cycle is reached regardless if it is repeating or not. This pull request has now been integrated. Changeset: cfa60ff7 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/cfa60ff7a54edcfd099f08585df71e1f7fc09ddb Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/552
Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v5]
On Wed, 30 Jun 2021 00:48:25 GMT, Phil Race wrote:
>> This enhancement adds the String property outputFileProperty() to the
>> JobSettings class.
>> The value should be a string that references a local file encoded as a URL.
>> If this is non-null and set to a location that the user has permission to
>> write to,
>> then the printer output will be spooled there instead of the printer, so
>> long as the platform printing system supports this.
>> The user can of course also set a print-to-file destination in the platform
>> printer dialogs which may over-ride what the application set. But now the
>> application can also see what it was set to, and cancel or alter it if
>> necessary.
>>
>> A simple manual test is provided, manual mainly because the few real
>> printing functional tests are all manual as they are only useful if run with
>> a printer configured.
>
> Phil Race has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - 8223717: javafx printing: Support Specifying Print to File in the API
> - 8223717: javafx printing: Support Specifying Print to File in the API
> - 8223717: javafx printing: Support Specifying Print to File in the API
I've added my final comments on the API docs. Some of them are pretty
nit-picky, so take them as suggestions.
modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 481:
> 479: * such as Postscript or PDF, and the application intends to
> distribute
> 480: * the result instead of printing it, or for some other reason the
> 481: * application does not want physical media (paper) emitted by the
> printer.
Very minor: maybe consider combining the first three paragraphs into a single
paragraph?
modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 486:
> 484: * equivalent to null, which means output is sent to the printer.
> 485: * So in order to reset to print to the printer, clear the value of
> 486: * this property by setting it to null or an empty string.
This doesn't flow as well as it could. I think you only need to mention once
that `null` is the same as an empty string, and then you can just say "empty
string". Maybe something like this?
The default value is an empty string, which means output is sent to the
printer. So in order to reset
to print to the printer, clear the value of this property by setting it to an
empty string. A value
of {@code null} is treated as an empty string.
modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 489:
> 487: *
> 488: * Additionally if the application displays a printer dialog which
> allows
> 489: * the user to specify a file destination including altering an
> application
Minor: I think there should be a comma between `destination` and `including`.
modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 491:
> 489: * the user to specify a file destination including altering an
> application
> 490: * specified file destination, the value of this property will
> reflect that
> 491: * user-specified choice, including clearing it to re-set to print to
`reset` is one word (no need to hyphenate).
modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 500:
> 498: * a user writable file, when printing the results are
> platform-dependent, including
> 499: * replacement with a default output file location, printing to the
> printer instead,
> 500: * or a platform printing error.
This sentence is a bit awkward and hard to parse. Maybe break it into two
sentences? Perhaps something like this:
If the specified name specifies a non-existent path, or does not specify a user
writable file, the
results when printing are platform-dependent. Possible behavior might include
replacement with
a default output file location, printing to the printer instead, or a platform
printing error.
-
PR: https://git.openjdk.java.net/jfx/pull/543
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. > It provides a `src.zip` file for use by IDEs in that same `lib` directory. If > a developer adds the `lib` directory to their application's module path in > the IDE, it will try to load `src.zip` as if it were a jar file, and will > fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to > the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by > eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ This indeed makes it easier, at least on NetBeans, to avoid issues with source code and jars in the same directory. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/558
Integrated: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. This pull request has now been integrated. Changeset: 098c0f39 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/098c0f393ef0849e140c9efd4d083f3282e1fa0e Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod 8269147: Update GStreamer to version 1.18.4 Reviewed-by: kcr, sykora - PR: https://git.openjdk.java.net/jfx/pull/541
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
On Wed, 30 Jun 2021 16:16:16 GMT, Kevin Rushforth wrote: > Thanks for running the test. This is sufficient to show that the changed > layout will work with IntelliJ. > > What happens with the current layout, where src.zip is in the lib dir, if you > add the lib dir? Does IntelliJ fail in the same way as NetBeans (complain > about duplicates)? No. It behaves the same as I documented above. So for IntelliJ, nothing really changed but the directory you need to choose the src.zip from. - PR: https://git.openjdk.java.net/jfx/pull/558
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. > It provides a `src.zip` file for use by IDEs in that same `lib` directory. If > a developer adds the `lib` directory to their application's module path in > the IDE, it will try to load `src.zip` as if it were a jar file, and will > fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to > the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by > eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ As documented in a comment, this is fine for IntelliJ. Verified, that the **src.zip** is now in the root of the sdk folder. - Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/558
RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel
This PR fixes 2 NPEs in Choice-and ComboBox, when the selection model is null. ChoiceBox: - Null check in **valueProperty()** listener ComboBox: - Null check in **valueProperty()** listener - Null check in **ComboBoxListViewSkin#updateValue()** The tests checks, that no NPE is printed to the console (JUnit5 has the **assertDoesNotThrow()** method, but 4 unfortunately has not). They also checks, that the set value is still displayed (either in the ComboBox button cell or the ChoiceBox display label) - Commit messages: - 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel Changes: https://git.openjdk.java.net/jfx/pull/557/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=557=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089398 Stats: 71 lines in 5 files changed: 62 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/557.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/557/head:pull/557 PR: https://git.openjdk.java.net/jfx/pull/557
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. > It provides a `src.zip` file for use by IDEs in that same `lib` directory. If > a developer adds the `lib` directory to their application's module path in > the IDE, it will try to load `src.zip` as if it were a jar file, and will > fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to > the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by > eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ Thanks for running the test. This is sufficient to show that the changed layout will work with IntelliJ. What happens with the current layout, where src.zip is in the lib dir, if you add the lib dir? Does IntelliJ fail in the same way as NetBeans (complain about duplicates)? - PR: https://git.openjdk.java.net/jfx/pull/558
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
On Wed, 30 Jun 2021 15:06:50 GMT, Kevin Rushforth wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. > It provides a `src.zip` file for use by IDEs in that same `lib` directory. If > a developer adds the `lib` directory to their application's module path in > the IDE, it will try to load `src.zip` as if it were a jar file, and will > fail. This is a pain point for developers using the SDK. > > The proposed solution is to move the `src.zip` file from the lib directory to > the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by > eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ I just tried it with IntelliJ. I did the following steps: 1. I build the PR with **gradle sdk** 2. I copied the content of the sdk folder into an own '**jfx-17-internal**' folder. 3. I added the **lib** folder as library in IntelliJScreenshot 4. I navigated into a class file (**Stage** in this case) and clicked on '**Choose sources...**' (top right)Screenshot 5. I chose the **src.zip** which is now inside the root folderScreenshot 6. I can now see the sources (in my case: **Stage**)Screenshot  Is this sufficient/Do I miss something or is this fine as test? - PR: https://git.openjdk.java.net/jfx/pull/558
RFR: 8258499: JavaFX: Move src.zip out of the lib directory
The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. It provides a `src.zip` file for use by IDEs in that same `lib` directory. If a developer adds the `lib` directory to their application's module path in the IDE, it will try to load `src.zip` as if it were a jar file, and will fail. This is a pain point for developers using the SDK. The proposed solution is to move the `src.zip` file from the lib directory to the top directory of the SDK. With this fix, the layout of the SDK will be: / bin/ (Windows) (Windows) legal/ ... lib/ *.jar (macOS and Linux) src.zip NOTES: 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by eclipse-efx/efxclipse-eclipse#85. 2. This still needs to be tested on IntelliJ - Commit messages: - 8258499: JavaFX: Move src.zip out of the lib directory Changes: https://git.openjdk.java.net/jfx/pull/558/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=558=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258499 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/558.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/558/head:pull/558 PR: https://git.openjdk.java.net/jfx/pull/558
Re: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2]
On Wed, 30 Jun 2021 00:15:26 GMT, Alexander Matveev wrote: >> Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of >> cycle is reached regardless if it is repeating or not. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc > [v2] Looks good. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/552
Re: RFR: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. We've also tested the changes on our build infrastructure and it all worked fine. - Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/541
