Re: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)

[Phil Race]

On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth  wrote:

> This is a fix for 
> [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable 
> the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the 
> first time they run a JavaFX application and move the mouse is moved into the 
> JavaFX window. It also is reported to block apps from being accepted in the 
> Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional 
> permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, 
> `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently 
> enough (it tracks events delivered to a specific view, whereas the current 
> code is implemented using a global monitor and a global set of touch points), 
> that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running 
> on macOS 10.15 (or later). This will disable the tracking of native touch 
> events, but those events are not used by default on macOS anyway. For Mac 
> systems with a trackpad we instead rely on macOS to do the gesture 
> recognition by default, and this fix does not intefere with that 
> functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the 
> HelloGestures program still runs correctly and still recognizes trackpad 
> gestures such as zoom and rotate. I also verified that the changes don't 
> affect macOS 10.14 or earlier (the Event Tap code is still enabled on those 
> older OS versions).
> 
> See [this 
> thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html)
>  on openjfx-dev for more discussion.

Looks OK to me.

-

Marked as reviewed by prr (Reviewer).

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

Re: RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)

[Kevin Rushforth]

On Thu, 30 Jan 2020 23:07:53 GMT, Kevin Rushforth  wrote:

> This is a fix for 
> [JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable 
> the use of `CGEventTap` when running on macOS 10.15 or later.
> 
> The effect of this bug is that a scary dialog is shown for all users the 
> first time they run a JavaFX application and move the mouse is moved into the 
> JavaFX window. It also is reported to block apps from being accepted in the 
> Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional 
> permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, 
> `NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently 
> enough (it tracks events delivered to a specific view, whereas the current 
> code is implemented using a global monitor and a global set of touch points), 
> that it would be too risky to change it this late in the release.
> 
> For openjfx14, I am proposing to disable touch events completely if running 
> on macOS 10.15 (or later). This will disable the tracking of native touch 
> events, but those events are not used by default on macOS anyway. For Mac 
> systems with a trackpad we instead rely on macOS to do the gesture 
> recognition by default, and this fix does not intefere with that 
> functionality.
> 
> I have verified that this avoids the dialog on macOS 10.15 and that the 
> HelloGestures program still runs correctly and still recognizes trackpad 
> gestures such as zoom and rotate. I also verified that the changes don't 
> affect macOS 10.14 or earlier (the Event Tap code is still enabled on those 
> older OS versions).
> 
> See [this 
> thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html)
>  on openjfx-dev for more discussion.

@arapte can you be one of the reviewers?

-

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

RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)

[Kevin Rushforth]

This is a fix for 
[JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to disable the 
use of `CGEventTap` when running on macOS 10.15 or later.

The effect of this bug is that a scary dialog is shown for all users the first 
time they run a JavaFX application and move the mouse is moved into the JavaFX 
window. It also is reported to block apps from being accepted in the Apple 
store.

This bug is caused by a change in macOS 10.15 to require additional permissions 
for using CGEventTap, which JavaFX uses to track touch events.

The suggested replacement API, `NSEvent::addLocalMonitorForEventsMatchingMask`, 
works just differently enough (it tracks events delivered to a specific view, 
whereas the current code is implemented using a global monitor and a global set 
of touch points), that it would be too risky to change it this late in the 
release.

For openjfx14, I am proposing to disable touch events completely if running on 
macOS 10.15 (or later). This will disable the tracking of native touch events, 
but those events are not used by default on macOS anyway. For Mac systems with 
a trackpad we instead rely on macOS to do the gesture recognition by default, 
and this fix does not intefere with that functionality.

I have verified that this avoids the dialog on macOS 10.15 and that the 
HelloGestures program still runs correctly and still recognizes trackpad 
gestures such as zoom and rotate. I also verified that the changes don't affect 
macOS 10.14 or earlier (the Event Tap code is still enabled on those older OS 
versions).

See [this 
thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html)
 on openjfx-dev for more discussion.

-

Commits:
 - d6109fb1: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 
(Catalina)

Changes: https://git.openjdk.java.net/jfx/pull/102/files
 Webrev: https://webrevs.openjdk.java.net/jfx/102/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231513
  Stats: 71 lines in 1 file changed: 26 ins; 6 del; 39 mod
  Patch: https://git.openjdk.java.net/jfx/pull/102.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/102/head:pull/102

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

Re: RFR: 8237770: Error creating fragment phong shader on iOS

[Kevin Rushforth]

On Fri, 24 Jan 2020 11:31:02 GMT, Jose Pereda  wrote:

> This PR defines a pre-processor in the phong frag files to avoid inline 
> declaration of #extension when several frags are combined that leads to the 
> error:
> 
> syntax error: #extension must always be before any non-preprocessor tokens

I verified that this works correctly. I have a minor style comment for you to 
consider.

modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/diffuse_color.frag
 line 32:

> 31: #extension GL_OES_standard_derivatives : enable
> 32: #define EXTENSION_APPLIED
> 33: #endif

Usual practice is to put the `#define` right after the `#ifndef`, but I don't 
have a strong opinion about that.

-



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

Re: [Rev 01] RFR: 8237944: webview native cl "-m32" unknown option for windows 32-bit build

[Kevin Rushforth]

On Wed, 29 Jan 2020 15:36:52 GMT, Guru Hb  wrote:

>> Marked as reviewed by kcr (Lead).
> 
>> the -m32 option seems to be ignored by the compiler:
>> cl : Command line warning D9002 : ignoring unknown option '-m32'
>> 
>> However, I agree it is better to conditionally remove it.
> "-m32" required for compiling other ports of webkit (WebkitGTK, WPE) and for 
> our platform I haven't tested this feature (i.e cross compiling on a 64 bit 
> Linux).

