Re: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v4]

[Paul]

> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided 
> to investigate.
> 
> Please note: I have not done any Objective-C or MacOS development before. So 
> I would really like some feedback from someone else who knows this stuff 
> better.
> 
> Anyway, after some googling, I discovered that MacOS uses points values for 
> measurements and not pixels, so the actual fix for this issue was this block 
> in `GlassMenu.m`:-
> 
> 
> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) {
> NSSize imgSize = {width / sx, height / sy};
> [image setSize: imgSize];
> }
> 
> 
> The rest of the changes were needed in order to get the `scaleX` and `scaleY` 
> values down from `PixelUtils.java` into `GlassMenu.m`.
> 
> Before this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880981-92163087-696b-4442-b047-845c276deb27.png;>
> 
> After this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880985-6bff0a06-9aee-4db2-b696-64730b0a6feb.png;>

Paul 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 six additional commits since the last 
revision:

 - Merge branch 'master' into JDK-8181084
 - Updated variable names to be a bit more consistent
 - Merge branch 'master' into JDK-8181084
 - Merge branch 'master' into JDK-8181084
 - Removing trailing whitespace.
 - Correctly scales hi-res icons in MacOS system menu items

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/743/files
  - new: https://git.openjdk.java.net/jfx/pull/743/files/bb6d34fe..e1d2885d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=743=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=743=02-03

  Stats: 5600 lines in 7 files changed: 5583 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/743.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743

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

Re: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v3]

[Paul]

> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided 
> to investigate.
> 
> Please note: I have not done any Objective-C or MacOS development before. So 
> I would really like some feedback from someone else who knows this stuff 
> better.
> 
> Anyway, after some googling, I discovered that MacOS uses points values for 
> measurements and not pixels, so the actual fix for this issue was this block 
> in `GlassMenu.m`:-
> 
> 
> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) {
> NSSize imgSize = {width / sx, height / sy};
> [image setSize: imgSize];
> }
> 
> 
> The rest of the changes were needed in order to get the `scaleX` and `scaleY` 
> values down from `PixelUtils.java` into `GlassMenu.m`.
> 
> Before this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880981-92163087-696b-4442-b047-845c276deb27.png;>
> 
> After this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880985-6bff0a06-9aee-4db2-b696-64730b0a6feb.png;>

Paul 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 five additional commits since the last 
revision:

 - Updated variable names to be a bit more consistent
 - Merge branch 'master' into JDK-8181084
 - Merge branch 'master' into JDK-8181084
 - Removing trailing whitespace.
 - Correctly scales hi-res icons in MacOS system menu items

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/743/files
  - new: https://git.openjdk.java.net/jfx/pull/743/files/3057f683..bb6d34fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=743=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=743=01-02

  Stats: 40324 lines in 468 files changed: 22990 ins; 6262 del; 11072 mod
  Patch: https://git.openjdk.java.net/jfx/pull/743.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743

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

Re: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v2]

[Paul]

On Sat, 2 Apr 2022 10:23:23 GMT, Paul  wrote:

>> I hit on JDK-8181084 while making some changes to Scene Builder, so I 
>> decided to investigate.
>> 
>> Please note: I have not done any Objective-C or MacOS development before. So 
>> I would really like some feedback from someone else who knows this stuff 
>> better.
>> 
>> Anyway, after some googling, I discovered that MacOS uses points values for 
>> measurements and not pixels, so the actual fix for this issue was this block 
>> in `GlassMenu.m`:-
>> 
>> 
>> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) {
>> NSSize imgSize = {width / sx, height / sy};
>> [image setSize: imgSize];
>> }
>> 
>> 
>> The rest of the changes were needed in order to get the `scaleX` and 
>> `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`.
>> 
>> Before this fix:-
>> 
>> > src="https://user-images.githubusercontent.com/437990/155880981-92163087-696b-4442-b047-845c276deb27.png;>
>> 
>> After this fix:-
>> 
>> > src="https://user-images.githubusercontent.com/437990/155880985-6bff0a06-9aee-4db2-b696-64730b0a6feb.png;>
>
> Paul 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 three additional commits since 
> the last revision:
> 
>  - Merge branch 'master' into JDK-8181084
>  - Removing trailing whitespace.
>  - Correctly scales hi-res icons in MacOS system menu items

Made a minor change to some variable names to be more consistent with how those 
values are referenced elsewhere and pulled in the latest upstream changes.

Can anyone help me out with pushing this little tweak over the finishing line?

-

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

Re: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v2]

[Paul]

> I hit on JDK-8181084 while making some changes to Scene Builder, so I decided 
> to investigate.
> 
> Please note: I have not done any Objective-C or MacOS development before. So 
> I would really like some feedback from someone else who knows this stuff 
> better.
> 
> Anyway, after some googling, I discovered that MacOS uses points values for 
> measurements and not pixels, so the actual fix for this issue was this block 
> in `GlassMenu.m`:-
> 
> 
> if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) {
> NSSize imgSize = {width / sx, height / sy};
> [image setSize: imgSize];
> }
> 
> 
> The rest of the changes were needed in order to get the `scaleX` and `scaleY` 
> values down from `PixelUtils.java` into `GlassMenu.m`.
> 
> Before this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880981-92163087-696b-4442-b047-845c276deb27.png;>
> 
> After this fix:-
> 
>  src="https://user-images.githubusercontent.com/437990/155880985-6bff0a06-9aee-4db2-b696-64730b0a6feb.png;>

Paul 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 three additional commits since the last 
revision:

 - Merge branch 'master' into JDK-8181084
 - Removing trailing whitespace.
 - Correctly scales hi-res icons in MacOS system menu items

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/743/files
  - new: https://git.openjdk.java.net/jfx/pull/743/files/9162aa44..3057f683

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=743=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=743=00-01

  Stats: 63592 lines in 202 files changed: 10562 ins; 25364 del; 27666 mod
  Patch: https://git.openjdk.java.net/jfx/pull/743.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743

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

RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display

[Paul]

I hit on JDK-8181084 while making some changes to Scene Builder, so I decided 
to investigate.

Please note: I have not done any Objective-C or MacOS development before. So I 
would really like some feedback from someone else who knows this stuff better.

Anyway, after some googling, I discovered that MacOS uses points values for 
measurements and not pixels, so the actual fix for this issue was this block in 
`GlassMenu.m`:-


if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) {
NSSize imgSize = {width / sx, height / sy};
[image setSize: imgSize];
}


The rest of the changes were needed in order to get the `scaleX` and `scaleY` 
values down from `PixelUtils.java` into `GlassMenu.m`.

Before this fix:-

https://user-images.githubusercontent.com/437990/155880981-92163087-696b-4442-b047-845c276deb27.png;>

After this fix:-

https://user-images.githubusercontent.com/437990/155880985-6bff0a06-9aee-4db2-b696-64730b0a6feb.png;>

-

Commit messages:
 - Removing trailing whitespace.
 - Correctly scales hi-res icons in MacOS system menu items

Changes: https://git.openjdk.java.net/jfx/pull/743/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=743=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8181084
  Stats: 86 lines in 14 files changed: 84 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/743.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743

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

Integrated: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card

[Paul]

On Mon, 20 Dec 2021 17:48:19 GMT, Paul  wrote:

> I have an AMD Radeon VII (vega20) series GPU which is identifying with a 
> vendor string of "AMD".
> 
> This is not present in the `X11GLFactory` list of `preQualificationFilter` 
> vendor names, so my system (and probably any other vega20 based cards under 
> Linux) will always fall back to software rendering.
> 
> This adds the "amd" string to the `preQualificationFilter` list.

This pull request has now been integrated.

Changeset: ae334c56
Author:Paul Court 
Committer: Kevin Rushforth 
URL:   
https://git.openjdk.java.net/jfx/commit/ae334c56687ad81cb3963f2529f93144586dd750
Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod

