Building OpenJFX on clean install of CentOS 7

2019-10-16 Thread Michael Franz 
Hi,

I did a clean install of CentOS 7, updated, added the necessary tools and
then cloned the repo and ran the default build.  I get the following errors:
/home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:598:1:
error: unused parameter ‘event’ [-Werror=unused-parameter]
 glass_gdk_master_pointer_grab(GdkEvent *event, GdkWindow *window,
GdkCursor *cursor) {
 ^
/home/test00/Source/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp:628:1:
error: unused parameter ‘event’ [-Werror=unused-parameter]
 glass_gdk_master_pointer_ungrab(GdkEvent *event) {
 ^
cc1plus: all warnings being treated as errors

> Task :graphics:ccLinuxGlassGlassgtk2 FAILED

Is this expected?  I have not found any documentation specifing the minimum
version of gcc/g++ and wonder if I need to upgrade? I am using g++ (GCC)
4.8.5 20150623 (Red Hat 4.8.5-39).  Also, other native code in the build
are treating the unused-parameter as a warning.  Why is this module
different?
/home/test00/Source/jfx/modules/javafx.graphics/src/main/native-font/pango.c:429:26:
warning: unused parameter ‘that’ [-Wunused-parameter]
 (JNIEnv *env, jclass that, jlong arg0)


Here are the detailed steps I followed:
0. sudo yum update
1. sudo yum install git bison flex pkgconfig gtk2-devel gtk3-devel
pango-devel freetype-devel libXtst-devel java-11-openjdk-devel ant gcc-c++
libstdc++-static
2. sudo alternatives --config java
  - specify Java 11
3. git clone https://github.com/openjdk/jfx.git
4. cd jfx
5. bash ./gradelw

Any suggestions is appreciated.

Michael

Change Priority of JDK-8231513

2019-10-16 Thread Sebastian Stenzel 
I would like to ask whether it doesn't make sense to give this issue a little 
more attention than P4:

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

Essentially, as Kevin Rushforth confirmed in the Ticket, any JavaFX application 
will trigger a warning on the latest stable macOS release that it is requesting 
permissions to an API to receive key events.

I want to stress that denying this permission will not impair the functionality 
of any JavaFX controls in any way.

Nevertheless this warning lets any JavaFX application appear as a malware. This 
is especially worrying for productivity apps used in enterprise environments. 
The only thing downstream developers can do atm is fingerpointing at JavaFX, 
which harms its spread as a UI frameworks for cross platform dev.

I suggest to solve this earlier than with openjfx-14, since it will affect any 
JavaFX app for any macOS Catalina user.

See related discussions:
- https://forums.developer.apple.com/thread/123797
- 
https://stackoverflow.com/questions/58094615/javafx-tornadofx-cause-keystroke-receiving-prompt-on-macos-10-15-catalina

Re: RFR: 8211308: Support HTTP/2 in WebView

2019-10-16 Thread Kevin Rushforth 
On Wed, 16 Oct 2019 18:10:00 GMT, Kevin Rushforth  wrote:

> On Wed, 16 Oct 2019 17:58:32 GMT, Arunprasad Rajkumar  
> wrote:
> 
>> On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg  
>> wrote:
>> 
>>> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar 
>>>  wrote:
>>> 
 On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos  wrote:
 
> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar 
>  wrote:
> 
>> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar 
>>  wrote:
>> 
>>> The goal of this enhancement is to use new [HttpClient 
>>> APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html)
>>>  available from JDK 11.
>>> 
>>> Reference:
>>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html
>>> [2] 
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
>>> 
>>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work 
>>> correctly due to the dependency on following issues,
>>> 
>>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable 
>>> to connect to https://google.com using java.net.HttpClient
>>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 
>>> 204 responses with Content-Length:0
>>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) 
>>> java.net.http HTTP client should allow specifying Origin and Referer 
>>> headers
>>> 
>>>  Task List
>>> - [x] simple GET requests
>>> - [x] Runtime setting to fallback to legacy client
>>> - [ ] Runtime settings to use *only* HTTP/1.1
>>> - [x] sync requests
>>> - [x] Error Handling & Propagation
>>> - [x] POST with form data
>>> - [x] AccessController association for HttpClient.sendAsync / send
>>> - [x] Redirection
>>> - [ ] Check for possibilities to write unit tests 
>>> - [ ] Sync request handling from WebCore java platform layer
>>> - [x] Make use of singleton instance of direct ByteBuffer instead of 
>>> using allocator pool
>>> - [x] gzip, deflate encoding support
>>> 
>>>  HTTP/2 Test pages
>>> - http://www.http2demo.io
>>> - https://http2.akamai.com/demo
>>> - https://http2.golang.org
>>> - https://google.com
>>> 
>>>  Redirection Test
>>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7
>>> 
>>> More details are available at 
>>> https://github.com/javafxports/openjdk-jfx/pull/247.
>>> 
>>> 
>>> 
>>> Commits:
>>>  - 1798a661: 8211308: Support HTTP/2 in WebView
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/14/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8211308
>>>   Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/14.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14
>> 
>> Still few changes need to be done as [suggested 
>> by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613)
>>  @kevinrushforth.
> 
> Good work. Should the title be prefixed with WIP until it's ready for 
> review, so that Skara will send the RFR when it is ready for review?
 
 I was wondering why @skara had sent the RFR when the PR is still in draft 
 stage. Actually @skara should consider the "Draft" attribute associated 
 with the PR.
>>> 
>>> Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to 
>>> track this.
>> 
>> @jfx team, now it is ready for a fresh review :)
> 
> @guruhb please also review this.