@guruhb this is ready to integrate unless @johanvos wants to review it.

-

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

Re: RFR: 8237782: Only read advances up to the minimum of the numHorMetrics or the available font data.

[Kevin Rushforth]

On Fri, 24 Jan 2020 17:08:42 GMT, Phil Race  wrote:

> … the available font data.

Looks like GitHub truncated your title, so I fixed it to match the JBS title.

-

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

RFR: 8231513: JavaFX cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)

[Kevin Rushforth]

The Skara bot isn't sending email at the moment, so here is an RFR for 
jfx14:


PR: https://github.com/openjdk/jfx/pull/102
JBS: https://bugs.openjdk.java.net/browse/JDK-8231513

This is a fix for 
[JDK-8231513](https://bugs.openjdk.java.net/browse/JDK-8231513) to 
disable the use of `CGEventTap` when running on macOS 10.15 or later.


The effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch events.


The suggested replacement API, 
`NSEvent::addLocalMonitorForEventsMatchingMask`, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in the 
release.


For openjfx14, I am proposing to disable touch events completely if 
running on macOS 10.15 (or later). This will disable the tracking of 
native touch events, but those events are not used by default on macOS 
anyway. For Mac systems with a trackpad we instead rely on macOS to do 
the gesture recognition by default, and this fix does not intefere with 
that functionality.


I have verified that this avoids the dialog on macOS 10.15 and that the 
HelloGestures program still runs correctly and still recognizes trackpad 
gestures such as zoom and rotate. I also verified that the changes don't 
affect macOS 10.14 or earlier (the Event Tap code is still enabled on 
those older OS versions).


See [this 
thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024876.html) 
on openjfx-dev for more discussion.


-- Kevin

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Mike Hearn]

I'm afraid I disagree. My eyesight isn't great and I like to zoom web apps
to sizes that most designers would consider wrong/bad/absurd, at least when
possible. How far I can go depends a lot on the app. Many modern desktop
apps feel far too dense and with fonts that are uncomfortably small for me.
I much prefer desktop/JavaFX apps for various reasons, but in this regard
the web wins - I can blow the sizes up nice and big, and things mostly just
work. Hence my interest in replicating this feature.

It's annoying because it feels like it's surely possible and even easy, but
that the knowledge of how to do it probably only exists in the heads of
five people. JavaFX can scale widgets to handle variable dpi, scale
transforms and other features. This one doesn't seem like a stretch. I'd
rather get an authoritative tip before diving into Glass to try and reverse
engineer it all from the code.




On Thu, Jan 30, 2020 at 16:59:54, Michael Paus  wrote:

> I am wondering whether this kind of scaling should actually be done on an
> application basis. On desktop computers this is normally achieved via some
> system setting of the monitor scaling. I think most people just want a
> consistent scaling across all applications and so there is just no need in
> general for an individual scaling. Just for very specific cases this may be
> useful, e.g., to scale the text size of an editor window in Eclipse where
> this can be done like in a browser via Cmd+/-. In a browser you only need
> this feature because web-sites are so inconsistent in their styling, which
> is normally not the case for desktop applications.
>
> Just my two €ent
>
> Am 30.01.20 um 17:29 schrieb Mike Hearn:
>
> Yes, a scale transform doesn't affect layout. That's the issue. Browser
> zoom scales fonts, images and widgets but in a way that affects layout
> bounds, not only render bounds.
>
> As far as I can tell there's no way to do a zoom or scale that affects
> layout bounds with the public JavaFX API. Exploring why not and what could
> work is how I ended up getting a bit lost in the weeds of all the different
> scale factors. It *feels* like one of them should be applicable if only it
> was public API. But I can't quite figure out which or how exactly it'd
> work. If nobody else has ever examined this task (it seems not) then I
> guess I can just compile my own JFX and experiment with forcing the
> different factors and ratios to see what happens. I'm not sure the results
> would be stable or portable though.
>
> On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
> wrote:
>
> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -Original Message-
> From: openjfx-dev  On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at   EDV
> Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Kevin Rushforth]

My obvious attempt failed to get any touch events delivered to the app. 
There is also code in GestureRecognizers (internal to glass) to register 
listeners for touch events that will then in some cases be turned into 
gestures, but it's disabled by default.


So it really does look like we are generating these low level macOS 
events for no purpose other than to cause the warning dialog on Catalina.


I'll do some more testing and will likely send out a PR for review to 
disable the low-level touch events on macOS 10.15 or later (option #2 
below). I'll also file a follow-up issue for 15 to fix it.


-- Kevin


On 1/30/2020 11:52 AM, Kevin Rushforth wrote:
Yeah, I was surprised, too. I can see the low level touch events being 
generated and passed up to the Java code, but I haven't actually 
verified yet that it turns them into JavaFX TouchEvents that get 
delivered to an application (I'll try that this afternoon).


-- Kevin


On 1/30/2020 10:55 AM, Michael Paus wrote:
In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't 
miss them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that

someone has ever used them.

Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
This affects TouchEvents generated via low-level native touch 
events, including those generated by a trackpad. GestureEvents still 
work. In particular, the HelloGestures app still works: even with 
low-level touch events disabled, I can use the trackpad to rotate 
and zoom and the app picks it up fine.


Mouse events, including trackpad scrolling events, are not affected 
at all by this.


-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
Just to clarify the implications of this issue: Are you only 
talking about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and 
synthesized MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
The effect of this bug is that a scary dialog is shown for all 
users the first time they run a JavaFX application and move the 
mouse is moved into the JavaFX window. It also is reported to 
block apps from being accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require 
additional permissions for using CGEventTap, which JavaFX uses to 
track touch events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just 
differently enough (it tracks events delivered to a specific view, 
whereas the current code is implemented using a global monitor and 
a global set of touch points), that it would be too risky to 
change it this late in the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 
14, I wanted to get some input from Mac users on the list. I can 
think of the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but 
I don't really like that idea, and I'm not sure how useful it 
would be anyway since setting that flag would cause the scary 
dialog again.
3. Defer enabling of touch events until the first time the 
application requests them -- this would require new interfaces in 
Glass, isn't risk free, and doesn't solve the dialog problem for 
those apps that do use touch.


I'm leaning towards option #2 (without the system property to 
force enable it), but wanted to get a sense from app developers as 
to whether that would be more of a problem than doing nothing 
(i.e., option #1). I only listed option #3 for completeness, since 
it doesn't really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

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

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Kevin Rushforth]