8279013: ES2Pipeline fails to detect AMD vega20 graphics card

Reviewed-by: kcr

-

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

Re: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card

[Paul]

On Tue, 21 Dec 2021 08:09:08 GMT, Paul  wrote:

> ... I signed the OCA **last year** ...

Added some emphasis. Hope I get a year off for Christmas next year! ;-)

-

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

Re: RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card

[Paul]

On Mon, 20 Dec 2021 17:48:19 GMT, Paul  wrote:

> I have an AMD Radeon VII (vega20) series GPU which is identifying with a 
> vendor string of "AMD".
> 
> This is not present in the `X11GLFactory` list of `preQualificationFilter` 
> vendor names, so my system (and probably any other vega20 based cards under 
> Linux) will always fall back to software rendering.
> 
> This adds the "amd" string to the `preQualificationFilter` list.

Just as a side note, I signed the OCA last year when I was doing some work with 
the Helidon project. I thought it was one OCA for all things Oracle?

Hi. I'm just wondering if there is anything else I need to do for the OCA? It's 
been 4 weeks now, so even taking into account the holidays, I'm wondering if 
this request has fallen through the cracks?

Thanks

-

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

RFR: 8279013 : ES2Pipeline fails to detect AMD vega20 graphics card

[Paul]

I have an AMD Radeon VII (vega20) series GPU which is identifying with a vendor 
string of "AMD".

This is not present in the `X11GLFactory` list of `preQualificationFilter` 
vendor names, so my system (and probably any other vega20 based cards under 
Linux) will always fall back to software rendering.

This adds the "amd" string to the `preQualificationFilter` list.

-

Commit messages:
 - Adds support for AMD graphics cards that identify themselves with "AMD" 
vendor strings.

Changes: https://git.openjdk.java.net/jfx/pull/698/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=698=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279013
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/698.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/698/head:pull/698

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

Re: [PATCH] 8182572 Numpad keys not working with JavaFX Monocle

[Paul Enuta]

Does this patch
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-September/020818.html
is
included in Gluon JavaFX8 arm6hf 8.60.9 release?
Is it possible for Gluon to release another JavaFX8 arm6hf based on latest
http://hg.openjdk.java.net/openjfx/8u/rt ?

Thanks a lot,
Paul

[13] RFR: JDK-8201539: WICCreateImagingFactory: defer CoUninitialize() call to thread exit

[Paul Tan]

Please review the following PR on GitHub which fixes a crash that
occurs when JavaFX is used with Monocle's headless platform (used in
TestFX's headless mode).

https://github.com/javafxports/openjdk-jfx/pull/367
https://bugs.openjdk.java.net/browse/JDK-8201539

Regards,
Paul

Re: BUG: TableView's setMouseTransparent method does not make mouse transparent

[Paul Ray Russell]

>> JavaFX does not use exclusive full-screen mode. It simulates full
>> screen by using an undecorated window that is exactly the size of the
>> screen. This means that pop-ups, such as those used by ComboBox and
>> content menus, will continue to work (they use separate windows).
>>
>>-- Kevin
>>
>>

> Well, that kind of stinks.

I agree, Ty: it's a terrible idea, and in my experience makes JavaFX
unworkable for games. There is no way to change native screen resolution, I
have to go to command line to achieve this and use a C++ solution. It's one
of my major gripes, along with no shader access. Ref: performance, I've
found the canvas, currently the fastest way to render content, to be slow
against pure native OpenGL/Vulcan/Dx solutions.

Re: openjfx-dev Digest, Vol 80, Issue 32

[Paul Ray Russell]

Hi Mark,

OK ignore that. I clicked through and looked at your POM.

Best,
Paul


On Sun, 22 Jul 2018 at 13:00,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Simple Maven example fails with unusual error (Mark Raynsford)
>2. Re: Simple Maven example fails with unusual error (Mark Raynsford)
>
>
> --
>
> Message: 1
> Date: Sat, 21 Jul 2018 15:55:15 +0100
> From: Mark Raynsford 
> To: openjfx-dev@openjdk.java.net
> Subject: Simple Maven example fails with unusual error
> Message-ID: <20180721155515.7d471...@almond.int.arc7.info>
> Content-Type: text/plain; charset=US-ASCII
>
> Hello!
>
> I've finally gotten around to trying out the artifacts that are
> currently on Maven Central.
>
> I put together a trivial example that does nothing but start up
> OpenJFX:
>
>   https://github.com/io7m/javafx-example-20180721
>
> It works, but only if I take the somewhat bizarre step of excluding the
> non-platform-specific artifacts from the build. Note the 
> elements in the Maven dependencies.
>
> The error I get if I don't do this:
>
> java.lang.module.FindException: Unable to derive module descriptor
> for
> /home/rm/var/maven/org/openjfx/javafx-graphics/11-ea+19/javafx-graphics-11-ea+19.jar
> Caused by: java.lang.IllegalArgumentException:
> javafx.graphics.11.ea.19: Invalid module name: '11' is not a Java
> identifier
>
> Is this a known issue?
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
>
> --
>
> Message: 2
> Date: Sat, 21 Jul 2018 16:07:45 +0100
> From: Mark Raynsford 
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Simple Maven example fails with unusual error
> Message-ID: <20180721160745.61862...@almond.int.arc7.info>
> Content-Type: text/plain; charset=US-ASCII
>
> On 2018-07-21T15:55:15 +0100
> Mark Raynsford  wrote:
> >
> > Is this a known issue?
>
> Forgot to mention:
>
> $ java -version
> openjdk version "10.0.1" 2018-04-17
> OpenJDK Runtime Environment (build 10.0.1+10)
> OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode)
>
> $ uname -a
> Linux almond.int.arc7.info 4.17.5-1-ARCH #1 SMP PREEMPT Sun Jul 8
> 17:27:31 UTC 2018 x86_64 GNU/Linux
>
> $ mvn --version
> Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root;
> 2017-10-25T11:09:52+01:00) Maven home: /opt/maven
> Java version: 10.0.1, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-10-openjdk
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.17.5-1-arch", arch: "amd64", family:
> "unix"
>
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
>
> End of openjfx-dev Digest, Vol 80, Issue 32
> ***
>

Simple Maven example fails with unusual error

[Paul Ray Russell]

Hi Mark,

Are you using the v. latest version maven compiler in your POM?

Best,
Paul

On Sun, 22 Jul 2018 at 13:00,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Simple Maven example fails with unusual error (Mark Raynsford)
>2. Re: Simple Maven example fails with unusual error (Mark Raynsford)
>
>
> --
>
> Message: 1
> Date: Sat, 21 Jul 2018 15:55:15 +0100
> From: Mark Raynsford 
> To: openjfx-dev@openjdk.java.net
> Subject: Simple Maven example fails with unusual error
> Message-ID: <20180721155515.7d471...@almond.int.arc7.info>
> Content-Type: text/plain; charset=US-ASCII
>
> Hello!
>
> I've finally gotten around to trying out the artifacts that are
> currently on Maven Central.
>
> I put together a trivial example that does nothing but start up
> OpenJFX:
>
>   https://github.com/io7m/javafx-example-20180721
>
> It works, but only if I take the somewhat bizarre step of excluding the
> non-platform-specific artifacts from the build. Note the 
> elements in the Maven dependencies.
>
> The error I get if I don't do this:
>
> java.lang.module.FindException: Unable to derive module descriptor
> for
> /home/rm/var/maven/org/openjfx/javafx-graphics/11-ea+19/javafx-graphics-11-ea+19.jar
> Caused by: java.lang.IllegalArgumentException:
> javafx.graphics.11.ea.19: Invalid module name: '11' is not a Java
> identifier
>
> Is this a known issue?
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
>
> --
>
> Message: 2
> Date: Sat, 21 Jul 2018 16:07:45 +0100
> From: Mark Raynsford 
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Simple Maven example fails with unusual error
> Message-ID: <20180721160745.61862...@almond.int.arc7.info>
> Content-Type: text/plain; charset=US-ASCII
>
> On 2018-07-21T15:55:15 +0100
> Mark Raynsford  wrote:
> >
> > Is this a known issue?
>
> Forgot to mention:
>
> $ java -version
> openjdk version "10.0.1" 2018-04-17
> OpenJDK Runtime Environment (build 10.0.1+10)
> OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode)
>
> $ uname -a
> Linux almond.int.arc7.info 4.17.5-1-ARCH #1 SMP PREEMPT Sun Jul 8
> 17:27:31 UTC 2018 x86_64 GNU/Linux
>
> $ mvn --version
> Apache Maven 3.5.2 (NON-CANONICAL_2017-10-25T13:09:52+03:00_root;
> 2017-10-25T11:09:52+01:00) Maven home: /opt/maven
> Java version: 10.0.1, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-10-openjdk
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.17.5-1-arch", arch: "amd64", family:
> "unix"
>
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
>
> End of openjfx-dev Digest, Vol 80, Issue 32
> ***
>

