Re: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class

[Ambarish Rapte]

On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth  wrote:

> This is a simple fix to remove some obsolete code. As noted in the JBS 
> description, GlassView2D was made obsolete back
> in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is 
> dead code, as there are no references to
> that class.

Looks good to me.

-

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/162

RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina

[Alexander Matveev]

https://bugs.openjdk.java.net/browse/JDK-8240694

- Original fix JDK-8236832 was reverted.
- Timestamp will be queried on event loop thread when spectrum event is 
received by event loop.
- FIx only enabled for macOS when using OSXPlatform.

-

Commit messages:
 - 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina

Changes: https://git.openjdk.java.net/jfx/pull/163/files
 Webrev: https://webrevs.openjdk.java.net/jfx/163/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8240694
  Stats: 62 lines in 11 files changed: 29 ins; 13 del; 20 mod
  Patch: https://git.openjdk.java.net/jfx/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163

PR: https://git.openjdk.java.net/jfx/pull/163

Re: [Rev 02] RFR: 8241476: Linux build warning issued on updated compilers (Ubuntu 18.04.4 / 20.04)

[Kevin Rushforth]

On Tue, 31 Mar 2020 20:45:44 GMT, Thiago Milczarek Sayao  
wrote:

>> I took a look yesterday and came to the same conclusion that what we really 
>> want are separate C and C++ flags. For now,
>> the only difference would be the presence or absence of 
>> `-Werror=implicit-function-declaration`, but it would allow for
>> other differences in the future if needed.
>
> Please, let me know if this is the desired way to do it. If not, I will 
> rework it. Thanks.

This is roughly what I had in mind. I want to test it, and also take a look at 
the WebKit and media builds as well.
WebKit uses the flags from `linux.gradle`, and is mostly C++, so I think it 
needs no changes. Media does not use any
flags from `linux.gradle` -- only the jfxmedia project has C++ files on Linux. 
I guess it should be fine, too, but I'll
see.

-

PR: https://git.openjdk.java.net/jfx/pull/150

Re: [Rev 03] RFR: 8217472: Add attenuation for PointLight

[Kevin Rushforth]

On Thu, 2 Apr 2020 12:59:11 GMT, Nir Lisker  wrote:

>> I have added few comments, but have not run tests and sample yet.
>
> @arapte Can you please test the performance changes too?

I think @arapte has a similar MacBookPro model to mine.

I think @prrace might be able to test it (I'll sync with him offline).

-

PR: https://git.openjdk.java.net/jfx/pull/43

Re: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Kevin Rushforth]

On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas  wrote:

>> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710
>> 
>> Root Cause : A menu can have empty submenu. This was not checked while 
>> processing RIGHT arrow key.
>> 
>> Fix : Added the null check for submenu. Added a unit test case which fails 
>> without fix and passes with it.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Minor review fixes

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/161

Re: [Rev 48] RFR: 8236651: Simplify and update glass gtk backend

[Thiago Milczarek Sayao]

> ### Summary
> * Simplify and update the Gtk glass backend, making Linux a first-class 
> OpenJFX platform.
> 
> ### Goals
> * Make Linux a first-class OpenJFX platform (see Motivation);
> * Simplify the code and reduce it's size;
> * Update to gtk3 (it was originally a port from gtk2);
> * Remove unused code (such as applets and web start);
> * Prepare the ground for a possible future Wayland support.
> ### Testing
> ./gradlew -PEXTRA_TEST_ARGS='-Djdk.gtk.new=true' -PFULL_TEST=true 
> -PUSE_ROBOT=true :systemTests:test

Thiago Milczarek Sayao has updated the pull request incrementally with two 
additional commits since the last revision:

 - Restore comment position
 - Restore deleted idea file

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/77/files
  - new: https://git.openjdk.java.net/jfx/pull/77/files/2f83ce7b..d18b5be4

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/77/webrev.48
 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.47-48

  Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77

PR: https://git.openjdk.java.net/jfx/pull/77