Yeah, I was surprised, too. I can see the low level touch events being 
generated and passed up to the Java code, but I haven't actually 
verified yet that it turns them into JavaFX TouchEvents that get 
delivered to an application (I'll try that this afternoon).


-- Kevin


On 1/30/2020 10:55 AM, Michael Paus wrote:
In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't 
miss them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that

someone has ever used them.

Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level 
touch events disabled, I can use the trackpad to rotate and zoom and 
the app picks it up fine.


Mouse events, including trackpad scrolling events, are not affected 
at all by this.


-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and 
synthesized MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
The effect of this bug is that a scary dialog is shown for all 
users the first time they run a JavaFX application and move the 
mouse is moved into the JavaFX window. It also is reported to block 
apps from being accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just 
differently enough (it tracks events delivered to a specific view, 
whereas the current code is implemented using a global monitor and 
a global set of touch points), that it would be too risky to change 
it this late in the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 
14, I wanted to get some input from Mac users on the list. I can 
think of the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but 
I don't really like that idea, and I'm not sure how useful it would 
be anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the 
application requests them -- this would require new interfaces in 
Glass, isn't risk free, and doesn't solve the dialog problem for 
those apps that do use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it 
doesn't really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

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

Re: How to build standalone openJFX modules for uploading to a local maven repository

[Matthias Bläsing]

Hi Danny,

Am Dienstag, den 28.01.2020, 09:50 + schrieb Danny Gonzalez:
> We have a java 11 project that uses maven to pull in openJFX
> modules  i.e. javafx-controls, javafx-web, javafx-swing.
> 
> What we would like to do is build our own versions of these openJFX
> modules for use as maven dependencies which use a fork of openJFX
> (which we build locally to fix up some bugs).
> 
> I can’t however see an obvious way of building these openJFX
> standalone modules for deploying in our local maven repository in the
> same way that they were originally built for uploading into maven
> central.
> 
> Is this documented anywhere?
> 

I would have a look at the publishMaven* tasks:

> bash gradlew tasks

[...]
Publishing tasks

[...]
publishMavenPublicationToMavenRepository - Publishes Maven publication 'maven' 
to Maven repository 'maven'.
publishToMavenLocal - Publishes all Maven publications produced by this project 
to the local Maven cache.
[...]

If I remember correctly, these tasks required a prior full build.

HTH

Matthias

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Michael Paus]

In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't miss 
them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that

someone has ever used them.

Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level 
touch events disabled, I can use the trackpad to rotate and zoom and 
the app picks it up fine.


Mouse events, including trackpad scrolling events, are not affected at 
all by this.


-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
The effect of this bug is that a scary dialog is shown for all users 
the first time they run a JavaFX application and move the mouse is 
moved into the JavaFX window. It also is reported to block apps from 
being accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just 
differently enough (it tracks events delivered to a specific view, 
whereas the current code is implemented using a global monitor and a 
global set of touch points), that it would be too risky to change it 
this late in the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, 
I wanted to get some input from Mac users on the list. I can think 
of the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but I 
don't really like that idea, and I'm not sure how useful it would be 
anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the 
application requests them -- this would require new interfaces in 
Glass, isn't risk free, and doesn't solve the dialog problem for 
those apps that do use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it 
doesn't really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

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

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Kevin Rushforth]

This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level touch 
events disabled, I can use the trackpad to rotate and zoom and the app 
picks it up fine.


Mouse events, including trackpad scrolling events, are not affected at 
all by this.


-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set 
of touch points), that it would be too risky to change it this late 
in the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, 
I wanted to get some input from Mac users on the list. I can think of 
the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but I 
don't really like that idea, and I'm not sure how useful it would be 
anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the 
application requests them -- this would require new interfaces in 
Glass, isn't risk free, and doesn't solve the dialog problem for 
those apps that do use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it 
doesn't really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

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

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Michael Paus]

Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in 
the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
wanted to get some input from Mac users on the list. I can think of 
the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but I 
don't really like that idea, and I'm not sure how useful it would be 
anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the application 
requests them -- this would require new interfaces in Glass, isn't 
risk free, and doesn't solve the dialog problem for those apps that do 
use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it doesn't 
really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

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

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Sebastian Stenzel]