com.sun.javafx.perf.PerformanceTracker

[Paul Ray Russell]

1. I have a game which I'm trying to performance tune: I can obviously
monitor how often I'm calling draw (draw rate), but I can't monitor how
often the GPU is actually rendering (FPS) since the PerformanceTracker was
removed from the JDK.

I'm running FX at full speed (-Djavafx.animation.fullspeed=true), and
experimentation (using GPU vendor FPS monitors) shows that if I lower my
"draw rate" to match the actual GPU FPS, I get marginally smoother
rendering. I've never managed to work out why this would be the case, I get
no errors in with Prism running in verbose mode, but if I call draw a
faster rate than the GPU renders, I get tiny stutters in my game. These
would appear to be missed frames. I can try to video the problem if
necessary, but I can't easily make a simple SSCE.

In short, I'd really like to see a new version of the PerformanceTracker in
the public API. Is this difficult to achieve?

2. The other thing I'd love to see would be some way to set the native
screen resolution in JavaFX: my question:
https://stackoverflow.com/questions/50545263/setting-native-resolution-in-javafx

All games offer this functionality in their graphics settings.

3. As, I last point: since I'm writing. It seems sad that Haxe Kha offers
transcompilation into Java, but all they can compile into is AWT, which
offers no shaders: hence there can be no Kha graphics4 in Java. Again, nods
to some modernising of the renderer in JavaFX to enable pipeline support
would be great.

Best,
Paul

OpenGL deprecated in OS-X

[Paul Ray Russell]

Tom's right. Major news. Presumably prism would need to cater for a third
renderer, Metal. What would be the time scales for this? Is this an
opportunity to update the way javafx renderer works? Perhaps a tie in to
Lwjgl is better? They have Vulcan bindings and no doubt will wrap Metal.
But I would advocate avoiding a naive object wrapper that privatises all
wrapped calls. Imo. The problem is, currently, if a dev needs lower level
access it's all shielded.

On Mon, 4 Jun 2018, 23:02 ,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Pedro Duque Vieira)
>2. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Scott Palmer)
>3. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Michael Paus)
>4. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Mario Ivankovits)
>5. OpenGL deprecated in OS-X (Tom Schindl)
>6. Re: Removal of apps/scenebuilder from OpenJFX repo (Sverre Moe)
>
>
> --
>
> Message: 1
> Date: Mon, 4 Jun 2018 15:44:55 +0100
> From: Pedro Duque Vieira 
> To: OpenJFX Mailing List 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID:
> <
> caaeud6za5jlngbsvsaw0d-mlwnreq2y6mmtqyrvxuvsuoex...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I agree with Johan and others, a splash screen is valuable and needed.
>
> Microsoft applications that run on Windows itself (think Word, Excel, etc),
> they have a splash screen, Intelllij has a splash screen (it's swing based
> AFAIK), etc.. If a Microsoft application running on its own operating
> system needs a splash screen then chances are pretty high that there will
> be Java apps that'll need a splash screen.
>
> Cheers,
>
>
> --
> Pedro Duque Vieira
>
>
> --
>
> Message: 2
> Date: Mon, 4 Jun 2018 12:22:18 -0400
> From: Scott Palmer 
> To: OpenJFX Mailing List 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID: <536bf700-3f7b-42d2-9cd9-21ef9385c...@gmail.com>
> Content-Type: text/plain;   charset=utf-8
>
> Nobody is arguing against splash screens.  I?m simply suggesting that the
> JVM startup is not slow enough that we need special handling of this in
> native code.
>
> If Java can get a window displayed in under half a second there is no need
> for the added complexity to support a native splash screen in the launcher.
>
> The idea that cinit code *can* be slow is not really the issue here unless
> it isn?t possible to get a window displayed quickly even when there is no
> significant initialization other than to get that window= shown.  Don?t put
> heavy initialization in the main class when you want a splash screen.  Use
> a pre-main class that shows the splash screen and calls the ?real? main
> class.
>
> It makes sense to understand if we have this problem before making a
> complex solution.
>
> Scott
>
>
> > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
> >
> > Hi,
> >
> > I agree with Johan and others, a splash screen is valuable and needed.
> >
> > Microsoft applications that run on Windows itself (think Word, Excel,
> etc),
> > they have a splash screen, Intelllij has a splash screen (it's swing
> based
> > AFAIK), etc.. If a Microsoft application running on its own operating
> > system needs a splash screen then chances are pretty high that there will
> > be Java apps that'll need a splash screen.
> >
> > Cheers,
> >
> >
> > --
> > Pedro Duque Vieira
>
>
>
> --
>
> Message: 3
> Date: Mon, 4 Jun 2018 18:35:15 +0200
> From: Michael Paus 
> To: OpenJFX 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID: <99ace730-ad9b-f8ba-dd35-c2cf56b99...@jugs.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Maybe I misunderstood the question but to my opinion the real question is
> whether the new java packager has to provide the support for a splash
> screen
> or not. This has nothing to do with the question whether applications
> should
> have a splash screen or not because if we find that todays Java is fast
> enough
> to display a simple window in less than a second or so, then the Java GUI
> (Swing or 

OpenJFX code review policies, etc.

[Paul Ray Russell]

 "and the desired direction of the Project" - perhaps, Kevin, it would be
worth you taking a few words describing what this "direction" is. We all
know with JFX is currently, but what is the future direction? What are
contributors working towards in the long run? I'm sure we've all got our
own personal areas of interest, and it's surely motivational to hold onto a
less than broad idea of this.

Best,
Paul

On 24 May 2018 at 13:00, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. OpenJFX code review policies, etc. (Kevin Rushforth)
>
>
> --
>
> Message: 1
> Date: Wed, 23 May 2018 15:16:49 -0700
> From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
> Subject: OpenJFX code review policies, etc.
> Message-ID: <a753ebbb-b793-9400-2515-37330ee0c...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> To: OpenJFX Developers
>
> As I mentioned in a message last week [1] I would like to restart the
> discussion we started a few months ago [2] around making it easier to
> contribute code to OpenJFX. To this end, I like to make some concrete
> proposals around code review / API review policies.
>
> Before getting to the details, I would like to acknowledge Gluon's
> contributions to the OpenJFX project, specifically those of Johan Vos. I
> am pleased to announce an expanded role for Johan Vos in the OpenJFX
> project. I would like to announce that starting now, Johan is
> effectively a co-lead for the purposes of setting direction, and
> approving new features for the Project.
>
> The short version of the proposal is:
>
> 1. Formalize the concept of Reviewers with an initial list of Reviewers
> and a defined criteria for adding additional Reviewers.
>
> 2. Revised code review policies for different types of changes: simple,
> low-impact fixes (1 Reviewer); higher-impact fixes (2 Reviewers + allow
> time for others to chime in); Features / API changes (CSR approval,
> including approval by a "lead", plus 3 Reviewers for the code)
>
> 3. Streamlining reviews of changes developed in the GitHub sandbox:
> provided that the review policy is followed to before a PR is merged
> into the develop branch in GitHub, a fast-track review can happen
> pointing to the changeset that was merged and the PR, which has review
> comments.
>
> Details follow.
>
> Quoting from my earlier message:
>
> > "Code reviews are important to maintain high-quality contributions,
> > but we recognize that not every type of change needs the same level of
> > review. Without lowering our standards of quality, we want to make it
> > easier to get low-impact changes (simple bug fixes) accepted."
>
> To that end, I propose the following policies. Many of these will
> involve judgment calls, especially when it comes to deciding whether a
> fix is low impact vs. high-impact. I think that's OK. It doesn't have to
> be perfect.
>
> Recommendations
>
> 1. I recommend that we formalize the concept of Reviewers, using the
> OpenJDK Reviewer role for the OpenJFX Project.
>
> A. I will provide an initial list of reviewers to the registrar based on
> past contributions, and also recognizing Committers who have become
> experts in their area. This is the only time we will have such latitude
> as the OpenJDK Bylaws specify the policy we need to follow for
> nominating and voting upon additional Reviewers.
>
> B. We need to set formal guidelines for becoming a Reviewer. The JDK
> uses a threshold of 32 significant contributions. While we don't want to
> relax it too much, one thing I have been discussing informally with a
> few people is that a Committer with, say, 24 commits, who regularly
> participates in reviews, offering good feedback, might be just a good a
> reviewer (maybe even better) than someone with 32 commits who rarely, if
> ever, provides feedback on proposed bug fixes. I'm open for suggestions
> here.
>
> One thing I'd like to add is that we expect Reviewers to feel

Re: openjfx-dev Digest, Vol 78, Issue 28

[Paul Ray Russell]

 >We are looking at the possibility of providing a replacement packaging
tool in OpenJDK.

+1 for this. Or something like a Maven Shade build with an exacting set of
dependency exclusions, and Launch4J would accomplish something similar? Has
the advantage that all the other plugins like resources, and obfuscation
can run in one automated build. I currently use this method.


On 16 May 2018 at 21:28,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Re: OpenJFX status update (Kevin Rushforth)
>2. Re: OpenJFX status update (Michael Ennen)
>3. Re: OpenJFX status update (Kevin Rushforth)
>4. Re: OpenJFX status update (Michael Ennen)
>5. Re: OpenJFX status update (Scott Palmer)
>
>
> --
>
> Message: 1
> Date: Wed, 16 May 2018 12:06:40 -0700
> From: Kevin Rushforth 
> To: Nir Lisker 
> Cc: "openjfx-dev@openjdk.java.net" 
> Subject: Re: OpenJFX status update
> Message-ID: <82914c4a-2349-6251-4d8c-c0b92f8c1...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> On 5/16/2018 11:54 AM, Nir Lisker wrote:
> > What will happen to the JavaDocs? Will they be removed from the EA
> > docs and upon release from the release docs?
>
> Correct. The JDK 11 docs will no longer include JavaFX modules and
> classes. We will need to host separate docs for JavaFX.
>
> -- Kevin
>
>
>
> --
>
> Message: 2
> Date: Wed, 16 May 2018 13:05:04 -0700
> From: Michael Ennen 
> To: Kevin Rushforth 
> Cc: Alan Snyder ,
> "openjfx-dev@openjdk.java.net" 
> Subject: Re: OpenJFX status update
> Message-ID:
> 

Re: Announcing EA builds of standalone JavaFX SDK

[Paul Ray Russell]

ChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at
javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.base/javafx.event.Event.fireEvent(Event.java:198)
at
javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3851)
at
javafx.graphics/javafx.scene.Scene$MouseHandler.access$1200(Scene.java:3579)
at
javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1849)
at
javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2588)
at
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:397)
at
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:295)
at java.base/java.security.AccessController.doPrivileged(Native
Method)
at
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:434)
at
javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:389)
at
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:433)
at
javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:556)
at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:942)
at
javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:175)
at java.base/java.lang.Thread.run(Thread.java:832)