Re: RFR: 8242209: Increase web native thread stack size for x86 mode

[Kevin Rushforth]

On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph  wrote:

> CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time 
> CLoop::execute() is called. For web native
> threads which has a default stack size of 320 KB, a Stack Overflow Error is 
> raised just after two calls to execute()
> function. While 64-bit windows has a default stack size of 1 MB.  Fix: 
> Increase the thread stack size of web native
> threads for x86 to 1 MB.

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/159

Re: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A)

[Kevin Rushforth]

On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas  wrote:

> Bug : https://bugs.openjdk.java.net/browse/JDK-8230809
> 
> Root Cause :
> Turned out to be a simpler issue than thought.
> Atomicity check was missed while updating toolbar state (which in turn 
> updates styles).
> 
> Fix :
> Added the missed atomicity check at two places that handle text selection 
> using keyboard keys.
> 
> Testing :
> Added two system test cases. They fail without this fix and pass with it.

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/155

Re: RFR: 8242209: Increase web native thread stack size for x86 mode

[Kevin Rushforth]

On Mon, 6 Apr 2020 11:57:54 GMT, Arun Joseph  wrote:

> CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time 
> CLoop::execute() is called. For web native
> threads which has a default stack size of 320 KB, a Stack Overflow Error is 
> raised just after two calls to execute()
> function. While 64-bit windows has a default stack size of 1 MB.  Fix: 
> Increase the thread stack size of web native
> threads for x86 to 1 MB.

@guruhb please also review this.

-

PR: https://git.openjdk.java.net/jfx/pull/159

Re: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A)

[Arun Joseph]

On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas  wrote:

> Bug : https://bugs.openjdk.java.net/browse/JDK-8230809
> 
> Root Cause :
> Turned out to be a simpler issue than thought.
> Atomicity check was missed while updating toolbar state (which in turn 
> updates styles).
> 
> Fix :
> Added the missed atomicity check at two places that handle text selection 
> using keyboard keys.
> 
> Testing :
> Added two system test cases. They fail without this fix and pass with it.

Marked as reviewed by ajoseph (Author).

-

PR: https://git.openjdk.java.net/jfx/pull/155

Re: RFR: 8242106: [macos] Remove obsolete GlassView2D.m class

[Kevin Rushforth]

On Tue, 7 Apr 2020 13:54:43 GMT, Kevin Rushforth  wrote:

> This is a simple fix to remove some obsolete code. As noted in the JBS 
> description, GlassView2D was made obsolete back
> in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is 
> dead code, as there are no references to
> that class.

@arapte can you review this?

-

PR: https://git.openjdk.java.net/jfx/pull/162

RFR: 8242106: [macos] Remove obsolete GlassView2D.m class

[Kevin Rushforth]

This is a simple fix to remove some obsolete code. As noted in the JBS 
description, GlassView2D was made obsolete back
in JDK 8, but the GlassView2D.m / .h class files were left in the repo. It is 
dead code, as there are no references to
that class.

-

Commit messages:
 - 8242106: [macos] Remove obsolete GlassView2D.m class

Changes: https://git.openjdk.java.net/jfx/pull/162/files
 Webrev: https://webrevs.openjdk.java.net/jfx/162/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242106
  Stats: 460 lines in 3 files changed: 0 ins; 460 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/162.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/162/head:pull/162

PR: https://git.openjdk.java.net/jfx/pull/162

Re: Support "trust all" SSL context in OpenJFX 14

[Lior Yaffe]

I'm not sure why but it doesn't work.

The only workaround I found is:
System.setProperty("com.sun.webkit.useHTTP2Loader", "false"); // Workaround
to support test certificate with OpenJFX 14 Webview

Then use the old code which works in OpenJFX 13 and earlier.
HttpsURLConnection.setDefaultSSLSocketFactory(TrustAllSSLProvider.getSslSocketFactory());
HttpsURLConnection.setDefaultHostnameVerifier(TrustAllSSLProvider.getHostNameVerifier());