I note that this change needs two reviewers (so should not be integrated until 
there are two approved reviews).

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

Re: RFR: 8211308: Support HTTP/2 in WebView

2019-10-16 Thread Kevin Rushforth 
On Wed, 16 Oct 2019 17:58:32 GMT, Arunprasad Rajkumar  
wrote:

> On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg  
> wrote:
> 
>> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar 
>>  wrote:
>> 
>>> On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos  wrote:
>>> 
 On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar 
  wrote:
 
> On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar 
>  wrote:
> 
>> The goal of this enhancement is to use new [HttpClient 
>> APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html)
>>  available from JDK 11.
>> 
>> Reference:
>> [1] https://openjdk.java.net/groups/net/httpclient/intro.html
>> [2] 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
>> 
>> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work 
>> correctly due to the dependency on following issues,
>> 
>> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable 
>> to connect to https://google.com using java.net.HttpClient
>> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 
>> 204 responses with Content-Length:0
>> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) 
>> java.net.http HTTP client should allow specifying Origin and Referer 
>> headers
>> 
>>  Task List
>> - [x] simple GET requests
>> - [x] Runtime setting to fallback to legacy client
>> - [ ] Runtime settings to use *only* HTTP/1.1
>> - [x] sync requests
>> - [x] Error Handling & Propagation
>> - [x] POST with form data
>> - [x] AccessController association for HttpClient.sendAsync / send
>> - [x] Redirection
>> - [ ] Check for possibilities to write unit tests 
>> - [ ] Sync request handling from WebCore java platform layer
>> - [x] Make use of singleton instance of direct ByteBuffer instead of 
>> using allocator pool
>> - [x] gzip, deflate encoding support
>> 
>>  HTTP/2 Test pages
>> - http://www.http2demo.io
>> - https://http2.akamai.com/demo
>> - https://http2.golang.org
>> - https://google.com
>> 
>>  Redirection Test
>> - https://www.httpwatch.com/httpgallery/redirection/#showExample7
>> 
>> More details are available at 
>> https://github.com/javafxports/openjdk-jfx/pull/247.
>> 
>> 
>> 
>> Commits:
>>  - 1798a661: 8211308: Support HTTP/2 in WebView
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/14/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8211308
>>   Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/14.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14
> 
> Still few changes need to be done as [suggested 
> by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613)
>  @kevinrushforth.
 
 Good work. Should the title be prefixed with WIP until it's ready for 
 review, so that Skara will send the RFR when it is ready for review?
>>> 
>>> I was wondering why @skara had sent the RFR when the PR is still in draft 
>>> stage. Actually @skara should consider the "Draft" attribute associated 
>>> with the PR.
>> 
>> Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to 
>> track this.
> 
> @jfx team, now it is ready for a fresh review :)