I hope this helps. Looking forwards to a pure Maven build.

Best,
Paul

On 8 May 2018 at 11:30, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Announcing EA builds of standalone JavaFX SDK (Kevin Rushforth)
>2. Re: [11] RFR JDK-8202199 : Provide public, unsupported API
>   for FX Swing interop (Prasanta Sadhukhan)
>3. Re: [11] RFR JDK-8202199 : Provide public, unsupported API
>   for FX Swing interop (Ali Ebrahimi)
>4. Re: Announcing EA builds of standalone JavaFX SDK (Johan Vos)
>5. Re: [11] RFR JDK-8202199 : Provide public, unsupported API
>   for FX Swing interop (Prasanta Sadhukhan)
>6. Re: [11] RFR JDK-8202199 : Provide public, unsupported API
>   for FX Swing interop (Alan Bateman)
>
>
> --
>
> Message: 1
> Date: Mon, 7 May 2018 16:00:19 -0700
> From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> To: "openjfx-dev@openjdk.java.net" <openjfx-dev@openjdk.java.net>
> Subject: Announcing EA builds of standalone JavaFX SDK
> Message-ID: <8ae613b7-bac6-fa44-94e4-7490b0726...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I am pleased to announce the first Early Access build of a standalone
> JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an
> OpenJDK 11 EA build.
>
> If your application is in an unnamed module (i.e., your app is on the
> classpath), you can run your application as follows, after unzipping the
> SDK bundle for your platform.
>
> $ java --module-path $PATH_TO_FX/javafx-sdk-11
> --add-modules=javafx.controls,javafx.fxml MyApp
>
> This assumes you don't need media or web. If you do, then add those
> modules, too. Note that since javafx.web "requires transitive
> javafx.controls", you can omit javafx.controls if you add javafx.web.
>
> If you are running a modular application, then you don't need the
> "--add-modules" option.
>
> Note that this is a stepping stone to javafx modules in a repository
> like Maven.
>
> Please test your applications with the SDK and give us feedback.
>
> Thanks.
>
> -- Kevin
>
> [1] http://jdk.java.net/openjfx/
>
>
>
> ---

Announcing EA builds of standalone JavaFX SDK

[Paul Ray Russell]

Excellent! I'll try to get this working for our game later in the week.

Best,
Paul

Re: native libs in modules

[Paul Ray Russell]

>* I'm thinking about this issue now because I quite like JavaFX and its
*>* future is clearly as a regular Java library, albeit a big one, distributed
*>* either via (not ideal) an SDK or (better) a set of regular libraries
*>* published to a Maven repository.
*>

+1 for this. (-1 for cross posting)

The OP is right IMO, hacky jars containing native payloads seem common.

Re: native libs in modules

[Paul Ray Russell]

 >I'm not sure I understand the question about platform-specific jar files,

Last time I worked on native specifics (which was to package up RXTX dlls
for different OSs / in 64/32 bit) The easiest solution for pure Maven
builds seemed to be, to package DLLs inside a jar. We then used a profile
to control which DLL's were grabbed in different cases. And surely for this
specific case, it would be better to split the native specifics into
separate jars per OS to avoid a huge cross-OS download?

Re: native libs in modules

[Paul Ray Russell]

 >If you use gradle or maven, the same should be achieved using e.g.
>dependencies {
>compile 'javafx:javafx.controls:11.0.0'
>}

So does this mean there a plan to offer this as pure Maven build - or will
it require Gradle? If pure Maven, are the native libs going to be packaged
inside a JAR file?