On Tue, Apr 7, 2020 at 2:28 PM Michał Zegan 
wrote:

> What about global SSLContext.setDefault()? maybe it doesn't apply of
> course.
>
> W dniu 07.04.2020 o 13:14, Lior Yaffe pisze:
> > Some background information on why we are facing the issue.
> > The internal implementation of WebView changed in OpenJFX 14 to use
> > HttpClient instead of Http(s)URLConnection. Therefore, it is no longer
> > possible to use the following methods to set a custom SSL context before
> > instantiation of a HttpsURLConnection object:
> >
> > HttpsURLConnection#setDefaultSSLSocketFactory
> > HttpsURLConnection#setDefaultHostnameVerifier
> >
> > The only way to set a custom SSLContext to a HttpClient is to use the
> > method HttpClientBuilder#sslContext unfortunately this method is not
> > accessible for the Webview code.
> >
> > Since there is no static method on the HttpClient to set a custom
> > SSLContext, we hereby request to introduce a public method on WebView (or
> > WebEngine) for the purpose of passing a custom SSL context.
> >
> > <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > Virus-free.
> > www.avg.com
> > <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
>

Re: Shared buffer in PixelBuffer

[Kevin Rushforth]

Thanks for sharing.

-- Kevin


On 4/7/2020 1:39 AM, Michael Paus wrote:

Hi,
it is nice to hear that you could make some good use of this work.
Michael
(mipastgt)


Am 07.04.20 um 02:36 schrieb hohonu...@icloud.com:

Hi All,

I just wanted to send a "thank you!" to all the JavaFX devs for your 
work on JavaFX and most especially, adding shared memory to JavaFX’s 
PixelBuffer. 
(https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html)


The “tl;dr” is that I now have a JavaFX-based video player tool, 
thanks to Caprica Software, that can play a wide variety of video 
formats well and can be easily modified to support my organization's 
science requirements. I’ve linked a YouTube video of the video player 
app, playing a ProRes 422 encoded QuickTime video and communicating 
with another annotation application. Thanks to the shared buffer the 
video playback is smoooth. https://youtu.be/FKeuG8-UYC0


Again thanks for your work. Stay well!

Brian Schlining
Software Engineer
P (831) 775-1855   F (831) 775-1620


Monterey Bay Aquarium Research Institute
7700 Sandholdt Road, Moss Landing CA 95039
www.mbari.org
Advancing marine science and engineering to understand our changing 
ocean.

Re: RFR: 8242167: ios keyboard handling

[Kevin Rushforth]

On Sun, 5 Apr 2020 14:09:32 GMT, Johan Vos  wrote:

> Use JavaFX controls for TextField and TextArea instead of the native iOS ones
> This fixes JDK-8242167

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/158

Re: RFR: 8242163: Android keyboard integration fails

[Kevin Rushforth]

On Sun, 5 Apr 2020 10:19:07 GMT, Johan Vos  wrote:

> Fix the code that integrates TextField/TextArea with the android keyboard
> 
> Fix for #8242163

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/157

Re: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Jeanette Winzenburg]

On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas  wrote:

>> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710
>> 
>> Root Cause : A menu can have empty submenu. This was not checked while 
>> processing RIGHT arrow key.
>> 
>> Fix : Added the null check for submenu. Added a unit test case which fails 
>> without fix and passes with it.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Minor review fixes

okay, thanks for the quicks changes :)

-

Marked as reviewed by fastegal (Author).

PR: https://git.openjdk.java.net/jfx/pull/161

Re: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Ajit Ghaisas]

On Tue, 7 Apr 2020 11:40:09 GMT, Ajit Ghaisas  wrote:

>> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710
>> 
>> Root Cause : A menu can have empty submenu. This was not checked while 
>> processing RIGHT arrow key.
>> 
>> Fix : Added the null check for submenu. Added a unit test case which fails 
>> without fix and passes with it.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Minor review fixes

> Verified the fix: test is failing before and passing after.