> To: Mac app developers / users
> 
> I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke Receiving 
> prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The effect of this 
> bug is that a scary dialog is shown for all users the first time they run a 
> JavaFX application and move the mouse is moved into the JavaFX window. It 
> also is reported to block apps from being accepted in the Apple store.
> 
> This bug is caused by a change in macOS 10.15 to require additional 
> permissions for using CGEventTap, which JavaFX uses to track touch events.
> 
> The suggested replacement API, NSEvent::addLocalMonitorForEventsMatchingMask, 
> works just differently enough (it tracks events delivered to a specific view, 
> whereas the current code is implemented using a global monitor and a global 
> set of touch points), that it would be too risky to change it this late in 
> the release.
> 
> Since there isn't an easy / safe fix that is feasible for JavaFX 14, I wanted 
> to get some input from Mac users on the list. I can think of the following 
> possibilities for JavaFX 14:
> 
> 1. Do nothing (defer the bug to FX 15)
> 2. Disable touch events completely if running on macOS 10.15 (or later) -- we 
> could consider a system property to re-enable it, but I don't really like 
> that idea, and I'm not sure how useful it would be anyway since setting that 
> flag would cause the scary dialog again.
> 3. Defer enabling of touch events until the first time the application 
> requests them -- this would require new interfaces in Glass, isn't risk free, 
> and doesn't solve the dialog problem for those apps that do use touch.
> 
> I'm leaning towards option #2 (without the system property to force enable 
> it), but wanted to get a sense from app developers as to whether that would 
> be more of a problem than doing nothing (i.e., option #1). I only listed 
> option #3 for completeness, since it doesn't really solve the issue.
> 
> Whatever we do for 14, the solution for 15 will very likely be to switch to 
> tracking per-View (per Window) touch events, either directly, or maybe using 
> local event monitoring.
> 
> -- Kevin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8231513 
> 
I'd also vote for #2 as a quickly available workaround (not as a long-term fix, 
though). Here are my thoughts:

Are there any (non-hackintosh) devices running macOS that have touch screens at 
all? Recent MacBooks have this thing called Touch Bar, which caused problems 
with JavaFX apps in the past (touching it crashed the application - is this 
related?). I'm not even sure why the touch event handling exists on macOS in 
the first place. Is it only the attempt to implement a Glass API that is 
intended for different device classes?

Maybe touch events are facilitated by applications that register events on 
third party devices like graphics tablets. If there are applications out there 
using it, we should have some flag to reenable it (despite the "scary dialog"). 
Otherwise I think it is fair to just disable it all together.

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Michael Paus]

I am wondering whether this kind of scaling should actually be done on
an application basis. On desktop computers this is normally achieved via
some system setting of the monitor scaling. I think most people just want
a consistent scaling across all applications and so there is just no need
in general for an individual scaling. Just for very specific cases this may
be useful, e.g., to scale the text size of an editor window in Eclipse
where this can be done like in a browser via Cmd+/-. In a browser you
only need this feature because web-sites are so inconsistent in their
styling, which is normally not the case for desktop applications.

Just my two €ent


Am 30.01.20 um 17:29 schrieb Mike Hearn:

Yes, a scale transform doesn't affect layout. That's the issue. Browser
zoom scales fonts, images and widgets but in a way that affects layout
bounds, not only render bounds.

As far as I can tell there's no way to do a zoom or scale that affects
layout bounds with the public JavaFX API. Exploring why not and what could
work is how I ended up getting a bit lost in the weeds of all the different
scale factors. It *feels* like one of them should be applicable if only it
was public API. But I can't quite figure out which or how exactly it'd
work. If nobody else has ever examined this task (it seems not) then I
guess I can just compile my own JFX and experiment with forcing the
different factors and ratios to see what happens. I'm not sure the results
would be stable or portable though.




On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
wrote:


I think that can not work because layouts don't take the scale factor into
account nor does stuff like ScrollView but i could be wrong.

Tom

On 27.01.20 17:29, David Grieve wrote:

Wouldn't this just be a scale transform?

-Original Message-
From: openjfx-dev  On Behalf Of
Mike Hearn
Sent: Monday, January 27, 2020 11:00 AM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?

Hello,

A feature I often miss when using non-web GUIs is support for browser
style zooming. In JavaFX it is quite easy to specify all font sizes in
terms of "ems", relative sizes ("largest") or percentages and then adjust
the base font size on a root node inside key handlers. This works OK but
doesn't do much for images or other controls, and of course most JavaFX GUI
code specifies sizes in terms of pixels.