Best,
Paul


On 30 April 2018 at 13:00, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. native libs in modules (Johan Vos)
>2. WaitForPaintPulse (Tom Eugelink)
>3. Re: native libs in modules (Philip Race)
>
>
> --
>
> Message: 1
> Date: Sun, 29 Apr 2018 17:05:51 +
> From: Johan Vos <johan@gluonhq.com>
> To: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
> Subject: native libs in modules
> Message-ID:
> <CABxFH2EBg3w6Nf3ER5pBW4uhvodiL1Ei_7yEXaxN33eEJ78Xkw@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Now that the OpenJFX SDK that works with Java 11 is about to be released in
> EA, we should think about releasing the modules.
>
> In case you download the OpenJFX SDK, running an app goes like
> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app
>
> If you use gradle or maven, the same should be achieved using e.g.
> dependencies {
> compile 'javafx:javafx.controls:11.0.0'
> }
>
> (ignore the naming and versioning for now)
>
> This will download the javafx controls module and its dependencies from
> e.g. maven central. The javafx controls module info declares a requires
> entry for javafx.base and javafx.graphics so those will be downloaded.
>
> The question is how the native libs should be downloaded. It is possible to
> bundle the native libs with the modules, but there are a number of options
> for dealing with platform-specific libraries:
>
> 1. javafx.graphics contains all native libraries for all platforms.
> 2. a generic javafx.graphics module containing java code only, plus N
> platform-specific modules (or jar) containing the native code. An example
> of how this is used is ND4J:
> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-
> native/1.0.0-SNAPSHOT/
>
> To make it more complex, there are a number of options for e.g. prims
> leading to a number of native libs. Do we want to include all relevant
> options for all platforms?
>
> - Johan
>
>
> --
>
> Message: 2
> Date: Sun, 29 Apr 2018 20:25:02 +0200
> From: Tom Eugelink <t...@tbee.org>
> To: openjfx-dev@openjdk.java.net
> Subject: WaitForPaintPulse
> Message-ID: <eadb4e62-e310-c0cb-da47-50649b647...@tbee.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Is there a way in J9+ to wait for a paint pulse? I'm having problems
> getting my unit tests stable.
>
> Tom
>
>
>
>
> --
>
> Message: 3
> Date: Sun, 29 Apr 2018 16:19:10 -0700
> From: Philip Race <philip.r...@oracle.com>
> To: Johan Vos <johan@gluonhq.com>
> Cc: "openjfx-dev@openjdk.java.net List" <openjfx-dev@openjdk.java.net>
> Subject: Re: native libs in modules
> Message-ID: <5ae652ee.8080...@oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> On 4/29/18, 10:05 AM, Johan Vos wrote:
> > Now that the OpenJFX SDK that works with Java 11 is about to be released
> in
> > EA, we should think about releasing the modules.
> >
> > In case you download the OpenJFX SDK, running an app goes like
> > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app
> >
> > If you use gradle or maven, the same should be achieved using e.g.
> > dependencies {
> >  compile 'javafx:javafx.controls:11.0.0'
> > }
> >
> > (ignore the naming and versioning for now)
> >
> > This will download the javafx controls module and its dependencies from
> > e.g. maven central. The javafx controls module info declares a requires
> > entry for javafx.base and javafx.

Re: Will OpenJFX have a release ready in time for the Java 11 launch?

[Paul Ray Russell]

 +1 :)

"This is imo the most important work right now, and a number of people are
working on it.

I am very positive this [both paths] will be realised before the Java 11
release date. "

On 6 April 2018 at 01:21,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Re: gradle :web:test fails (Kevin Rushforth)
>2. Will OpenJFX have a release ready in time for the Java 11
>   launch? (Mikael Christensen - QIAGEN)
>3. Re: Will OpenJFX have a release ready in time for the Java 11
>   launch? (Kevin Rushforth)
>4. Re: Will OpenJFX have a release ready in time for the Java 11
>   launch? (Johan Vos)
>5. Re: gradle :web:test fails (Nir Lisker)
>6. Re: HEADS-UP: Proposal to bump the minimum boot JDK for FX to
>   JDK 10 (Kevin Rushforth)
>
>
> --
>
> Message: 1
> Date: Thu, 05 Apr 2018 05:01:13 -0700
> From: Kevin Rushforth 
> To: Murali Billa 
> Cc: "openjfx-dev@openjdk.java.net Mailing"
> 
> Subject: Re: gradle :web:test fails
> Message-ID: <5ac61009.9080...@oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Yes, this is very likely the issue. If you take the jfxwebkit.dll from
> the latest EA build of JDK 11 then you should be fine. Alternatively, if
> you have the patience to build webkit from source (at least once) then
> you can use that.
>
> Johan had a good idea that gradle :web:test should produce a warning if
> COMPILE_WEBKIT is false [1].
>
> I just now filed a bug [2] to track this.
>
> -- Kevin
>
> [1]
> https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment-
> 378521501
> [2] https://bugs.openjdk.java.net/browse/JDK-8201176
>
>
> Murali Billa wrote:
> > Hi Lisker,
> >
> > +one more point:
> >
> > I think you are not compiling webkit . The command "gradle :web:test"
> picks the webkit dll from JDK (which can have older versions like 10 / 9) .
> >
> > You can compile webkit  with command " gradle -PCOMPILE_WEBKIT=true
> :web:test" and in this case webkit dll will be picked up from your source
> code repo (not from JDK).
> >
> > Thanks,
> > Murali
> >
> > -Original Message-
> > From: Murali Billa
> > Sent: Thursday, April 05, 2018 10:19 AM
> > To: Nir Lisker ; openjfx-dev@openjdk.java.net
> Mailing 
> > Subject: RE: gradle :web:test fails
> >
> > Hi Lisker,
> >
> > Can you print  the value of  useragentString ? Looks like you are using
> fxversion as 11 (you can print this value from  
> System.getProperty("javafx.runtime.version");)
> but the useragentstring does not contain 11.
> >
> > final WebView webView = new WebView();
> > final WebEngine webEngine = webView.getEngine();
> System.out.println(webEngine.getUserAgent());
> >
> >
> > Thanks,
> > Murali
> > -Original Message-
> > From: Nir Lisker 
> > Sent: Thursday, April 05, 2018 7:03 AM
> > To: openjfx-dev@openjdk.java.net Mailing 
> > Subject: gradle :web:test fails
> >
> > I'm running :web:test in revision 10889 and getting the following failing
> > test:
> >
> > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED
> > java.lang.AssertionError: UserAgentString does not contain JavaFX/11
> > at org.junit.Assert.fail(Assert.java:91)
> > at org.junit.Assert.assertTrue(Assert.java:43)
> > at
> > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(
> MiscellaneousTest.java:441)
> >
> > 379 tests completed, 1 failed, 12 skipped :web:test FAILED
> >
> > Is this known?
> >
> > - Nir
> >
>
>
> --
>
> Message: 2
> Date: Thu, 5 Apr 2018 12:12:32 +
> From: Mikael Christensen - QIAGEN 
> To: "openjfx-dev@openjdk.java.net" 
> Subject: Will OpenJFX have a release ready in time for the Java 11
> launch?
> Message-ID:
>  eurprd05.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> This is a question about Oracle's statement that JavaFX will no longer be
> part of the SDK starting from Java 11:
> https://blogs.oracle.com/java-platform-group/the-future-of-
> javafx-and-other-java-client-roadmap-updates
>
> Is the plan, 

Prism documentation (Nir Lisker)

[Paul Ray Russell]

Yes please for some documentation. And the way that Prism renderer fails:
for example if you supply an OpenGL or D3D texture > max GPU texture size
is difficult to deal with.

There should be a set of catchable Prism Renderer errors.