Thanks for the quick test.

> See one inline comment (just noting my personal pref :).
> 
> And again me fighting the system (can't seem to review code parts that are 
> not near a change, so doing here:

Well, you are part of the system :)

> * copyright year doesn't seem to be updated

I have updated this now.
 
> * there's another fishy looking code line in MenuItemContainer 
> actionHandler:
>   ```
>   actionEventHandler = e -> {
>if (item instanceof Menu) {
>  final Menu menu = (Menu) item;
>  if (openSubmenu == menu && submenu.isShowing()) return;
>   ```
> 
> 
> don't know when/if that's ever reached (could get there - an action handler 
> on the region itself?), anyway, at other
> places with a similar pattern (f.i processRightKey) there's an explicit guard 
> against a null submenu, don't know if the
> latter is over-caution - logic and code is rather .. well .. inter-twined ;)

Yes. This code does not seem to be ideal, but, it has evolved and a lot of 
fixes have gone in. So rewriting is ruled
out.

-

PR: https://git.openjdk.java.net/jfx/pull/161

Re: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Ajit Ghaisas]

> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710
> 
> Root Cause : A menu can have empty submenu. This was not checked while 
> processing RIGHT arrow key.
> 
> Fix : Added the null check for submenu. Added a unit test case which fails 
> without fix and passes with it.

Ajit Ghaisas has updated the pull request incrementally with one additional 
commit since the last revision:

  Minor review fixes

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/161/files
  - new: https://git.openjdk.java.net/jfx/pull/161/files/dbb56031..aecc69c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/161/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/161/webrev.00-01

  Stats: 15 lines in 2 files changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/161.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161

PR: https://git.openjdk.java.net/jfx/pull/161

Re: [Rev 01] RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Ajit Ghaisas]