There are various scaling factors applied to pixel sizes. There is the
per-node scaling transform, but this doesn't affect layout so isn't
comparable to what browsers do. There's a per-screen DPI, there's a
"platform scale", there's a
"render scale" and then there's a "ui scale". These seem related to
hidpi/retina support and are all internal (for the purposes of this
question I'm happy to modify JavaFX itself).

Render scale seems to affect resolution without affecting positions or
layout, so that's not quite what I want. UI scale sounds promising but
isn't documented and I couldn't quite figure it out by reading the code,
though I could just fiddle with it and see what happens.

It feels like someone probably explored this before now. Is there a way to
effectively expand the size of every node without altering the size of the
containing viewport, to get browser-style layout affecting zoom? If not,
has anyone explored the complexity of the modifications required?

thanks,
-mike

--
Tom Schindl, CTO
BestSolution.at  EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Kevin Rushforth]

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in the 
release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
wanted to get some input from Mac users on the list. I can think of the 
following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or later) 
-- we could consider a system property to re-enable it, but I don't 
really like that idea, and I'm not sure how useful it would be anyway 
since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the application 
requests them -- this would require new interfaces in Glass, isn't risk 
free, and doesn't solve the dialog problem for those apps that do use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to whether 
that would be more of a problem than doing nothing (i.e., option #1). I 
only listed option #3 for completeness, since it doesn't really solve 
the issue.


Whatever we do for 14, the solution for 15 will very likely be to switch 
to tracking per-View (per Window) touch events, either directly, or 
maybe using local event monitoring.


-- Kevin

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

Windows: Mnemonics Issue

[Abhinay Agarwal]

On Windows, mnemonics is activated when ALT is pressed. This is true for apps 
made in JavaFX.

However I have found the following discrepancy between Windows Native Apps and 
JavaFX apps:

In Windows, pressing any key(not assigned to mnemonics) in combination with ALT 
doesn't de-activates mnemonics. It is automatically deactivated
when ALT is released. This can be reproduced in Notepad.
However in JavaFX, pressing ALT activates mnemonics. If any key (not assinged 
to mnemonics) is pressed while ALT is being pressed, it deactivates mnemonics. 
This can lead to an unwanted state.

This can be tested by the following steps:

1. Open Notepad -> Type ALT + A. Nothing happens. Once ALT is released, 
mnemonics is de-activated on the MenuBar.
2. Run the attached JavaFX sample. Press ALT -> mnemonics activated. Press 'ALT 
+ A' -> mnemonics activates and then de-activates.
If you continue tapping 'A' (with ALT pressed), we can see that mnemonics are 
activated and deactivated. If we leave the mnemonics in activated state and try 
to
enter text 'F' in textfield, it will show the MenuItem(s) in the 'File' Menu.

Sample
===


import javafx.application.Application;

import javafx.stage.Stage;

import javafx.scene.Scene;

import javafx.scene.control.Menu;

import javafx.scene.control.MenuBar;

import javafx.scene.control.MenuItem;

import javafx.scene.control.TextField;

import javafx.scene.layout.BorderPane;

public class MenuBarMnemonics extends Application {

@Override

public void start(Stage primaryStage) {

BorderPane root = new BorderPane();

MenuBar b = new MenuBar();

Menu file = new Menu("_File");

MenuItem fileTest = new MenuItem("Tes_t");

file.getItems().add(fileTest);

b.getMenus().add(file);

Menu edit = new Menu("_Edit");

MenuItem editTest = new MenuItem("Te_st");

edit.getItems().add(editTest);

b.getMenus().add(edit);

root.setTop(b);

root.setCenter(new TextField());

Scene scene = new Scene(root,400,400);

primaryStage.setScene(scene);

primaryStage.show();

}

}

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Mike Hearn]

Yes, a scale transform doesn't affect layout. That's the issue. Browser
zoom scales fonts, images and widgets but in a way that affects layout
bounds, not only render bounds.

As far as I can tell there's no way to do a zoom or scale that affects
layout bounds with the public JavaFX API. Exploring why not and what could
work is how I ended up getting a bit lost in the weeds of all the different
scale factors. It *feels* like one of them should be applicable if only it
was public API. But I can't quite figure out which or how exactly it'd
work. If nobody else has ever examined this task (it seems not) then I
guess I can just compile my own JFX and experiment with forcing the
different factors and ratios to see what happens. I'm not sure the results
would be stable or portable though.




On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
wrote:

> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -Original Message-
> From: openjfx-dev  On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at  EDV Systemhaus GmbH
> Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Should Skara tooling invalidate approvals when new commits are pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]

[Kevin Rushforth]

Hearing no objections, we will enable this for pull requests on the jfx 
repo starting Tuesday, Feb 4.


-- Kevin