On 2 April 2018 at 13:00,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Prism documentation (Nir Lisker)
>
>
> --
>
> Message: 1
> Date: Mon, 2 Apr 2018 12:52:56 +0300
> From: Nir Lisker 
> To: Kevin Rushforth 
> Cc: "openjfx-dev@openjdk.java.net Mailing"
> 
> Subject: Prism documentation
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Kevin,
>
> Since Prism is only used internally it has no publicly available
> documentation (none that I could fine). I was wondering if there are any
> design materials or writeups that exist internally and can be released for
> development purpose.
>
> Specifically, I was looking at the d3d pipeline was was baffled by the use
> of self-defined classes (like D3DLight) when d3d already offers classes
> with these classes (D3DLight9).
>
> - Nir
>
>
> End of openjfx-dev Digest, Vol 77, Issue 1
> **
>

Re: Update on enabling JavaFX to work with OpenJDK builds

[Paul Ray Russell]

 "I mentioned our intention to make it easier for OpenJFX to be built,
tested, and run with OpenJDK builds that don't already contain javafx.*
modules."

+1 Great

Re: future content of OpenJFX

[Paul Ray Russell]

I think ref: numbers of developers, the willingness of Oracle to open
JavaFX up to the community has not reached significant numbers. There are a
lot of people who've lost interest in following the framework a long time
ago. If we are going to improve the low level rendering API, (I've a great
deal to say on this - in another thread), and we can improve scene graph
speed etc. Then I think some posts in relevant forums should promote this.

The java game dev. forum would be one such place.
http://www.java-gaming.org/

Re: future content of OpenJFX

[Paul Ray Russell]

+1

* more alignment with mobile
* a clean and lean low-level rendering pipeline API that would allow easier
plugability with upcoming low-level rendering systems

I would like to add a higher level desire

* a consensus that JavaFX will continue to open itself more to integration.
It has a rumour for being closed to integration. I recall the folks at JOGL
concluded this when they tried to integrate, but mostly, I have in mind the
might of JMagick, which could be easily integrated to provide all the image
manipulation that JavaFX so lacks currently.

Perhaps a forum poll would ease a vote?

Re: More community participation in JavaFX

[Paul Ray Russell]

"I think a discussion on "where we should take the platform" is a good
one to have...just not as part of this thread. "

I'm looking forwards to the new thread :)

Re: More community participation in JavaFX

[Paul Ray Russell]

Yeah - I looked at the windows build process recently - which was enough to
dissuade me from starting. I do know JavaFX fairly well, and have a potted
history working in software companies. I'd like to get on-board once I
finish my current game. I'd be interested in game related areas; but
realise these may not be areas of development that JavaFX was ever
intended, or *will* ever be directed to cover. That would be another whole
conversation to have.

If it's the case that JavaFX is to remain a GUI toolkit, with v. limited
graphics abilities: something useful for front-ending business apps, but
not much more, then it needs to be made clearer that this is the aim.

The games community has grown despondent about JavaFX as a framework, which
is a shame. I see evidence of this scattered all over the web. Too many
abandoned projects from 2013 era. It's all bit depressing. It's such a
great framework.

On 2 February 2018 at 00:07,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. More community participation in JavaFX (Kevin Rushforth)
>2. Re: More community participation in JavaFX (Michael Ennen)
>3. Re: More community participation in JavaFX (Richard Steiger)
>
>
> --
>
> Message: 1
> Date: Thu, 01 Feb 2018 15:26:24 -0800
> From: Kevin Rushforth 
> To: "openjfx-dev@openjdk.java.net" 
> Subject: More community participation in JavaFX
> Message-ID: <5a73a220.7030...@oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> To: OpenJFX Developers
>
> We are looking to grow the community of contributors to the OpenJFX
> project, especially serious contributors who will stick around long
> enough to become reviewers, to help us keep the platform vibrant. To
> this end we are looking at ways to encourage more participation and make
> it easier for interested folks to contribute.
>
> We are specifically looking to discuss ideas around the following areas:
>
> * Easing barriers to contribution (e.g., making JavaFX easier to build,
> better documentation, making it easier to test changes)
>
> * Code review policies
>
> * API / feature review policies
>
> * Code review tools (we currently use webrev, but that isn't set in stone)
>
>
> To keep this thread productive, the following are explicitly out of scope:
>
> * Discussion of specific features or bugs that you would like to
> implement (or wish someone else would)
>
> * Discussion about platform support
>
> * Discussion about version control systems (e.g., hg versus git),
> hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus
> github), etc...at least for now. We are aware of the potential benefits
> of such changes, but we'd like to focus our efforts on higher-leverage
> things we can do in the short term.
>
> * Discussion about the requirement of a signed OCA to become a contributor
>
> * Off-topic or tangential commentary about OpenJFX that isn't directly
> related to the topic at hand
>
>
> As a starting point for discussion, here are some areas I think need
> improvement; I'm sure there are others:
>
> I. Helping contributors get started
>
> It isn?t as easy to get started with OpenJFX as it should be. We want to
> make it easier for potential OpenJFX contributors to get started. Here
> are some ideas that I think might help:
>
> * Improve the build instructions / Wiki (I made a first start, but there
> is much more to be done)
>
> * Make the build itself more resilient where possible, and provide
> better error messages, specifically when dealing with native compilers
> and libraries
>
> * Add an option to skip building all native code and use prebuilt
> binaries (like we do already for media and webkit); this is tracked by
> JDK-8092279, but it hasn?t been looked at recently
>
> * Make it easier to build / test your local OpenJFX build using an
> OpenJDK build (currently the only way to do this is to build OpenJDK
> locally, after using configure to point to your just-built javafx.*
> modules).
>
> * Provide step-by-step instructions for how to make a contribution,
> including testing requirements; a lot of the pieces are there, but are
> out of date or scattered in several places. As part of this, we could
> have a section on how to contribute docs, samples or tests, since that
> is often a good place to start.
>
> * Provide a 

Community builds

[Paul Ray Russell]

Hi OpenJFX -

Anyone point me to a community build for Java9 with JavaFX already added? I
understand I that i can't just overlay one on the other now? I'm seeking
windows right now, but will need to target Linux and Mac in the end.

Best,
Paul

Re: Innovation again (was Re: Text classes)

[Paul Ray Russell]

Hi John,

>>>Re: Significant improvements in scene graph rendering speed using modern
game-engine style structures and algorithms.

Agree,

Also, I haven't been feeling the enthusiasm either. It's a mood that's
permeating the user base. You just have to scout YouTube for JavaFX games,
to read the mood. It's all feeling a bit like the last throws of Swing did.

To my mind, JavaFX is the perfect 2D gaming platform, it just misses better
lighting.

I'd like to see the scene graph speed improved, and more work on the
lighting for games. I'm busy working on our game : kattrunonthetide.com (
https://www.facebook.com/KattGame/) : Javafx is proving to be a great
platform. If one "applies" azimuth lights to a flat canvas scene, (one with
no scene graph) the bump mapping seems automatic.

https://drive.google.com/file/d/1y0WHd5LiIWu1qSvRiHyPrPKBP2fp4gXL/view?usp=sharing

But, the effect is ill documented, and I think it would be great to have
more work in the this area.

Some way to access pixels at high speed would be brilliant too. I know
nothing of the Java shading language, JSL, and still think this would be a
great addition if exposed.

Currently something like LibGDX is a much better choice for games writing
than JavaFX. Eyes to OpenGL, but I still think JavaFX with all it's great
UI support (and FXGL library) should still be a good choice.

Best,
Paul