On Tue, 7 Apr 2020 10:13:39 GMT, Jeanette Winzenburg  
wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Minor review fixes
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java
>  line 658:
> 
>> 657: ContextMenuContent cmContent = 
>> (ContextMenuContent)submenu.getSkin().getNode();
>> 658: if (cmContent != null) {
>> 659:if (cmContent.itemsContainer.getChildren().size() > 0) {
> 
> just a mini-note: personally, I prefer early-return on no-match (vs. wrapping 
> nearly the whole method inside an if match
> 
> if (submenu == null) return;

I prefer a single point of return for small methods. Anyway, this file has lot 
of early returns. Hence, I am modifying
as per your suggestion.

-

PR: https://git.openjdk.java.net/jfx/pull/161

Re: Support "trust all" SSL context in OpenJFX 14

[Michał Zegan]

What about global SSLContext.setDefault()? maybe it doesn't apply of course.

W dniu 07.04.2020 o 13:14, Lior Yaffe pisze:
> Some background information on why we are facing the issue.
> The internal implementation of WebView changed in OpenJFX 14 to use
> HttpClient instead of Http(s)URLConnection. Therefore, it is no longer
> possible to use the following methods to set a custom SSL context before
> instantiation of a HttpsURLConnection object:
> 
> HttpsURLConnection#setDefaultSSLSocketFactory
> HttpsURLConnection#setDefaultHostnameVerifier
> 
> The only way to set a custom SSLContext to a HttpClient is to use the
> method HttpClientBuilder#sslContext unfortunately this method is not
> accessible for the Webview code.
> 
> Since there is no static method on the HttpClient to set a custom
> SSLContext, we hereby request to introduce a public method on WebView (or
> WebEngine) for the purpose of passing a custom SSL context.
> 
> 
> Virus-free.
> www.avg.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 

Support "trust all" SSL context in OpenJFX 14

[Lior Yaffe]

Some background information on why we are facing the issue.
The internal implementation of WebView changed in OpenJFX 14 to use
HttpClient instead of Http(s)URLConnection. Therefore, it is no longer
possible to use the following methods to set a custom SSL context before
instantiation of a HttpsURLConnection object:

HttpsURLConnection#setDefaultSSLSocketFactory
HttpsURLConnection#setDefaultHostnameVerifier

The only way to set a custom SSLContext to a HttpClient is to use the
method HttpClientBuilder#sslContext unfortunately this method is not
accessible for the Webview code.

Since there is no static method on the HttpClient to set a custom
SSLContext, we hereby request to introduce a public method on WebView (or
WebEngine) for the purpose of passing a custom SSL context.


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Jeanette Winzenburg]

On Tue, 7 Apr 2020 07:36:00 GMT, Ajit Ghaisas  wrote:

> Bug : https://bugs.openjdk.java.net/browse/JDK-8241710
> 
> Root Cause : A menu can have empty submenu. This was not checked while 
> processing RIGHT arrow key.
> 
> Fix : Added the null check for submenu. Added a unit test case which fails 
> without fix and passes with it.

Verified the fix: test is failing before and passing after.

See one inline comment (just noting my personal pref :).

And again me fighting the system (can't seem to review code parts that are not 
near a change, so doing here:

- copyright year doesn't seem to be updated
- there's another fishy looking code line in MenuItemContainer actionHandler:

  actionEventHandler = e -> {
   if (item instanceof Menu) {
 final Menu menu = (Menu) item;
 if (openSubmenu == menu && submenu.isShowing()) return;
 
don't know when/if that's ever reached (could get there - an action handler on 
the region itself?), anyway, at other
places with a similar pattern (f.i processRightKey) there's an explicit guard 
against a null submenu, don't know if the
latter is over-caution - logic and code is rather .. well .. inter-twined ;)

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ContextMenuContent.java
 line 658:

> 657: ContextMenuContent cmContent = 
> (ContextMenuContent)submenu.getSkin().getNode();
> 658: if (cmContent != null) {
> 659:if (cmContent.itemsContainer.getChildren().size() > 0) {

just a mini-note: personally, I prefer early-return on no-match (vs. wrapping 
nearly the whole method inside an if match

if (submenu == null) return;

-

PR: https://git.openjdk.java.net/jfx/pull/161

Re: RFR: 8241840: Memoryleak: Closed focused Stages are not collected with Monocle.

[Ambarish Rapte]

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

Suggested some changes and query. I still need to verify the fix in detail.

tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 77:

> 76: Platform.runLater(() -> stage.close());
> 77: }
> 78:

Looks like the primary `stage` is not required for actual test, and this block 
is only used to initialize JavaFX
runtime. Please check if it can be replaced by below block

```
@BeforeClass
public static void initFX() throws Exception {
startupLatch = new CountDownLatch(1);
Platform.startup(startupLatch::countDown);
Assert.assertTrue("Timeout waiting for FX runtime to start",
startupLatch.await(15, TimeUnit.MILLISECONDS));
}

tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 133:

> 132:
> 133: Assert.assertNull(weakReference.get());
> 134: }

This assert check call should be added to the @Test method.
I would recommend to refer [this
method](https://github.com/openjdk/jfx/blob/364c64a2e55b561df4ca1afc85c91054b339eea8/modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java#L1998)
from ListViewTest.

tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 113:

> 112: });
> 113:
> 114: Assert.assertTrue("Timeout, waiting for runLater. ", 
> leakLatch.await(15, TimeUnit.SECONDS));

Is it really required to nest the `Platform.runLater()` calls ? Can you please 
check if this code can be simplified by
making the calls sequential, Consider using `Util.runAndWait()`

tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 84:

> 83: counter += 1;
> 84: testLeakOnce();
> 85: }

If the test has constant behavior on every run, then only one run should be 
done.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 354:

> 353: }
> 354: if(Window.focusedWindow == this) {
> 355: Window.focusedWindow = null;

Please correct format by adding space after `if`.

tests/system/src/test/java/test/javafx/stage/FocusedWindowTest.java line 53:

> 52: System.setProperty("monocle.platform","Headless");
> 53: }
> 54:

The test will always run with Monocle. I see that if this static block is 
removed then the test fails on Windows 10.
Can you please verify all the platforms and change the test such that it runs 
on all platforms/ combinations.

-

Changes requested by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/153

Re: Shared buffer in PixelBuffer

[Michael Paus]

Hi,
it is nice to hear that you could make some good use of this work.
Michael
(mipastgt)


Am 07.04.20 um 02:36 schrieb hohonu...@icloud.com:

Hi All,

I just wanted to send a "thank you!" to all the JavaFX devs for your work on 
JavaFX and most especially, adding shared memory to JavaFX’s PixelBuffer. 
(https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html)

The “tl;dr” is that I now have a JavaFX-based video player tool, thanks to 
Caprica Software, that can play a wide variety of video formats well and can be 
easily modified to support my organization's science requirements. I’ve linked 
a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime 
video and communicating with another annotation application. Thanks to the 
shared buffer the video playback is smoooth. https://youtu.be/FKeuG8-UYC0

Again thanks for your work. Stay well!

Brian Schlining
Software Engineer
P (831) 775-1855   F (831) 775-1620


Monterey Bay Aquarium Research Institute
7700 Sandholdt Road, Moss Landing CA 95039
www.mbari.org
Advancing marine science and engineering to understand our changing ocean.

Re: RFR: 8242163: Android keyboard integration fails

[Johan Vos]

On Mon, 6 Apr 2020 23:26:12 GMT, Kevin Rushforth  wrote:

>> Fix the code that integrates TextField/TextArea with the android keyboard
>> 
>> Fix for #8242163
>
> Similar question as for the IOS keyboard issue: The newly moved 
> `TextAreaSkinAndroid ` and `TextFieldSkinAndroid`
> classes will become part of the public API for Android, since they are in the 
> `javafx.scene.control.skin` package. Is
> this intended, or might they still be able to live somewhere under 
> `com.sun.javafx`?

Same reason as in the iOS case. The `TextFieldSkinAndroid` was in 
`com.sun.javafx` at the same level as
`TextFieldSkin`. Since `TextFieldSkin` was moved to `javafx`, I moved 
`TextFieldSkinAndroid` as well.

-

PR: https://git.openjdk.java.net/jfx/pull/157

Re: RFR: 8242167: ios keyboard handling

[Johan Vos]

On Mon, 6 Apr 2020 23:21:17 GMT, Kevin Rushforth  wrote:

> The new `TextAreaSkinIos` and `TextFieldSkinIos ` classes will become part of 
> the public API for IOS, since they are in
> the `javafx.scene.control.skin` package. Is this intended, or might they be 
> able to live somewhere under
> `com.sun.javafx`?

That is intentional indeed, as libraries may want to change behavior. The 
Android classes used to be in com.sun.javafx,
at the same level as the desktop classes. But the desktop classes 
(`TextAreaSkin` and `TextFieldSkin`) are moved to
`javafx.scene.control.skin` hence it seems logic to move the Android classes to 
the same level, and the iOS classes as
well then. Alternatively, we could completely get rid of the ios/android 
specific classes, and add the logic to
show/hide the keyboard in the desktop classes. But that is much more intrusive, 
so I think it's safer to keep them
separated for now.

-

PR: https://git.openjdk.java.net/jfx/pull/158

RFR: 8241710: NullPointerException while entering empty submenu with "arrow right"

[Ajit Ghaisas]

Bug : https://bugs.openjdk.java.net/browse/JDK-8241710

Root Cause : A menu can have empty submenu. This was not checked while 
processing RIGHT array key.

Fix : Added the null check for submenu. Added a unit test case which fails 
without fix and passes with it.

-

Commit messages:
 - Fix NPE

Changes: https://git.openjdk.java.net/jfx/pull/161/files
 Webrev: https://webrevs.openjdk.java.net/jfx/161/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241710
  Stats: 29 lines in 2 files changed: 20 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/161.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/161/head:pull/161

PR: https://git.openjdk.java.net/jfx/pull/161