@guruhb please also review this.

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

Re: RFR: 8211308: Support HTTP/2 in WebView

2019-10-16 Thread Arunprasad Rajkumar 
On Fri, 11 Oct 2019 11:21:08 GMT, Robin Westberg  wrote:

> On Fri, 11 Oct 2019 07:01:48 GMT, Arunprasad Rajkumar  
> wrote:
> 
>> On Fri, 11 Oct 2019 06:44:09 GMT, Johan Vos  wrote:
>> 
>>> On Fri, 11 Oct 2019 06:18:38 GMT, Arunprasad Rajkumar 
>>>  wrote:
>>> 
 On Fri, 11 Oct 2019 06:07:14 GMT, Arunprasad Rajkumar 
  wrote:
 
> The goal of this enhancement is to use new [HttpClient 
> APIs](https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html)
>  available from JDK 11.
> 
> Reference:
> [1] https://openjdk.java.net/groups/net/httpclient/intro.html
> [2] 
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> 
> Though this uses JDK 11 HttpClient APIs, it needs latest JDK 12 to work 
> correctly due to the dependency on following issues,
> 
> [JDK-8218546](https://bugs.openjdk.java.net/browse/JDK-8218546) Unable to 
> connect to https://google.com using java.net.HttpClient
> [JDK-8218662](https://bugs.openjdk.java.net/browse/JDK-8218662) Allow 204 
> responses with Content-Length:0
> [JDK-8203850](https://bugs.openjdk.java.net/browse/JDK-8203850) 
> java.net.http HTTP client should allow specifying Origin and Referer 
> headers
> 
>  Task List
> - [x] simple GET requests
> - [x] Runtime setting to fallback to legacy client
> - [ ] Runtime settings to use *only* HTTP/1.1
> - [x] sync requests
> - [x] Error Handling & Propagation
> - [x] POST with form data
> - [x] AccessController association for HttpClient.sendAsync / send
> - [x] Redirection
> - [ ] Check for possibilities to write unit tests 
> - [ ] Sync request handling from WebCore java platform layer
> - [x] Make use of singleton instance of direct ByteBuffer instead of 
> using allocator pool
> - [x] gzip, deflate encoding support
> 
>  HTTP/2 Test pages
> - http://www.http2demo.io
> - https://http2.akamai.com/demo
> - https://http2.golang.org
> - https://google.com
> 
>  Redirection Test
> - https://www.httpwatch.com/httpgallery/redirection/#showExample7
> 
> More details are available at 
> https://github.com/javafxports/openjdk-jfx/pull/247.
> 
> 
> 
> Commits:
>  - 1798a661: 8211308: Support HTTP/2 in WebView
> 
> Changes: https://git.openjdk.java.net/jfx/pull/14/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/14/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8211308
>   Stats: 1161 lines in 14 files changed: 876 ins; 217 del; 68 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/14.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14
 
 Still few changes need to be done as [suggested 
 by](https://github.com/javafxports/openjdk-jfx/pull/247#pullrequestreview-283699613)
  @kevinrushforth.
>>> 
>>> Good work. Should the title be prefixed with WIP until it's ready for 
>>> review, so that Skara will send the RFR when it is ready for review?
>> 
>> I was wondering why @skara had sent the RFR when the PR is still in draft 
>> stage. Actually @skara should consider the "Draft" attribute associated with 
>> the PR.
> 
> Good point, I've created https://bugs.openjdk.java.net/browse/SKARA-129 to 
> track this.

@jfx team, now it is ready for a fresh review :)

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

Re: [Rev 01] RFR: WIP: 8211308: Support HTTP/2 in WebView

2019-10-16 Thread Arunprasad Rajkumar 
The pull request has been updated with additional changes.



Added commits:
 - 1832c2db: Incorporate fixes provided by @kcr

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/14/files
  - new: https://git.openjdk.java.net/jfx/pull/14/files/1798a661..1832c2db

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

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

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

Re: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing

2019-10-16 Thread Arunprasad Rajkumar 
On Wed, 16 Oct 2019 15:29:05 GMT, Kevin Rushforth  wrote:

> On Wed, 16 Oct 2019 15:21:55 GMT, Arunprasad Rajkumar  
> wrote:
> 
>> On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar 
>>  wrote:
>> 
>>> 8232158: [macOS] Fallback to command line tools if xcode is missing
>>> 
>>> 
>>> 
>>> Commits:
>>>  - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode 
>>> is missing
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/13/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232158
>>>   Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/13.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13
>> 
>> @kevinrushforth Am I missing anything here which prevents the review process?
> 
> No, I have just been swamped the last few days. It's on my list to review. 
> Sorry for the delay.

Thanks @kevin.

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

Re: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing

2019-10-16 Thread Kevin Rushforth 
On Wed, 16 Oct 2019 15:21:55 GMT, Arunprasad Rajkumar  
wrote:

> On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar  
> wrote:
> 
>> 8232158: [macOS] Fallback to command line tools if xcode is missing
>> 
>> 
>> 
>> Commits:
>>  - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is 
>> missing
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/13/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232158
>>   Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/13.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13
> 
> @kevinrushforth Am I missing anything here which prevents the review process?

No, I have just been swamped the last few days. It's on my list to review. 
Sorry for the delay.

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

Re: RFR: 8232378: change JavaFX release version in 13-dev to 13.0.1

2019-10-16 Thread Kevin Rushforth 

+1

On 10/16/2019 7:42 AM, Johan Vos wrote:

Please review http://cr.openjdk.java.net/~jvos/8232378/webrev.00/ which
fixes https://bugs.openjdk.java.net/browse/JDK-8232378

Thanks,

- Johan

Re: RFR: 8232158: [macOS] Fallback to command line tools if xcode is missing

2019-10-16 Thread Arunprasad Rajkumar 
On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar  
wrote:

> 8232158: [macOS] Fallback to command line tools if xcode is missing
> 
> 
> 
> Commits:
>  - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is 
> missing
> 
> Changes: https://git.openjdk.java.net/jfx/pull/13/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/13/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232158
>   Stats: 33 lines in 1 file changed: 15 ins; 1 del; 17 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/13.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/13/head:pull/13

@kevinrushforth Am I missing anything here which prevents the review process?

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

RFR: 8232378: change JavaFX release version in 13-dev to 13.0.1

2019-10-16 Thread Johan Vos 
Please review http://cr.openjdk.java.net/~jvos/8232378/webrev.00/ which
fixes https://bugs.openjdk.java.net/browse/JDK-8232378

Thanks,

- Johan

Re: RFR: 8232377: Change JavaFX release version in 11-dev to 11.0.5

2019-10-16 Thread Kevin Rushforth 

+1

On 10/16/2019 7:24 AM, Johan Vos wrote:

Please review the webrev for bumpding the JavaFX release version for 11-dev
to 11.0.5 [1], available at [
2]

Thanks,

- Johan

[1] https://bugs.openjdk.java.net/browse/JDK-8232377
[2] http://cr.openjdk.java.net/~jvos/8232377/webrev.00/

RFR: 8232377: Change JavaFX release version in 11-dev to 11.0.5

2019-10-16 Thread Johan Vos 
Please review the webrev for bumpding the JavaFX release version for 11-dev
to 11.0.5 [1], available at [
2]

Thanks,

- Johan

[1] https://bugs.openjdk.java.net/browse/JDK-8232377
[2] http://cr.openjdk.java.net/~jvos/8232377/webrev.00/

Re: [14] RFR: Request to sync October 2019 CPU changes into jfx

2019-10-16 Thread Johan Vos 
+1

On Tue, Oct 15, 2019 at 6:42 PM Kevin Rushforth 
wrote:

> Johan and Phil,
>
> I request approval to sync changes from to the just-released October
> 2019 CPU release into 'jfx'. Here is the aggregate set of changes for
> the fixes:
>
> https://github.com/kevinrushforth/jfx/compare/64aaeb8...bada612
>
> NOTE: Since this is an integration of already-reviewed fixes into the
> jfx repo, I will push it directly rather than via a pull request.
>
> -- Kevin
>
>

Re: [11][13] RFR: Request to backport October 2019 CPU changes

2019-10-16 Thread Johan Vos 
+1

On Tue, Oct 15, 2019 at 6:43 PM Kevin Rushforth 
wrote:

> Hi Johan,
>
> I request approval to backport the changes from the just-released April
> 2019 CPU to 11-dev and 13-dev.
>
> https://cr.openjdk.java.net/~kcr/cpu-1910-sync/11-dev/webrev/
> https://cr.openjdk.java.net/~kcr/cpu-1910-sync/13-dev/webrev/
>
> Each is a straight backport (patch applies cleanly) of the one FX fix
> that went into the October CPU.
>
> Thanks.
>
> -- Kevin
>
>

Re: RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

2019-10-16 Thread Kevin Rushforth 
On Wed, 16 Oct 2019 13:07:45 GMT, Jeanette Winzenburg  
wrote:

> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
> 
> The issue is that default/cancel button on a scene are triggered even though 
> a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug 
> for details on both cause and fix.
> 
> There are additional/changed tests to verify the fix. All old tests are 
> passing.
> 
> 
> 
> Commits:
>  - 93556393: Fix: VK_ENTER not consumed by TextField when default Button 
> exists
> 
> Changes: https://git.openjdk.java.net/jfx/pull/15/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/15/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8207759
>   Stats: 553 lines in 8 files changed: 528 ins; 20 del; 5 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/15.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15

@aghaisas can you review this as well?

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

RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

2019-10-16 Thread Jeanette Winzenburg 
This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759

The issue is that default/cancel button on a scene are triggered even though a 
onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for 
details on both cause and fix.

There are additional/changed tests to verify the fix. All old tests are passing.



Commits:
 - 93556393: Fix: VK_ENTER not consumed by TextField when default Button exists

Changes: https://git.openjdk.java.net/jfx/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/jfx/15/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8207759
  Stats: 553 lines in 8 files changed: 528 ins; 20 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15

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

Re: Bug in TreeTableView rendering

2019-10-16 Thread Jeanette Winzenburg 



Zitat von Sverre Moe :


A comment on the JDK-8231644 issue was added by Jeanette Winzenburg
https://bugs.openjdk.java.net/browse/JDK-8231644


hmm .. no testing done but: the data object looks pathological - it's

always problematic to have nodes as data (even though technically
possible). That will explode with the known glitches with
graphics/disclosureNode in treeTableRow

I would like to know more about what you are saying here:

1) That OurDataObject and AlsoOurDataObject as data model/type to
TreeTableView is pathological?

2) "Having nodes as data". Are you referring to using a Label node in the
Column CellValueFactory?
column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(
new OurDataObjectLabel(param.getValue().getValue(;



exactly, _class OurDataObjectLabel extends Label_

is a terrible mixing of data with view - simply don't, they should be  
separated for a reason ..




Instead of using:
column.setCellValueFactory(new TreeItemPropertyValueFactory<>("name"));

The reason we are using OurDataObjectLabel, is because we want to style a
specific type of data determined by AlsoOurDataObject.



suboptimal approach: instead let a custom cell style itself based on content


3) What known glitches?


there are a bunch of bugs (don't have references handy, sry) - search  
the bug parade for Tree/Table/Cell andTree/TableRow

Re: Bug in TreeTableView rendering

2019-10-16 Thread Sverre Moe 
A comment on the JDK-8231644 issue was added by Jeanette Winzenburg
https://bugs.openjdk.java.net/browse/JDK-8231644

> hmm .. no testing done but: the data object looks pathological - it's
always problematic to have nodes as data (even though technically
possible). That will explode with the known glitches with
graphics/disclosureNode in treeTableRow

I would like to know more about what you are saying here:

1) That OurDataObject and AlsoOurDataObject as data model/type to
TreeTableView is pathological?

2) "Having nodes as data". Are you referring to using a Label node in the
Column CellValueFactory?
column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(
new OurDataObjectLabel(param.getValue().getValue(;

Instead of using:
column.setCellValueFactory(new TreeItemPropertyValueFactory<>("name"));

The reason we are using OurDataObjectLabel, is because we want to style a
specific type of data determined by AlsoOurDataObject.

3) What known glitches?

/Sverre