On 6 December 2017 at 08:36, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Re: Innovation again (was Re: Text classes) (John-Val Rose)
>2. RE: Innovation again (was Re: Text classes) (Markus KARG)
>3. Re: Innovation again (was Re: Text classes) (Mario Torre)
>4. RE: Innovation again (was Re: Text classes) (Markus KARG)
>
>
> --
>
> Message: 1
> Date: Wed, 6 Dec 2017 17:16:07 +1100
> From: John-Val Rose <johnvalr...@gmail.com>
> To: Philip Race <philip.r...@oracle.com>
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Innovation again (was Re: Text classes)
> Message-ID: <2fa8027d-79b1-4339-8bca-6b5cb58d3...@gmail.com>
> Content-Type: text/plain;   charset=utf-8
>
> Absolutely - there needs to be a viable community that is not just Oracle.
>
> So, is there one? If not, how do we build one?
>
> OK, so let me rephrase my earlier email:
>
> I am willing to work with *anyone* (within Oracle or not) on the features
> that the community craves, such as those I listed (and any others). Not
> just because ?many hands make light work? but because I don?t know
> everything (or even close) and I need the knowledge and skills of others to
> assist me. Not to mention that I have only 24 hours in a day like everyone
> else and, also like everyone else, some of that time has to be devoted to
> earning an income.
>
> So, if there?s anyone reading this who has the time, the skills, the
> commitment and the passion to work hard (in your own time) to get these
> tasks done then please contact me privately.
>
> > On 6 Dec 2017, at 16:50, Philip Race <philip.r...@oracle.com> wrote:
> >
> > There needs to be a viable community that is not just Oracle to support
> you here ..
> > I think everyone has come to be dependent on Oracle to "be there".
> > But if there is a specific community need that Oracle doesn't see as
> essential, then the community should help out.
> >
> > -phil.
> >
> >> On 12/5/17, 9:27 PM, John-Val Rose wrote:
> >> Well, that?s all fine but you didn?t address the issue of working with
> someone within Oracle to get these innovations done.
> >>
> >> Sure, I could just toil away by myself but clearly it would be better
> all around if there was someone with much more extensive knowledge of
> JavaFX and its internals who was accessible when required.
> >>
> >> I would assume that a member of the Oracle JavaFX team would be such a
> person. If not, then who?
> >>
> >>> On 6 Dec 2017, at 15:53, Philip Race<philip.r...@oracle.com>  wrote:
> >>>
> >>> I think looking at it as an Oracle-owned and controlled project maybe
> t

Decora JSL shaders

[Paul Ray Russell]

Sorry for resend. I'm not trying to spam, but I didn't change the subject
of the email.

Ref: http://labonnesoupe.org/static/code/

I notice project Decora: are there any plans for JSL shader language
support for JavaFX in the near future?

Thanks,

On 15 November 2017 at 12:00, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. Re: openjfx-dev Digest, Vol 72, Issue 14 (Paul Ray Russell)
>2. [10] Review Request: JDK-8184270 NullPointerException when
>   using Combobox in combination with accessibility app
>   (Prem Balakrishnan)
>
>
> --
>
> Message: 1
> Date: Tue, 14 Nov 2017 14:38:35 +
> From: Paul Ray Russell <paulrussel...@gmail.com>
> To: openjfx-dev@openjdk.java.net
> Subject: Re: openjfx-dev Digest, Vol 72, Issue 14
> Message-ID:
> <CA+oj-NsjEPsbubXdgD1mZ52EUvyR4dmaXsP
> hd91ckhtteby...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Ref: http://labonnesoupe.org/static/code/
>
> I notice project Decora: are there any plans for JSL shader language
> support for JavaFX in the near future?
>
> Thanks,
> Best,
> Paul
>
> On 14 November 2017 at 12:00, <openjfx-dev-requ...@openjdk.java.net>
> wrote:
>
> > Send openjfx-dev mailing list submissions to
> > openjfx-dev@openjdk.java.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> > or, via email, send a message with subject or body 'help' to
> > openjfx-dev-requ...@openjdk.java.net
> >
> > You can reach the person managing the list at
> > openjfx-dev-ow...@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. [10] Review request for 8187594: Media crashes with
> >   libavcodec 57 on Ubuntu 17.04 32-bit (Alexander Matveev)
> >2. Re: [10] Review request for 8187594: Media crashes with
> >   libavcodec 57 on Ubuntu 17.04 32-bit (Kevin Rushforth)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 13 Nov 2017 13:26:24 -0800
> > From: Alexander Matveev <alexander.matv...@oracle.com>
> > To: David DeHaven <david.deha...@oracle.com>, Kevin Rushforth
> > <kevin.rushfo...@oracle.com>
> > Cc: openjfx-dev@openjdk.java.net
> > Subject: [10] Review request for 8187594: Media crashes with
> > libavcodec 57 on Ubuntu 17.04 32-bit
> > Message-ID: <10b2da88-9e8a-83b8-84a3-76f609aed...@oracle.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hi Kevin and David,
> >
> > Please review the following:
> > http://cr.openjdk.java.net/~almatvee/8187594/webrev.00
> >
> > Fixed crash by preloading avplugin on separate thread on 32-bit Linux.
> >
> > Thanks,
> > Alexander
> >
> >
> > --
> >
> > Message: 2
> > Date: Mon, 13 Nov 2017 14:31:56 -0800
> > From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> > To: Alexander Matveev <alexander.matv...@oracle.com>
> > Cc: openjfx-dev@openjdk.java.net
> > Subject: Re: [10] Review request for 8187594: Media crashes with
> > libavcodec 57 on Ubuntu 17.04 32-bit
> > Message-ID: <5a0a1d5c.9070...@oracle.com>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Looks good.
> >
> > +1
> >
> > -- Kevin
> >
> >
> > Alexander Matveev wrote:
> > > Hi Kevin and David,
> > >
> > > Please review the following:
> > > http://cr.openjdk.java.net/~almatvee/8187594/webrev.00
> > >
> > > Fixed crash by preloading avplugin on separate thread on 32-bit Linux.
> > >
> > > Thanks,
> > > Alex

Re: openjfx-dev Digest, Vol 72, Issue 14

[Paul Ray Russell]

Ref: http://labonnesoupe.org/static/code/

I notice project Decora: are there any plans for JSL shader language
support for JavaFX in the near future?

Thanks,
Best,
Paul

On 14 November 2017 at 12:00, <openjfx-dev-requ...@openjdk.java.net> wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@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. [10] Review request for 8187594: Media crashes with
>   libavcodec 57 on Ubuntu 17.04 32-bit (Alexander Matveev)
>2. Re: [10] Review request for 8187594: Media crashes with
>   libavcodec 57 on Ubuntu 17.04 32-bit (Kevin Rushforth)
>
>
> --
>
> Message: 1
> Date: Mon, 13 Nov 2017 13:26:24 -0800
> From: Alexander Matveev <alexander.matv...@oracle.com>
> To: David DeHaven <david.deha...@oracle.com>, Kevin Rushforth
> <kevin.rushfo...@oracle.com>
> Cc: openjfx-dev@openjdk.java.net
> Subject: [10] Review request for 8187594: Media crashes with
> libavcodec 57 on Ubuntu 17.04 32-bit
> Message-ID: <10b2da88-9e8a-83b8-84a3-76f609aed...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Kevin and David,
>
> Please review the following:
> http://cr.openjdk.java.net/~almatvee/8187594/webrev.00
>
> Fixed crash by preloading avplugin on separate thread on 32-bit Linux.
>
> Thanks,
> Alexander
>
>
> --
>
> Message: 2
> Date: Mon, 13 Nov 2017 14:31:56 -0800
> From: Kevin Rushforth <kevin.rushfo...@oracle.com>
> To: Alexander Matveev <alexander.matv...@oracle.com>
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: [10] Review request for 8187594: Media crashes with
> libavcodec 57 on Ubuntu 17.04 32-bit
> Message-ID: <5a0a1d5c.9070...@oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Looks good.
>
> +1
>
> -- Kevin
>
>
> Alexander Matveev wrote:
> > Hi Kevin and David,
> >
> > Please review the following:
> > http://cr.openjdk.java.net/~almatvee/8187594/webrev.00
> >
> > Fixed crash by preloading avplugin on separate thread on 32-bit Linux.
> >
> > Thanks,
> > Alexander
>
>
> End of openjfx-dev Digest, Vol 72, Issue 14
> ***
>