On 1/8/2020 11:34 AM, Kevin Rushforth wrote:
Does anyone strongly feel otherwise? If not, then I'll request the 
Skara team to enable this feature.


-- Kevin


On 1/8/2020 11:26 AM, Johan Vos wrote:
I agree. If the fix is trivial, the time for the reviewer will be 
really short. The more complex the fix, the more time it will take -- 
with the risk of being delayed to the next release.
The github interface makes it very easy to inspect the new commit, 
hence a typo in javadoc can easily be fixed and re-approved.


I think this approach is safer than the approach were "trivial" fixes 
don't need re-approval, as that approach leaves more room for 
interpretation (and probably even more interactions with the 
reviewers ("is this a trivial fix?")).


- Johan

Op wo 8 jan. 2020 om 19:34 schreef Nir Lisker >:


    Looks like an all-or-nothing situation - either any commit requires
    re-approval or no commit requires re-approval. In this case, I
    would say
    that all commits should require re-approval since it's the safer
    approach.
    Having the issue stay in approved state after a significant change
    is much
    worse than requiring the reviewers to take a look at an 
insignificant

    commit and re-approve. The time is takes for a reviewer to go over a
    comment or formatting change is short and, I believe, not 
intrusive to

    their workflow.

    On Tue, Dec 31, 2019 at 7:48 PM Kevin Rushforth
    mailto:kevin.rushfo...@oracle.com>>
    wrote:

    > Since this isn't directly related to the PR in question, I'm
    starting a
    > new thread.
    >
    > On 12/20/2019 7:22 PM, Philip Race wrote:
    > > On 12/20/19, 7:04 PM, Scott Palmer wrote:
    > >> I'm not sure if I'me supposed to try to integrate now that
    I've made
    > >> that 10 ->  0 change, or if the new change resets the need
    for review...
    > >
    > > It shows ready, which surprises me.
    > > Still learning skara .. I'd expect any change to reset as how
    can it
    > > know if it is
    > > a  good or insignificant change or not no matter how the 
commenter

    > > characterised the issue ?
    >
    > Pushing a new commit doesn't automatically invalidate existing
    > approvals, although it is highlighted in the "Approvers" section
    that
    > the approval was for a prior commit:
    >
    >      Approvers
    >          Phil Race (prr - Reviewer) Note! Review applies to 
f846ad6

    >
    > I remember bringing this up with the Skara team during my initial
    > testing, since I also had wondered whether pushing a new commit
    should
    > invalidate approvals. The current policy allows for doing
    trivial fixes
    > brought up when approving a review (e.g., a change in a comment or
    > formatting) without requiring all reviewers to re-approve. It
    matches
    > current practice for email-based reviews, so I think the current
    > behavior is a reasonable default.
    >
    > They did say that they could implement an optional feature 
(i.e., a

    > project would need to opt-in to this behavior, probably via a
    > .jcheck/conf property) to invalidate all approvals upon pushing
    a new
    > commit, but I don't think an RFE was filed to track it.
    >
    > This seems like it could be a valuable feature, although it does
    come
    > with a slight cost in terms of timing and flexibility. What do
    others
    > think?
    >
    > -- Kevin
    >
    >

Re: [Rev 04] RFR: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size

[Ambarish Rapte]

On Thu, 30 Jan 2020 08:15:48 GMT, Frederic Thevenet 
 wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown 
>> from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of 
>> maxTextureSize^2 dimensions (or less, as needed), and then recomposes all 
>> the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file 
>> named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " 
>> java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> The pull request has been updated with 1 additional commit.

With my basic testing, the change looks good, scaled up and scaled down 
snapshots seem correct visually.

After this change the tiled snapshot will be limited by dimensions of the 
`WritableImage`.
We can not create a `WritableImage` of dimension `(8192 * 3, 8192 * 3)` or 
greater.
`new WritableImage(8192 * 3, 8192 * 3)`  causes an exception.
java.lang.IllegalArgumentException: capacity < 0: (-1879048192 < 0)
at java.base/java.nio.Buffer.createCapacityException(Buffer.java:257)
This is an existing behavior of `WritableImage`.
May be we should consider to wrap and re-throw the exception and update the API 
JavaDoc.
Anyway not a stopper for this PR.
Approving.

-

Marked as reviewed by arapte (Reviewer).

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