Thanks to the reviewer for checking out my bug post

[Paul Russell]

Hi JavaFX mailing list,

I posted this bug:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189180

I really appreciate how quickly this was looked into. However, I still
can't see how this expected behaviour, unless there is a better way to
create modal windows? My application is a game, and my hand-drawn cursor is
distinct from the windows system cursor. Hence, this behaviour looks
appalling, I've switched to

.initModality(Modality.NONE);

But disabling parent windows controls is cluttering my code.

Thanks

WebGL support in JavaFX WebView

[Kondratko, Paul]

Hi,

WebView that comes with JavaFX does not support WebGL. I understand from other 
online posts that there is no plan to add WebGL support.

Is anyone familiar with a webView plugin that supports WebGL? Ideally open 
source.

Thank you and Best Regards,
Paul




NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or 
views contained herein are not intended to be, and do not constitute, advice 
within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and 
Consumer Protection Act. If you have received this communication in error, 
please destroy all electronic and paper copies; do not disclose, use or act 
upon the information; and notify the sender immediately. Mistransmission is not 
intended to waive confidentiality or privilege. Morgan Stanley reserves the 
right, to the extent permitted under applicable law, to monitor electronic 
communications. This message is subject to terms available at the following 
link: http://www.morganstanley.com/disclaimers If you cannot access these 
links, please notify us by reply message and we will send the contents to you. 
By messaging with Morgan Stanley you consent to the foregoing.

Re: Handling Enter key presses on Buttons in JavaFX

[Paul Furbacher]

On June 7, 2016 at 6:41:37 PM EDT, Tomas Mikula  wrote: 

> This would be very confusing if you had two TextFields and after entering
> text into the first one the user hits Enter and the form gets submitted
> with empty second field.

Apple’s HIG documentation clarifies how such a situation should be handled: see 
https://goo.gl/AwhKiW.

Quoting the relevant paragraph: "Don’t use a default button if you use the 
Return key in the dialog’s text fields. Having two behaviors for one key can 
confuse users and make the interface less predictable. Also, users might press 
Return one too many times and dismiss the dialog (and activate the default 
button) without meaning to.”

Beyond that and in reference to the entire discussion, I would suggest that 
JavaFX follow the platform behavior as closely as possible. But in complex 
dialogs in which the user is presented with controls which respond to the 
“Enter/Return” key, it is probably up to the programmer to be aware of the 
guidelines, and make the necessary adjustment by making sure that none of the 
buttons in the button bar are set to “default button”.

As noted, OS X configures the key press triggers for actions of the default 
(“Return”) and focused button (space) differently. Whether *all* users are 
aware of, or understand, this is probably not the point. For those who do know 
how Apple prescribes how dialog buttons should work, it has become ingrained 
behavior to hit the spacebar to fire the focused button. However, note that the 
ability to have a focused button other than the default depends on the user 
having activated “Full Keyboard Access — All controls” in the Accessibility 
preferences. Only then can one can navigate through the dialog controls to 
focus a non-default button, such as “Don’t Save” in TextWrangler. My guess is 
that few Mac users, other than programmers, have enabled this functionality. 
(It may be too much to ask — or impossible — to have JavaFX respect the 
accessibility settings: that is, not allow tabbed navigation across the buttons 
if the “All controls” setting is not in force.)

[I haven’t used Windows in a very long time, so I cannot comment on how it, 
across its many versions, prescribes how dialog buttons should work.]

Bug ID: JDK-8131151 -- updated test code

[Paul Furbacher]

Because of the move to JBS, we commoners can no longer comment or add more info 
on bug reports we submit. It seems we are stuck with bothering this list with 
such stuff.

For Bug ID: JDK-8131151 : Pressing ESC in a nested alert closes self and 
parent alert”, I decided to do some more investigating — is this just something 
that happens with file choosers? So, I extended the test code and discovered it 
is not limited to such circumstances. 

Here’s the updated code which I hope provides a pretty thorough look into the 
problem but which I am not able to provide as an update on JBS. Sorry to make 
more work for someone else.


import javafx.application.Application;
import javafx.application.Platform;
import javafx.collections.ObservableList;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.control.Alert;
import javafx.scene.control.Alert.AlertType;
import javafx.scene.control.Button;
import javafx.scene.control.ButtonType;
import javafx.scene.control.Label;
import javafx.scene.layout.VBox;
import javafx.stage.DirectoryChooser;
import javafx.stage.Stage;

/**
 * As of at least JDK 1.8.0_60 early releases (maybe earlier, e.g. 1.8.0_40), 
if you launch a dialog
 * (e.g., file/dir chooser from a JavaFX Alert, and the user presses ESC to 
close the dialog, the
 * alert will also close.
 * 
 * In this demo, I show that the behavior occurs in any type of child alert (or 
file browser) which 
 * presents an ButtonType.CANCEL button. It does not occur if such a button is 
absent.
 * 
 * This is unexpected behavior.
 * 
 * @author Paul Furbacher
 *
 */
public class DemoApp extends Application {

private static final String VBOX_STYLE = -fx-padding: 12px; -fx-alignment: 
center;

@Override
public void start(Stage primaryStage) throws Exception {

VBox vbox = new VBox(16);
vbox.setStyle(VBOX_STYLE);
Label label = new Label(Press button to launch dialog);
Button button = new Button(Save ...);
button.setOnAction(ae - {
createAndShowDirChooser();
});
vbox.getChildren().addAll(label, button);

primaryStage.setScene(new Scene(vbox));
primaryStage.sizeToScene();
primaryStage.show();
}

protected void createAndShowDirChooser() {
Alert alert = new Alert(AlertType.INFORMATION); // or try other types, 
such as
// 
AlertType.CONFIRMATION.
// Except for AlertType.NONE, they all exhibit the problem.

alert.setTitle(Demo Alert);
Button browseButton = new Button(Browse...);
browseButton.setOnAction(ae - {
DirectoryChooser chooser = new DirectoryChooser();
chooser.showDialog(browseButton.getScene().getWindow());
});

VBox vbox = new VBox(16);
vbox.setStyle(VBOX_STYLE);
vbox.getChildren().addAll(
new Label(Press ESC in the directory chooser.\n\n
+ Unexpected result: this dialog will also close!\n\n),
browseButton,
new Label(Test whether this also occurs with child 'Alert' dialogs 
of different types.\n\n
+ Yes, it does if a Cancel button is present.));

ObservableListNode children = vbox.getChildren();
for (AlertType alertType : AlertType.values()) {
Button childAlertButton = new Button(Child Alert ( + 
alertType.name() + ));
childAlertButton.setOnAction(ae - {
createAndShowChildAlert(alertType);
});
children.add(childAlertButton);
}
alert.getDialogPane().setContent(vbox);
Platform.runLater(() - browseButton.requestFocus());
alert.showAndWait();
}

private void createAndShowChildAlert(AlertType alertType) {
Alert alert = new Alert(alertType);
alert.setTitle(Child Alert :: type =  + alertType.name());
alert.setContentText(Just press ESC to close.);
if (alertType.equals(AlertType.NONE)) {
alert.setContentText(alert.getContentText().concat(
\n\n(Normally, AlertType.NONE has no buttons. We added one 
here 
+ to demonstrate that it is the presence of a 
ButtonType.CANCEL button which prompts this buggy behavior.));
alert.getButtonTypes().add(ButtonType.CANCEL);
}

alert.showAndWait();
}

public static void main(String[] args) {
Application.launch(args);
}

}




Paul Furbacher